要約

  • draft-ietf-emu-eap-ppt-04は、前版が外側のTLSエクスポーターから導出していた128オクテットを削除し、EAP-PPTはMSKもEMSKも生成しないと明記した。
  • Privacy PassトークンはTLSトンネル内で渡されるベアラー資格情報である。トンネル終端者はトークンを読め、同じエクスポーター値も計算できるため、その値はトークン保持者と終端者が同一だと証明しない。

エクスポーターは壊れていなかった。指定どおり128オクテットを返した。問題は、その出力に「内側の当事者もこのTLSセッションに暗号学的に参加した」という意味を与えようとしたことにある。

EAP-PPT第03版は、外側のTLSトンネルからEXPORTER_EAP_PPT_Key_Materialというラベルで値を導出した。コンテキストにはEAP Typeと償還済みトークンが入り、128オクテットはMSKとEMSKとして扱える設計だった。外形だけを見れば、内側のEAP方式が独自の鍵材料を提供したように映る。

9月30日付の第04版は、この構成を取り除いた。EAP-PPTはMSKもEMSKも出力せず、トンネル方式に鍵材料を報告してはならない。削除は機能の後退ではない。機構が裏付けられない保証を、APIやログに残さないための修正である。

ベアラートークンは内側の秘密を共有しない

EAP-PPTはトンネル内で使うEAP方式だ。ピアは発行者から帯域外でPrivacy Passトークンを取得し、別のEAP方式が作るサーバー認証済みTLSトンネルに入り、EAP-PPTサーバーへトークンを送って償還する。

公開検証型なら、サーバーは発行者の公開鍵でトークンを確認する。非公開検証型なら、発行者とEAP-PPTサーバーが共有する材料を使う。いずれもピアとサーバーの間に新しい共有秘密を作らない。ピアが示すのは、転送可能なベアラー資格情報を手元に持つことだ。

一方、TLSエクスポーターは外側のセッションに属する。トンネルを終端した主体なら同じ値を計算できる。しかもトークンはそのトンネル内を通るので、終端者はエクスポーターのコンテキストに使われるトークンも見る。コンテキストへトークンを足せば導出を区別できるが、終端者に隠された入力が増えるわけではない。

値はセッションごとに異なり、正しいラベルを持ち、十分に長くてもよい。それでも「誰が内側だけの秘密を寄与したか」という問いには答えられない。独占的な寄与がない以上、ランダムに見える128オクテットは本人性の代用品にならない。

外側のTLSだけでは内側の主体を証明できない

この誤解はTEAPのCrypto-Bindingで深刻になる。TEAPはトンネルと内側方式の鍵材料を組み合わせ、両者の結び付きを検査できる。しかし内側から来たように見える値が、実は同じトンネルと終端者に見えるトークンだけから作られていれば、二つの独立した証明を結合したことにはならない。

第04版は、この点を明示する。古い値を報告すると、トンネル方式はCrypto-Binding TLVを計算できるが、EAP-PPTがトンネルへ暗号学的に結び付いた保証は生まれない。メッセージ列には二つの寄与者がいるように見えても、すべての入力を持つ者は一人である。

修正後の境界は明快だ。EAP-PPTはトークンの償還によってピアを認可するが、リンクの鍵は作らない。リンク鍵は外側のトンネル型EAP方式から得る。製品がEAP-PPTについてMSKやエクスポーター由来の欄を表示するなら、それは新しい保証ではなく、削除済みの曖昧さを復活させている。

鍵を持たない内側方式ではリレー対策が変わる

内側の暗号学的結合がない場合、サーバー証明書の厳格な検証がリレーに対する第一防線になる。攻撃者のTLSトンネルをピアが正当だと誤認すれば、攻撃者はEAP-PPTの交換を本物のサービスへ中継し、ベアラートークンを観察して自分のアクセスに使える。

