要約

  • RFC 9966のTLS-POKでは、サーバーは端末のBSK公開鍵を知ることを、端末は対応する秘密鍵を持つことを相互に示す。
  • その公開鍵がサーバーへ届いた経路、端末との結び付き、正当な保有者かどうか、ネットワークへの許可は、プロトコルが引き受けない別の判断である。

新しい機器を企業網へ入れる場面では、資格情報を得るために接続が要り、接続には資格情報が要るという循環が生じる。Dan HarkinsとOwen FrielのRFC 9966は、有線ネットワークでその最初の結び目を解くTLS Proof of Knowledge、TLS-POKを定義した。出発点は楕円曲線のBootstrap Key、BSKである。

BSKには公開鍵と秘密鍵がある。秘密鍵は端末だけが知り、公開鍵は端末とその所有者または保有者が知ったうえで、TLSサーバーの運用者がサーバーに登録する。TLS 1.3の交換では、サーバーが公開鍵を知ることを端末に示し、端末が私鍵を持つことをサーバーに示す。EPSKは公開鍵から導かれ、端末はraw public keyで認証に加わる。ここで確かになるのは鍵材料についての限定された知識であり、物の来歴ではない。

RFCはもっとも重要な前段を範囲外と呼ぶ。サーバーがBSK公開鍵を得る正確な手段は定めない。QRコードの読取りや部品表（BOM）のアップロードを例として挙げるだけである。端末にQRラベルが物理的に付いている場合、物理的な所持を正当な所有とみなすモデルも示す。これはオンボーディングを始めるための仮定であって、TLSが購入、譲渡、ラベルの真正性、保管責任を検証したという意味ではない。

その区別は脅威モデルにも現れる。クライアント側の信頼は、BSK公開鍵が広く漏れていないことに依存する。攻撃者がこの公開鍵を知り、端末を自分のサーバーへ誘導できれば、攻撃者のネットワークに対してTLS-POKを完了させられる。また、もっと早い段で正規端末の鍵を不正端末の公開鍵へ差し替えれば、正規のサーバーが不正端末をオンボードしてしまい得る。交換記録が矛盾なくても、渡された入力の保管経路が正しかったとは限らない。

実装上の線引きも明快だ。端末はServerHelloを処理してTLSの鍵スケジュールを検証するまでBSK公開鍵を送ってはならず、PSKの検証に失敗したら送らずに終了する。製造者には端末ごとに固有のBSKが推奨される。共通BSKを複数端末で使うと、運用者は端末を区別できず、特定の許可済み端末だけを接続させる保証も持てない。これは鍵の露出と識別を扱う規則であり、資産台帳の代替ではない。

TLS-POKの後、サーバーは後続EAP認証用の資格情報を端末へ配布できる。BSKはその後ずっと使う資格情報ではなく、RFCではbootstrapだけに用いる。したがって、公開鍵の取得、サーバー登録、TLSの結果、資格情報の発行、EAPの判断、実際のポートでの執行は、つながってはいても同じ証拠ではない。成功したハンドシェイク一つに後続の全責任を背負わせることはできない。

IETFの公開プロフィールはHarkinsとRFC 9966の関係を示し、IEEE 802.11の表彰写真は人物肖像の本人性参照になる。どちらも個人が実際の端末群や網を統治している証拠ではない。この仕様の価値は、最初の証明を役立つものにしつつ、それが自分で保管経路を作ったかのように見せない点にある。

出典