跳到主要内容

3.3. SA Payload

3.3. SA Payload​

本文档中记作 SA 的安全关联（Security Association）负载，用于协商安全关联的属性。组装安全关联负载需要极大的耐心。一个 SA 负载可以包含多个提议（Proposal）。如果存在多个提议，则 MUST 按照从最优先到最不优先的顺序排列。每个提议包含一个单一的 IPsec 协议（协议可以是 IKE、ESP 或 AH），每个协议可以包含多个变换（Transform），每个变换可以包含多个属性（Attribute）。在解析一个 SA 时，实现 MUST 检查总的 Payload Length 是否与该负载内部的长度和计数一致。提议、变换和属性各自有其可变长度的编码。它们嵌套组织，使得 SA 的 Payload Length 包含了 SA、提议、变换和属性信息的合并内容。提议的长度包含其所包含的所有变换和属性的长度。变换的长度包含其所包含的所有属性的长度。

安全关联、提议、变换和属性的语法基于 ISAKMP；然而，其语义有所不同。这种复杂性和层次结构的原因，是为了允许在单个 SA 中对多种可能的算法组合进行编码。有时需要在多个算法之间进行选择，而有时则是算法的组合。例如，发起方可能想要提议使用 ESP，配合（3DES 和 HMAC_MD5）或（AES 和 HMAC_SHA1）。

SA 负载的语义相较于 ISAKMP 和 IKEv1 发生改变的原因之一，是为了在常见情况下使编码更加紧凑。

提议结构内部包含一个 Proposal Num 和一个 IPsec 协议 ID。每个结构 MUST 的序号比前一个结构大 1。发起方 SA 负载中的第一个提议 MUST 的 Proposal Num 为 1（一）。使用多个提议的原因之一，是为了同时提议标准加密算法和组合模式（combined-mode）算法。组合模式算法将完整性和加密包含在单一加密算法中，MUST 要么不提供完整性算法，要么提供单个 "none" 完整性算法，其中不提供完整性算法是 RECOMMENDED 方法。如果发起方想要同时提议组合模式算法和普通算法，它必须包含两个提议：一个包含所有组合模式算法，另一个包含所有带有完整性算法的普通算法。例如，这样一个提议会具有两个提议结构。提议 1 是 ESP，采用 CBC 模式下的 AES-128、AES-192 和 AES-256，完整性算法为 HMAC-SHA1-96 或 XCBC-96；提议 2 是 GCM 模式下的 AES-128 或 AES-256，带 8 字节的完整性校验值（ICV）。两个提议都允许但不要求使用 ESN（扩展序列号）。这可以表示为：

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 )

每个提议/协议结构后面跟随一个或多个变换结构。不同变换的数量通常由协议决定。AH 一般有两个变换：扩展序列号（ESN）和一个完整性校验算法。ESP 一般有三个：ESN、一个加密算法和一个完整性校验算法。IKE 一般有四个：一个 Diffie-Hellman 组、一个完整性校验算法、一个 PRF 算法和一个加密算法。对于每个协议，允许使用的变换集合被赋予 Transform ID 编号，这些编号出现在每个变换的头部。

如果同一个 Transform Type 下有多个变换，则该提议是这些变换的"或"（OR）关系。如果不同 Transform Type 下有多个变换，则该提议是不同组之间的"与"（AND）关系。例如，要提议 ESP 配合（3DES 或 AES-CBC）和（HMAC_MD5 或 HMAC_SHA），该 ESP 提议将包含两个 Transform Type 1 候选项（一个对应 3DES，一个对应 AEC-CBC）以及两个 Transform Type 3 候选项（一个对应 HMAC_MD5，一个对应 HMAC_SHA）。这实际上提出了四种算法组合。如果发起方只想提议这些组合的某个子集，例如（3DES 和 HMAC_MD5）或（IDEA 和 HMAC_SHA），则无法将其编码为单个提议内的多个变换。相反，发起方必须构造两个不同的提议，每个提议包含两个变换。