そのため草案は、ネットワークごとに期待されるEAPサーバーの証明書を厳密に検証するよう求める。名前が一致しなければ利用者に判断を委ねず拒否し、TOFUにも頼らない。Privacy Pass challengeのorigin_infoを証明書の識別名と照合すればchallenge差し替えを制約できるが、内側の鍵材料を生むものではない。

サーバー配置も信頼設計の一部だ。EAPサーバーとEAP-PPTサーバーを同居させれば、提供者内部で利用されうる分離面が一つ減る。Phase 1とPhase 2のサーバーを分ける構成は、両者の関係と通信路を保護しない限り推奨されない。単なる性能や運用上の配置問題ではない。

Channel bindingは、ピアが参加したと思うネットワークとサーバー側のauthenticator情報が一致しない状況を見つけられる。短命トークンは被害時間を狭め、二重使用検出は事後にリレーの兆候を示せる。それぞれ有用だが、削除された値にトークン保持者の連続性を付与する機能ではない。

コンテキスト判定より先にトークンは使用済みになる

第04版には、成功率の集計だけでは見えにくい順序の規則も加わった。トークンを正常に償還した後、EAP-PPTサーバーはEAP Successの前にEAP-Request/PPT-Channel-Bindingを送れる。以前のEAP方式が必要な情報を既に提供した場合、この要求を省略することもある。

ピアがその要求を受け取った時点で、トークンは受理され、使用済みである。後でchannel-binding応答が不正と判定されても、EAPエラーになっても、最終的なネットワークアクセスが失敗しても、トークンは再利用できない。償還前のエラーに適用される再試行規則は、消費後には戻らない。

従って「使用済み」は限定された受領証だ。トークンの償還成功は示すが、channel binding合格、EAP Success、外側方式によるリンク鍵導入、RADIUS/NASの許可、実際の通信開始は示さない。

使用済みトークン数を接続成功数として扱えば、独立した複数の判断を一つへ潰してしまう。EAP Successだけでトークン保持者とトンネル終端者の同一性まで主張すれば、第04版が鍵スケジュールから除いた誤りを別の帳票で繰り返す。

第04版はエンコード以外も改めた

新しい版はメッセージ内容をJSONからTEAP型のTLVへ替え、Privacy Pass構造をbase64url化せず直接運ぶ。No-Suitable-Token TLVを新設し、長さ、重複、フィールドの完全消費、単一階層の入れ子、未知TLVのM-bit処理を定め、オクテット単位のテストベクトルも追加した。

エラーコード9は、償還に至らない不正メッセージと、整形式トークンの検証失敗を分ける。トークンを再利用できるかどうかが、サーバーによる消費の有無で変わるためだ。リレー分析も拡張され、公開・非公開・連合型トークンに関する推奨も整理された。

ただし、精密なワイヤ形式は導入実績ではない。この文書はStandards Trackを目指すEMUワーキンググループのInternet-Draftで、Datatracker上の状態はI-D Existsである。担当AD、shepherd、telechatはなく、RFCでもない。凍結した資料から実装、相互接続、性能、採用は確認できない。

運用では別々の受領証を結合する

監査に耐える運用には、設定したネットワークと期待するEAPサーバー名、検証済み証明書と信頼アンカー、実際のTLS終端、challengeとorigin_info、トークン種別・発行者鍵・challengeダイジェスト、償還結果と使用時刻、channel bindingの出所と判定、EAPの成否、外側リンク鍵、RADIUS/NAS判断、実通信を、それぞれ保存する必要がある。

証明書はピアがどのサーバーを受け入れたかを答える。償還記録は資格情報が有効だったかを答える。channel bindingは両側が観測したネットワーク文脈の一致を答える。EAP結果、NAS判断、通信観測はさらに別の段階だ。単一の「認証済み」欄では因果関係を説明できない。

第04版の意義は、仕様を軽んじたことではない。権威のありそうな128オクテットに、機構が持たない権威を与えないと決めたことにある。稼働中のシステムは、削除された出力では代替できない結合証拠を残さなければならない。

情報源