要約

  • RFC 3631 の現在にも残る価値は、暗号方式の一覧ではなく、脅威モデル、保護対象、層、粒度、信頼モデル、鍵管理を一つずつ結び直す設計原則にある。
  • 証明書の妥当性と秘密鍵の所持は、アプリケーションが意図した相手、利用者の権限、取引の完了を自動では証明しない。
  • 実運用では、設定、ネゴシエーション、参照名、検証経路、鍵、保護されたレコード、認可判断、観測結果をつないだ受領記録が必要になる。

接続前にしか作れない証拠がある

接続先から証明書を受け取った後で、その証明書に書かれた名前を「探していた相手」と定義すれば、検証は循環する。参照名は接続前のアプリケーション意図から生まれなければならない。設定、サービス発見、利用者入力、テナント選択のどれがその名前を作ったのかが最初の証拠になる。

現在の RFC 9325 は、一般的な認証付き TLS でホスト名検証が安全上重要だとする。証明書が有効で相手が秘密鍵を所持していても、望んだエンドポイントへの接続とは限らない。必要なのは、参照名、証明書中の識別名、照合規則、信頼アンカー、検証時刻、状態情報、例外、最終判断の組である。

この判断の後にも、別の問いが残る。サーバーを認証したことはクライアント利用者の認証ではない。クライアント証明書が機器を識別しても、その機器が特定の台帳を書き換える権限までは決めない。トランスポートの相手、アプリケーションの主体、許可された操作は別々の主語である。

RFC 3631 は現行暗号カタログではない

RFC 3631 は 2003 年 12 月、Internet Architecture Board のストリームから Informational RFC として公開された。Internet Standard ではない。RFC Editor の情報と IETF Datatracker がその位置づけを示す。文書履歴は公開過程であり、普及率の記録ではない。エラッタ検索も実装監査ではない。

文書内の SHA-1、当時の TLS、IPsec、証明書運用に関する評価は時代の資料として読むべきで、現在の推奨へコピーしてはならない。TLS 1.3 の仕様は RFC 8446、現在の実装・配備上の指針は RFC 9325 が担う。

残るのは、暗号を完成済みプロトコルへ後付けすれば安全になるという発想への反論である。プロトコルの意味上の前提が誤っていれば、暗号演算の正しさは前提を修復しない。何を誰から守るのか、どの層で、どの単位を、どの信頼関係で守るのかを先に決める必要がある。

脅威モデルが保護サービスを選ぶ

RFC 3631 は意思決定の最初に脅威モデルを置く。攻撃者、資源、能力、位置を明らかにする。公開情報のサーバーでも、内容を書き換えられたときの損害が大きければ完全性は重要になる。機密性の要否だけで強弱を決められない。

RFC 3552 は、想定する攻撃能力と対象外にする脅威を記述する方法を整理した。攻撃者がすべてオフパスだと仮定してはならず、限定領域で始まったプロトコルが広い環境へ出た場合も考えるべきだとする。RFC 2316 の IAB ワークショップ報告も、脅威、対策、限界を RFC で意味のある形にすることを求めた。

運用側では、資産、操作、損害、オンパス・オフパス・内部者・侵害端末の能力、必要な保護期間を記録する。さらに、機密性、完全性、ピア認証、送信元認証、リプレイ耐性、可用性、認可のどれが必要かを分ける。「強い暗号」はこの表の一項目ですらなく、方式を選ぶ前の結論にすぎない。

実装必須は、使用済みを意味しない

RFC 3631 が mandatory-to-implement を論じる目的は相互運用性にある。複数の選択肢だけを設けると、二つの実装が互いに重ならない方式を選び、安全な共通手段を失う。共通の必須方式は、その床を作る。

しかし義務の相手は実装者であり、運用者の全接続ではない。有効化、既定値、実際の選択を意味せず、古く弱くなった方式を停止することも妨げない。RFC 3365 は強い安全機構を要求しながら、実装と利用の違いを明記している。

監査では、コードに存在、設定で許可、クライアントが提示、相手が選択、当該接続で利用、現行方針に適合、を別の状態として保存する。「TLS 対応」は最初の一つしか示さない。古い方式がバイナリに残ることと、本番で露出していることも別である。

ALPN と 0-RTT は飾りではない

TLS 1.3 はアプリケーションプロトコルから独立した仕組みであり、上位プロトコルが TLS の開始方法と認証結果の意味を定める。バージョン、暗号スイート、クライアント認証、ALPN、再開、0-RTT は、それぞれ主張の範囲を変える。

ALPN が期待する上位プロトコルと一致しなければ、証明書が正しくても別の意味のサービスへ安全に話している可能性がある。0-RTT は再送され得るため、重複が許されない操作を実行する前に、アプリケーション側で対策が必要になる。暗号化済みであることと、一度だけ実行されたことは同じでない。

終端も証拠になる。アプリケーションが完全なストリームを必要とするなら、close_notify や切断の扱いが、正常完了と切り詰めの区別に影響する。最後のレコードが保護されていても、受信側が部分取引を完了と解釈すれば業務結果は変わる。

一度の認証でセッション全体を覆わない

