3.3. SA ペイロード

本書では SA と記載される Security Association（セキュリティアソシエーション）ペイロードは、セキュリティアソシエーションの属性を交渉するために用いられる。SA ペイロードの組み立てには多大な忍耐力を要する。1 つの SA ペイロードには複数の提案（Proposal）を含めることができる。複数の提案がある場合は、最も優先するものから優先度の低いものの順に並べなければならない（MUST）。各提案には単一の IPsec プロトコル（プロトコルは IKE、ESP、または AH であり得る）が含まれ、各プロトコルには複数の変換（Transform）を含めることができ、各変換には複数の属性（Attribute）を含めることができる。SA を解析する際、実装は、ペイロード長（Payload Length）が当該ペイロード内の長さとカウントの合計と一致するかどうかを検査しなければならない（MUST）。提案、変換、および属性はそれぞれ可変長の符号化を持つ。それらは入れ子に構成されており、SA の Payload Length には、SA、提案、変換、および属性の情報が統合された内容が含まれる。提案の長さには、それに含まれるすべての変換と属性の長さが含まれる。変換の長さには、それに含まれるすべての属性の長さが含まれる。

セキュリティアソシエーション、提案、変換、および属性の構文は ISAKMP に基づくが、その意味論（セマンティクス）は異なる。このような複雑さと階層構造の理由は、単一の SA の中に複数の考えられるアルゴリズムの組み合わせを符号化できるようにするためである。複数のアルゴリズムの中から選択しなければならない場合もあれば、アルゴリズムの組み合わせでなければならない場合もある。たとえば、イニシエータは、ESP と（3DES および HMAC_MD5）または（AES および HMAC_SHA1）を提案したいと考え得る。

SA ペイロードの意味論が ISAKMP や IKEv1 と比べて変更された理由の 1 つは、一般的な場合において符号化をよりコンパクトにするためである。

提案構造には、Proposal Num と IPsec プロトコル ID が含まれる。各構造の番号は、直前の構造よりも 1 大きくなければならない（MUST）。イニシエータの SA ペイロードにおける最初の提案の Proposal Num は 1（壱）でなければならない（MUST）。複数の提案を用いる理由の 1 つは、標準的な暗号化アルゴリズムと複合モード（combined-mode）アルゴリズムを同時に提案するためである。複合モードアルゴリズムは、単一の暗号化アルゴリズムの中に完全性と暗号化を取り込むものであり、完全性アルゴリズムを提供しないか、単一の「none」完全性アルゴリズムを提供しなければならない（MUST）。完全性アルゴリズムを提供しないことが推奨（RECOMMENDED）される方法である。イニシエータが複合モードアルゴリズムと通常のアルゴリズムを同時に提案したい場合、2 つの提案を含めなければならない（MUST）。1 つはすべての複合モードアルゴリズムを含み、もう 1 つは完全性アルゴリズム付きのすべての通常のアルゴリズムを含む。たとえば、そのような提案は 2 つの提案構造を持つことになる。提案 1 は ESP であり、CBC モードの AES-128、AES-192、AES-256 を用い、完全性アルゴリズムは HMAC-SHA1-96 または XCBC-96 である。提案 2 は、8 オクテットの完全性チェック値（ICV）を持つ GCM モードの AES-128 または AES-256 である。両方の提案は ESN（拡張シーケンス番号）の使用を許可するが、それを要求するものではない。これは次のように表すことができる。

各提案／プロトコル構造の後には、1 つ以上の変換構造が続く。異なる変換の数は、一般にプロトコルによって決まる。AH には一般に 2 つの変換（拡張シーケンス番号（ESN）と完全性検証アルゴリズム）がある。ESP には一般に 3 つ（ESN、暗号化アルゴリズム、完全性検証アルゴリズム）ある。IKE には一般に 4 つ（Diffie-Hellman 群、完全性検証アルゴリズム、PRF アルゴリズム、暗号化アルゴリズム）ある。各プロトコルについて、許可される変換の集合には、各変換のヘッダに現れる Transform ID 番号が付与される。

