Summary

  • Revision 08 of draft-ietf-tcpm-tcp-ao-algs, posted on 1 October, now says explicitly that its KMAC256-KDF conforms to the KMAC# variant in NIST SP 800-56C Revision 2 rather than being described only by the generic KMAC definition in SP 800-185.
  • An operator therefore needs evidence for the whole function instance—variant, public arguments, encodings, context, vector result and observed TCP-AO bytes—not merely two configuration screens that both display KMAC256.

Suppose two routers are prepared for one authenticated TCP session. Both configurations contain the string KMAC256. Both teams conclude that the cryptographic choice matches. The connection nevertheless fails before the application can exchange useful traffic.

That hypothetical failure does not establish a flaw in KMAC or TCP-AO. It exposes a narrower possibility: the same primitive name can sit above different function contracts. One implementation may invoke the generic KMAC interface it learned from NIST SP 800-185. The other may implement the one-step key-derivation construction in SP 800-56C Revision 2. If their inputs are assembled differently, the peers will derive different Traffic Keys before either computes the MAC carried in the TCP Authentication Option.

Revision 08 of draft-ietf-tcpm-tcp-ao-algs, dated 1 October 2026, makes that boundary explicit. It says KMAC256 and its arguments were originally defined in SP 800-185, while SP 800-56C Revision 2 defines a variant called KMAC# with a different set of arguments. The draft then states that its KMAC256-KDF conforms to the KMAC# variant. It also adds that the fixed 32-bit counter value 1, encoded in network byte order, indicates the KDF version.

The status is important. This is an active TCPM working-group Internet-Draft with intended Standards Track status. The working-group milestone targets submission to the IESG in November. It is not an RFC, an IESG approval, an IANA assignment or deployment evidence. The captured IANA registry still lists only SHA1 and AES128 for TCP-AO; the draft requests two additions, it does not prove they have been registered.

The KMAC KDF contract is compact, but every field is consequential. Revision 08 describes a 132-byte all-zero salt; a 32-bit network-order counter containing 1; Z, which is the TCP-AO Master Key; FixedInfo, which is the TCP-AO connection context; a 256-bit output; and the ASCII customization string KDF. Because the requested Traffic Key length equals that output size, one invocation is sufficient.

The next operation has its own contract. The draft pairs KMAC256-KDF with KMAC256-128. The derived 256-bit Traffic Key becomes the MAC key, the TCP-AO message becomes the input, the MAC customization string is empty, and KMAC is asked for 128 output bits directly. That 16-byte result makes the complete TCP-AO option consume 20 of TCP's 40 option bytes. The KDF's KDF customization string and the MAC's empty customization string are not interchangeable details.

RFC 5925 supplies the connection-specific material behind FixedInfo. Its KDF context combines source and destination addresses, source and destination ports, and initial sequence numbers. Traffic Keys are directional. A SYN for which the destination initial sequence number is not yet known uses zero in that position; later segments use the known pair. The Master Key Tuple also carries the connection selector, option-coverage choice, send and receive IDs, Master Key, KDF and MAC selection.

The wire option cannot settle a configuration dispute by itself. TCP-AO carries Kind, Length, KeyID, RNextKeyID and the MAC. RFC 5925 says those fields do not identify the MAC algorithm. The algorithm is associated out of band through the Master Key Tuple. Two packet captures can therefore show the same KeyID while the endpoints have attached different local meanings to it.

This is why a compatibility statement needs more resolution than “supports KMAC256”. A useful algorithm-instance receipt would record the exact draft revision; KDF and MAC identifiers; NIST source revisions; salt size and value; counter value and byte order; output sizes; both customization strings; the non-secret identity of the Master Key Tuple; implementation and build identity; and a hash of the agreed known-answer-vector output. It would then connect those inputs to captured TCP-AO option bytes, the peer's verification result, the TCP state reached and the application exchange observed.

The secret material must not appear in that receipt. A Master Key identifier can establish which controlled configuration was used without disclosing the key. A Traffic Key hash or test-vector digest can support comparison under a deliberately non-production vector; production-derived secrets should not be turned into logs merely to make an audit look complete.

The draft already includes IPv4 and IPv6 test vectors for the HMAC and KMAC branches, both with and without coverage of other TCP options. Those vectors are the natural first checkpoint. Matching one proves that an implementation reproduced that specified calculation under those stated inputs. It does not prove that two live endpoints loaded the same Master Key Tuple, selected the same KeyID, constructed the same connection context or authenticated the same bytes.

The evidence chain therefore has several distinct rungs. A capability declaration says a build advertises an algorithm. A known-answer-vector match says a calculation agreed for one controlled case. A valid incoming MAC says one segment verified under the receiver's current state. An established TCP connection says the transport progressed. A BGP OPEN, keepalive or another application message says the carried protocol made additional progress. None of these observations should be promoted into the next one without evidence.

That separation follows Heng Lu's Minimum Initial Specification discipline. The common contract should contain only what independent implementations must share, but “minimum” cannot mean vague: the variant, argument roles, encodings, context and output lengths are precisely the common facts required to calculate the same bytes. Local implementations may choose libraries, APIs, key stores and observability systems. They cannot localise the mathematical input contract and still claim interoperability.

Running-Code Primacy changes the order of proof. A draft label and a configuration label are coordinates. The stronger evidence comes from reproducible vectors and the bytes that running endpoints produce and accept. Reality Layers prevents the operator from collapsing an Internet-Draft, a requested registry entry, a configured capability, a derived-key match, one authenticated segment and a stable application session into one undifferentiated word: support. These are Daniel Kade's editorial applications of Heng Lu's work, not positions attributed to the IETF or NIST.

The revision should also be read narrowly. It does not say KMAC is broken. It does not say revision 07 implementations disagree. It does not accuse a vendor of choosing the generic interface. Nor does its 128-bit output settle every design question raised during review. The Security Directorate's earlier review asked about the benefit of the new pairs, longer outputs and TCP option-space trade-offs, but the public record used here does not establish that this review caused the revision 08 clarification.

What revision 08 does provide is a useful operational warning in unusually small form. Algorithm agility fails when the selectable name is treated as the complete object. The true object is the function instance plus its input contract. An organisation that can reproduce and preserve that object can distinguish an implementation mismatch from a wrong key, wrong context, rejected segment or higher-layer failure. An organisation that records only KMAC256 has saved the chapter title and discarded the page.

Sources