Summary

  • The 1 October revision of the TCPM TCP-AO algorithms draft explicitly identifies its KMAC256-KDF as NIST SP 800-56C Rev. 2's KMAC# variant, not simply the KMAC256 interface originally specified in SP 800-185. It also labels the network-order 32-bit counter value 1 as a KDF-version indicator.
  • The formula and published test vectors were already in revision 07. Revision 08 clarifies how to interpret them; it does not report a deployed key change, approve an RFC or create a new TCP-AO wire format.

Imagine two routers configured with the same master key and the same promising algorithm name. Their TCP-AO options still fail to authenticate each other if their implementations feed different arguments into the key derivation function. The configuration screen has expressed agreement in words, but the packets need agreement in bytes. That gap is the operational significance of a modest amendment to a working-group Internet-Draft.

draft-ietf-tcpm-tcp-ao-algs-08, dated 1 October 2026, adds a precise sentence to section 3.1.2. The proposed KMAC256-KDF conforms to the KMAC# variant described in section 4.1 of NIST SP 800-56C Rev. 2. The draft contrasts it with the KMAC256 function and argument set originally defined in SP 800-185. The counter remains the 32-bit integer one, encoded in network byte order, but revision 08 now explains that it indicates the KDF version. The draft's KDF equation was not introduced this week; the change is an interpretive anchor for an existing recipe.

The recipe is concrete. It combines a 132-byte all-zero salt, the counter, the master key as Z, the TCP connection context as FixedInfo, a 256-bit output length and the ASCII customization string KDF. One KMAC256 invocation yields a 256-bit traffic key. The resulting proposed MAC is 128 bits. The same document also proposes HMAC-SHA256-128 with an HKDF-SHA256 derivation path. Those two choices, the 16-byte tag and the accompanying test vectors predate this revision. Calling them new would turn a clarification into a false launch story.

An implementation review should therefore ask a narrower question than “does it support KMAC?” It should identify the exact variant and arguments at the key-derivation boundary, then compare derived traffic keys and packet MACs against the draft's test vectors, including cases that cover and omit TCP options. The last sentence is an editorial acceptance test, not an IETF-issued certification scheme. Agreement on a label, successful loading of a master key, or an established BGP session with some other algorithm does not demonstrate conformance to this proposed KMAC path.

Nor does the revision settle every deployment question. The 128-bit MAC consumes 20 of TCP's 40 available option bytes once encoded in TCP-AO, leaving a real option-budget consideration that the draft already stated. Its security section still requires master keys of at least 256 bits and warns that cryptographic strength alone cannot cure a protocol-engineering bypass. Revision 08 supplies neither adoption data nor an incident showing incompatible products. It does not change existing keys or authenticate route announcements; TCP-AO is concerned with the TCP connection carrying BGP, not the authority of each route.

The draft remains an active TCPM working-group Internet-Draft in I-D Exists state. Its header expresses a Standards Track intention, while the Datatracker's intended-status field has no value; neither is an approval. The immediate lesson is not that operators must switch algorithms. It is that a cryptographic name is the beginning of a conformance claim, not its proof. The exact variant and byte-level derivation decide whether two ends really share the same traffic key.

Sources