要約

  • Cookieの組はISAKMP SAを、Message IDはフェーズ2の進行中状態を、提案と実行時のSPIは別のSA領域を識別した。値の一致は本人確認ではなかった。
  • CommitとCONNECTEDは設置前の同期ギャップを狭めたが、最終メッセージの損失は残った。完全な証拠には認証、方針、設置、実パケット、アプリケーション結果が必要だった。

最終メッセージを送った側は、交渉が終わったと思っている。待っている側には届かない。直後に暗号化トラフィックが来る。これはSAが成立した証拠なのか、それとも失われた確認を無視した危険な先走りなのか。

RFC 2408はこの曖昧さを隠さなかった。Commitビットを設定した側は、相手にCONNECTEDを含む保護されたInformational Exchangeを待たせられた。その通知は元のフェーズ2 Message IDを使い、どの交渉についての同期なのかを示した。

だが最後の通知は失われ得た。RFCは、検証可能な後続メッセージや暗号化トラフィックから成立を判断する案と、最後の交渉メッセージを再送する案を示した。唯一の回復動作は標準化されなかった。実装は確信が得られるまで最後のメッセージを保持してもよかった。

ここでMessage IDの役割が明確になる。四オクテットの値は、フェーズ2のプロトコル状態を識別するためにイニシエータが生成した。フェーズ1ではゼロでなければならない。ほぼ同時に始まる複数交渉は別のMessage IDを持ち、同じ親SAの下で並行できた。

Message IDは「どの仕事か」を答えた。「誰の仕事か」は答えなかった。相手の本人性には、RFC 2408が別に要求する強い認証が必要だった。資格情報がどの識別子を結び、どの方針が許可したかは、Message IDの範囲外だった。

親状態はCookieの組で識別された。最初のフェーズ1要求にはInitiator Cookieが入り、Responder CookieとMessage IDはゼロだった。応答後は双方のCookieがISAKMP SAを示し、その後の通信に使われた。

Cookieはanti-clogging tokenでもあった。高価な公開鍵処理より前に、安価な検証で偽造要求をふるい落とす。生成は当事者に依存し、発行者だけが受理される値を作れ、しかも高速でなければならなかった。アドレス、ポート、ローカル秘密、時刻をハッシュする方法が示された。

これは資源防御であって身分証ではない。アドレスは材料であり、本人名ではない。発行済みトークンを返せることは、証明書の秘密鍵を持つことと同じではない。RFC自身も絶対的なDoS防御は不可能とし、偽装パケットが作る状態にはガベージ収集が必要だとした。

Cookieの組、Message ID、SPIは階層を作った。Cookieの組はISAKMP SA、Message IDは進行中フェーズ2、ProposalのSPIは作成中のプロトコルSA、後のESP/AHヘッダーのSPIは実行中のパケット処理状態を選んだ。

一つの監視IDに畳むと、どこが成功しどこが失敗したか分からなくなる。親SAは健全でも子交渉が衝突し得る。交渉は完了してもカーネル設置が失敗し得る。設置されてもセレクタが対象フローに一致しないことがある。

固定ヘッダーの他のフィールドはパーサの契約だった。Exchange Typeがメッセージとペイロードの順序を決め、Next Payloadが最初の型を示し、各汎用ヘッダーが次を指した。Version、Flags、Lengthも別々に検証された。

受信処理はCookie、Next Payload、Version、Exchange Type、Flags、Message IDの順で確認し、その後にチェーンを進んだ。ある検査に合格しても次の検査は保証されない。正しいチェーンは署名の正しさを保証せず、正しい署名はローカル方針を保証しない。

異常時の通知とログも自動ではなかった。無効Cookie、無効型、無効Version、無効Flags、無効Message IDは破棄につながるが、監査記録やInformational通知はMAYであり、ローカルセキュリティ方針が決めた。共通エラー番号は共通の証拠保存を作らなかった。

ISAKMPは具体的鍵交換から意図的に分離された。SAの確立、交渉、変更、削除の手続きと形式を与え、鍵生成と認証の材料を運んだが、一つのアルゴリズムや認証方式に固定しなかった。枠組みの成功を具体的認証の成功として扱えない理由である。

フェーズ1は後続管理を保護するISAKMP SAを作り、フェーズ2は他プロトコルのSAを作った。一度のフェーズ1コストを複数フェーズ2に使える。さらに、フェーズ1はホストやサーバ、フェーズ2はユーザーやアプリケーションを認証し得た。

同じCookieの組にぶら下がるからといって、全ての子SAが同じ主体を意味するわけではない。監査にはフェーズ、認証された主体、資格情報、方針、Message IDを残す必要がある。

提案選択にもローカル権限が残った。イニシエータは一案だけを出すか、優先順で複数を出せた。複数ならレスポンダが自分の方針に最適なものを選んだ。Message IDは返答先を示しただけで、その方針が正しいとは証明しない。

Commitが必要だった事実は、選択と設置準備の間に境界があることを示す。CONNECTEDを受けても、その後のカーネル状態、パケット受理、アプリ結果は別である。受けられなければ、さらに不確実性が増える。

Deleteペイロードも慎重だった。送信者が自分のSAデータベースから対象を削除したという通知であり、受信者への削除要求ではない。応答確認も期待されなかった。受信側は通常ローカル状態を片付けるが、その処理は方針に委ねられた。

したがってDeleteのキャプチャは遠隔削除の証明にならない。保護の検証、受信方針、データベース変化、対象SPI、後続パケット、再確立を結ぶ必要がある。送信者の現実と受信者の現実は一つのメッセージで同一にならない。

Lu Hengの現実層で見ると、Cookieは相関と資源、Message IDは交渉状態、Next Payloadは構文、認証は本人性、方針は許可、SAは実行可能状態、パケットとアプリは結果である。上の層の領収書を下の層の判決に使ってはいけない。

エージェンシー問題も同じだ。認証局、方針所有者、デーモン、カーネル、アプリは別の責任主体である。デーモンの「connected」が全員の代理証明になると、失敗の所有者が消える。

running codeを優先する監査は、CookieとMessage IDを捨てない。むしろ資格情報指紋、方針版、選択、設置結果、実行時SPI、セレクタ、カウンタ、パケット判定、サービス観測へつなぐ。相関値は、範囲を守るとき最も役立つ。

RFC 2408は1998年11月に公開された。RFC 4306は2005年に2407/2408/2409をIKEv2へ置き換えた。2023年にIKEv1群はHistoricとなり、RFC 9395は関連レジストリを閉じた。RFC 7296は後にIKEv2のInternet Standardとなった。これは現在のアルゴリズム推奨ではなく歴史的境界の分析である。

Message IDは交渉を追跡した。その精度は重要だった。だからこそ、相手の身元と実行結果まで背負わせてはいけない。

出典