Summary

  • RFC 5926 required every fully compliant TCP-AO implementation to provide two MAC algorithms and two corresponding key derivation functions, so algorithm choice did not erase the common interoperability baseline.
  • HMAC-SHA-1-96 represented the widely supported starting point in 2010, while AES-128-CMAC-96 supplied a distinct alternative; both produced 96-bit tags for the TCP-AO option.

Agility without agreement is failure

TCP-AO does not authenticate with an abstract promise to use “strong cryptography.” A sender derives a connection-specific traffic key and computes a message authentication code with a particular algorithm. The receiver must perform the same derivation and calculation. If the pair differs, the received tag is not an alternative interpretation of the same proof; it is simply unverifiable.

RFC 5926 therefore paired choice with a mandatory floor. A fully compliant implementation had to implement HMAC-SHA-1-96 and AES-128-CMAC-96, together with KDF_HMAC_SHA1 and KDF_AES_128_CMAC. The requirement did not mean that a connection used both suites at once, nor did it introduce an in-band negotiation protocol. It meant that independently built systems shared two defined choices that operators could configure consistently.

That pairing mattered because the MAC name alone was not the complete contract. The KDF takes a configured Master_Key, connection-specific Context and requested output length and produces the Traffic_Key used on TCP segments. Each TCP-AO MAC definition identifies its KDF. A future KDF could serve more than one MAC, but a deployed MAC could not leave traffic-key derivation unspecified.

Two primitives, one option budget

The two suites reached the wire through different constructions. HMAC-SHA-1-96 uses a 160-bit traffic key and starts from HMAC-SHA1 output. AES-128-CMAC-96 uses a 128-bit traffic key and AES-CMAC. In both cases, the value carried in the TCP-AO option is truncated to 96 bits. RFC 5926 described that length as a compromise between authentication strength and the limited space available in a TCP option; it did not redefine the underlying functions as 96-bit primitives.

The standard's choice recorded a moment in cryptographic transition. HMAC-SHA1 was recommended as the user-interface default because it was then broadly implemented in Internet systems. AES-128-CMAC was also mandatory because the working group wanted a stronger, structurally different option and a route away from dependence on SHA-1 if future analysis made that necessary. This was planned diversity, not a contemporary verdict about which suite operators should prefer today.

The AES-CMAC KDF also handled an awkward operational boundary. Administrators might configure a master key shorter or longer than the 16 octets AES-CMAC requires. Rather than making the interface accept only one length, the KDF derives a 128-bit key from a variable-length input when needed. RFC 5926 immediately limits the inference: accepting varied lengths does not turn a weak or predictable shared secret into a safe one.

What the baseline did—and did not—settle

The four MUST-implement components made compliant software capable of meeting on common ground. They did not make configuration self-correcting. Peers still needed matching selections and shared key material, and RFC 5926's manual-keying model left that coordination outside the TCP exchange.

The document also provided an interface for future MACs and KDFs, including a stated target for the number of messages a future MAC should protect at a low collision probability. That is an extensibility boundary, not evidence that later algorithms were automatically installed, selected or negotiated.

Sources