要約

  • RFC 3079のマスター値は次の導出にだけ使われ、実際の送受信コンテキストは役割と方向ごとに作られた一時鍵で初期化された。
  • テストベクトルとの一致が示すのは計算の一致だけである。両端が同じ最初の認証、補完関係にある方向、同じMPPE強度を選び、アプリケーションまで届けたことは別に証明する必要があった。

最上位の名前、途中の役割

仕様は、マスターセッションキーをデータの暗号化にも復号にも使わないと明記した。MS-CHAP-2では、パスワード由来の二重ハッシュとNT-Responseからマスター値を作る。次にGetAsymmetricStartKeyが、送信か受信か、ローカル側がサーバーかという二つの条件で枝を選ぶ。GetNewKeyFromSHAが一時鍵を作り、そこで初めてRC4テーブルに入る。

したがって「マスターキー導出成功」というログは早すぎる。どの枝を選び、どちらの方向へ入れ、相手が補完する枝を選んだかを示さない。同じ実装が両端で正常終了しても、役割を二重にサーバーと判断すれば通信は成立しない。

RFC 3079は2001年3月にInformational RFCとして公開され、Microsoft製品との相互運用に必要な参照を第三者へ開くことを目的とした。CCP交渉、MPPEパケット、セッション中の鍵更新はRFC 3078の範囲であり、公開はInternet Standardや実装実績を意味しなかった。

認証方式は結果の中に残る

MS-CHAP-1の40・56ビット系はLAN Managerパスワードハッシュから、128ビット系はWindows NTパスワードハッシュとチャレンジから始まった。MS-CHAP-2は全強度でWindows NT系統とNT-Responseを使った。EAP-TLSはTLSからエクスポートされたマスターシークレットを起点にした。

同じMPPE鍵へ到達しても、証拠は同じではない。認証方式、発呼側、採用した最初の認証、チャレンジ／レスポンスまたはTLS世代、対象リンクを残す必要がある。8オクテットという事実だけでは40ビットと56ビットを区別できない。

RFC 2759はMS-CHAP-2の二種類のチャレンジ、ChallengeHash、NT-Response、AuthenticatorResponseを定義した。RFC 2433は旧方式を、RFC 2716はPPP内のEAP-TLSを定義した。いずれも上流入力を示すが、CCPがOpenedになった証明ではない。

「最初」が分散状態になる

両方向の初期鍵は、呼を開始したピアの資格情報から導出する。チャレンジを使う場合は最初の認証のものを選ぶ。この規則は相互認証でも、multilink bundleの各リンクでも変わらない。

分散システムでは、この「最初」が失われやすい。認証サービスが最後の成功だけを保存し、bundle制御が元のチャレンジを捨て、待機系シャーシがユーザー名と成功フラグだけを受け取ることがある。数式は正しくても、歴史が違えば答えは違う。

RFCはmulti-chassis multilinkで、全参加機器が正しい鍵を生成する責任を実装側に置いた。アルゴリズム自体は状態を配布しない。セッション識別子には、認証イベント、役割、リンク、導出世代まで必要だった。

こちらの送信は、あちらの受信

GetAsymmetricStartKeyの固定ラベルは両端を交差させる。サーバー送信用の枝はクライアント受信用の枝と対応し、逆方向も同様である。EAP-TLS節は「一方のsend keyは他方のreceive key」と明記した。

そのため、ある機器のsend_keyを相手のsend_keyへコピーしてはいけない。名前はローカル、関係は二者間にある。秘密を記録せず、端点、client/server役割、ローカル方向、相手方向、認証世代と一時鍵の指紋を結ぶ必要がある。

強度も単なる長さではない。40ビットは8オクテットの先頭3オクテットを固定値で上書きし、56ビットは先頭1オクテットを上書きする。128ビットは16オクテットである。EAP-TLSでは短い値を左ゼロ詰めし、長い値を切り詰めた。同じ最終長は同じ来歴を意味しない。

テストベクトルは算術を検査できるが、実セッションの来歴や安全な受け渡し、交渉結果までは検査しない。RFC自身も、MS-CHAP-1の40ビット初期鍵が同じ資格情報で反復することを警告した。これは歴史分析であり、RC4や旧MS-CHAPを現在推奨するものではない。

導出の先にサービスがある

RFC 3078はMPPE送信前にPPPのNetwork-Layer Protocol段階とCCP Openedを要求した。RFC 2548はRADIUSによる方向別鍵の運搬と、プロキシが担う保管境界を扱った。RFC 1661はPPPの段階を分けた。

認証成功、秘密の到着、正しいリンクへの割り当て、方向対応、CCP交渉、同期した復号、アプリケーション処理は別々の受領証である。Lu Hengの現実レイヤーの視点は、「master」「send」「authenticated」「128-bit」という記号を実行上の結果と混同させない。

RFC 3079の歴史的価値は、相互運用の最小条件に来歴を含めたことにある。導出成功は次の検証へ進む資格であり、サービス完了の証明ではない。

出典