同じ Transform Type の変換が複数ある場合、その提案はそれらの変換の「論理和」（OR）である。異なる Transform Type の変換が複数ある場合、その提案は異なるグループ間の「論理積」（AND）である。たとえば、ESP と（3DES または AES-CBC）および（HMAC_MD5 または HMAC_SHA）を提案するには、ESP 提案に 2 つの Transform Type 1 候補（1 つは 3DES 用、1 つは AEC-CBC 用）と 2 つの Transform Type 3 候補（1 つは HMAC_MD5 用、1 つは HMAC_SHA 用）を含める。これは実効的に 4 つのアルゴリズムの組み合わせを提案する。イニシエータが、たとえば（3DES および HMAC_MD5）または（IDEA および HMAC_SHA）のように、これらの組み合わせのサブセットのみを提案したい場合、それを単一の提案内の複数の変換として符号化することはできない。その代わり、イニシエータは、それぞれが 2 つの変換を含む 2 つの異なる提案を構成しなければならない（MUST）。

特定の変換は、1 つ以上の属性を持ち得る（MAY）。属性は、変換を複数の方法で使用できる場合（たとえば可変長の鍵長を持つ暗号化アルゴリズム）に必要となる。変換はアルゴリズムを指定し、属性は鍵長を指定する。ほとんどの変換は属性を持たない。変換は、同じ型の属性を複数持ってはならない（MUST NOT）。ある属性の代替値（たとえば AES 暗号化アルゴリズムの複数の鍵長）を提案するには、実装は、それぞれが別個の属性を持つ、同じ Transform Type の変換を複数含めなければならない（MUST）。

変換と属性の意味論は、IKEv1 のそれとは大きく異なることに注意されたい。IKEv1 では、単一の変換がプロトコルに対する複数のアルゴリズムを担い、そのうち 1 つが変換内で運ばれ、残りが属性内で運ばれていた。

                 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 6:  SA ペイロードのフォーマット

o Proposals（可変長） – 1 つ以上の提案のサブ構造。

SA ペイロードのペイロードタイプは 33（三十三）である。

3.3.1. 提案のサブ構造

                 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 2 | RESERVED | Proposal Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposal Num | Protocol ID | SPI Size |Num Transforms| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 7:  提案のサブ構造

o 0（最後）または 2（続く）（1 バイト） – これが SA 内の最後の提案サブ構造であるかどうかを示す。この構文は ISAKMP から受け継がれたものだが、最後の提案は SA の長さから識別できるため、必須ではない。値（2）は IKEv1 における Proposal のペイロードタイプに対応しており、提案構造の先頭 4 バイトは、ペイロードのヘッダに似るように設計されている。

o RESERVED（1 バイト） – 0 として送信しなければならない（MUST）；受信時には無視しなければならない（MUST）。

o Proposal Length（2 バイト、符号なし整数） – この提案の長さ。後続するすべての変換および属性を含む。

o Proposal Num（1 バイト） – 提案を行う際、SA ペイロードにおける最初の提案は 1 でなければならず（MUST）、後続の提案は直前の提案よりも 1 大きくなければならない（MUST）（これは 2 つの提案間の「論理和」関係を示す）。提案が受け入れられた際、SA ペイロード内の提案番号は、送信された受け入れ済み提案の番号と一致しなければならない（MUST）。

o Protocol ID（1 バイト） – 現在交渉中の IPsec プロトコル識別子を示す。以下の表の値は RFC 4306 発行時点でのみ有効であった。それ以降、他の値が追加されたか、あるいは追加されるであろう。最新の値については、読者は [IKEV2IANA] を参照されたい。

Protocol Protocol ID

IKE 1 AH 2 ESP 3

o SPI Size（1 バイト） – 最初の IKE SA 交渉においては、このフィールドは 0 でなければならない（MUST）；SPI は外側のヘッダから取得される。その後の交渉においては、対応するプロトコル（IKE は 8、ESP および AH は 4）の SPI サイズ（バイト単位）に等しい。

o Num Transforms（1 バイト） – この提案における変換の数を示す。

o SPI（可変長） – 送信エンティティの SPI。SPI Size フィールドが 4 バイトの整数倍でなくとも、ペイロードにパディングは適用されない。SPI Size フィールドが 0 の場合、このフィールドは Security Association ペイロード内に現れない。

o Transforms（可変長） – 1 つ以上の変換サブ構造。

3.3.2. 変換のサブ構造

                 1                   2                   3

     Figure 8:  変換のサブ構造

