要約

  • RFC 2411はIPsecの仕様群を七つの役割に分け、新しい暗号方式がESP、AH、割当値、鍵管理の一般則を何度も書き直す事態を抑えた。
  • その地図は参照先を示す情報文書であり、製品がどの版を実装したか、二者が何を交渉したか、SAが入ったか、通信が成功したかを証明するものではなかった。

RFC 2411の図には、暗号化されたデータも認証タグもない。あるのは箱と矢印だけである。

最上段にArchitecture、左右にESPとAH、その下に暗号アルゴリズムと認証アルゴリズム、中央にDOI、最下段に鍵管理が置かれる。1998年のIPsecを理解する案内図だが、本当の対象は文書そのものではない。規則が増えるとき、誰がその規則を所有するかという問題である。

新しい暗号アルゴリズムを追加するたびにIPsec全体を改訂すれば、共通部分が不安定になる。逆に、各アルゴリズム文書がESPやAHの一般説明をコピーすれば、やがてコピー同士が異なる意味を持ち始める。RFC 2411は後者を「draft explosion」と呼んだ。文書数だけでなく、同じ規則の複製数が爆発するのである。

そこで共通の概念とセキュリティ要件はアーキテクチャ文書に残した。ESPとAHはパケット形式と一般処理を受け持つ。個々の暗号文書は、その方式をESPでどう使うかに集中する。ESPとAHで同じ認証方式を使えるなら、一つの認証アルゴリズム文書が両方を扱う。DOIは交渉可能な値に共通の番号を与え、鍵管理文書は鍵素材の確立と管理を担う。

これは、中央文書がすべてを命令する構造ではない。責任を狭くする構造である。

鍵長を考えると、境界が見える。鍵管理は選択された方式に十分な長さと強度の素材を生成しなければならない。しかし各方式の鍵長、弱い鍵、パリティ、複数鍵の順序まで鍵管理文書が所有すれば、新方式のたびに鍵管理側を書き換えることになる。RFC 2411は、それらをアルゴリズム文書の責任とした。

複数の鍵が必要な場合の抽出法はアーキテクチャが示す。だが、鍵管理プロセスが先に分割するか、素材全体をカーネルへ渡してカーネルが「slicing and dicing」するかは実装上の問題とされた。

ネットワーク上で一致すべき結果は共通化する。内部の配置は、相互運用性が要求しない限りローカルに残す。この停止線こそ、最小初期仕様の実務的な姿である。

オプションについては、放任ではなく削減を勧めた。技術的に妥当な共通値があるなら固定し、交渉の組合せを減らす。オプションが増えれば、二つの実装がそれぞれ準拠していても共通の提案を持たない可能性が高まるからだ。

固定できない場合には理由が必要になる。既定値、範囲、フィールド形式、処理への影響を明記する。「選べる」という一語では、実装者が同じものを選べるとは限らない。

RFC 2411が将来のアルゴリズム文書に求めた項目は、運用に近い。鍵の最小・最大・推奨長、乱数生成、弱い鍵、更新頻度、性能、入出力形式、パディング、既存方式との相互作用、既知の攻撃、実装上の落とし穴、検証手順、テストベクトルである。

しかし、RFC 2411自身がそれらを検証したわけではない。検証可能な情報を、最も近い文書に置けと要求したのである。

この違いを失うと、文書の地図が実行証明へ化ける。ロードマップにアルゴリズムが載っていることは、その製品が実装した証拠ではない。IANAに番号があることは推奨の証拠ではない。製品仕様の「対応」は、実際の交渉結果ではない。IKEログの選択は、両端のカーネルにSAが入った証拠ではない。一方のSAとカウンターは、相手の状態やアプリケーションの成功を保証しない。

文書地図、原規則、実装、交渉、インストール、パケット、結果は、それぞれ別の受領証を要する。

RFC 2411は自らをInformationalとし、Internet Standardを規定しないと明記した。セキュリティ手順についてはアーキテクチャ、ESP、AH、暗号・認証アルゴリズム文書を参照するよう求めた。多くの暗号方式は認証なしでは安全でないという注意も、展開済みシステムへの合格印ではない。必要な文書を組み合わせて判断せよという指示である。

2011年のRFC 6071はRFC 2411を廃止し、膨張したIPsec/IKE文書群を新たに整理した。そこではロードマップ自身が「snapshot」と呼ばれ、アルゴリズム要件は2011年2月時点のものにすぎず、後続RFCによって変わり得るとされた。ほかのRFCと衝突するなら、ほかのRFCが優先するとも明記された。

優れた要約は、自分が一次資料ではないことを隠さない。

RFC 6071はさらに、文書の状態と配備の状態を分けて記録した。新しいIPsecが古いIPsecを廃止しても、旧版は実装で広く使われていた。IKEv2がIKEv1を置き換えても、IKEv1は運用に残った。Obsoleteは文書グラフ上の関係であり、遠隔装置からコードを消す命令ではない。一方、稼働中であることは安全性や推奨を回復させるものでもない。

ロードマップの箱も変化した。暗号と完全性を一体化したcombined-modeアルゴリズムが独立した位置を得た。必須アルゴリズムは、パケット形式より速く更新できる別文書へ移された。IKEv2は、ISAKMP、Oakley、DOIに分かれて時に矛盾したIKEv1の材料を一つにまとめた。

分割には、変更を局所化する力がある。分割しすぎれば、現行規則を探す負担と矛盾が増える。正しい文書数が先にあるのではない。変更速度、専門性、相互運用境界が違うところに境界を引くべきなのである。

RFC 8221がアルゴリズム要件を独立して更新するのも同じ理由だ。暗号解読は進み、装置の能力は異なり、今日の推奨は永遠ではない。IANA番号は機械の語彙を安定させるが、登録された方式を安全、必須、有効、選択済みに変えない。RFC 9395が後にIKEv1と古い方式を非推奨化しても、歴史的な番号と文書は残る。

RFC 2411が示したのは、仕様の編集にもプロトコル設計が必要だということだった。共通規則を共通層に置き、固有規則を機構の近くに置き、相互運用に影響しない内部選択は実装に残す。これによって新しいアルゴリズムは全体を書き直さずに参加できる。

ただし、参加を現実にするのは出版ではない。実装が規則を採用し、二者が互換な提案を選び、双方が状態を設置し、パケットが処理されて初めて、文書の可能性が運用の事実になる。

RFC 2411は規則の所在を示した。装置の状態を示す仕事は、最後まで装置側に残った。

出典