要約

  • 9月30日付のEMU作業部会Internet-Draft第04版は、EAP-PPTがMSKもEMSKも導出しないと明記した。第03版では外側のTLSエクスポーターから128オクテットを得て両者に分けていた。新稿は、その値をEAP-PPTの鍵材料として運搬側の方式へ報告してはならないとする。文書はまだI-D Existsで、RFCでも導入実績でもない。
  • Privacy Passトークンの検証は接続許可の判断に使える。しかし、その提示はピアとEAP-PPTサーバーだけが共有する秘密を生まない。トンネル自身が算出できる値に内側の鍵という名前を与えても、両者の独立した暗号学的結合を証明したことにはならない。

前の版が鍵を「作れた」ことと、その鍵が何を立証するかは別問題だ。第03版の6.6節はTLSセッションのエクスポーターから128オクテットを取り、64ずつをMaster Session KeyとExtended Master Session Keyに割り当てた。第04版の5.7節はその構成を消し、EAP-PPTは両方とも導出しないと定める。鍵材料は運搬するトンネル型EAP方式に報告しない。これはアルゴリズムの失敗報告ではなく、提案中の方式が主張できる保証の修正だ。

トークンは持参人型の資格情報である。公開検証型なら発行者の公開鍵で、非公開検証型なら発行者とEAP-PPTサーバーの共有材料で確認する。後者の共有相手はピアではない。ピアはトークンを渡して保有を示すが、この処理によってサーバーとの新たな共有秘密を確立するわけではない。TLSを終端する側は自分のセッションからエクスポーター値を計算できる。そこから取り出した数字を「内側の方式が供給した鍵」と扱うと、外側の主体が作った証拠を独立の証拠として二度数えることになる。

新稿の安全性一覧はEAP-PPTの鍵導出と暗号学的結合をともに「No」とし、チャネル結合は「Yes」とする。後者はピアが見たネットワーク情報とサーバー側の情報を照合する別の検査だ。内側に鍵がないから外側にも鍵がない、という意味ではない。認証器へ渡すリンク用の鍵はトンネル型EAP方式の責任であり、サーバー認証もその外側の仕組みに依存する。接続許可、証明書の検証、鍵の出所、ネットワーク情報の整合を一つの「成功」にまとめると、失敗した境界を見失う。

第04版の9.4節は中継の場面を説明する。攻撃者の証明書をピアが受け入れれば、攻撃者はピアとのトンネルから内側の交換を正規サーバーへ転送し、トークンを自分のアクセスのために使い得る。草案が第一の防御とするのは、接続先ネットワーク用に設定した信頼アンカーと期待するサーバー名による厳格な証明書確認だ。初回だけ信頼する設定や、検証失敗を利用者が押し切る例外を認めない。サーバー機能の同居、チャネル結合、短寿命トークン、二重使用検知は被害の条件を変え得るが、持参人型トークンを鍵交換に変えるわけではない。

同じ版ではメッセージのJSON表現をTLVへ替え、解析やエラー処理も整理した。これらは別の変更であり、実ネットワークで障害が起きた証拠にはならない。今回の焦点は、トンネルの終端者自身が導出できる値を内側の独立保証として数えないという線引きにある。

出典