o 0（最後）または 3（続く）（1 バイト） – これが提案内の最後の変換サブ構造であるかどうかを示す。この構文は ISAKMP から受け継がれたものだが、最後の変換は提案の長さから識別できるため、必須ではない。値（3）は IKEv1 における Transform のペイロードタイプに対応しており、変換構造の先頭 4 バイトは、ペイロードのヘッダに似るように設計されている。

o RESERVED – 0 として送信しなければならない（MUST）；受信時には無視しなければならない（MUST）。

o Transform Length – 変換サブ構造の長さ（バイト単位）。ヘッダおよび属性を含む。

o Transform Type（1 バイト） – この提案で指定された変換の型。異なるプロトコルは異なる変換の型をサポートする。一部のプロトコルでは、一部の変換が省略可能であり得る。ある変換が省略可能であり、イニシエータがその変換を除外して提案したい場合、その型の変換を提案に含めない。イニシエータが、その変換をレスポンダに対して省略可能としたい場合、選択肢の 1 つとして Transform ID = 0 を持つ変換サブ構造を含める。

o Transform ID（2 バイト） – 提案された変換型の具体的なインスタンス。

Transform Type の値は以下の表に示すとおりである。以下の表の値は RFC 4306 発行時点でのみ有効であった。それ以降、他の値が追加されたか、あるいは追加されるであろう。最新の値については、読者は [IKEV2IANA] を参照されたい。

Description Trans. Used In Type

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

(*) 本書で規定する暗号化ペイロードフォーマットに関しては、完全性アルゴリズムの交渉は必須である。たとえば、 [AEAD] は、別個の完全性アルゴリズムを交渉しない、認証付き暗号化（authenticated encryption）に基づく追加のフォーマットを規定している。

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（疑似乱数関数）について、Transform ID は以下の表に示すとおりである。以下の表の値は RFC 4306 発行時点でのみ有効であった。それ以降、他の値が追加されたか、あるいは追加されるであろう。最新の値については、読者は [IKEV2IANA] を参照されたい。

Name Number Defined In

PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_SHA1 2 (RFC2104), [SHA] 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 1 Appendix B 1024-bit MODP 2 Appendix B 1536-bit MODP 5 [ADDGROUP] 2048-bit MODP 14 [ADDGROUP] 3072-bit MODP 15 [ADDGROUP] 4096-bit MODP 16 [ADDGROUP] 6144-bit MODP 17 [ADDGROUP] 8192-bit MODP 18 [ADDGROUP]

ESP および AH は Diffie-Hellman 交換を直接含まないが、Child SA のために Diffie-Hellman 群を交渉してもよい（MAY）。これにより、ピアは CREATE_CHILD_SA 交換において Diffie-Hellman を用いて、生成された Child SA の鍵に対する perfect forward secrecy（完全転送秘密性）を提供できる。

Transform Type 5（拡張シーケンス番号）について、定義済みの Transform ID は以下の表に示すとおりである。以下の表の値は RFC 4306 発行時点でのみ有効であった。それ以降、他の値が追加されたか、あるいは追加されるであろう。最新の値については、読者は [IKEV2IANA] を参照されたい。

Name Number

No Extended Sequence Numbers 0 Extended Sequence Numbers 1

ESN をサポートするイニシエータは、通常、値「0」と「1」を持つ 2 つの ESN 変換をその提案に含めることに注意されたい。値「1」を持つ単一の ESN 変換のみを含む提案は、通常（拡張でない）シーケンス番号の使用が許容されないことを意味する。

RFC 4306 の発行以降、多数の追加の Transform Type が定義されている。詳細については、IANA の IKEv2 レジストリを参照されたい。

3.3.3. プロトコルごとの有効な変換の型

SA ペイロードに付随する変換の数と型は、SA 自身が存在するプロトコルに依存する。SA を確立する提案は、以下の必須および省略可能な変換の型を持つ。準拠する実装は、それがサポートする各プロトコルのすべての必須および省略可能な型を理解しなければならない（MUST）（ただし、許容できない組み合わせを含む提案を受け入れる必要はない）。ある省略可能な型について、それが受け入れる唯一の値が NONE である場合、提案はその省略可能な型を除外してもよい（MAY）。

Protocol Mandatory Types Optional Types

IKE ENCR, PRF, INTEG*, D-H ESP ENCR, ESN INTEG, D-H AH INTEG, ESN D-H

