要約

  • RFC 9645 は TLS クライアント／サーバーの本人性、相手認証、Hello パラメーター、keepalive を再利用可能な YANG grouping として表す。ただし対象は「最小公分母」の設定であり、セッション単位の完全な記録ではない。
  • 証明書、Raw Public Key、PSK の設定は、運用者が許可した可能性を示すにすぎない。相手が何を要求し、どの資格情報が提示・検証され、再開が使われ、アプリケーションが誰を受け入れたかは別の事実である。
  • 必要なのは、モデルと設定の版から実際のハンドシェイク分岐、相手の本人性、検証結果、クライアント認証、アプリケーション主体、操作結果までを結ぶ認証経路レシートである。

丸印が並んでも、経路は分からない

運用レビューで、設定項目の横に緑の丸が並んでいるとする。サーバー証明書は参照可能で、クライアント認証用の CA と Raw Public Key も登録済み、緊急用 External PSK も有効である。TLS ライブラリは許可されたバージョンと暗号スイートをサポートしている。

ここで「問題の操作を行った接続は、どの本人性経路を使ったのか」と尋ねる。緑の丸は、いずれもその問いに答えない。

RFC 9645 は ietf-tls-common、ietf-tls-client、ietf-tls-server と、IANA 管理の暗号スイート列挙モジュールを定義する。クライアントとサーバーの grouping は TLS 固有の設定に集中し、接続先アドレスやポートの決定を利用側モデルに残す。仕様自身も、汎用モデルを完全版ではなく「least common denominator」と位置付けている。

この限定は健全である。共通モデルは意図を共有するための言語を提供するが、一回のハンドシェイクや業務判断の証人にはならない。問題は、組織がその境界を消し、設定受理を実行証明として扱うときに生じる。

四つの本人性方式は、同じ証拠ではない

RFC 9645 の本人性 choice には、証明書、Raw Public Key、TLS 1.2 PSK、TLS 1.3 External PSK がある。これらを「TLS credential」という一項目にまとめると、最も重要な差が失われる。

証明書経路では、チェーン、参照名、有効時刻、Key Usage、署名方式、Trust Anchor、ローカルポリシーが関係する。Raw Public Key は証明書チェーンの意味を持たず、通常は信頼済み鍵との厳密な一致に依存する。TLS 1.2 PSK は旧世代の共有秘密と identity の扱いを持つ。TLS 1.3 External PSK には external identity、hash、任意の context や target 情報がある。

RFC 9257 は、PSK identity が可視・追跡可能になり得ること、共有 PSK の参加者同士が互いになりすませることを指摘する。RFC 9258 は、外部の供給過程を context で結び付けた Imported PSK と、context-free な PSK を区別する。したがって PSK 成功は、必ずしも一台の機器や一人の操作者への帰属を意味しない。

レシートは、秘密そのものを保存せず、実際に用いた分岐、鍵または証明書の保護された識別子、PSK の種類と context の有無を記録しなければならない。

サーバー認証とクライアント認証を分ける

クライアント grouping は client-identity と server-authentication を分けている。クライアント本人性は任意であり、上位プロトコルが認証を担う場合もある。設定済みでも、サーバーから要求されたときに初めて TLS の資格情報が提示される。

サーバー grouping でも server-identity と任意の client-authentication は別である。後者がなければサーバーはクライアント資格情報を要求すべきではない。存在する場合でも、CA、特定 End-Entity 証明書、Raw Public Key、PSK は複数の受入可能性であり、どれが一回の接続で成立したかは設定からは分からない。

この構造から見ると、「mTLS 有効」というラベルは粗すぎる。サーバーが要求能力を持つこと、実際に CertificateRequest を送ること、クライアントが応答すること、検証に成功すること、アプリケーションが主体を作ること、権限を与えることは別々の段階である。

レシートには、クライアント認証の要求有無、提示方式、検証根拠、結果、アプリケーション主体を個別に残す必要がある。ここを一つの真偽値にすると、障害時に「要求しなかった」のか「提示されなかった」のか「検証に失敗した」のかを区別できない。

再開セッションは、証明書を再検証したとは限らない

TLS 1.3 の現行仕様 RFC 9846 は、バージョン、署名方式、Supported Groups、Key Share、PSK identity を別のハンドシェイク入力として扱う。サーバーは互換性のある PSK と暗号スイートを選び、binder によって現在の transcript との結合を検証する。

