摘要

  • RFC 5926 要求完全符合标准的实现支持 HMAC-SHA-1-96、AES-128-CMAC-96 及其配套 KDF。
  • 两种方案都把输出截短为 96 位标签，因而同时提供共同基线和迁移选择。

只有算法灵活性还不够

TCP-AO 并不是用“采用强密码”这样的抽象承诺完成认证。发送端要为连接派生专用 Traffic_Key，再用确定的算法计算 MAC。接收端必须进行相同的派生和计算。若两端使用的组合不同，收到的标签不是另一种可接受的解释，而是无法验证的数据。

因此，RFC 5926 把选择空间和强制基线放在一起。合规实现必须提供 HMAC-SHA-1-96、AES-128-CMAC-96、KDF_HMAC_SHA1 和 KDF_AES_128_CMAC。这不表示一条连接会同时使用两套方案，也不表示 TCP 交换中存在算法协商；它表示不同实现拥有可以一致配置的共同选项。

MAC 名称本身也不是完整契约。KDF 接收配置的 Master_Key、连接专用的 Context 和请求的输出长度，生成 TCP 报文使用的 Traffic_Key。RFC 5926 为每种 MAC 指定配套 KDF；一种 KDF 可以服务多个 MAC，但流量密钥的派生方式不能含糊。

两种原语与一个有限的选项空间

HMAC-SHA-1-96 使用 160 位流量密钥，并以 HMAC-SHA1 输出为基础。AES-128-CMAC-96 使用 128 位流量密钥和 AES-CMAC。两者最终都将值截短为 96 位，放入 TCP-AO 选项。这个长度是在认证强度和 TCP 选项空间之间作出的工程折中，并不意味着底层原语只有 96 位输出。

RFC 发布于 2010 年时，因 HMAC-SHA1 已得到广泛实现，文档建议把它作为用户界面默认值；AES-128-CMAC 则作为不同的替代方案和迁移路径被列为必选。那是当时的历史理由，不是今天的安全建议。

AES-CMAC KDF 还允许配置长度不固定的主密钥：输入不是正好 16 个八位组时，它会派生出 128 位密钥。但这种接口便利不会把弱密钥或可预测密钥变得安全。

基线解决了什么，又没有解决什么

四个强制组件让合规软件能够站在共同基础上。它们不会自动修正不一致的配置。两端仍须拥有相同选择和共享密钥材料，而手工密钥模型把协调工作留在 TCP 交换之外。

RFC 还为未来 MAC 和 KDF 留出了接口，并提出了关于消息数量与碰撞概率的目标。这是扩展边界，并不是线路上的自动协商机制。

来源