(*) 本書で規定する暗号化ペイロードフォーマットに関しては、完全性アルゴリズムの交渉は必須である。たとえば、 [AEAD] は、別個の完全性アルゴリズムを交渉しない、認証付き暗号化に基づく追加のフォーマットを規定している。

3.3.4. 必須の Transform ID

本書において相互運用性のためにサポートが必須（MUST）および推奨（SHOULD）とされていた組（suite）は、本文書の進化よりも速く変化し得るため削除された。本書の発行時点において、これらの組は [RFC4307] によって規定されているが、将来更新される可能性があり、また他の RFC が異なる組の集合を規定する可能性があることに注意されたい。

IKEv1 から学ばれた重要な教訓の 1 つは、いかなるシステムも必須のアルゴリズムのみを実装し、それらがすべての顧客にとって最良の選択であると期待すべきではないということである。

IANA は将来さらに変換を追加する可能性が高く、一部の利用者は（特に IKE について）私用の組を用いたいと考えている可能性がある。実装は、特定のサイズ制限まで異なるパラメータをサポートできるようにすべきである（SHOULD）。この目標を支援するため、すべての IKEv2 実装は、（利用者またはシステム管理者が）新しい Diffie-Hellman 群の Diffie-Hellman パラメータ（生成元、法、および指数の長さと値）を指定できる管理機能を含むべきである（SHOULD）。実装は、これらのパラメータと関連する Transform ID を入力することで、そのような群の交渉を可能にする管理インタフェースを提供すべきである（SHOULD）。

すべての IKEv2 実装は、利用者またはシステム管理者が IKE と共に使用する許容される組を指定できる管理機能を含まなければならない（MUST）。Transform ID の集合を含むペイロードを受信した際、実装は、ローカルポリシーに従って提案された組の許容性を検証するため、送信された Transform ID を管理制御によりローカルに設定された Transform ID と比較しなければならない（MUST）。実装は、これらの IKE 組制御によって認可されていない SA 提案を拒否しなければならない（MUST）。なお、暗号組の実装が必須であることが、ローカルポリシーに対して許容可能と設定されていることを意味するものではない。

3.3.5. 変換属性

Security Association ペイロード内の各変換は、その変換の仕様を修正または精緻化する属性を含み得る（MAY）。有効な属性の集合は変換に依存する。現在、定義されている属性型は 1 つだけである。鍵長（Key Length）属性は、可変長の鍵を持つ一部の暗号化変換によって使用される（後述）。

属性は型／値の組であり、以下のように定義される。属性は、固定された 2 バイトの値を持つか、可変長の値を持ち得る。後者の場合、属性は型／長さ／値（TLV）として符号化される。

                 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:  データ属性

o Attribute Format（AF）（1 ビット） – データ属性が型／長さ／値（TLV）フォーマットに従うか、短縮された型／値（TV）フォーマットに従うかを示す。AF ビットが 0 の場合、属性は TLV フォーマットを使用する。AF ビットが 1 の場合、TV フォーマット（2 バイトの値を伴う）が使用される。

o Attribute Type（15 ビット） – 各属性型の一意の識別子（後述）。

o Attribute Value（可変長） – 属性型に関連付けられた属性値。AF ビットが 0 の場合、このフィールドは Attribute Length フィールドで定義される可変長を持つ。AF ビットが 1 の場合、Attribute Value の長さは 2 バイトである。

現在定義されている唯一の属性型（Key Length）は固定長である。可変長符号化の包含は、将来の拡張のためのみである。固定長と記述される属性は、その長さが 2 バイトを超える場合を除き、可変長として符号化してはならない（MUST NOT）。可変長属性は、その値が 2 バイトに収まるとしても、固定長として符号化してはならない（MUST NOT）。注意：これは IKEv1 とは異なる。IKEv1 では、増した柔軟性によってメッセージの作成者を単純化し得たが、間違いなく構文解析器を複雑にした。

以下の表の値は RFC 4306 発行時点でのみ有効であった。それ以降、他の値が追加されたか、あるいは追加されるであろう。最新の値については、読者は [IKEV2IANA] を参照されたい。

Attribute Type Value Attribute Format

Key Length (in bits) 14 TV