この結合は重要だが、現在の接続で元の証明書交換を繰り返したことにはならない。再開は以前の接続で得た状態を利用し得る。ログが「TLS success」だけを示し、レポートが静的設定から証明書名を補うなら、その証明書が今回提示・検証されたという誤った印象を作る。

External PSK と resumption PSK も区別すべきである。前者は帯域外供給、後者は以前のセッションに由来する。0-RTT を伴う場合、重要なアプリケーションデータが通常の確認境界より前に送られる可能性もある。最終的なハンドシェイク成功だけでは、操作が置かれた replay と認可の境界を説明できない。

ゆえに、full、resumed、early-data のどの経路か、PSK は外部・context 付き import・再開由来のどれかを、機密を漏らさずに記録する必要がある。

暗号スイートが安全でも、相手の本人性は別である

hello-params-grouping は TLS バージョンの範囲と、利用者順序の暗号スイート一覧を設定できる。supported-algorithm の運用状態は実装能力を示す。しかしバージョンと暗号スイートは、本人性判断の代用にはならない。

IANA TLS レジストリは、暗号が時間とともに弱くなること、専門家による登録が推奨を意味しないことを警告する。TLS 1.3 の cipher suite は TLS 1.2 以前と意味も異なる。RFC 9325 は配備の推奨を示し、RFC 9852 は対象範囲内の新しい TLS 利用プロトコルに TLS 1.3 サポートを要求する。識別子が残っても、許可判断は変化する。

従ってレシートは negotiated version と cipher suite を必要とするが、それを certificate／Raw Public Key／PSK／resumption の選択や検証結果と混同してはならない。「TLS 1.3 だった」は暗号チャネルの説明であり、「期待した相手だった」の証明ではない。

意図から実行へ進むための最小レシート

RFC 8342 は intended configuration と operational state を分け、RFC 8341 は敏感な設定変更へのアクセス制御を与える。RFC 9641 と RFC 9642 は truststore と keystore の再利用可能な参照を提供する。各層は価値を持つが、次の層の結果を代行しない。

keystore 参照が解決しても、別の資格情報が選ばれ得る。truststore が存在しても証明書が提示されないことがある。設定が適用済みでも対象 listener に接続しないことがある。TLS が鍵を認証してもアプリケーションが主体を認めないことがある。

Heng Lu のいう記号的権力と稼働現実の分離を、この順序に適用できる。モデルは語彙、変更管理は意図、TLS スタックは一つの分岐、アプリケーションは意味と結果を支配する。

最小レシートには次が必要である。

  • RFC／YANG 版、feature、deviation、利用側モデル
  • 適用設定の版、datastore 起源、承認者、反映時刻
  • endpoint identity の分岐と、実際に解決した keystore／truststore 参照
  • ロードされた credential と trust material の保護された指紋または版
  • セッション相関 ID と信頼できる時刻
  • negotiated version と cipher suite（本人性方式とは別欄）
  • full／resumed／early-data と PSK の由来・context 状態
  • 相手が提示した本人性、検証方式、結果、不確実性
  • クライアント認証の要求、応答、検証、アプリケーション主体
  • 完了、alert、retry、fallback の履歴
  • アプリケーション認可、操作、受入条件、結果
  • 観測不能項目と、最終表現を承認する責任者

これは RFC が規定する統一フォーマットではない。境界から導いた運用設計である。証明できる最小文は、「このセッションと操作では、この適用設定の下で、この認証分岐を用い、この相手をこの方針で検証し、この主体に対応付け、この結果になった」である。

出典

  1. 最小初期仕様
  2. 現実の層と象徴的権力
  3. Running-code primacy
  4. RFC 9645 文書履歴
  5. RFC 9645 情報ページ
  6. RFC 9645 HTML
  7. RFC 9645 プレーンテキスト
  8. RFC 9645 XML
  9. RFC 9645 インライン正誤
  10. IANA TLS パラメーター
  11. IANA TLS cipher-suite YANG モジュール
  12. RFC 9641：Truststore モデル
  13. RFC 9642：Keystore モデル
  14. RFC 9846：現行 TLS 1.3
  15. RFC 9852：新規プロトコルの TLS 1.3
  16. RFC 9325：安全な TLS 配備
  17. RFC 9257：External PSK ガイダンス
  18. RFC 9258：External PSK の import
  19. RFC 8341：ネットワーク設定アクセス制御
  20. RFC 8342：ネットワーク管理 datastore architecture