一个给定的变换 MAY 具有一个或多个属性。当变换可以以多种方式使用时（例如加密算法具有可变密钥长度），属性是必要的。变换指定算法，属性指定密钥长度。大多数变换没有属性。一个变换 MUST NOT 具有多个相同类型的属性。要为某个属性提议备选值（例如 AES 加密算法的多个密钥长度），实现 MUST 包含多个具有相同 Transform Type 的变换，每个变换带有一个单独属性。

注意，变换和属性的语义与 IKEv1 中的语义有很大不同。在 IKEv1 中，单个变换为协议携带多个算法，其中一个在变换中携带，其余在属性中携带。

                 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（变长）- 一个或多个提议的子结构。

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 的负载类型，且提议结构的前四个字节被设计得有点像负载的头部。

o RESERVED（1 字节）- MUST 发送为 0；接收时 MUST 忽略。

o Proposal Length（2 字节，无符号整数）- 本提议的长度，包括后面跟随的所有变换和属性。

o Proposal Num（1 字节）- 当发起提议时，SA 负载中的第一个提议 MUST 为 1，后续提议 MUST 比前一个提议大 1（表示两个提议的"或"关系）。当提议被接受时，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 协商，此字段 MUST 为 0；SPI 从外层头部获取。在后续协商期间，它等于对应协议（IKE 为 8，ESP 和 AH 为 4）的 SPI 大小（以字节为单位）。

o Num Transforms（1 字节）- 指明本提议中变换的数量。

o SPI（变长）- 发送实体的 SPI。即使 SPI Size 字段不是 4 字节的整数倍，也不会对负载应用填充。当 SPI Size 字段为 0 时，此字段不出现在安全关联负载中。

o Transforms（变长）- 一个或多个变换子结构。

3.3.2. 变换的子结构​

                 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 3 | RESERVED | Transform Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transform Type | RESERVED | Transform ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Transform Attributes ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 8:  变换的子结构

o 0（最后一个）或 3（更多）（1 字节）- 指明这是否为提议中最后一个变换子结构。此语法继承自 ISAKMP，但并无必要，因为最后一个变换可以从提议的长度中识别出来。值（3）对应于 IKEv1 中 Transform 的负载类型，且变换结构的前四个字节被设计得有点像负载的头部。

o RESERVED - MUST 发送为 0；接收时 MUST 忽略。

o Transform Length - 变换子结构的长度（以字节为单位），包括头部和属性。

o Transform Type（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 交换，但 MAY 为 Child SA 协商一个 Diffie-Hellman 组。这允许对端在 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 的发起方通常会在其提议中包含两个 ESN 变换，值分别为 "0" 和 "1"。包含单个值为 "1" 的 ESN 变换的提议，意味着使用普通（非扩展）序列号是不可接受的。

自 RFC 4306 发布以来，已经定义了众多额外的 Transform Type。详情请参考 IANA 的 IKEv2 注册表。

3.3.3. 各协议的有效变换类型​

伴随 SA 负载的变换数量和类型取决于 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 支持的套件已被移除，因为它们可能比本文档演化的速度变化得更快。在本文档发布之时，[RFC4307] 规定了这些套件，但请注意它未来可能会更新，其他 RFC 也可能规定不同的套件集合。

从 IKEv1 中学到的一个重要教训是：没有任何系统应该只实现强制算法，并期望它们是所有客户的最佳选择。

IANA 未来很可能会添加额外的变换，并且一些用户可能希望使用私有套件，特别是对于 IKE，实现 SHOULD 能够支持不同的参数，直至特定的大小限制。为支持这一目标，所有 IKEv2 实现 SHOULD 包含一个管理设施，允许（由用户或系统管理员）指定新的 Diffie-Hellman 组的 Diffie-Hellman 参数（生成元、模数以及指数长度和值）。实现 SHOULD 提供一个管理接口，通过这些接口可以输入这些参数以及关联的 Transform ID，以启用此类组的协商。

