3.3 Security Association Payload (安全关联载荷)
3.3 Security Association Payload (安全关联载荷)
Security Association 载荷在本文档中记为 SA, 用于协商安全关联 (Security Association) 的属性. 组装 SA 载荷需要非常谨慎. SA 载荷可以包含多个 proposal (提案). 若多于一个, 必须按从最受偏好到最不受偏好的顺序排列. 每个 proposal 包含单一 IPsec 协议 (协议指 IKE, ESP 或 AH), 每个协议可以包含多个 transform (变换), 每个 transform 可以包含多个 attribute (属性). 解析 SA 时, 实现必须检查总 Payload Length 是否与载荷内部长度及计数一致. 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. 发起方 SA 载荷中的第一个 Proposal 的 Proposal Num 必须为 1. 使用多个 proposal 的原因之一, 是同时提议标准密码算法与组合模式密码 (combined-mode cipher). 组合模式密码在单一加密算法中同时提供完整性与加密, 必须要么不提供完整性算法, 要么仅提供单一完整性算法且为 "NONE", 推荐采用不提供完整性算法的方式. 若发起方希望同时提议组合模式密码与普通密码, 必须包含两个 proposal: 其一包含全部组合模式密码, 另一包含带完整性算法的全部普通密码. 例如, 某一提议可有两个 proposal 结构. Proposal 1 为采用密码分组链接 (Cipher Block Chaining, CBC) 模式的 ESP, 密钥长度可为 AES-128, AES-192, AES-256, 完整性算法为 HMAC-SHA1-96 或 XCBC-96 之一; Proposal 2 为 GCM 模式下的 AES-128 或 AES-256, 带 8 字节完整性校验值 (Integrity Check Value, ICV). 两个 proposal 均允许但不要求使用 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 结构之后跟一个或多个 transform 结构. 不同 transform 的数量一般由协议决定. AH 通常有两个 transform: ESN 与完整性校验算法. ESP 通常有三个: ESN, 加密算法与完整性校验算法. IKE 通常有四个 transform: Diffie-Hellman 群, 完整性校验算法, PRF 算法与加密算法. 对每种协议, 允许的 transform 集合被分配 Transform ID 编号, 出现在各 transform 首部中.
若存在多个相同 Transform Type 的 transform, 则 proposal 表示这些 transform 的析取 (OR). 若存在多个不同 Transform Type 的 transform, 则 proposal 表示各组之间的合取 (AND). 例如, 要提议 ESP 使用 (3DES 或 AES-CBC) 且 (HMAC_MD5 或 HMAC_SHA), ESP proposal 应包含两个 Transform Type 1 候选 (分别对应 3DES 与 AEC-CBC) 以及两个 Transform Type 3 候选 (分别对应 HMAC_MD5 与 HMAC_SHA). 这实际上提议了四种算法组合. 若发起方只想提议其中一部分, 例如 (3DES 与 HMAC_MD5) 或 (IDEA 与 HMAC_SHA), 则无法在单个 Proposal 内用多个 transform 编码. 此时发起方必须构造两个不同的 Proposal, 各含两个 transform.
给定 transform 可以带有一个或多个 Attribute. 当 transform 有多种用法时需要 Attribute, 例如加密算法具有可变密钥长度时, transform 指明算法, attribute 指明密钥长度. 大多数 transform 没有 attribute. 同一 transform 不得包含多个相同类型的 attribute. 要为某一 attribute 提议多个可选值 (例如 AES 的多种密钥长度), 实现必须包含多个相同 Transform Type 的 transform, 各带单一 Attribute.
注意 Transform 与 Attribute 的语义与 IKEv1 很不相同. 在 IKEv1 中, 单个 Transform 为某协议承载多种算法, 一种在 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 (可变) - 一个或多个 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 子结构. 若为最后一个 Proposal 子结构则值为 0, 若其后还有 Proposal 子结构则值为 2. 该语法继承自 ISAKMP, 但并非必要, 因为最后一个 Proposal 也可由 SA 长度确定. 值 (2) 对应 IKEv1 中 Proposal 载荷类型, Proposal 结构的前四字节设计成略似载荷首部.
-
RESERVED (1 字节) - 发送时必须为 0; 接收时必须忽略.
-
Proposal Length (2 字节, 无符号整数) - 本 proposal 的长度, 包含其后所有 transform 与 attribute.
-
Proposal Num (1 字节) - 发出提议时, SA 载荷中第一个 proposal 必须为 1, 后续 proposal 必须比前一个大 1 (表示两个 proposal 之间为 OR). 接受提议时, SA 载荷中的 proposal 编号必须与所接受的已发送 proposal 上的编号一致.
-
Protocol ID (1 字节) - 指明当前协商所用的 IPsec 协议标识. 下表取值仅截至 RFC 4306 发布时有效, 此后可能已有新增. 读者应查阅 [IKEV2IANA] 获取最新取值.
| Protocol | Protocol ID |
|---|---|
| IKE | 1 |
| AH | 2 |
| ESP | 3 |
-
SPI Size (1 字节) - 对初始 IKE SA 协商, 本字段必须为零; SPI 从外层首部取得. 后续协商中, 本字段等于对应协议 SPI 的字节长度 (IKE 为 8, ESP 与 AH 为 4).
-
Num Transforms (1 字节) - 指明本 proposal 中的 transform 数量.
-
SPI (可变) - 发送实体的 SPI. 即使 SPI Size 不是 4 的倍数, 也不对载荷做填充. 当 SPI Size 为零时, Security Association 载荷中不存在本字段.
-
Transforms (可变) - 一个或多个 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 子结构. 若为最后一个 Transform 子结构则值为 0, 若其后还有 Transform 子结构则值为 3. 该语法继承自 ISAKMP, 但并非必要, 因为最后一个 transform 也可由 proposal 长度确定. 值 (3) 对应 IKEv1 中 Transform 载荷类型, Transform 结构的前四字节设计成略似载荷首部.
-
RESERVED - 发送时必须为 0; 接收时必须忽略.
-
Transform Length - Transform 子结构的长度 (以字节计), 含首部与 Attribute.
-
Transform Type (1 字节) - 本 transform 所指定的变换类型. 不同协议支持不同的 Transform Type. 对某些协议, 部分 transform 可为可选. 若某 transform 可选且发起方希望提议省略该 transform, 则在 proposal 中不包含该类型的 transform. 若发起方希望由响应方决定是否使用该 transform, 则可在选项中加入 Transform ID = 0 的 transform 子结构.
-
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 群. 这样对等方可在 CREATE_CHILD_SA 交换中使用 Diffie-Hellman, 为生成的 Child SA 密钥提供完美前向保密 (perfect forward secrecy).
注意, 上文所列 MODP Diffie-Hellman 群无需执行特殊有效性测试, 但其他类型的群 (椭圆曲线群, 以及具有小子群的 MODP 群) 要安全使用需执行额外测试. 详见 "Additional Diffie-Hellman Tests for IKEv2" ([RFC6989]).
Transform Type 5 (扩展序列号, ESN) 的已定义 Transform ID 见下表. 取值仅截至 RFC 4306 发布时有效, 此后可能已有新增. 读者应查阅 [IKEV2IANA] 获取最新取值.
| Name | Number |
|---|---|
| No Extended Sequence Numbers | 0 |
| Extended Sequence Numbers | 1 |
注意, 支持 ESN 的发起方通常会在其提议中包含两个 ESN transform, 取值分别为 "0" 与 "1". 若某提议仅含一个取值为 "1" 的 ESN transform, 表示不接受使用普通 (非扩展) 序列号.
自 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. 合规实现必须理解其所支持各协议的全部必选与可选类型 (尽管仍可拒收不可接受的套件提议). 若对可选类型唯一可接受的取值为 NONE, 则 proposal 可以省略这些可选类型.
| 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) 支持的套件规定已从本文档中移除, 因为其变更速度可能快于本文档演进. 本文档发布时, 这些套件由 [RFC4307] 规定, 但该文档日后可能被更新, 其他 RFC 也可能规定不同的套件集合.
从 IKEv1 得到的一条重要经验是, 任何系统都不应只实现必选算法并指望它们对所有客户都是最佳选择.
未来 IANA 很可能继续增加 transform, 部分用户可能希望使用私有套件, 尤其对 IKE 而言, 实现应能在一定长度上限内支持不同参数. 为支持该目标, 所有 IKEv2 实现应该包含管理功能, 允许 (由用户或系统管理员) 指定新 Diffie-Hellman 群的 Diffie-Hellman 参数 (生成元, 模数, 指数长度与取值). 实现应该提供管理接口, 供 (用户或系统管理员) 输入这些参数及关联 Transform ID, 以便协商此类群.
所有 IKEv2 实现必须包含管理功能, 使用户或系统管理员能够指定可与 IKE 一起使用的可接受套件. 收到带有 Transform ID 集合的载荷时, 实现必须将收到的 Transform ID 与通过管理控制本地配置的集合比对, 以根据本地策略验证所提议套件是否可接受. 实现必须拒收未经这些 IKE 套件控制授权的 SA 提议. 注意, 必须实现的密码学套件不必配置为本地策略可接受.
3.3.5 Transform Attributes (变换属性)
Security Association 载荷中的每个 transform 可包含用于修改或补全该 transform 规范的 attribute. 合法 attribute 集合取决于 transform. 目前仅定义一种 attribute 类型: Key Length attribute 由某些具有可变长度密钥的加密 transform 使用 (详见下文).
attribute 为类型/取值对, 定义见下. attribute 的取值可以是固定两字节长度, 也可以是变长; 后者按 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 比特) - 指明数据属性遵循 Type/Length/Value (TLV) 格式还是简化的 Type/Value (TV) 格式. AF 为 0 时使用 TLV; AF 为 1 时使用 TV (两字节取值).
-
Attribute Type (15 比特) - 各 attribute 类型的唯一标识 (见下文).
-
Attribute Value (变长) - 与 attribute 类型关联的取值. AF 为 0 时, 本字段长度由 Attribute Length 字段定义. AF 为 1 时, Attribute Value 长度为 2 字节.
目前唯一定义的 attribute 类型 (Key Length) 为定长; 变长编码说明仅为将来扩展预留. 描述为定长的 attribute 不得使用变长编码, 除非长度超过两字节. 变长 attribute 不得编码为定长, 即使其取值可放入两字节. 注意: 这与 IKEv1 不同, IKEv1 中增加的灵活性可能简化了消息构造, 但无疑使解析更复杂.
下表取值仅截至 RFC 4306 发布时有效, 此后可能已有新增. 读者应查阅 [IKEV2IANA] 获取最新取值.
| Attribute Type | Value | Attribute Format |
|---|---|---|
| Key Length (in bits) | 14 | TV |
值 0-13 与 15-17 在 IKEv1 的类似上下文中已使用, 除与既有取值对应外不应再分配.
Key Length attribute 以比特为单位指明密钥长度 (必须使用网络字节序), 对某些 transform 的适用规则如下:
-
Key Length attribute 不得用于使用固定长度密钥的 transform. 例如包括 ENCR_DES, ENCR_IDEA, 以及本文档规定的全部 Type 2 (PRF) 与 Type 3 (完整性算法) transform. 建议未来的 Type 2 或 3 transform 不使用本 attribute.
-
部分 transform 规定必须始终包含 Key Length attribute (不允许省略, 不含该 attribute 的提议必须被拒收). 例如包括 ENCR_AES_CBC 与 ENCR_AES_CTR.
-
部分 transform 允许可变长度密钥, 但若未包含 attribute 则规定默认密钥长度. 例如包括 ENCR_RC5 与 ENCR_BLOWFISH.
实现说明: 为促进互操作并支持端点独立升级, 本协议实现者应该接受其认为能提供更高安全性的取值. 例如, 若对等方配置为接受密钥长度为 X 比特的变长密码, 而对方以更大密钥长度提议该密码, 若实现支持更长密钥, 则应该接受该提议.
该能力使响应方能表达 "至少" 达到某安全级别的概念, 即 "对密码 Y, 密钥长度至少 X 比特". 然而, 由于 attribute 总是原样返回 (见下一节), 若发起方愿意接受多种密钥长度, 必须包含多个相同 Transform Type 的 transform, 各带不同的 Key Length attribute.
3.3.6 Attribute Negotiation (属性协商)
在 Security Association 协商中, 发起方向响应方出示提议. 响应方必须从提议中选择单一完整参数集合 (若均不可接受则必须全部拒收). 若有多个 proposal, 响应方必须选择其中一个. 若所选 proposal 中有多个相同类型的 transform, 响应方必须从中选出一个. 所选 transform 的任何 attribute 必须原样返回. 交换的发起方必须检查所接受提议是否与其某一提议一致, 否则必须终止交换.
若响应方收到的 proposal 含有其无法理解的 Transform Type, 或缺少必选 Transform Type, 则必须认为该 proposal 不可接受; 但同一 SA 载荷中的其他 proposal 仍按常规则处理. 类似地, 若响应方收到无法理解的 transform, 或含有其无法理解的 Transform Attribute 的 transform, 则必须认为该 transform 不可接受; 同一 Transform Type 的其他 transform 仍按常规则处理. 从而允许将来定义新的 Transform Type 与 Transform Attribute.
协商 Diffie-Hellman 群存在一些特殊困难. SA 提议在同一消息中包含提议的 attribute 与 Diffie-Hellman 公钥 (KE). 若在初始交换中发起方提议使用若干 Diffie-Hellman 群之一, 应该选择响应方最可能接受的一个, 并包含与该群对应的 KE. 若响应方所选 proposal 使用不同的 Diffie-Hellman 群 (非 NONE), 响应方将在响应中指明正确群, 发起方在重传第一条消息时应为该群选取 KE 元素. 但发起方仍应继续提议其完整支持的群集合, 以防中间人降级攻击. 若所提议之一为 Diffie-Hellman 群 NONE 且响应方选择了该群, 则必须忽略发起方的 KE 载荷, 且响应中不得包含 KE 载荷.