]> HPE

USA ronald.bonica@hpe.com

HPE

USA tony.li@tony.li

HPE

Canada ping.chen@hpe.com

Arista Networks

India reji.thomas@arista.com

Cisco Systems

India sujeetnayak@yahoo.com

Cisco Systems

USA ayabaner@cisco.com

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

Introduction creates a list of cryptographic algorithms that can be used with TCP-AO . This document expands that list, adding two Message Authentication Code (MAC) algorithms, HMAC-SHA256 and KMAC256. For each MAC algorithm, a corresponding Key Derivation Function (KDF) is also added. The MAC algorithms described by this document produce 256-bit (i.e., 32-byte) MACs. When 32-byte MACs are encoded in TCP-AO, the TCP-AO consumes 36 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 secure 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). It MUST be at least 256 bits in length.
• Context is binary string containing information related to the TCP connection, as defined in Section 5.2 of .
• Output_Length is the desired length of the Traffic_Key. In this document, the Output_Length is always equal to 256 bits.

This document defines two KDFs:

• HKDF-SHA256
• KMAC256-KDF

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

HKDF-SHA256 HKDF-SHA256 is as described in , , and . HKDF-SHA256 executes in the following stages:

• Extract
• Expand

The interface to the Extract stage is:

• PRK = HKDF-Extract(salt, IKM)

where:

• PRK is a Pseudo-random 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.

The expand stage expands the pseudorandom key to the desired length. The output key length depends on the specific cryptographic algorithms for which the keys are needed. Implementations MUST execute the expand stage.

KMAC256-KDF KMAC256-KDF is as described in and . So, the interface to KMAC256-KDF as described in :

• OKM = KMAC256(Z, salt, x, H_outputBits, S)

where:

• Z is the Master_Key argument provided to the KDF interface.
• salt is an all-zero byte string whose length equals 132 bytes.
• x 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.

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 256 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 MAC Algorithm used.
• Traffic_Key is the result of KDF.
• Message is the message to be authenticated, as specified in Section 5.1 of .

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

• KDF_Alg: HKDF-SHA256.
• Key_Length: 256 bits.
• MAC_Length: 256 bits.

For:

• MAC = MAC_alg (Traffic_Key, Message)

HMAC-SHA256 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 Use of KMAC256 The three fixed elements for KMAC256 are:

• KDF_Alg: KMAC256-KDF
• Key_Length: 256 bits.
• MAC_Length: 256 bits.

For:

• MAC = MAC_alg (Traffic_Key, Message)

KMAC256 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 .

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. When using the algorithms mentioned in this document, the Master_key MUST be 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 an ASCII string is used, it SHOULD be the hex or base64 representation of a cryptographic key with at least 256 bits of entropy, rather than a human-readable password or passphrase. 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 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" (https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-3). IANA Actions

Algorithm	Reference
HMAC-SHA256	This Document
KMAC256	This Document

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

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] 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] 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. 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 specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. 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). National Institute of Standards and Technology National Institute of Standards and Technology

Test Vectors This appendix provides test vectors to validate the correct implementation of TCP-AO and the cryptographic algorithms defined in this document. It includes the specification of all endpoint parameters to generate the variety of TCP segments covered by different keys and MAC coverage, i.e., both the default case and the variant where TCP options are ignored for middlebox traversal.

Input Test Vectors Input test vectors are as described in Section 3 of .

IPv4 HMAC-SHA256 Output Test Vectors In the following sections, all values are indicated as 2-digit hexadecimal values with spacing per line representing the contents of 16 consecutive bytes, as is typical for data dumps. The IP/TCP data indicates the entire IP packet, including the TCP segment and its options (whether covered by TCP-AO or not, as indicated), including TCP-AO.

HMAC-SHA256 (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 (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 Output Test Vectors In the following sections, all values are indicated as 2-digit hexadecimal values with spacing per line representing the contents of 16 consecutive bytes, as is typical for data dumps. The IP/TCP data indicates the entire IP packet, including the TCP segment and its options (whether covered by TCP-AO or not, as indicated), including TCP-AO.

KMAC256 (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 (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 Output Test Vectors

HMAC-SHA256 (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 (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 Output Test Vectors

KMAC256 (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 (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)