RFC 3631 の HMAC 例は時間方向の範囲を示す。共有秘密によるチャレンジは古いセッションの再利用を防ぎ、開始時点を認証できる。しかし TCP 接続の冒頭だけに HMAC を使い、その後のプロトコル単位を保護しなければ、認証後にセッションを奪われ得る。

どのメソッド、宛先、ヘッダー、本文、nonce、順序番号、応答が MAC や署名に入ったのかを残す必要がある。状態変更メッセージはすべて保護されたか。再接続で以前の権限が継続したか。保護された封筒の中に、結び付けられていない命令はないか。

MAC の妥当性は、対象バイトと鍵の関係を証明する。主体、資源、範囲、鮮度、方針を入力に持つ認可は別の判断である。検証器の出力をそのまま認可に使うと、存在しない入力から権限を作ってしまう。

フレームワークは下位方式の性質を継承する

RFC 3631 は SASL の性質が実際にネゴシエートされた方式に依存すると説明し、GSS-API でも下位方式を別途評価するよう求める。フレームワーク名は、相互認証、後続メッセージ保護、チャネルバインディング、リプレイ耐性を一意にしない。

提示集合、選択方式、パラメータ、チャネルとの結び付け、フォールバック、得られた属性を記録する。文法上正しい選択でも、ローカル方針に反することがある。互換性のために残した弱い選択肢が通常経路に変わるとき、ダウングレードは成功率の中へ隠れる。

鍵の寿命はプロトコル名から見えない

RFC 4107 は、自動鍵管理と手動鍵管理の証拠能力を分ける。自動方式はピアの生存確認、新しい鍵の確立、大規模な更新を行える。手動方式が妥当なのは限定条件であり、それでも鍵識別、移行、交換、侵害対応が必要になる。

鍵の生成、保管、配布、ピア、用途、作成時刻、ローテーション、失効、破棄、侵害状態を保存する。同じ方式でも、接続ごとの一時鍵と、多数のホストが長期間共有する秘密では意味が違う。セッションチケットの鍵を長く保持すれば、再開接続の過去データに期待した性質も変化する。

鍵管理を「後から加える運用」と扱うと、最初の鍵が事実上の永久権限になる。暗号は稼働し続けても、誰が権限を失ったのかを示せなくなる。

トンネルの緑とパケットの経路は別である

RFC 3631 は IPsec の広いカバレッジと、ホスト・ゲートウェイ単位ではアプリケーション主体に粗すぎる場合を区別した。後の RFC 4301 では、セキュリティサービスがプロトコル、モード、Security Association の端点、鍵、ポリシーで決まる。トラフィックは保護、破棄、バイパスへ分類される。

したがって「トンネルは稼働中」は、問題のパケットが保護ルールに入った証拠ではない。ポリシーデータベースの版、セレクター、SA、カウンター、フロー相関、内側アプリケーションの判断までつなぐ必要がある。ゲートウェイ認証は利用者認証ではない。

ファイアウォールは地理を前提にする

RFC 3631 はファイアウォールをトポロジー上の防御と捉える。内外の境界が明確であることに依存し、内部攻撃はそれだけでは止められない。トンネル、無線、直結回線、侵害端末が境界を変えても、ルールの表示は同じままである。

アドレスや名前による認証も、ルーティング、DHCP、プロキシ、スプーフィング、DNS に依存する。DNSSEC は署名された DNS データを保護するが、基礎となる対応関係の真偽やアプリケーション権限を作らない。代替経路、クラウド境界、例外を設定と同じく版管理する必要がある。

形式、実行、判断を一つにしない

Lu Heng の現実の層と動くコードの優先を使えば、仕様、実装能力、設定、ネゴシエーション、検証、認可、結果を別記録として扱える。最小初期仕様は共通の証拠形式が将来のローカル判断を奪わないようにする。権威と信念は各主張の発行者、範囲、限界を問う。

重要操作では、資源と脅威、必要属性、ソフトウェア、設定、提示と選択、参照名、資格情報、信頼アンカー、鍵、保護単位、アプリケーション主体、認可規則、許可または拒否、ネットワークと業務結果を保存する。アラート、フォールバック、バイパス、リプレイ拒否、名前不一致、切断、例外も同じ証拠である。

冒頭の TLS は正しく相手との通信を守った。欠けていたのは、誰を相手にするべきだったかというアプリケーション自身の記録である。その空白を暗号の成功で埋めてはならない。

出典

  1. RFC 3631 — Security Mechanisms for the Internet
  2. RFC 3631 プレーンテキスト
  3. RFC Editor の RFC 3631 情報
  4. IETF Datatracker の RFC 3631
  5. RFC 3631 の文書履歴
  6. RFC 3631 エラッタ検索
  7. RFC 2316 — IAB セキュリティアーキテクチャ・ワークショップ
  8. RFC 3365 — 強いセキュリティ要件
  9. RFC 3552 — Security Considerations の指針
  10. RFC 4107 — 暗号鍵管理の指針
  11. RFC 4301 — IPsec アーキテクチャ
  12. RFC 8446 — TLS 1.3
  13. RFC 9325 — TLS/DTLS の安全な利用
  14. Lu Heng — Running Code Primary
  15. Lu Heng — Minimum Initial Specification
  16. Lu Heng — On Reality Layers
  17. Lu Heng — On Authority and Belief