]> HPE

USA ronald.bonica@hpe.com

HPE

USA tony.li@tony.li

HPE

Canada ping.chen@hpe.com

HPE

India prashant.kumar5@hpe.com

Arista Networks

India reji.thomas@arista.com

Cisco Systems

India sua@cisco.com

Cisco Systems

USA ayabaner@cisco.com

Transport TCPM Working Group TCP-AO RFC 5926 established a registry of cryptographic algorithms that can be used with TCP-AO. This document expands that registry, adding two Message Authentication Code (MAC) algorithms, HMAC-SHA256-128 and KMAC256-128. For each MAC algorithm, a corresponding Key Derivation Function (KDF) is also added. The MAC algorithms described by this document produce 128-bit (i.e., 16-byte) MACs. When 16-byte MACs are encoded in TCP-AO, the TCP-AO consumes 20 of the 40 bytes available for TCP options.

Introduction established a registry of cryptographic algorithms that can be used with TCP-AO . This document expands that registry, adding two Message Authentication Code (MAC) algorithms, HMAC-SHA256-128 and KMAC256-128. For each MAC algorithm, a corresponding Key Derivation Function (KDF) is also added. The MAC algorithms described by this document produce 128-bit (i.e., 16-byte) MACs. When 16-byte MACs are encoded in TCP-AO, the TCP-AO consumes 20 of the 40 bytes available for TCP options.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 when, and only when, they appear in all capitals, as shown here.

Algorithm Classes requires the following cryptographic algorithm classes:

• Key Derivation Functions (KDFs)
• MAC Algorithms

of this document addresses KDFs while addresses MAC algorithms.

Key Derivation Functions (KDFs) A KDF converts Input Keying Material (IKM) into cryptographically strong Output Keying Material (OKM). In the case of TCP-AO, a KDF converts an administratively assigned Master_Key into a Traffic_Key. KDFs have the following interface:

• Traffic_Key = KDF_alg(Master_Key, Context, Output_Length)

where:

• KDF_alg is the KDF algorithm being used.
• Master_Key is a variable-length pre-shared key (PSK), represented as an octet string. It MUST be at least 256 bits (32 octets) in length. The octet string is used directly as the KDF input. A configuration interface MAY accept a textual encoding (for example, hex or base64), but MUST decode it to octets before use. A text string that has not been decoded MUST NOT be used as the Master_Key. If a Master_Key shorter than 256 bits is configured for an algorithm defined in this document, the implementation MUST reject it and MUST NOT use it.
• Context is a binary string containing information related to the TCP connection, as defined in Section 5.2 of (Figures 7 and 8).
• Output_Length is the desired length of the Traffic_Key. In this document, the Output_Length is always equal to 256 bits (i.e., 32 bytes).

This document defines two KDFs:

• HKDF-SHA256
• KMAC256-KDF

of this document describes HKDF-SHA256 while describes KMAC256-KDF.

HKDF-SHA256 HKDF-SHA256 uses HKDF and the SHA-256 hash function . It executes in the following stages:

• Extract
• Expand

The interface to the Extract stage is:

• PRK = HKDF-Extract(salt, IKM)

where:

• PRK is a pseudorandom key, to be used in the Expand stage.
• salt is an all-zero byte string whose length equals 32 bytes.
• IKM is the Master_Key argument provided to the KDF interface.

According to , the goal of the Extract stage is to concentrate the possibly dispersed entropy of the input keying material into a short, but cryptographically strong pseudorandom key. Implementations MUST execute the Extract stage. The interface to the Expand stage is:

• OKM = HKDF-Expand(PRK, info, L)

where:

• OKM is the Traffic_Key.
• PRK is the value produced by the Extract stage.
• info is the Context argument provided to the KDF interface.
• L is equal to 32 bytes (i.e., 256 bits).

The Expand stage expands the pseudorandom key to the desired length. Implementations MUST execute the Expand stage.

