1.2. The Initial Exchanges (初期交換)
1.2 The Initial Exchanges (初期交換)
IKE を用いた通信は常に IKE_SA_INIT と IKE_AUTH 交換 (IKEv1 では Phase 1) から始まる. これらの初期交換は通常 4 メッセージから成るが, シナリオによっては増える. IKE を用いたすべての通信はリクエスト/レスポンスのペアから成る. まず基本交換を述べ, 続いて変種を述べる. 最初のメッセージのペア (IKE_SA_INIT) は暗号アルゴリズムを交渉し, nonce を交換し, Diffie-Hellman 交換 [DH] を行う.
2 番目のメッセージのペア (IKE_AUTH) は先行メッセージを認証し, アイデンティティと証明書を交換し, 最初の Child SA を確立する. これらのメッセージの一部は IKE_SA_INIT 交換で確立した鍵で暗号化および完全性保護されるため, アイデンティティは盗聴者から隠され, すべてのメッセージのすべてのフィールドが認証される. 暗号鍵の生成方法は第 2.14 節を参照. (IKE_AUTH 交換を完了できない中間者攻撃者でも, イニシエータのアイデンティティは見える.)
初期交換に続くすべてのメッセージは, IKE_SA_INIT 交換で交渉した暗号アルゴリズムと鍵で暗号的に保護される. これらの後続メッセージは第 3.14 節に記載の Encrypted ペイロードの構文を用い, 第 2.14 節に記載の方法で導出した鍵で暗号化される. 後続のすべてのメッセージには Encrypted ペイロードが含まれる. 文中 "empty" と呼んでもよい. CREATE_CHILD_SA, IKE_AUTH, または INFORMATIONAL 交換では, ヘッダに続くメッセージが暗号化され, ヘッダを含むメッセージ全体が IKE SA 用に交渉した暗号アルゴリズムで完全性保護される.
すべての IKE メッセージは固定ヘッダの一部として Message ID を含む. この Message ID はリクエストとレスポンスの対応付けおよびメッセージの再送の識別に用いられる.
以下の説明では, メッセージに含まれるペイロードを下表の名称で示す.
| Notation | Payload |
|---|---|
| AUTH | Authentication |
| CERT | Certificate |
| CERTREQ | Certificate Request |
| CP | Configuration |
| D | Delete |
| EAP | Extensible Authentication |
| HDR | IKE header (not a payload) |
| IDi | Identification - Initiator |
| IDr | Identification - Responder |
| KE | Key Exchange |
| Ni, Nr | Nonce |
| N | Notify |
| SA | Security Association |
| SK | Encrypted and Authenticated |
| TSi | Traffic Selector - Initiator |
| TSr | Traffic Selector - Responder |
| V | Vendor ID |
各ペイロードの内容の詳細は第 3 節に記載する. オプションで現れうるペイロードは [CERTREQ] のように角括弧で示す. これは Certificate Request ペイロードをオプションで含められることを示す.
初期交換は次のとおりである.
Initiator Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni -->
HDR には Security Parameter Indexes (SPI), バージョン番号, Exchange Type, Message ID, 各種フラグが含まれる. SAi1 ペイロードはイニシエータが IKE SA 用にサポートする暗号アルゴリズムを述べる. KE ペイロードはイニシエータの Diffie-Hellman 値を送る. Ni はイニシエータの nonce である.
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
レスポンダはイニシエータの提示から暗号スイートを選び SAr1 ペイロードでそれを表し, KEr ペイロードで Diffie-Hellman 交換を完了し, Nr ペイロードで nonce を送る.
この時点で各当事者は SKEYSEED と呼ばれる量 (第 2.14 節参照) を生成でき, その IKE SA のすべての鍵がそこから導出される. 続くメッセージはメッセージヘッダを除き全体が暗号化および完全性保護される. 暗号化と完全性保護に用いる鍵は SKEYSEED から導出され, SK_e (暗号化) および SK_a (認証, すなわち完全性保護) と呼ばれる, 詳細は第 2.13 節および第 2.14 節. 各方向に別々の SK_e と SK_a が計算される. IKE SA 保護のため Diffie-Hellman 値から導出した SK_e と SK_a に加え, Child SA のさらなる鍵材料導出に用いる SK_d も導出される. 記号 SK { ... } は, これらのペイロードがその方向の SK_e と SK_a で暗号化および完全性保護されることを示す.
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2,
TSi, TSr} -->
イニシエータは IDi ペイロードでアイデンティティを主張し, IDi に対応する秘密の知識を証明し, AUTH ペイロードで最初のメッセージの内容を完全性保護する (第 2.15 節). CERT ペイロードで証明書を, CERTREQ ペイロードで信頼アンカの一覧を送ってもよい. CERT ペイロードを含む場合, 最初に提供する証明書には AUTH フィールド検証用の公開鍵が含まれていなければならない (MUST).
オプションの IDr ペイロードにより, イニシエータはレスポンダのどのアイデンティティと話したいか指定できる. レスポンダを動かすマシンが同一 IP アドレスで複数アイデンティティをホストする場合に有用である. イニシエータが提案した IDr がレスポンダに受け入れられない場合, レスポンダは別の IDr で交換を終えてもよい. イニシエータが要求と異なる IDr をレスポンダが用いたことを受け入れない場合, イニシエータはその事実に気づいた後 SA を閉じてもよい.
Traffic Selector (TSi と TSr) は第 2.9 節で論じる.
イニシエータは SAi2 ペイロードで Child SA の交渉を開始する. 最終フィールド (SAi2 から) は CREATE_CHILD_SA 交換の説明に記載する.
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
レスポンダは IDr ペイロードでアイデンティティを主張し, オプションで証明書を 1 つ以上送る (AUTH 検証用公開鍵を含む証明書を再び先頭に), AUTH ペイロードでアイデンティティを認証し 2 番目のメッセージの完全性を保護し, 以下 CREATE_CHILD_SA 交換の説明の追加フィールドで Child SA の交渉を完了する. IKE_AUTH 交換の双方は, すべての署名と Message Authentication Code (MAC) が正しく計算されていることを検証しなければならない (MUST). いずれかが共有秘密で認証する場合, ID ペイロードの名前は AUTH ペイロード生成に用いた鍵に対応しなければならない (MUST).
イニシエータは IKE_SA_INIT で Diffie-Hellman 値を送るため, レスポンダがサポートするグループの一覧から選ぶ Diffie-Hellman グループを推測しなければならない. 推測が誤っている場合, レスポンダは INVALID_KE_PAYLOAD 型の Notify ペイロードで選択グループを示して応答する. その場合イニシエータは修正された Diffie-Hellman グループで IKE_SA_INIT を再試行しなければならない (MUST). 拒否メッセージは未認証であるため, イニシエータは再び受け入れ可能な暗号スイートの完全な集合を提案しなければならない (MUST). さもなくば能動的攻撃者が双方が好むより強いスイートより弱いスイートに誘導しうる.
IKE_AUTH 交換中に Child SA の作成が何らかの理由で失敗しても, IKE SA は通常どおり作成される. IKE SA の確立を妨げない IKE_AUTH 交換内の Notify メッセージタイプには, 少なくとも NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED がある.
IKE SA の作成に関係する失敗 (例: AUTHENTICATION_FAILED Notify エラーメッセージが返る) の場合, IKE SA は作成されない. IKE_AUTH メッセージは暗号化および完全性保護されているが, この Notify エラーを受け取るピアがまだ他端を認証していない (または何らかの理由で認証に失敗した) 場合, 情報は注意して扱う必要がある. より正確には, MAC が正しく検証できると仮定すれば, エラー Notify の送信者は IKE_SA_INIT 交換のレスポンダであることが分かるが, 送信者のアイデンティティは保証されない.
IKE_AUTH メッセージには KEi/KEr または Ni/Nr ペイロードは含まれない. したがって IKE_AUTH 交換の SA ペイロードは Transform Type 4 (Diffie-Hellman グループ) を NONE 以外の値で含めてはならない. 実装は値 NONE を送る代わりに transform サブ構造全体を省略すべきである (SHOULD).