要約

  • draft-ietf-tls-pake-02 は二メッセージに収まる内部PAKEと、TLS前に実行して出力をRFC 9258の外部PSKとして取り込む外部PAKEを分ける。
  • 後段TLSの成功は取り込まれた鍵の所持を示すが、前段PAKEの相手、identity、channel binding、接続対応を自動的には証明しない。

四往復のPAKEが成功し、アプリケーションは得られた秘密を外部PSKとして取り込んだ。続くTLS 1.3接続も成功した。しかし障害調査で、どのPAKE実行がどのTLS接続に使われたかを示す記録がなかった。

二つの成功は並んでいた。つながってはいなかった。

draft-ietf-tls-pake-02 の第02版は2026年7月6日公開、2027年1月7日失効予定のTLS作業部会Internet-Draftである。Informationalと記される作業中の文書で、RFC、最終レジストリ、実装証明、セキュリティ監査ではない。文書自身も十分な安全性分析が未了だと注意する。

内部PAKEはTLS transcriptの内側にいる

TLS 1.3の通常PSKは高エントロピーを前提とし、人間のパスワードを直接入れるとbinderから辞書攻撃が可能になる。提案されるpake拡張はPAKEメッセージを運び、得た共有秘密を通常の一時鍵交換と合わせて鍵スケジュールへ入れる。

内部PAKEはClientHelloとServerHelloの二メッセージで必要な交換を完了する。PAKEのメッセージはTLS transcriptに入り、Finishedが鍵確認を担う。この場合、前段と後段の結合は同じhandshakeの構造に見える。

それでもscheme選択、登録検索、server Finished、client Finishedは別段階である。サーバーは存在しない登録に対して擬似応答を返せるため、ServerHelloだけではアカウント存在を証明しない。

外部PAKEは境界をまたぐ

二メッセージ以上を必要とする方式はTLSの外で実行される。アプリケーション管理の経路でPAKEを終え、結果からPSKを導出し、RFC 9258の仕組みでTLS 1.3へ取り込み、そのPSKで接続する。

この構成には少なくとも四つの出来事がある。PAKEを誰と実行したか、どのidentityと文脈を使ったか、どのimported identityを作ったか、どのTLS接続がそれを消費したかである。

TLS側は最後の鍵を知っていることを確認できる。だが、その鍵が意図したPAKE transcriptから来たか、別の同時実行と入れ替わっていないか、正しい役割とサーバー名に結び付いたかはアプリケーションの責任になる。

RFC 9258は文脈を要求するが、観測はしない

外部PSK importは、元の秘密を対象プロトコル、KDF、任意文脈へ結び付け、異なる用途の鍵を分離する。生成元プロトコルのchannel bindingを文脈に含めることも求める。

これは重要な暗号学的インターフェースである。しかしアプリケーションが誤ったidentity、空のbinding、再利用された相関値を渡したかどうかをRFC 9258自身が観測するわけではない。

監査には、PAKE transcriptのハッシュ、client/server identity、役割、import context、imported identity、TLS connection IDの最小結合が必要だ。生のパスワードや不要な識別子を保存する必要はないが、結合そのものを捨ててはならない。

PSK成功を前段認証へ逆投影できない

後段TLSが成功したとき確実に言えるのは、その接続の両端が同じimported keyへ到達したことである。前段PAKEの登録手続、相手の法的identity、アプリケーション権限までは含まれない。

再試行はさらに難しい。PAKE成功後にTLSだけ再試行するのか、毎回PAKEからやり直すのか、imported keyを何回使えるのかで証拠の寿命が変わる。接続プールや並列処理は、古い結果を別接続へ結ぶ事故を起こし得る。

有効期限と単回使用方針を明示し、消費時に原子的に記録しなければ、「認証済みPSK」は運用上の持ち回り証票になってしまう。

identityはSNIや証明書と同義ではない

PAKEのserver_identityはSNIと独立している。内部方式でも外部方式でも、この違いは残る。SNIは接続先の選択に使われ、PAKE identityは登録と秘密の文脈に使われる。

クライアントがsignature_algorithmsも送れば、PAKE選択時にサーバー証明書を要求するモードになる。証明書検証は別のサーバーidentity主張を追加するが、PAKE identityとの対応規則を自動生成しない。

接続記録には三つを別欄で残すべきだ。後から一つのprincipalへ正規化すると、どのauthorityがどの対応を決めたのか分からなくなる。

client Finishedまではclient認証ではない

内部PAKEでは、サーバーがclientのFinishedを検証して初めてclient認証が完了する。存在しない登録に対する擬似shareもそこまで進み得る。アプリケーションデータを先に送れば、認証前の相手へ情報を渡す。

外部PAKEで事前認証が済んだと考える実装でも、後段接続のbindingを確認する前に権限を与えてはならない。前段結果の所持と、現在のTLS endpointへの結合は二つの条件である。

Finishedはセッション鍵所持を示す。アカウントが現在有効か、登録した人物が正しいか、要求された操作が許可されるかは別の判断である。

量子耐性にも二つの台帳がある

通常TLS key shareをhybridまたはpost-quantumにすれば、記録されたアプリケーショントラフィックの将来復号を抑えられる。PAKEが古典方式なら、そのPAKEメッセージから長期パスワードが後に回復される危険は残る。

外部PAKEはtranscriptが別経路にあるため、保存場所と保持期間もTLSログと異なり得る。トラフィック暗号化だけ棚卸ししても、認証情報の将来露出面は見えない。

OQUAKE系やhybrid外部方式は研究中の草案に依存する。試験結果を最終的な安全性保証へ昇格させず、scheme、版、仮定、保持範囲を記録する必要がある。

成功を結ぶ証拠が製品になる

外部PAKEの価値は、TLSの二メッセージ制約を超える方式を組み込めることにある。その自由度は、境界をまたぐ相関を新しい制御面にする。

暗号APIが鍵を返した、TLSが成功した、アプリケーションが許可したという三つの緑ランプは、同じ取引に属する証明がなければ一つの認証ではない。

設計時に相関receiptを定義し、privacy最小化、単回消費、期限、再試行、ローテーションを決めるべきだ。後からログ名を似せても、失われた結合は復元できない。

出典