要約
- Quick Modeは親ISAKMP SAのcookie対と子交渉のMessage IDを分け、Message IDごとに独立した最初のIVを作った。
HASH(1)、HASH(2)、HASH(3)は各子交渉の転写とnonceを認証した。 - 状態機が暗号的に完了しても、両端のSAD/SPD、セレクタ、経路、ハードウェア、パケットカウンタは自動的に一つの証拠にならない。最後の
HASH(3)には第四の応答も設置結果も含まれなかった。
一つの親SAの下で、二つのQuick Modeがほぼ同時に始まる。両方とも同じPhase 1の認証関係を借りるが、同じ暗号ストリームを借りてはいけない。RFC 2409はMessage IDを境界にした。
RFC 2408のISAKMPは、認証と鍵交換を特定せず、SA管理の枠組みを定めていた。RFC 2407はIPsec DOIの語彙を定めた。RFC 2409はOakleyとSKEMEの技法を組み合わせ、IKEとして具体的な交換と鍵導出を与えた。
Phase 1では双方向のISAKMP SAを確立する。Main Modeは実装必須、Aggressive Modeは実装推奨だった。どちらも一時的Diffie-Hellmanから認証済み鍵材料を作るが、身元の見せ方と保護順序は異なる。
Quick ModeはPhase 2専用であり、すでに認証されたPhase 1関係の上で非ISAKMP SAを交渉する。AHやESPが実際のパケットを処理するための鍵とパラメータを、同じ親関係から何度も作れた。
親SAはInitiator CookieとResponder Cookieで識別された。各Quick Modeは固有のMessage IDを持った。最初のCBC IVは、Phase 1最後のCBC出力ブロックとそのMessage IDのハッシュから導出された。
そのため、同じ親SAの下のQuick Mode AとBは別のIV系列を持つ。片方の再送や遅延が、もう片方の暗号状態を進めてはならない。並行性は識別子だけでなく暗号履歴にも現れた。
しかしMessage IDは認証情報ではない。該当する子状態を見つけ、HASH入力に含まれることで転写との結合を得る。正しい状態を検索できても、相手の権限やローカル設置はまだ証明されない。
第一メッセージはHASH(1)、SA提案、Niを運ぶ。必要ならKEとIDci、IDcrも続く。ISAKMPヘッダ以後はPhase 1 SAで暗号化され、HASHの直後にはSAが置かれる。
HASH(1)はMessage IDと、HASH以後の完全なメッセージを対象にする。レスポンダは、Phase 1の認証状態を持つ者が、この子交渉でこの提案とnonceを送ったことを検証できる。
検証は受諾ではない。レスポンダのポリシーは提案を拒否できる。検証時点ではAH/ESP SAがカーネルに存在する必要もない。認証された選択肢と実行済み状態は別物である。
第二メッセージはHASH(2)、選択されたSA、Nrを返す。計算はレスポンダの残りのメッセージより前にNiを加える。RFC 2409はこれをliveness proofと位置づけた。
イニシエータがHASH(2)を検証すれば、Phase 1状態を持つレスポンダが自分のnonceを受け、選択を行い、新しいNrを作ったと分かる。双方は同じ候補KEYMATを導出する入力をそろえる。
第三メッセージはHDR*, HASH(3)だけである。ゼロの一オクテット、Message ID、Ni、NrがPRFに入る。レスポンダは、イニシエータがNrを受け取り、認証済み状態を保持していると確認する。
ここで知識が非対称になる。レスポンダはHASH(3)を受信する。イニシエータは送信する。基本Quick Modeには、受信・検証をイニシエータへ返す第四メッセージがない。
これは仕様の欠陥を断定する話ではない。三メッセージという定義から、基本転写が自身の最終受信について双方向の受領証を持たない、と限定して推論している。後続トラフィックや再送、別の同期機構は追加証拠になり得る。
RFC 2408のCommitとCONNECTEDは準備状態を別に扱ったが、最終メッセージ消失の可能性を完全には消さなかった。この機構は隣接文脈であり、本稿の所有する中心はQuick Modeの三HASHと設置証明の境界である。
第四メッセージがあったとしても、二つのカーネル設置を自動証明しない。IKEデーモンは交渉し、カーネルやアクセラレータはSPI、鍵、アルゴリズム、寿命、セレクタ、リプレイ状態を設置する。
メッセージ受信とシステムコール成功は違う。システムコール成功と双方向SA整合は違う。整合と最初の保護パケットは違う。パケットとアプリケーションの有用な結果も違う。
nonceは強いが狭い証拠を作った。NiとNrは新鮮さを供給し、古い交換の再生で偽のSAが作られるのを防ぐ。KEを使わない場合、KEYMATはSKEYID_d、protocol、SPI、二つのnonceから導出された。
この基本導出はPhase 1の指数演算から材料を更新するが、Phase 2鍵に独立したPFSを与えない。Quick Modeで追加KEを使えば、新しいDiffie-Hellman共有秘密を混ぜ、生成鍵にPFSを与えられた。
KEの利用は任意だが対応は必須だった。KEがある場合、各SA提案の各transformは同じDiffie-Hellman groupを含む必要がある。クライアント身元を使う場合も、交渉内の全SAへ一貫して適用する。
PFSは将来の秘密漏えいが過去鍵へ及ぼす影響を制限する性質である。SAD書き込みの成功、SPDセレクタの一致、NICへのオフロード、パケット到達を証明する性質ではない。
IDciとIDcrは認証主体とトラフィック主体の違いを示す。Phase 1で認証されたのはゲートウェイでも、Phase 2で許可される対象は特定ホスト、サブネット、プロトコルかもしれない。
ゲートウェイの認証成功は、すべてのクライアント関係への権限を与えない。HASHは身元フィールドを転写へ結びつける。ローカルポリシーは、その結びつきを許可するか決める。
レスポンダは提案からtransformとSPIを選び、HASH(2)で選択を認証する。イニシエータはHASH(3)で応答受領を示す。それでもメモリ、セレクタ衝突、寿命換算、ドライバ、ハードウェア制約、後段ポリシーで設置は失敗し得る。
HASH入力には、まだ起きていないローカル処理結果を入れられない。「Quick Mode complete」という表示が後続結果まで代表するなら、それはUIが主張を拡大している。
IV管理は状態機械の慎重さを物語る。暗号文を受け取っただけでrunning IVを進めてはならない。復号したメッセージが基本的健全性検査を通り、実際にIKE状態機械を進めると判断されてから更新する。
正しい再送は、新しい進行ではない。有効cookieを含む偽メッセージもIVをずらしてはならない。受信、復号、検証、状態進行は一つの処理内でも分離されていた。
並行Quick Modeではこの区別がさらに重要になる。Aの再送がBのIVを変えず、Bの設置失敗がAの転写成功を否定せず、Aのパケット成功がBの結果を証明しない。親SA共有は証拠共有ではない。
UDP上では最後のHASH(3)が失われ得る。イニシエータは保護トラフィックを観測できなければ再送するかもしれない。レスポンダは再送を新しい設置命令として扱わず、既処理状態と照合する必要がある。
監査では各Quick Modeを独立行として保持する。親cookie対、Message ID、IV起点、Ni、Nr、三HASH、提案、SPI、ポリシー、設置、runtime SPI、セレクタ、カウンタを同じ相関キーで結ぶ。
Lu Hengの現実層モデルでは、Message IDは相関、HASHは認証転写、nonceとKEYMATは鍵導出、ポリシーは権限、SAD/SPDは実行状態、カウンタはパケット処理、アプリケーション検査は結果に属する。
代理問題は境界ごとに現れる。credential管理者はPhase 1身元、セキュリティ所有者はPhase 2許可、IKEデーモンは交換、カーネルとアクセラレータは設置、運用はパケット、サービス所有者は有用性を持つ。
最小共通仕様はメッセージと計算を統一したが、各ホストのポリシーやカーネル実装を統一しなかった。その分散性を守るには、各所有者が自分の受領証を残さなければならない。
running codeを優先するなら、転写の成功を実装結果へ結ぶ。Phase 1 credential fingerprint、HASH検証、nonce、KEYMAT識別、ポリシー版、設置要求と返答、SA一覧、セレクタ、パケット判定、アプリケーション観測を保存する。
そうすれば障害の層が分かる。レスポンダにHASH(3)がなければ転写終端前。両デーモンが完了して片側SAがなければ設置。両側にカウンタがありサービスが失敗すればIPsec以後である。
RFC 2409は1998年11月に公開された。RFC 4109がIKEv1アルゴリズム要件を更新し、RFC 4306がRFC 2407/2408/2409をIKEv2へ置き換えた。RFC 7296は後にIKEv2 Internet Standardとなった。2023年にIKEv1はHistoricへ移され、RFC 9395はIKEv1を非推奨化し関連レジストリを閉じた。
並行状態を分ける設計は精密だった。その精密さこそ、転写完了と設置完了を混同してはならない理由である。
出典
- IETFにおけるRFC 2409の履歴
- IKEv1をHistoricへ移す状態変更
- Lu Heng — 最小初期仕様とローカル判断
- Lu Heng — 代理問題
- Lu Heng — 現実層と象徴権力
- Lu Heng — running codeの優先
- IANA IKEv1・IPsecレジストリ
- RFC 2409の正誤情報
- RFC EditorのRFC 2409情報
- RFC 2407 — IPsec DOI
- RFC 2408 — ISAKMP
- RFC 2409 — IKE
- RFC 4109 — IKEv1アルゴリズム要件
- RFC 4306 — IKEv2
- RFC 6071 — IPsec・IKE文書ロードマップ
- RFC 7296 — IKEv2 Internet Standard
- RFC 9395 — IKEv1非推奨化とレジストリ閉鎖
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
