摘要

  • RFC 2403 和 RFC 2404 都把计算所得 HMAC 的前 96 位放入 ESP 或 AH；两者的完整输出长度和规定密钥长度并不相同。
  • 后来的 ESP/AH 实现指南将它们分开：RFC 8221 对 HMAC-MD5-96 标为 MUST NOT，对 HMAC-SHA1-96 标为 MUST-。线上标签长度相同，从未意味着安全评估也相同。

一个字段，两种构造

1998 年 11 月，RFC 2403 与 RFC 2404 分别规定了 IPsec 的封装安全载荷（ESP）和认证头（AH）如何使用带密钥的认证变换。前者将 HMAC 与 MD5 结合，后者与 SHA-1 结合。只要共享秘密仅由通信双方掌握，两者都用于验证数据来源并保护完整性；单靠任何一种变换都不提供机密性。

在线上包里看见的数字却一样：96 位。RFC 2403 的 HMAC-MD5 完整输出为 128 位，RFC 2404 的 HMAC-SHA-1 完整输出为 160 位。两种变换都要求发送方把前 96 位写入认证字段；接收方重新计算完整 HMAC，再比较这前 96 位。选 96 位，是为了对应 AH 默认的认证字段长度，让不同构造占用相同的线上空间。它并未把完整摘要变成 96 位哈希。

密钥规则也不同：RFC 2403 要求 128 位 HMAC 密钥，RFC 2404 则要求 160 位。于是，同样长的字段可以对应不同的完整输出和固定密钥长度。协商到哪种变换、密钥如何管理依然关键；只数线上可见的认证位数，并不足以描述整个机制。

抗碰撞性并不能回答 HMAC 的全部问题

1998 年的文本没有把无密钥哈希发生碰撞等同于 HMAC 立即失效。RFC 2403 指出，与基于 MD5 的签名相比，HMAC 对 MD5 强碰撞抗性的依赖较弱；当时也没有已知的 HMAC-MD5-96 实用攻击。RFC 2404 对 HMAC-SHA-1-96 给出了同属那个时期的评估。这些历史判断并非对未来的保证。

实现要求的变化表明，评估会演进，但标签长度并未成为决定因素。2005 年，RFC 4305 将 HMAC-SHA1-96 列为 MUST，把 HMAC-MD5-96 列为 MAY。2007 年的 RFC 4835 延续了这一差异，并称当时已发现的碰撞弱点不应影响这两种哈希与 HMAC 的组合。2014 年，RFC 7321 提到针对 HMAC-MD5 的理论结果，但没有发现明显的实用漏洞，也不认为立即从现有协议中移除它很紧迫；尽管 SHA-1 的碰撞抗性已不足，它仍认为 HMAC-SHA-1 安全。

2017 年发布的 RFC 8221 对 ESP/AH 实现要求画出了更清晰的界线：HMAC-MD5-96 变为 MUST NOT；HMAC-SHA1-96 则由 MUST 降至 MUST-。前者的禁用理由是 MD5 已知易受碰撞攻击；后者降级则归因于业界逐步弃用 SHA-1 的趋势。这既不是说 96 位字段改变了，也不是说 RFC 2404 突然定义了另一种标签。

状态表不是流量记录

后来 RFC 9395 更新了 RFC 8221，并修改 IKEv2 变换注册表，其中有一项名为 AUTH_HMAC_MD5_96 的条目标记为 DEPRECATED。这份注册表不是 RFC 8221 的 ESP/AH 实现要求表。相同的名称可能出现在相邻的 IPsec 上下文；判断状态时，应结合协议与文档范围核对。

这些文档记录的是协议参数和特定时期的实现建议。它们没有统计部署设备，没有找出最后一条协商 HMAC-MD5 的安全关联，也没有确定全网统一的退役日期。运营方需要分别确认所用协议、变换标识、两端能力、已安装的安全关联和实际观测到的流量。96 位标签只是证据的一部分。

来源