跳到主要内容

2.7. 算法协商

2.7. 算法协商​

实现所支持的每个加密算法都必须被指定一个特定的 SA 属性类型、变换 ID 值以及任何所需的参数 (如密钥长度)。这些在 [IKEV2IANA] 中列出。

在单个 SA 提议中, 实现可以列出多组与某个提议兼容的变换。每组的成员必须全部兼容。如果列出变换 ID "NONE" (值 0), 则该变换 ID 必须是该类型中列出的唯一变换。NONE 只允许用于完整性算法。NONE 完整性算法意味着不提供完整性保护, 除非使用组合模式加密算法 (参见第 3.3.2 节)。如果选择组合模式加密算法, 则不应为加密算法指定单独的完整性算法, 并且 MUST 应为 NONE (参见第 3.3.2 节)。NONE 在其他情况下必须 (MUST) 被拒绝。

发起方必须 (MUST) 提出至少一个被其实现支持的提议, 并且 MUST 响应方必须 (MUST) 接受第一个被其实现支持的提议。在有多个兼容提议的情况下, 响应方的做法是特定的。发起方必须 (MUST) 仅包括其实现支持的提议。响应方可以 (MAY) 拒绝一个有效的提议, 如果它在先前的 IKE 交换中已经从对端收到并提出了一个更喜欢的提议。

为了协商每个协议 (IKE 或 AH 或 ESP), 在 SA 载荷中必须 (MUST) 至少有一个提议, 并且每个提议必须 (MUST) 至少包含一种变换, 每种类型各一个: 每种类型 (加密、完整性、PRF 和 DH) 至多一个变换, 除非无法单独协商多个变换 (例如, 组合模式加密算法, 它包含完整性保护, 但不作为单独的变换)。密码套件本身可以是组合的, 但请注意组合算法在 SA 载荷中表示为一个单独的变换。

2.7.1. 密码套件选择​

各实现必须 (MUST) 实现以下密码套件:

  • 加密: ENCR_AES_CBC 以及 AEAD 加密算法 ENCR_AES_GCM_16 (参见第 3.3.2 节)。实现也可以 (MAY) 实现 ENCR_AES_CTR 作为替代的 AES 变换。实现可以 (MAY) 实现 ENCR_3DES, ENCR_DES, ENCR_CAST 和 ENCR_BLOWFISH, 但它们已过时, 不建议 (SHOULD NOT) 用于新实现。

  • 伪随机函数: PRF_HMAC_SHA1。实现必须 (MUST) 实现 PRF_HMAC_SHA1, 并且可以 (MAY) 实现 PRF_AES128_XCBC 和 PRF_HMAC_SHA2_256 或 PRF_HMAC_SHA2_384 或 PRF_HMAC_SHA2_512。

  • 完整性: AUTH_HMAC_SHA1_96。实现必须 (MUST) 实现 AUTH_HMAC_SHA1_96, 并且可以 (MAY) 实现 AUTH_AES_XCBC_96, AUTH_HMAC_SHA2_256_128 或 AUTH_HMAC_SHA2_384_192 或 AUTH_HMAC_SHA2_512_256。

  • 有限域 DH 组: 1024 位 MODP 组 2 和 EC 组 19 的实现必须 (MUST) 实现。实现可以 (MAY) 实现 2048 位 MODP 组 14 (以及 EC 组 20、21、23、24 或 25) 作为替代。EC 组和组 2 的互操作性尚未确立, 但标准化的优点是使部署能够标准化在某一组上, 如果比较新的实现仅支持 EC 组。

  • 实现可以 (MAY) 实现其他 Diffie-Hellman 组, 但不要求 (REQUIRED)。

看起来, 该文档不应要求实现特定的算法, 因为密码分析学的发展可能使它们过时; 然而, 如果所有实现选择了不同的可选算法集合, 则不可能实现互操作性。因此, 该文档定义了强制算法的最小集合, 并要求新的算法与这些算法共同协商。因此, 一个实现所需的所有算法都应是强制的、标准化的 (如上述), 或者应实现上面列出的一项强制算法。

实现应该 (SHOULD) 支持用于标识的 X.509 v3 证书以及用于签名 (在 AUTH 载荷中) 的 RSA 和不可逆的 ECDSA (如 [PKI] 和 [EAIKEv2] 中所述)。为了支持 EAP, 实现必须 (MUST) 支持 EAP 认证。支持 EAP 的实现应该 (SHOULD) 支持 EAP 方法 EAP-MSCHAPv2, 并且可以 (MAY) 支持其他方法。强烈建议 (RECOMMENDED) 实现支持预共享密钥认证。

2.7.2. 重新协商​

在 IKE SA 中, 除非做出其他安排 (例如, 通过 "挥发性" 的 CREATE_CHILD_SA 交换, 参见第 2.18 节), 否则在 SA 的生存期内, 所协商的加密算法的密码套件不应 (SHOULD NOT) 改变。可以 (MAY) 发起重新协商以替换即将到期的 SA, 或者为了为已存在的 IKE SA 协商新的 (基于证书的) 密钥或身份, 或者为了改变 IKE SA 的属性 (例如, 从使用预共享密钥认证切换到使用证书认证)。在重新协商期间, 几乎整个消息流都重复了一遍, 只是它是在现有 IKE SA 的受保护部分内完成的, 而不是在明文中。

由于重新协商使用了 CREATE_CHILD_SA 交换, 它具有为现有 IKE SA 创建新的子 SA 的效果。发起方可以 (MAY) 在 CREATE_CHILD_SA 交换中不指定任何 SA 载荷 (包括协议 ID), 以指示它希望重新协商 IKE SA 本身而不是创建新的子 SA。在这种情况下, 当使用 CREATE_CHILD_SA 交换来重新协商 IKE SA 时, 它不能 (MUST NOT) 用于同时创建子 SA。这种类型的交换也称为 "类型 1" 重新协商。

如果发起方在 CREATE_CHILD_SA 交换中包括了 SA 载荷, 则该 SA 载荷必须 (MUST) 用于创建子 SA (或额外的子 SA), 同时重新协商 IKE SA, 并且响应方必须 (MUST) 接受。这种类型的交换也称为 "类型 2" 重新协商。不要求 (REQUIRED) 实现支持类型 2 重新协商。

2.7.3. 支持的认证方法​

实现必须 (MUST) 支持以下认证方法:

  • 基于数字的签名 (见第 3.8 节), 使用 RSA 或不可逆转的 ECDSA 算法, 如 [PKI] 和 [EAIKEv2] 中所述。

  • 预共享密钥 (见第 2.15 和 3.8 节)。

  • 可扩展认证协议 (EAP), 如 [EAP] 中所述。

实现可以 (MAY) 支持其他认证方法, 但不要求 (REQUIRED)。