Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)
Extracted elements (21)
MAC outputs are truncated to 96 bits to balance security against message size, fitting the authentication tag within the TCP-AO option field. HMAC-SHA-1 produces 160 bits and AES-128-CMAC produces 128 bits before truncation.
The KDF_AES_128_CMAC variable-key-length mechanism (using an all-zero key as a randomness extractor) was adopted to avoid burdening administrators with an exact 128-bit key requirement, while still providing a well-defined derivation path per RFC 4615 Section 3.
The Label 'TCP-AO' is included in the KDF input block primarily to comply with FIPS 140 certification requirements, even though TCP-AO currently makes only one call to the KDF.
Two MAC algorithms (HMAC-SHA-1-96 and AES-128-CMAC-96) are mandated rather than one: SHA-1 is included because it is widely deployed with sufficient strength; AES-128-CMAC is included to drive adoption of a stronger algorithm and provide a fallback if SHA-1 is ever compromised.
Two TCP-AO systems cannot interoperate unless they are configured to use the same MAC algorithm and KDF. This document standardizes the minimum required algorithms (HMAC-SHA-1-96 and AES-128-CMAC-96) to ensure a common baseline.
All four cryptographic components (HMAC-SHA-1-96, AES-128-CMAC-96, KDF_HMAC_SHA1, and KDF_AES_128_CMAC) MUST be implemented for full compliance with this RFC.
Deployers are RECOMMENDED to use a randomly generated 128-bit string as the Master_Key when using AES_128_CMAC, though the specification acknowledges that deployers may use variable-length keys.
Each MAC algorithm MUST specify the KDF to be used with that MAC algorithm; however, a KDF MAY be used with more than one MAC algorithm.
Future MAC algorithms for TCP-AO SHOULD protect at least 2**48 messages with a collision probability of less than one in 10**9.
The management interface by which the pre-shared key (PSK) is configured MUST accept ASCII strings, and SHOULD also allow configuration of any arbitrary binary string in hexadecimal form.
UIs SHOULD refer to KDF_HMAC_SHA1 as 'SHA1' and KDF_AES_128_CMAC as 'AES128', and SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO settings due to its wide support.
AES-128-CMAC-96 is defined for TCP-AO with KDF_Alg=KDF_AES_128_CMAC, Key_Length=128 bits, and MAC_Length=96 bits. The AES-128-CMAC output is truncated from 128 bits to 96 bits.
HMAC-SHA-1-96 is defined for TCP-AO with KDF_Alg=KDF_HMAC_SHA1, Key_Length=160 bits, and MAC_Length=96 bits. The HMAC-SHA1 output is truncated from 160 bits to 96 bits.
KDF_AES_128_CMAC uses AES-CMAC-PRF-128 with a 128-bit output length. To handle variable-length Master_Keys, if the key is not exactly 16 octets, a derived 128-bit key K is first produced via AES-CMAC with an all-zero key applied to the Master_Key; K is then used as the AES-CMAC key for the actual KDF computation.
KDF_HMAC_SHA1 uses HMAC-SHA1 as its PRF with a 160-bit output length. Input is (i || Label || Context || Output_Length) and the Master_Key is used directly as the HMAC key.
KDF input blocks are structured as (i || Label || Context || Output_Length), where i is a single-octet counter starting at 1, Label is the ASCII string 'TCP-AO', Context is the connection-specific data, and Output_Length is encoded in two octets.
MAC algorithms for TCP-AO are defined by three fixed elements: KDF_Alg (name of the paired KDF), Key_Length (required Traffic_Key length in bits), and MAC_Length (final truncated output length in bits). The interface is: MAC = MAC_alg(Traffic_Key, Message).
TCP-AO Key Derivation Functions (KDFs) take a Master_Key, a Context (connection-specific binary string as defined in RFC 5925 Section 5.2), and an Output_Length (in bits) to produce a Traffic_Key. The interface is: Traffic_Key = KDF_alg(Master_Key, Context, Output_Length).
IANA created the 'Cryptographic Algorithms for TCP-AO' registry with registration procedure 'RFC Publication after Expert Review'. Initial entries are 'SHA1' (KDF_HMAC_SHA1) and 'AES128' (KDF_AES_128_CMAC), both referencing RFC 5926.
The MUST-implement algorithms are not known to be broken at time of publication, but future weaknesses may be discovered; implementors should check for updated versions of this document before implementing. The SHA-1 vulnerabilities driving migration to SHA-256 for digital signatures do not immediately compromise SHA-1 in HMAC mode for this application.
The security of TCP-AO's cryptographic system depends on algorithm strength, key unpredictability, and correct protocol engineering. Administrators should use randomly generated keys per RFC 4086; the variable-length key support in KDF_AES_128_CMAC does not make weak keys acceptable.