3.3 Security Association Payload (SA ペイロード)
3.3 Security Association Payload (SA ペイロード)
Security Association ペイロードは本文書では SA と記し, セキュリティアソシエーション (Security Association) の属性を交渉するために用いる. SA ペイロードの組み立てには十分な注意が必要である. SA ペイロードは複数の proposal を含んでもよい (MAY). 複数ある場合は, 最も望ましいものから順に並べなければならない (MUST). 各 proposal は単一の IPsec プロトコル (IKE, ESP, AH のいずれか) を含み, 各プロトコルは複数の transform を含んでもよく (MAY), 各 transform は複数の attribute を含んでもよい (MAY). SA を解析する際, 実装は総 Payload Length が内部の長さおよび個数と整合するか確認しなければならない (MUST). Proposal, Transform, Attribute はそれぞれ可変長符号化を持ち, SA の Payload Length は SA, Proposal, Transform, Attribute 情報の合計を含むようにネストする. Proposal の長さは内包するすべての Transform と Attribute の長さを含み, Transform の長さは内包するすべての Attribute の長さを含む.
Security Association, Proposal, Transform, Attribute の構文は ISAKMP に基づくが, 意味論はやや異なる. 複雑さと階層の理由は, 単一の SA に複数の可能なアルゴリズム組み合わせを符号化できるようにするためである. 複数アルゴリズムの選択の場合もあれば, 組み合わせの場合もある. 例えば発起者は ESP で (3DES と HMAC_MD5) または (AES と HMAC_SHA1) を提案したいことがある.
ISAKMP および IKEv1 から SA ペイロードの意味論が変わった理由の一つは, よくあるケースで符号化をよりコンパクトにするためである.
Proposal 構造には Proposal Num と IPsec プロトコル ID が含まれる. 各構造の proposal 番号は直前より 1 大きくなければならない (MUST). 発起者の SA ペイロードの最初の Proposal の Proposal Num は 1 でなければならない (MUST). 複数 proposal を用いる理由の一つは, 標準暗号と結合モード暗号 (combined-mode cipher) の両方を提案するためである. 結合モード暗号は単一の暗号アルゴリズムに完全性と暗号化の両方を含み, 完全性アルゴリズムを提供しないか, 単一の "NONE" 完全性アルゴリズムのいずれかでなければならず (MUST), 完全性アルゴリズムなしが推奨される (RECOMMENDED). 発起者が結合モードと通常暗号の両方を提案する場合, 2 つの proposal を含めなければならない: 一方はすべての結合モード暗号, 他方は完全性アルゴリズム付きのすべての通常暗号である. 例として 2 つの proposal 構造を持つ. Proposal 1 は CBC モードの ESP で AES-128, AES-192, AES-256, 完全性は HMAC-SHA1-96 または XCBC-96; Proposal 2 は GCM の AES-128 または AES-256 で 8 オクテットの ICV (Integrity Check Value). いずれも ESN (Extended Sequence Numbers) の利用を許容するが要求しない. 図示すると次のとおり:
SA Payload
|
+--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
| | 7 transforms, SPI = 0x052357bb )
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 128 )
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 192 )
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 256 )
| |
| +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
| +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
| +-- Transform ESN ( Name = ESNs )
| +-- Transform ESN ( Name = No ESNs )
|
+--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
| 4 transforms, SPI = 0x35a1d6f2 )
|
+-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
| +-- Attribute ( Key Length = 128 )
|
+-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
| +-- Attribute ( Key Length = 256 )
|
+-- Transform ESN ( Name = ESNs )
+-- Transform ESN ( Name = No ESNs )
各 Proposal/Protocol 構造の後に 1 つ以上の transform 構造が続く. transform の種類数は一般にプロトコルで決まる. AH は通常 2 つ: ESN と完全性検証アルゴリズム. ESP は通常 3 つ: ESN, 暗号アルゴリズム, 完全性検証アルゴリズム. IKE は通常 4 つ: Diffie-Hellman 群, 完全性検証, PRF, 暗号アルゴリズム. 各プロトコルで許容される transform 集合に Transform ID が割り当てられ, 各 transform ヘッダに現れる.
同一 Transform Type の transform が複数あれば proposal はそれらの論理和 (OR) である. 異なる Transform Type が複数あれば論理積 (AND) である. 例: ESP で (3DES または AES-CBC) かつ (HMAC_MD5 または HMAC_SHA) を提案するには, Transform Type 1 が 2 つ (3DES と AEC-CBC), Type 3 が 2 つ (HMAC_MD5 と HMAC_SHA) となる. 実質 4 通りの組み合わせを提案する. (3DES と HMAC_MD5) または (IDEA と HMAC_SHA) のような部分集合だけを単一 Proposal 内の複数 transform で符号化することはできない. その場合は transform が 2 つずつの異なる Proposal を 2 つ作る必要がある.
ある transform は 1 つ以上の attribute を持ってもよい (MAY). 暗号の鍵長が可変など, 複数の使い方があるとき attribute が必要である. transform がアルゴリズムを, attribute が鍵長を指定する. 多くの transform に attribute はない. 同一タイプの attribute を複数持ってはならない (MUST NOT). 属性の別値を提案するには (例: AES の複数鍵長), 同一 Transform Type の transform を複数, 各々単一 attribute で含めなければならない (MUST).
Transform と Attribute の意味論は IKEv1 とは大きく異なる. IKEv1 では 1 つの Transform が複数アルゴリズムを運び, 1 つは Transform に, 残りは Attribute に載る.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Proposals> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Security Association Payload
- Proposals (可変) - 1 つ以上の proposal 下位構造.
Security Association ペイロードのペイロード型番号は 33 である.
3.3.1 Proposal Substructure (提案下位構造)
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Substruc | RESERVED | Proposal Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proposal Num | Protocol ID | SPI Size |Num Transforms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Transforms> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Proposal Substructure
-
Last Substruc (1 オクテット) - SA 内の最後の Proposal 下位構造かどうか. 最後なら 0, まだ続くなら 2. ISAKMP 由来の構文だが SA の長さから最後は分かるため必須ではない. 値 2 は IKEv1 の Proposal ペイロード型に対応し, 先頭 4 オクテットはペイロードヘッダに似せてある.
-
RESERVED (1 オクテット) - 送信時はゼロ (MUST), 受信時は無視 (MUST).
-
Proposal Length (2 オクテット, 符号なし) - 本 proposal の長さ (続く transform と attribute を含む).
-
Proposal Num (1 オクテット) - 提案時, SA ペイロードの最初は 1, 以降は直前より 1 大きい (OR を示す). 採択時, SA 内の番号は採択された送信 proposal の番号と一致しなければならない (MUST).
-
Protocol ID (1 オクテット) - 現在の交渉の IPsec プロトコル識別子. 下表は RFC 4306 時点. 最新は [IKEV2IANA].
| Protocol | Protocol ID |
|---|---|
| IKE | 1 |
| AH | 2 |
| ESP | 3 |
-
SPI Size (1 オクテット) - 初期 IKE SA 交渉ではゼロ (MUST); SPI は外側ヘッダから得る. 以降の交渉では対応プロトコルの SPI のオクテット長 (IKE は 8, ESP/AH は 4).
-
Num Transforms (1 オクテット) - 本 proposal の transform 数.
-
SPI (可変) - 送信側の SPI. SPI Size が 4 の倍数でなくてもパディングしない. SPI Size がゼロなら本フィールドはない.
-
Transforms (可変) - 1 つ以上の transform 下位構造.
3.3.2 Transform Substructure (変換下位構造)
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Substruc | RESERVED | Transform Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type | RESERVED | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Transform Attributes ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Transform Substructure
-
Last Substruc (1 オクテット) - Proposal 内で最後の Transform 下位構造か. 最後なら 0, 続きがあれば 3. ISAKMP 由来. 値 3 は IKEv1 の Transform ペイロード型に対応.
-
RESERVED - 送信時ゼロ (MUST), 受信時無視 (MUST).
-
Transform Length - ヘッダと Attribute を含む下位構造の長さ (オクテット).
-
Transform Type (1 オクテット) - 本 transform の種類. プロトコルごとに異なる. 任意の transform は, 省略を提案するならその型を proposal に含めない. 応答者に任せるなら Transform ID = 0 の下位構造を選択肢の一つに含める.
-
Transform ID (2 オクテット) - 提案する Transform Type の具体インスタンス.
Transform Type の値は下表. RFC 4306 時点. 最新は [IKEV2IANA].
| Description | Trans. Type | Used In |
|---|---|---|
| Encryption Algorithm (ENCR) | 1 | IKE and ESP |
| Pseudorandom Function (PRF) | 2 | IKE |
| Integrity Algorithm (INTEG) | 3 | IKE*, AH, optional in ESP |
| Diffie-Hellman Group (D-H) | 4 | IKE, optional in AH & ESP |
| Extended Sequence Numbers (ESN) | 5 | AH and ESP |
(*) 本文書の Encrypted ペイロード形式では完全性アルゴリズムの交渉が必須である. 例えば [AEAD] は認証付き暗号に基づく追加形式を定め, 別途完全性を交渉しない.
Transform Type 1 (暗号アルゴリズム) の Transform ID は下表. RFC 4306 時点. 最新は [IKEV2IANA].
| Name | Number | Defined In |
|---|---|---|
| ENCR_DES_IV64 | 1 | (UNSPECIFIED) |
| ENCR_DES | 2 | [RFC2405], [DES] |
| ENCR_3DES | 3 | [RFC2451] |
| ENCR_RC5 | 4 | [RFC2451] |
| ENCR_IDEA | 5 | [RFC2451], [IDEA] |
| ENCR_CAST | 6 | [RFC2451] |
| ENCR_BLOWFISH | 7 | [RFC2451] |
| ENCR_3IDEA | 8 | (UNSPECIFIED) |
| ENCR_DES_IV32 | 9 | (UNSPECIFIED) |
| ENCR_NULL | 11 | [RFC2410] |
| ENCR_AES_CBC | 12 | [RFC3602] |
| ENCR_AES_CTR | 13 | [RFC3686] |
Transform Type 2 (疑似乱数関数, PRF) の Transform ID は下表. RFC 4306 時点. 最新は [IKEV2IANA].
| Name | Number | Defined In |
|---|---|---|
| PRF_HMAC_MD5 | 1 | [RFC2104], [MD5] |
| PRF_HMAC_SHA1 | 2 | [RFC2104], [FIPS.180-4.2012] |
| PRF_HMAC_TIGER | 3 | (UNSPECIFIED) |
Transform Type 3 (完全性アルゴリズム) の定義済み Transform ID は下表. RFC 4306 時点. 最新は [IKEV2IANA].
| Name | Number | Defined In |
|---|---|---|
| NONE | 0 | |
| AUTH_HMAC_MD5_96 | 1 | [RFC2403] |
| AUTH_HMAC_SHA1_96 | 2 | [RFC2404] |
| AUTH_DES_MAC | 3 | (UNSPECIFIED) |
| AUTH_KPDK_MD5 | 4 | (UNSPECIFIED) |
| AUTH_AES_XCBC_96 | 5 | [RFC3566] |
Transform Type 4 (Diffie-Hellman 群) の定義済み Transform ID は下表. RFC 4306 時点. 最新は [IKEV2IANA].
| Name | Number | Defined In |
|---|---|---|
| NONE | 0 | |
| 768-bit MODP Group | 1 | Appendix B |
| 1024-bit MODP Group | 2 | Appendix B |
| 1536-bit MODP Group | 5 | [ADDGROUP] |
| 2048-bit MODP Group | 14 | [ADDGROUP] |
| 3072-bit MODP Group | 15 | [ADDGROUP] |
| 4096-bit MODP Group | 16 | [ADDGROUP] |
| 6144-bit MODP Group | 17 | [ADDGROUP] |
| 8192-bit MODP Group | 18 | [ADDGROUP] |
ESP と AH は直接 Diffie-Hellman 交換を含まないが, Child SA 用に Diffie-Hellman 群を交渉してもよい (MAY). ピアは CREATE_CHILD_SA で Diffie-Hellman を用い, 生成した Child SA 鍵に完全前方秘匿を与えられる.
上記 MODP 群に特別な妥当性テストは不要だが, 楕円曲線群や小子群を持つ MODP 群などは安全利用のため追加テストが必要である. 詳細は [RFC6989].
Transform Type 5 (拡張シーケンス番号, ESN) の定義済み Transform ID は下表. RFC 4306 時点. 最新は [IKEV2IANA].
| Name | Number |
|---|---|
| No Extended Sequence Numbers | 0 |
| Extended Sequence Numbers | 1 |
ESN を支持する発起者は通常, 提案に値 "0" と "1" の 2 つの ESN transform を含める. ESN transform が 1 つだけで値 "1" の proposal は, 通常 (非拡張) シーケンス番号は受け付けないことを意味する.
RFC 4306 以降, 多数の追加 Transform Type が定義されている. IANA の "Internet Key Exchange Version 2 (IKEv2) Parameters" レジストリを参照.
3.3.3 Valid Transform Types by Protocol (プロトコル別に有効な変換タイプ)
SA ペイロードに付随する transform の数と型は, SA 内のプロトコルに依存する. SA 確立を提案する SA ペイロードは以下の必須・任意 Transform Type を持つ. 適合実装は支持する各プロトコルについて必須・任意のすべての型を理解しなければならない (MUST) (ただし不適切な suite の提案は拒否してよい). 任意型について受け入れるのが NONE のみなら, proposal から省略してもよい (MAY).
| Protocol | Mandatory Types | Optional Types |
|---|---|---|
| IKE | ENCR, PRF, INTEG*, D-H | |
| ESP | ENCR, ESN | INTEG, D-H |
| AH | INTEG, ESN | D-H |
(*) 本文書の Encrypted ペイロード形式では完全性アルゴリズムの交渉が必須である. 例えば [AEAD] は認証付き暗号に基づく追加形式を定め, 別途完全性を交渉しない.
3.3.4 Mandatory Transform IDs (必須 Transform ID)
相互運用のため MUST/SHOULD で支持する suite の指定は本文書から削除した. 変更が本文書より速いためである. 本文書公開時点では [RFC4307] がこれらを定めるが, 将来更新され, 他の RFC が異なる集合を定めてもよい.
IKEv1 からの教訓として, 必須アルゴリズムだけを実装しすべての顧客に最適だと期待してはならない.
IANA は今後も transform を追加し, ユーザーは私有 suite を使いたい場合がある. 特に IKE では実装は上限まで異なるパラメータを支持すべきである. そのためすべての IKEv2 実装は, 新しい Diffie-Hellman 群のパラメータ (生成元, 法, 指数の長さと値) を (ユーザーまたは管理者が) 指定できる管理機能を含めるべきである (SHOULD). これらのパラメータと Transform ID を入力する管理インタフェースも提供すべきである (SHOULD).
すべての IKEv2 実装は, IKE で使用してよい suite をユーザーまたは管理者が指定できる管理機能を含めなければならない (MUST). Transform ID の集合を含むペイロードを受け取ったら, 送信された ID を管理設定と照合し, ローカル方針に適合するか検証しなければならない (MUST). これらの制御で許可されない SA 提案は拒否しなければならない (MUST). MUST で実装する suite がローカル方針で許可リストに入っている必要はない.
3.3.5 Transform Attributes (変換属性)
SA ペイロード内の各 transform は, 仕様を変更または完成させる attribute を含んでもよい. 有効な attribute 集合は transform による. 現在定義されているのは Key Length のみで, 可変鍵長の一部の暗号 transform が用いる (下記).
attribute は型/値の対であり, 値は固定 2 オクテットまたは可変長. 可変長は type/length/value で符号化する.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Attribute Type | AF=0 Attribute Length |
|F| | AF=1 Attribute Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AF=0 Attribute Value |
| AF=1 Not Transmitted |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Data Attributes
-
Attribute Format (AF) (1 ビット) - TLV か短縮 TV か. AF が 0 なら TLV, 1 なら 2 オクテット値の TV.
-
Attribute Type (15 ビット) - attribute 型の一意識別子 (下記).
-
Attribute Value (可変長) - 型に対応する値. AF が 0 なら Attribute Length で長さ定義. AF が 1 なら長さ 2 オクテット.
現時点で定義されている Key Length は固定長である. 可変長の説明は将来拡張用. 固定長と記された attribute は 2 オクテットを超えない限り可変長符号化を使ってはならない (MUST NOT). 可変長 attribute を値が 2 オクテットに収まっても固定長で符号化してはならない (MUST NOT). 注: IKEv1 とは異なり, 柔軟性は構成を簡単にしたが解析を複雑にした.
下表は RFC 4306 時点. 最新は [IKEV2IANA].
| Attribute Type | Value | Attribute Format |
|---|---|---|
| Key Length (in bits) | 14 | TV |
値 0-13 と 15-17 は IKEv1 の類似文脈で使用済みであり, 対応する値以外に割り当てないこと.
Key Length attribute はビット単位の鍵長を指定する (ネットワークバイトオーダー MUST). 適用は次のとおり:
-
固定長鍵の transform では Key Length を使ってはならない (MUST NOT). 例: ENCR_DES, ENCR_IDEA, 本文書の Type 2 および Type 3 のすべて. 将来の Type 2/3 では本 attribute を使わないことが望ましい.
-
一部の transform は Key Length を常に含めなければならない (MUST) (省略不可, 含まない提案は拒否 MUST). 例: ENCR_AES_CBC, ENCR_AES_CTR.
-
一部は可変鍵長を許すが, attribute 省略時のデフォルト鍵長を定める. 例: ENCR_RC5, ENCR_BLOWFISH.
実装ノート: 相互運用と端点の独立アップグレードのため, より高い安全性と判断する値は受け入れるべきである (SHOULD). 例: ピアが X ビットまで受け入れる設定で, より長い鍵長で提案された場合, 長い鍵を支持するなら受け入れるべきである (SHOULD).
応答者は「少なくとも X ビット」という要件を表現できる. ただし attribute は変更されず返る (次節) ので, 複数鍵長を受け入れる発起者は同一 Transform Type で異なる Key Length を複数 transform で含める必要がある.
3.3.6 Attribute Negotiation (属性交渉)
SA 交渉で発起者が応答者に提案を示す. 応答者は提案から単一の完全なパラメータ集合を選ばなければならない (MUST) (すべて不可ならすべて拒否). proposal が複数なら 1 つ選ぶ (MUST). 選んだ proposal に同一型の transform が複数あれば 1 つ選ぶ (MUST). 選んだ transform の attribute は変更せず返す (MUST). 発起者は採択が自らのいずれかの提案と整合するか確認し, しなければ交換を終了しなければならない (MUST).
応答者が理解できない Transform Type を含む proposal, または必須 Transform Type が欠ける proposal を受け取った場合, その proposal は不可とみなす (MUST); 同一 SA ペイロードの他 proposal は通常処理する. 理解できない transform, または理解できない Transform Attribute を含む transform を受け取った場合もその transform は不可 (MUST); 同一 Transform Type の他 transform は通常処理する. 将来の型定義を可能にする.
Diffie-Hellman 群の交渉には難しさがある. SA 提案は同じメッセージに属性提案と KE を含む. 初期交渉で複数群のいずれかを提案する場合, 応答者が最も受け入れそうな群を選び (SHOULD), 対応する KE を含めるべきである. 応答者が別の群 (NONE 以外) を選んだら応答で正しい群を示し, 発起者は最初のメッセージ再送時にその群の元を KE に選ぶべきである (SHOULD). ただし中間者によるダウングレード攻撃を防ぐため, 支持する群の全集は提案し続けるべきである (SHOULD). 提案の一つが群 NONE で応答者がそれを選んだら, 発起者の KE を無視し (MUST), 応答に KE を含めてはならない (MUST).