所有 IKEv2 实现 MUST 包含一个管理设施，使用户或系统管理员能够指定与 IKE 一起使用时可接受的套件。在接收到带有 Transform ID 集合的负载时，实现 MUST 将传输的 Transform ID 与通过管理控制本地配置的 Transform ID 进行比较，以根据本地策略验证所提议的套件是否可接受。实现 MUST 拒绝那些未被这些 IKE 套件控制授权的 SA 提议。注意，MUST 实现的加密套件不必被配置为对本地策略可接受。

3.3.5. 变换属性​

安全关联负载中的每个变换 MAY 包含修改或完善该变换规范的属性。有效属性的集合取决于变换。目前，仅定义了一个单一属性类型：密钥长度（Key Length）属性由某些具有可变长度密钥的加密变换使用（详见下文）。

属性是类型/值对，定义如下。属性可以具有固定两字节长度的值，也可以具有可变长度的值。对于后者，属性编码为类型/长度/值（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 格式（带两字节的值）。

o Attribute Type（15 位）- 每种属性类型的唯一标识符（见下文）。

o Attribute Value（变长）- 与属性类型关联的属性值。如果 AF 位为零（0），则此字段具有由 Attribute Length 字段定义的变长；如果 AF 位为一（1），则 Attribute Value 的长度为 2 字节。

目前唯一已定义的属性类型（密钥长度）是固定长度的；包含可变长度编码规范仅为将来的扩展而设。被描述为固定长度的属性 MUST NOT 使用可变长度编码，除非该长度超过两个字节。可变长度属性 MUST NOT 被编码为固定长度，即使其值可以放入两个字节。注意：这与 IKEv1 不同，在 IKEv1 中，增加的灵活性可能简化了消息的编写者，但无疑使解析器变得复杂。

下表中的值仅截至 RFC 4306 发布之日有效。此后可能已添加或将会添加其他值。读者应参考 [IKEV2IANA] 获取最新值。

Attribute Type Value Attribute Format​

Key Length (in bits) 14 TV

值 0-13 以及 15-17 在 IKEv1 的类似上下文中使用过，除非为匹配的值，否则不应被分配。

密钥长度属性以比特为单位指定密钥长度（MUST 使用网络字节序），适用于某些变换，如下所示：

o 密钥长度属性 MUST NOT 用于使用固定长度密钥的变换。例如，这包括 ENCR_DES、ENCR_IDEA，以及本文档规定的所有 Type 2（伪随机函数）和 Type 3（完整性算法）变换。建议未来的 Type 2 或 Type 3 变换不要使用此属性。

o 某些变换规定密钥长度属性 MUST 始终包含在内（不允许省略该属性，且 MUST 拒绝不包含它的提议）。例如，这包括 ENCR_AES_CBC 和 ENCR_AES_CTR。

o 某些变换允许可变长度密钥，但同时规定了如果未包含该属性时的默认密钥长度。例如，这些变换包括 ENCR_RC5 和 ENCR_BLOWFISH。

实现说明：为了进一步增强互操作性并支持独立升级端点，本协议的实现者 SHOULD 接受他们认为能提供更高安全性的数值。例如，如果对端被配置为接受密钥长度为 X 比特的可变长度密码，并被提供该密码的更大密钥长度，则如果实现支持使用更长的密钥，SHOULD 接受该提议。

对此能力的支持允许响应方表达"至少"某一安全级别的概念——"密码 Y 的密钥长度至少为 X 比特"。然而，由于该属性总是原样返回（见下一节），愿意接受多个密钥长度的发起方 MUST 包含多个具有相同 Transform Type 的变换，每个变换带有一个不同的密钥长度属性。

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 组中的一个，它 SHOULD 选择响应方最有可能接受的那个，并包含对应于该组的 KE。如果响应方选择了使用不同 Diffie-Hellman 组（NONE 除外）的提议，响应方将在响应中指明正确的组，并且发起方在重试第一条消息时 SHOULD 选择该组的一个元素作为其 KE 值。然而，它 SHOULD 继续提议其完整支持的组集合，以防止中间人降级攻击。如果被提议的组之一是 NONE 的 Diffie-Hellman 组，且响应方选择了该 Diffie-Hellman 组，则它 MUST 忽略发起方的 KE 负载，并从响应中省略 KE 负载。