5. Security Considerations (安全考量)
5. Security Considerations (安全考量)
虽然本协议旨在尽量减少向未认证对等端暴露配置信息, 但某些暴露不可避免. 总有一方必须先标识自身并先证明身份. 为避免探测, 要求交换发起方先标识自身, 通常还要求其先完成认证. 然而, 发起方仍可获知响应方支持 IKE 及其支持的密码协议. 响应方 (或冒充响应方者) 不仅可以探测发起方的身份, 还可能借助 CERTREQ 载荷确定发起方愿意使用的证书.
使用 EAP 认证会略微改变可被探测的情形. 使用 EAP 认证时, 响应方先于发起方证明身份, 因此若发起方知道某个有效发起方名称, 便可探测响应方的名称与证书.
在不进行额外 Diffie-Hellman 交换的情况下反复使用 CREATE_CHILD_SA 重密钥, 会使所有 SA 暴露于对单一密钥的密码分析风险之下. 实现者应牢记这一点, 并对指数运算之间的 CREATE_CHILD_SA 交换次数设定上限. 本文档不规定该上限.
使用本文定义的任一群组进行 Diffie-Hellman 交换所得密钥的强度, 取决于群组固有强度, 所用指数大小, 以及随机数生成器所提供的熵. 由于这些输入因素, 难以确定各已定义群组对应密钥的强度. Diffie-Hellman 群组编号二在配合强随机数生成器且指数不少于 200 位时, 常与 3DES 一起使用. 群组五比群组二提供更高安全性. 群组一仅具历史意义, 除与同样仅具历史意义的 DES 一起使用外, 不能提供足够强度. 实现者在制定策略与协商安全参数时应参考这些估计.
注意, 上述限制针对 Diffie-Hellman 群组本身. IKE 中没有任何内容禁止使用更强群组, 也没有任何内容会削弱从更强群组获得的强度 (受所协商的其他算法含 PRF (Pseudorandom Function, 伪随机函数) 强度限制). 事实上, IKE 的可扩展框架鼓励定义更多群组, 使用椭圆曲线群组可能以小得多的数值大幅提高强度.
假定所有 Diffie-Hellman 指数在使用后从内存中擦除.
IKE_SA_INIT 与 IKE_AUTH 交换发生在发起方尚未被认证之前. 因此, 本协议实现在部署于任何不安全网络时必须完全健壮. 实现缺陷, 特别是 DoS (Denial of Service, 拒绝服务) 攻击, 可被未认证对等端利用. 这一问题在基于 EAP 的认证具有无限报文数时尤其令人担忧.
所有密钥的强度受所协商 PRF 输出长度限制. 因此, 输出长度小于 128 位的 PRF (例如 3DES-CBC) 绝对不能与本协议一起使用.
本协议的安全性关键取决于随机所选参数的随机性. 这些参数应由强随机源或正确播种的伪随机源生成 (见 [RANDOMNESS]). 实现者应谨慎设计随机数在密钥与 nonce (Number used once, 一次性数) 中的用法, 以免损害密钥安全.
关于本协议中诸多密码设计选择的理由, 见 [SIGMA] 与 [SKEME]. 尽管已协商子 SA (Child SA) 的安全性不依赖于 IKE SA 中协商的加密与完整性保护强度, 实现绝对不能将 NONE 协商为 IKE 完整性保护算法, 也不能将 ENCR_NULL 协商为 IKE 加密算法.
使用预共享密钥时, 关键问题是如何保证这些秘密的随机性. 最佳实践是确保任意预共享密钥所含的随机性不低于所协商的最强密钥. 从口令, 姓名或其他低熵源派生共享秘密并不安全. 这些源易受字典攻击与社会工程攻击等威胁.
NAT_DETECTION_*_IP 通知包含地址与端口的散列, 试图隐藏 NAT 后的内部 IP 地址. 由于 IPv4 地址空间仅 32 位且通常非常稀疏, 攻击者可能穷举所有 IP 地址并匹配散列, 从而发现 NAT 设备后使用的内部地址. 端口号通常固定为 500, SPI (Security Parameter Index, 安全参数索引) 可从报文中提取. 这使散列计算次数降至 2^32. 若对私有地址空间的使用作出有根据的猜测, 计算次数还会小得多. 因此设计者不应假定使用 IKE 不会泄露内部地址信息.
当使用的 EAP 认证方法不为保护后续 AUTH 载荷生成共享密钥时, 可能出现某些中间人与服务器冒充攻击 [EAPMITM]. 当 EAP 也用于未受安全隧道保护的协议时, 会出现这些弱点. 由于 EAP 是通用认证协议, 常用于提供单点登录, 若已部署的 IPsec 方案依赖不生成共享密钥的 EAP 认证方法 (亦称非密钥生成型 EAP 方法), 则可能因完全无关的应用也以无保护方式使用同一非密钥生成型 EAP 方法而遭到破坏. 注意该弱点不仅限于 EAP, 在复用认证基础设施的其他场景中也可能发生. 例如, 若 IKEv2 使用的 EAP 机制采用令牌认证器, 中间人攻击者可冒充 Web 服务器, 截获令牌认证交换, 并用其发起 IKEv2 连接. 因此, 在可能的情况下应避免使用非密钥生成型 EAP 方法. 在必须使用之处, 极为重要的是这些 EAP 方法的所有用法都应使用受保护隧道, 且发起方在启动 EAP 认证之前应校验响应方证书. 实现者应在实现文档中说明使用非密钥生成型 EAP 方法的弱点, 以便部署 IPsec 方案的管理员了解这些风险.
使用 EAP 的实现还必须在 EAP 认证开始前对客户端执行基于公钥的服务器认证, 即使该 EAP 方法提供相互认证. 这可以避免额外的 IKEv2 协议变体, 并保护 EAP 数据免受主动攻击者侵害.
若 IKEv2 报文过长以致需要 IP 级分片, 攻击者可能通过耗尽重组缓冲区阻止交换完成. 可通过使用 Hash and URL 编码代替发送证书来降低这种可能性 (见第 3.6 节). 其他缓解措施见 [DOSUDPPROT].
准入控制对协议安全至关重要. 例如, 用于标识 IKE 对等端的信任锚可能宜与用于其他信任形式 (如标识公共 Web 服务器) 的锚不同. 此外, 尽管 IKE 在为可信对等端的身份, 凭据及其关联定义安全策略方面留有很大余地, 显式定义此类安全策略对安全实现仍然必不可少.