5. 安全考量

虽然本协议旨在最大限度地减少向未认证对端披露配置信息，但某些此类披露是不可避免的。一方或另一方必须先标识自身并首先证明其身份。为了避免探测，交换的发起方被要求首先标识自身，并且通常要求首先认证自身。然而，发起方可以了解到响应方支持 IKE 以及它支持哪些加密协议。响应方（或冒充响应方的人）可以通过 CERTREQ payload 不仅探测发起方的身份，还可能确定发起方愿意使用哪些证书。

使用 EAP 认证在一定程度上改变了探测的可能性。当使用 EAP 认证时，响应方在发起方之前证明其身份，因此知道有效发起方名称的发起方可以探测响应方的名称和证书。

使用 CREATE_CHILD_SA 进行重复重密钥而不进行额外的 Diffie-Hellman 交换，会使所有 SA 容易受到对单一密钥的密码分析攻击。实现者应注意这一事实，并对指数运算之间的 CREATE_CHILD_SA 交换数量设置限制。本文档并未规定此类限制。

从本文定义的任何组进行 Diffie-Hellman 交换导出的密钥强度，取决于组本身的固有强度、所用指数的大小以及所使用的随机数生成器提供的熵。由于这些输入，很难确定任何定义组的密钥强度。当与强随机数生成器一起使用且指数不小于 200 位时，Diffie-Hellman 第 2 组常用于 3DES。第 5 组提供比第 2 组更高的安全性。第 1 组仅用于历史目的，除用于同样仅用于历史目的的 DES 外，不提供足够强度。实现者在制定策略和协商安全参数时应注意这些估计。

请注意，这些限制是针对 Diffie-Hellman 组本身的。IKE 中没有任何内容禁止使用的组，也没有任何内容会削弱从更强的组获得的强度（受包括 PRF 在内的其他协商算法的强度限制）。事实上，IKE 的可扩展框架鼓励定义更多的组；使用椭圆曲线组可以用小得多的数字极大地提高强度。

假定所有 Diffie-Hellman 指数在使用后从内存中擦除。

IKE_SA_INIT 和 IKE_AUTH 交换发生在发起方被认证之前。因此，部署在任何不安全网络上的本协议实现需要完全健壮。实现漏洞，特别是 DoS 攻击，可能被未认证的对端利用。由于基于 EAP 的认证中消息数量不受限制，此问题尤其令人担忧。

所有密钥的强度都受协商的 PRF 输出大小的限制。因此，输出小于 128 位（例如 3DES-CBC）的 PRF MUST NOT 与本协议一起使用。

本协议的安全性关键依赖于随机选择的参数的随机性。这些参数应由强随机或正确播种的伪随机源生成（参见 [RANDOMNESS]）。实现者应注意确保用于密钥和 nonce 的随机数的使用方式不会损害密钥的安全性。

关于本协议中许多加密设计选择的基本原理，请参见 [SIGMA] 和 [SKEME]。尽管协商的 Child SA 的安全性不依赖于在 IKE SA 中协商的加密和完整性保护的强度，但实现 MUST NOT 将 NONE 协商为 IKE 完整性保护算法，或将 ENCR_NULL 协商为 IKE 加密算法。

使用预共享密钥时，一个关键的考虑是如何确保这些秘密的随机性。最强的做法是确保任何预共享密钥包含与正在协商的最强密钥一样多的随机性。从密码、名称或其他低熵源派生共享秘密是不安全的。这些源容易受到字典攻击和社会工程攻击等。

NAT_DETECTION_*_IP 通知包含地址和端口的哈希，试图隐藏 NAT 背后的内部 IP 地址。由于 IPv4 地址空间只有 32 位，且通常非常稀疏，攻击者可能通过尝试所有可能的 IP 地址并尝试找到匹配的哈希来发现 NAT 盒背后使用的内部地址。端口号通常固定为 500，SPI 可以从数据包中提取。这将哈希计算次数减少到 2^32。通过有根据地猜测私有地址空间的使用，哈希计算次数要小得多。因此，设计者不应假设使用 IKE 不会泄漏内部地址信息。

当使用的 EAP 认证方法不生成用于保护后续 AUTH payload 的共享密钥时，可能会发生某些中间人攻击和服务器冒充攻击 [EAPMITM]。当 EAP 也用于未受安全隧道保护的协议时，会出现这些漏洞。由于 EAP 是一种通用的认证协议，常用于提供单点登录功能，依赖不生成共享密钥的 EAP 认证方法（也称为非密钥生成 EAP 方法）的已部署 IPsec 解决方案，可能会由于部署了一个完全不相关的、恰好也使用相同非密钥生成 EAP 方法但以保护不足的方式运行的应用程序而受到损害。请注意，此漏洞不仅限于 EAP，也可能发生在重用认证基础设施的其他场景中。例如，如果 IKEv2 使用的 EAP 机制利用令牌认证器，中间人攻击者可能冒充 Web 服务器，拦截令牌认证交换，并利用它发起 IKEv2 连接。因此，应尽可能避免使用非密钥生成 EAP 方法。在使用这些方法时，极其重要的是所有这些 EAP 方法的使用 SHOULD 利用受保护的隧道，其中发起方在启动 EAP 认证之前验证响应方的证书。实现者应在其实现的文档中描述使用非密钥生成 EAP 方法的漏洞，以便部署 IPsec 解决方案的管理员了解这些危险。

使用 EAP 的实现 MUST 在 EAP 认证开始之前也使用基于公钥的服务器对客户端的认证，即使 EAP 方法提供相互认证。这避免了额外的 IKEv2 协议变体，并保护 EAP 数据免受主动攻击者的攻击。

如果 IKEv2 消息长到必须进行 IP 级分片，攻击者可能通过耗尽重组缓冲区来阻止交换完成。通过使用 Hash and URL 编码而不是发送证书（见第 3.6 节），可以最大限度地减少这种可能性。[DOSUDPPROT] 中讨论了其他缓解措施。

准入控制对协议的安全性至关重要。例如，用于标识 IKE 对端的信任锚可能应该不同于用于其他形式信任（例如用于标识公共 Web 服务器）的信任锚。此外，尽管 IKE 在为可信对端的身份、凭据及其之间的关联定义安全策略方面提供了很大的自由度，但明确定义此类安全策略对于安全的实现至关重要。