]> HPE

USA ronald.bonica@hpe.com

HPE

USA tony.li@tony.li

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 Key Derivation Functions (KDFs) and two Message Authentication Code (MAC) Algorithms. They are called HKDF-SHA384, KMAC384-KDF, HMAC-SHA384, and KMAC384. The algorithms described by this document produce 384-bit (i.e., 48-byte) MACs. When 48-byte MACs are encoded in TCP-AO, the TCP-AO consumes 52 bytes. This exceeds TCP's current 40-byte option size limitation.

Introduction creates a list of cryptographic algorithms that can be used with TCP-AO . This document expands that list, adding two Key Derivation Functions (KDFs) and two Message Authentication Code (MAC) Algorithms. They are called HKDF-SHA384, KMAC384-KDF, HMAC-SHA384, and KMAC384. The algorithms described by this document produce 384-bit (i.e., 48-byte) MACs. When 48-byte MACs are encoded in TCP-AO, the TCP-AO consumes 52 bytes. This exceeds TCP's current 40-byte option size limitation.

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 Initial 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, human-readable pre-shared key (PSK).
• Context is binary string containing information related to the TCP connection, as defined in , Section 5.2.
• Output_Length is the desired length of the Traffic_Key. In this document, the Output_Length is always equal to 384 bits.

This document defines two KDFs:

• HKDF-SHA384
• KMAC384-KDF

of this document describes HKDF-SHA384 while describes KMAC384-KDF.

HKDF-SHA384 HKDF-SHA384 is as described in . HKDF-SHA384 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 a 48-byte string of all-zero values.
• 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. In some applications, the input may already be a good pseudorandom key. In these cases, the extract stage is not necessary, and the expand part can be used alone. However, when used with TCP-AO, implementations MUST execute the extract stage. The interface to the Expand Step 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 the Output_Length argument provided to the KDF interface.

The expand step expands the pseudorandom key to the desired length. The number and lengths of the output keys depend on the specific cryptographic algorithms for which the keys are needed.

KMAC384-KDF KMAC384-KDF is as described in . The interface to KMAC384-KDF is:

• OKM = KMAC384(K, X, L, S).

Where:

• OKM is the Traffic_Key.
• K is the Master_Key argument provided to the KDF interface.
• X is the Context argument provided to the KDF interface.
• L is the Output_Length argument provided to the KDF interface.
• S is application specific information. It is always equal to "TCP-AO".

KMAC384-KDF operates in the following stages:

• Absorb
• Squeeze

Both stages compensate for lack of entropy in the Master_Key and neither stage is optional.

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 384 bits.
• MAC_Length is the desired length of the MAC to be produced by the algorithm. In this document, the MAC_Length is always 384 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.

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

• KDF_Alg: HKDF-SHA384.
• Key_Length: 384 bits.
• MAC_Length: 384 bits.

For:

• MAC = MAC_alg (Traffic_Key, Message)

HMAC-SHA-384 for TCP-AO has the following values:

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

The Use of KMAC384 The three fixed elements for KMAC384 are:

• KDF_Alg: KMAC384-KDF.
• Key_Length: 384 bits.
• MAC_Length: 384 bits.

For:

• MAC = MAC_alg (Traffic_Key, Message)

KMAC384 for TCP-AO has the following values:

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

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. Master_Keys SHOULD have 256 bits of entropy. This document RECOMMENDS that operators randomly generate 256-bit strings for use as Master_Keys. However, it is understood that may not do so. 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-SHA384	This Document
KMAC384	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 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).