KMAC256-KDF KMAC256-KDF uses the one-step key-derivation function specified in Section 4.1 of , with KMAC256 as the auxiliary function, as described by Option 3. defines KMAC256 and its arguments. uses the name KMAC# to refer to either KMAC128 or KMAC256. It also renames some of the arguments. This document uses the KMAC# argument names as defined in Section 4.1 of . The interface to KMAC256-KDF is:

• OKM = KMAC256(salt, counter || Z || FixedInfo, H_outputBits, S)

where:

• OKM is the Traffic_Key.
• salt is an all-zero byte string whose length equals 132 bytes. It is used as the KMAC key K.
• counter is the 32-bit integer 1, encoded in network byte order. The counter is equal to 1 because, due to the requested output length, only the first iteration is needed.
• Z is the Master_Key argument provided to the KDF interface.
• FixedInfo is the Context argument provided to the KDF interface.
• H_outputBits is equal to 256 bits.
• S is the byte string 01001011 || 01000100 || 01000110, which represents the sequence of characters "K", "D", and "F" in 8-bit ASCII.

Because the required output length is equal to H_outputBits, only one KMAC256 invocation is required. In the notation of , that is:

• OKM = KMAC256(K = 132 zero octets, X = 00000001 || Master_Key || Context, L = 256, S = "KDF")

MAC Algorithms Each MAC algorithm defined for TCP-AO has the following fixed elements as part of its definition:

• KDF_alg is the name of the KDF algorithm used to generate the Traffic_Key.
• Key_Length is the length of the Traffic_Key used in this MAC, measured in bits. In this document, the Key_Length is always 256 bits.
• MAC_Length is the desired length of the MAC to be produced by the algorithm. In this document, the MAC_Length is always 128 bits.

MACs computed for TCP-AO have the following interface:

• MAC = MAC_alg(Traffic_Key, Message)

where:

• MAC is the value to be encoded in TCP-AO.
• MAC_alg is the MAC algorithm used.
• Traffic_Key is the result of the KDF.
• Message is the message to be authenticated, as specified in Section 5.1 of .

The Use of HMAC-SHA256-128 The three fixed elements for HMAC-SHA256-128 are:

• KDF_alg: HKDF-SHA256.
• Key_Length: 256 bits.
• MAC_Length: 128 bits.

In the interface:

• MAC = MAC_alg(Traffic_Key, Message)

HMAC-SHA256-128 for TCP-AO has the following values:

• MAC is the value to be encoded in TCP-AO.
• MAC_alg is HMAC-SHA256.
• Traffic_Key is the result of the KDF.
• Message is the message to be authenticated, as specified in Section 5.1 of .

The HMAC-SHA256 output is truncated to its leftmost 128 bits (the first 16 octets).

The Use of KMAC256-128 The three fixed elements for KMAC256-128 are:

• KDF_alg: KMAC256-KDF.
• Key_Length: 256 bits.
• MAC_Length: 128 bits.

In the interface:

• MAC = MAC_alg(Traffic_Key, Message)

KMAC256 takes more arguments than the generic two-argument interface above. In the notation of , KMAC256-128 for TCP-AO is:

• MAC = KMAC256(K = Traffic_Key, X = Message, L = 128, S = "")

KMAC256-128 for TCP-AO has the following values:

• MAC is the value to be encoded in TCP-AO.
• MAC_alg is KMAC256.
• Traffic_Key is the result of the KDF.
• Message is the message to be authenticated, as specified in Section 5.1 of .
• L = 128 (bits) is the requested MAC length.
• S is the empty (zero-length) string.

