摘要

  • AES-XCBC-MAC-96 把 128 位结果的前 96 位作为 IPsec 校验值发送。RFC 3664 则把完整 128 位结果用作 IKE 的 PRF 输出。
  • RFC 4434 保留了这一输出以及 128 位密钥的结果，却取消了密钥必须恰为 128 位的限制。IKEv2 生成密钥材料时按固定长度处理；用共享密钥做认证时则允许可变长度。

三种长度不能混为一谈

这段历史里的“128 位”并不只指一个数值。RFC 3566 先计算 128 位 AES-XCBC 值，再把最左侧 96 位放进 ESP 或 AH 校验字段。接收方会重新计算完整结果，再比较同样的 96 位。这个缩短字段用于数据包认证，不代表算法只能产生这么长的结果。RFC 3566

IKE 要解决的是另一类问题：伪随机函数（PRF）的输出参与密钥生成。RFC 3664 因而认为，96 位输出不足以长期用于 IKEv1 或 IKEv2。它所做的改动很克制：沿用 AES-XCBC，但省略最后的截短步骤，于是 PRF 输出为 128 位。这不等于 IKE 派生出的每把密钥都长 128 位；PRF 输出仍进入协议自己的派生过程。RFC 3664

RFC 3664 还继承了 AES-XCBC-MAC-96 的一项约束：密钥必须正好 128 位。PRF 输出是完整的，输入密钥却只能是固定长度。对于其他长度的 IKE 共享密钥，这条规则会让规范难以适用。后来的修订没有改变 128 位输入密钥的结果，而是说明进入 AES 运算前应怎样规范化输入。RFC 3664 信息页与勘误 RFC 3664 勘误

2006 年的修订针对输入

RFC 4434 删除了密钥必须恰为 128 位的限制。128 位密钥直接使用；较短的密钥在右侧补零，直到达到 128 位；若密钥至少有 129 位，则使用 128 位全零密钥再次运行 PRF，并把过长密钥作为消息，所得结果成为规范化密钥。长密钥路径并不是普通截断，也不是通用哈希。RFC 4434

“相同算法”可能遮住两个不同问题：线上产生什么结果，以及实现接受哪些输入。RFC 4434 表明，输入密钥为 128 位时，线上结果与 RFC 3664 相同；其他长度不再直接拒绝，而是被转换为 128 位 AES 密钥。PRF 仍输出完整的 128 位 XCBC 值，不是 ESP/AH 使用的 96 位校验字段。RFC 4434 信息页与勘误 RFC 4434 勘误

IKEv2 给 PRF 分配了两种用途

后继规范还区分 IKEv2 内部的两种用途。生成密钥材料时，AES-XCBC-PRF-128 被视为固定长度 PRF：IKEv2 按规范把两端 nonce 的贡献分开。使用共享密钥做认证时，RFC 4434 则将其视为可变长度，因此共享密钥本身不必是 128 位。文档承认这套逻辑有些绕，原因是要让遵循 RFC 3664 固定长度规则的实现，与采用灵活规则的实现能够互通。RFC 4306 RFC 4434

这是一项接口约定的修订，不是已有实现故障或普遍部署的证据。RFC 4434 保留完整输出和 128 位密钥情形，同时写明短密钥与长密钥的转换方式。后来的 RFC 8221 讨论 ESP/AH 的算法建议，不能用来证明 IKE PRF 的协商结果或具体实现行为。RFC 8221

这段标准史的关键在于把步骤拆开：为数据包字段截短 MAC；为 IKE PRF 保留完整值；再按用途规范化输入密钥。

来源