値 0–13 および 15–17 は IKEv1 の類似の文脈で使用されたものであり、対応する値でない限り割り当てられるべきではない。

鍵長（Key Length）属性は鍵長をビット単位で指定し（ネットワークバイトオーダーを使用しなければならない（MUST））、一部の変換に以下のように適用される。

o 鍵長属性は、固定長の鍵を用いる変換には使用してはならない（MUST NOT）。これには、ENCR_DES、ENCR_IDEA、および本書で規定されるすべての型 2（疑似乱数関数）および型 3（完全性アルゴリズム）の変換が含まれる。将来の型 2 または型 3 の変換は、この属性を使用しないことが推奨される。

o 一部の変換は、鍵長属性を常に含めなければならない（MUST）と規定している（属性の除外は許されず、それを含まない提案は拒否しなければならない（MUST））。これには、たとえば ENCR_AES_CBC および ENCR_AES_CTR が含まれる。

o 一部の変換は、可変長の鍵を許可するが、属性が含まれない場合の既定の鍵長を規定している。これには、たとえば ENCR_RC5 および ENCR_BLOWFISH が含まれる。

実装上の注意：相互運用性をさらに向上させ、独立してアップグレードされるエンドポイントを支援するため、このプロトコルの実装は、より高いセキュリティを提供すると考えられる数値を受け入れてよい（SHOULD）。たとえば、ピアがある暗号について X ビットの鍵長を受け入れるように設定されており、その暗号のより長い鍵長が提示された場合、実装がより長い鍵の使用をサポートしていれば、その提案を受け入れるべきである（SHOULD）。

この能力のサポートにより、レスポンダは「少なくとも」あるセキュリティレベル——「Y という暗号の鍵長は少なくとも X ビット」——という概念を表現できる。しかしながら、属性は常にそのまま返されるため（次節参照）、複数の鍵長を受け入れたいイニシエータは、それぞれが異なる鍵長属性を持つ、同じ Transform Type の変換を複数含めなければならない（MUST）。

3.3.6. 属性の交渉

セキュリティアソシエーションの交渉中、イニシエータはレスポンダに提案を提示する。レスポンダは、提案の中から単一の完全なパラメータの組を選択しなければならない（MUST）（許容可能な提案がない場合は、すべての提案を拒否する）。複数の提案がある場合、レスポンダは単一の提案を選択しなければならない（MUST）。選択された提案に同じ型の変換が複数ある場合、レスポンダは単一の変換を選択しなければならない（MUST）。選択された変換のすべての属性は、そのまま返されなければならない（MUST）。交換のイニシエータは、受け入れられた提案が自身の提案のいずれかと一致するか検査しなければならず（MUST）、一致しない場合は交換を打ち切らなければならない（MUST）。

レスポンダが、理解できない Transform Type を含む提案、または必須の Transform Type を欠く提案を受信した場合、その提案を許容不可能とみなさなければならない（MUST）。ただし、同じ SA ペイロード内の他の提案は通常通り処理される。同様に、レスポンダが、理解できない変換、または理解できない Transform Attribute を含む変換を受信した場合、その変換を許容不可能とみなさなければならない（MUST）。同じ Transform Type の他の変換は通常通り処理される。これにより、将来の新しい Transform Type および Transform Attribute の定義が可能となる。

Diffie-Hellman 群の交渉には、いくつかの特有の課題がある。SA 提案は、同じメッセージ内に提案の属性と Diffie-Hellman 公開値（KE）の両方を含む。最初の交換において、イニシエータが複数の Diffie-Hellman 群のうちの 1 つを使用することを提案する場合、レスポンダが最も受け入れそうなものを選択し、それに対応する KE を含めるべきである（SHOULD）。レスポンダが（NONE を除く）異なる Diffie-Hellman 群を用いる提案を選択した場合、応答の中で正しい群を示し、イニシエータは最初のメッセージを再送する際に、その群の要素を KE 値として選択すべきである（SHOULD）。ただし、中間者によるダウングレード攻撃を防ぐため、サポートする群の完全な集合を引き続き提案すべきである（SHOULD）。提案された群の 1 つが NONE の Diffie-Hellman 群であり、レスポンダがその Diffie-Hellman 群を選択した場合、レスポンダはイニシエータの KE ペイロードを無視し、応答から KE ペイロードを省略しなければならない（MUST）。