Security Considerations This document inherits all of the security considerations of , , , and . The security of cryptography-based systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system. As specified in , the Master_Key used with the algorithms in this document is at least 256 bits in length. Master_Keys SHOULD have at least 256 bits of entropy, and they SHOULD be generated by a cryptographic random number generator or similar. The use of low-entropy secrets (such as passwords) is vulnerable to brute-force attacks. If a textual encoding is used for configuration, it SHOULD be the hex or base64 encoding of a cryptographic key whose decoded length is at least 256 bits and which has at least 256 bits of entropy, rather than a human-readable password or passphrase. The 256-bit minimum applies to the decoded octets, not to the length of the text string (for example, a hex-encoded key must be at least 64 characters). Implementations MUST NOT apply the length check to the encoded string. Master_Keys MUST be kept secret. Each party in the Master_Key distribution path is an opportunity for compromise and disclosure. Master_Keys MUST be changed immediately if compromise is suspected. TCP-AO Master Key Tuples (MKTs) MUST be rotated at a rate commensurate with the strength of the cryptographic algorithms.

IANA Considerations IANA is requested to add the following entries to the "Cryptographic Algorithms for TCP-AO Registration" registry in the "Transmission Control Protocol (TCP) Parameters" registry group. This registry was created by , and its registration procedure is "RFC Publication After Expert Review". IANA Actions

Algorithm	Reference
HMAC-SHA256-128	This Document
KMAC256-128	This Document

