]> 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 RFC5926 creates 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 and KMAC256. 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 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 and KMAC256. 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). HMAC-SHA256 uses HKDF-SHA256 while KMAC256 uses KMAC256-KDF, which is based on the one-step key-derivation function in . describes both of these.

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

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

In the interface:

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

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 for TCP-AO is:

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

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 .
• L = 256 (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 .

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 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 HPE HPE HPE HPE Arista Networks Cisco Systems Cisco Systems 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.

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): 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 36 bytes long (Kind 29, Length 36, KeyID, RNextKeyID, and a 32-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. Because the TCP-AO option is 36 bytes long, only 4 of the 40 bytes available for TCP options remain for other options. The SYN and SYN-ACK segments therefore carry only the MSS option (4 bytes) in addition to TCP-AO, and the non-SYN segments carry no other TCP options. Consequently, in the "Omits TCP Options" vectors, omission affects the MAC input only for the SYN and SYN-ACK segments, where the MSS option is removed. 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 source address, destination address, source port, destination port, the sender's ISN, and 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 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 HMAC-SHA256(Traffic_Key, MAC input):

KMAC256 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, 256 bits, ""):

IPv4 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)

IPv4 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)

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)