摘要

  • 2026 年 10 月 1 日的 draft-ietf-tcpm-tcp-ao-algs-08 在第 3.1.2 节明确：所提 KMAC256-KDF 遵循 NIST SP 800-56C 第 2 次修订版中的 KMAC# 变体；它的参数集合不同于 SP 800-185 最初定义的 KMAC256。草案还说明，以网络字节序编码、数值为 1 的 32 位计数器用于指示派生函数版本。
  • 派生公式、测试向量和两种 128 位 MAC 候选在第 07 版已经存在。此次是对既有配方的解释锚定，不是已部署密钥更换、线路格式更新或 RFC 获批。

路由器配置页面上的算法名可能完全一致，而 TCP-AO 报文仍无法互认。原因并不一定在链路：相同主密钥若送入不同变体，或按不同顺序编码上下文与计数器，最后得到的流量密钥就会不同。验证器看到的是字节，不会接受“双方都选了 KMAC”作为替代证据。新修订的价值正落在这道容易被名称遮蔽的边界上。

TCPM 的第 08 版把 KMAC256-KDF 明确对应到 NIST SP 800-56C Rev. 2 第 4.1 节的单步派生方案及其 KMAC# 变体。文中同时点明，它与 SP 800-185 原始 KMAC256 的参数约定不同。原有公式仍把 132 字节全零盐、32 位计数器、作为 Z 的主密钥、作为 FixedInfo 的 TCP 连接上下文、256 位输出长度和 ASCII 字符串 KDF 放进一次调用。新加的是“究竟按哪个变体理解这些参数”以及计数器为何为 1 的说明，而非换一套测试结果。

草案另外提出 HMAC-SHA256-128 与 KMAC256-128，两者均产生 128 位 MAC，并使用 256 位流量密钥；前者的密钥派生走 HKDF-SHA256，后者走上述 KMAC256-KDF。16 字节 MAC 编进 TCP-AO 后占去 TCP 可用 40 字节选项空间中的 20 字节。这是评估互通与选项预算时必须带上的背景，却不是第 08 版刚发明的新功能。把旧有参数和测试向量包装成“今天上线”会误导读者。

一个合理的实现验收可以从两端独立计算出的流量密钥开始，再比较覆盖及不覆盖 TCP 选项时的 MAC 是否命中草案测试向量。若失败，先核对变体、参数顺序、网络字节序、上下文及输出长度，而非仅查看设备是否勾选了同名算法。这是本文提出的工程检查顺序，并非 IETF 新设的认证制度。草案也未给出厂商采用率或实际跨设备故障记录；测试建议不能冒充事故报告。

安全边界还包括至少 256 位的主密钥要求，以及草案提醒的协议工程绕过风险。强算法不能替低质量密钥或错误的会话策略担保。TCP-AO 保护承载 BGP 的 TCP 连接，并不因此证明每条 BGP 路由有发布权限；这也不同于旧文讨论的密钥轮换是否已在双向连接上完成。

IETF Datatracker 仍将该文件列为 TCPM 活跃工作组 Internet-Draft，状态为 I-D Exists。正文页眉写着 Standards Track 意向，Datatracker 的目标状态栏却是 (None)；二者都不是批准通知。眼下可核实的新事，是草案把密码学名称落到了一个具体的 NIST 调用变体。是否让设备采用它，仍要由逐字节互通证据决定。

来源