Acknowledgements Thanks to Eric Biggers, Lars Eggert, Gorry Fairhurst, C.M. Heard, Russ Housley, John Mattsson, Yoshifumi Nishida, Joe Touch, Michael Tuexen, and Magnus Westerlund for their review and comments.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK] Federal Information Processing Standard, FIPS RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. National Institute of Standards and Technology National Institute of Standards and Technology Informative References The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). [STANDARDS-TRACK] This document updates the "Cryptographic Message Syntax (CMS) Algorithms" (RFC 3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme (RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA). The conventions for the associated signer public keys in CMS are also described. This document provides test vectors to validate implementations of the two mandatory authentication algorithms specified for the TCP Authentication Option over both IPv4 and IPv6. This includes validation of the key derivation function (KDF) based on a set of test connection parameters as well as validation of the message authentication code (MAC). Vectors are provided for both currently required pairs of KDF and MAC algorithms: KDF_HMAC_SHA1 and HMAC- SHA-1-96, and KDF_AES_128_CMAC and AES-128-CMAC-96. The vectors also validate both whole TCP segments as well as segments whose options are excluded for middlebox traversal. This document describes the conventions for using the one-way hash functions in the SHA3 family with the Cryptographic Message Syntax (CMS). The SHA3 family can be used as a message digest algorithm, as part of a signature algorithm, as part of a message authentication code, or as part of a Key Derivation Function (KDF).

Test Vectors This appendix provides test vectors to validate the correct implementation of TCP-AO and the cryptographic algorithms defined in this document. The format of these test vectors follows . In the following sections, all values are shown as space-separated two-digit hexadecimal octets, 16 octets per line, as is typical for data dumps. The IP/TCP data shows the entire IP packet, including the TCP segment, the TCP-AO option, and any other TCP options (whether or not they are covered by TCP-AO, as indicated). In these test vectors, the Master_Key is the following 32-octet string, used directly as an octet string (not as ASCII hex text): 0x0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef. All vectors are shown from the client's perspective. In the IPv4 vectors, the client is 10.11.12.13 and the server is 172.27.28.29. In the IPv6 vectors, the client is fd00::1 and the server is fd00::2. The client uses an ephemeral port and the server uses port 179. The Sequence Number Extension (SNE) is 0. The TCP-AO option is 20 bytes long (Kind 29, Length 20, KeyID, RNextKeyID, and a 16-byte MAC). Segments sent by the client carry KeyID 61 (0x3d) and RNextKeyID 84 (0x54). Segments sent by the server carry KeyID 84 and RNextKeyID 61. For the "Omits TCP Options" test vectors, the MAC is computed as described in Section 5.1 of . All TCP options other than TCP-AO are removed from the MAC input. The Data Offset field of the TCP header and the TCP length in the pseudoheader retain the values of the original segment; they are not recomputed to reflect the removed options. The TCP checksum and the MAC field are set to zero. The MAC input therefore consists of the following, in order:

• The 4-byte SNE.
• The IP pseudoheader, using the TCP length of the original segment.
• The 20-byte fixed TCP header, with the original Data Offset and the checksum set to zero.
• The TCP-AO option, with the MAC field set to zero.
• The TCP payload, if any.

The KDF Context contains the sender's ISN followed by the receiver's ISN. The receiver's ISN is zero only for a segment with SYN set and ACK clear (the initial SYN). A SYN-ACK carries the client's ISN in its acknowledgment, so its traffic key is derived with both ISNs and is the same as the key for subsequent non-SYN segments in that direction.

Intermediate Values This section shows the intermediate values for the first test vector of each algorithm: the IPv4 Send (Client) SYN that covers TCP options. The Master_Key is the 32-octet string given above.

HMAC-SHA256-128 The Context is the source address, destination address, source port, destination port, sender ISN, and receiver ISN (zero for a SYN), for a total of 20 octets: The PRK is HKDF-Extract(salt, Master_Key), where the salt is 32 zero octets: The traffic key is HKDF-Expand(PRK, Context, 32), which is the Send_SYN_traffic_key shown in the vector. The MAC input is the following 76 octets. The MAC is the first 16 octets of HMAC-SHA256(Traffic_Key, MAC input):

KMAC256-128 The Context is: The traffic key is KMAC256 with a key of 132 zero octets, the following 56 octets as input (counter, Master_Key, and Context), an output length of 256 bits, and the customization string "KDF". It is the Send_SYN_traffic_key shown in the vector: The MAC input is the following 76 octets. The MAC is KMAC256(Traffic_Key, MAC input, 128 bits, ""):

IPv4 HMAC-SHA256-128 Output Test Vectors

HMAC-SHA256-128 (Default - Covers TCP Options)

Send (Client) SYN (Covers Options)

Receive (Server) SYN-ACK (Covers Options)

Send (Client) Non-SYN (Covers Options)

Receive (Server) Non-SYN (Covers Options)

HMAC-SHA256-128 (Omits TCP Options)

Send (Client) SYN (Omits Options)

Receive (Server) SYN-ACK (Omits Options)

Send (Client) Non-SYN (Omits Options)

Receive (Server) Non-SYN (Omits Options)

IPv4 KMAC256-128 Output Test Vectors

KMAC256-128 (Default - Covers TCP Options)

Send (Client) SYN (Covers Options)

Receive (Server) SYN-ACK (Covers Options)

Send (Client) Non-SYN (Covers Options)

Receive (Server) Non-SYN (Covers Options)

KMAC256-128 (Omits TCP Options)

Send (Client) SYN (Omits Options)

Receive (Server) SYN-ACK (Omits Options)

Send (Client) Non-SYN (Omits Options)

Receive (Server) Non-SYN (Omits Options)

IPv6 HMAC-SHA256-128 Output Test Vectors

HMAC-SHA256-128 (Default - Covers TCP Options)

Send (Client) SYN (Covers Options)

Receive (Server) SYN-ACK (Covers Options)

Send (Client) Non-SYN (Covers Options)

Receive (Server) Non-SYN (Covers Options)

HMAC-SHA256-128 (Omits TCP Options)

Send (Client) SYN (Omits Options)

Receive (Server) SYN-ACK (Omits Options)

Send (Client) Non-SYN (Omits Options)

Receive (Server) Non-SYN (Omits Options)

IPv6 KMAC256-128 Output Test Vectors

KMAC256-128 (Default - Covers TCP Options)

Send (Client) SYN (Covers Options)

Receive (Server) SYN-ACK (Covers Options)

Send (Client) Non-SYN (Covers Options)

Receive (Server) Non-SYN (Covers Options)

KMAC256-128 (Omits TCP Options)

Send (Client) SYN (Omits Options)

Receive (Server) SYN-ACK (Omits Options)

Send (Client) Non-SYN (Omits Options)

Receive (Server) Non-SYN (Omits Options)