]> UK National Cyber Security Centre

Ben.S3@ncsc.gov.uk

UK National Cyber Security Centre

Adam.R@ncsc.gov.uk

UK National Cyber Security Centre

Jonathan.C@ncsc.gov.uk

Security IPSECME ipsec sha-3 ikev2 kmac shake This document specifies the use of KMAC128 and KMAC256 within the Internet Key Exchange Version 2 (IKEv2), Encapsulating Security Payload (ESP), and Authentication Header (AH) protocols. These algorithms can be used as integrity protection algorithms for ESP, AH and IKEv2, and as Pseudo-Random Functions (PRFs) for IKEv2. Requirements for supporting signature algorithms in IKEv2 that use SHA3-256, SHA3-384, SHA3-512, SHAKE128 and SHAKE256 are also specified.

Changes in draft-ietf-ipsecme-sha3-02 Removed the SHA-3 hash algorithms as options for SIGNATURE_HASH_ALGORITHMS. The draft now only discusses KMAC, with SHAKE as an option for a signature hash function. The draft's title has been changed to reflect this. Aligned the document with -02 of . This removes use of customization labels and reverts back to use of an 0x01 byte to provide domain separation between uses of prf and prf+. Corrected key sizes for AUTH transforms in AUTH transform table. Corrected conflicting details about KMAC output lengths when used as a PRF.

Introduction This document specifies how to use KMAC128 and KMAC256, specified in , with IKEv2 and IPsec for integrity protection, and as a PRF for IKEv2. Use of KMAC as a PRF and in prf+ is aligned with the framework for use of variable-length PRFs in IKEv2 specified in . This document also allocates values used for announcing support for SHAKE128 and SHAKE256, defined in , when generating and validating signatures in IKEv2.

Conventions and Definitions 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 BCP 14 when, and only when, they appear in all capitals, as shown here. Additionally, this document uses several terms to collectively refer to sets of algorithms. The term "SHA-3 cryptographic hash functions" is used to collectively refer to SHA3-256, SHA3-384 and SHA3-512. The term "KMAC" is used to collectively refer to KMAC128 and KMAC256. The term "SHA-3" (without any other qualifiers) is used to collectively refer to the cryptographic algorithms defined in and . The term "SHA-2" (without any other qualifiers) is used to collectively refer to SHA-256, SHA-384, and SHA-512. The term "SHAKE" is used to collectively refer to SHAKE128 and SHAKE256.

SHA-3 and Keccak SHA-3 is a collection of cryptographic algorithms that all utilise the Keccak sponge construction. describes the SHA-3 cryptographic hash functions, which produce a fixed-length digest for any length of input. These hash functions are intended to be used in the same manner and contexts as other traditional hash functions such as SHA-2. also describes the SHAKE XOFs. An XOF differs from a traditional hash function in that the length of the XOF's output can be chosen by the application that uses it. describes cSHAKE, a customizable version of SHAKE, and KMAC, which is a PRF and keyed hash function built using cSHAKE. Like SHAKE and cSHAKE, the length of KMAC's output is application-dependent. SHA-3 was specified to provide applications with an alternative to SHA-2, which is based on the Merkle-Damgård construction. Use of the Merkle-Damgård construction in SHA-2 means that length extension attacks are possible if SHA-2 isn't used correctly. At the time of writing, use of SHA-2 in IPsec is believed to be secure, and hence there is no security motivation to migrate away from SHA-2 to SHA-3 in this context. However, in the event that a significant attack on SHA-2 is discovered, SHA-3 will be an immediately viable alternative. Migration to use of post-quantum algorithms in IKEv2 may make use of SHA-3 more appealing for minimal implementations of IPsec, as , , , and all make use of SHA-3 internally. Since SHA-3 must be implemented as a component of these algorithms, some IPsec implementers may prefer to implement SHA-3, and only SHA-3, if interoperability with general-purpose IKEv2 and IPsec implementations is not required. SHA-2 is widely used with HMAC in IKEv2 and IPsec, as specified in . While the SHA-3 cryptographic hash functions can be used with HMAC, KMAC is more efficient as it directly uses the Keccak sponge function to produce a MAC, rather than treating Keccak as a traditional cryptographic hash function and then feeding that hash function into a separate MAC algorithm. The SHA-3 cryptographic hash functions could also be used with signature algorithms that support a pre-hash, but use of SHA-3 in this way has not been specified in IETF standards, whereas use of SHAKE for this purpose is specified in . As such, this document specifies use of KMAC and SHAKE in IPsec, but not the SHA-3 cryptographic hash functions.

KMAC API The basic API for KMAC is defined below. The symbols used in this API description are consistent with those used for prf+ in , which clash with the API described in . uses S to describe the input string to prf+, whereas uses that symbol for the optional customization string. KMAC implementations used in IKEv2 and IPsec do not need to conform to these APIs exactly; they are merely used in this document for illustrative purposes. For the purposes of this document, the API for KMAC is defined as:

• KMAC(K, S, L, C) -> Z

where: K is the key. It is a bit string of length between zero and (2^2040)-1 bits, inclusively. S is the input string. It is a bit string of any length, including zero. L is an integer representing the requested output length in bits. This parameter is typically fixed in the context of IPsec, except when extracting key material using prf+ in IKEv2, where it depends on the length of key material needed by the negotiated cipher suite. C is an optional customization string. It is a bit string of length between zero and (2^2040)-1 bits, inclusively. For the purposes of this document, C is always empty. Z is the output string of KMAC, which is a message authentication code. It is a bit string of length L.

Constraints on KMAC inputs and outputs Per , the length of the key input K input to KMAC MUST be less than 2^2040 bits. In the context of IKEv2 and IPsec, there is no situation where a key that long would be expected. Initiator and Responder nonces Ni and Nr are used as inputs to IKEv2 PRF calls, although the length of these nonces combined cannot exceed 4096 bits. Pre-shared keys used for authentication in IKEv2 are used as keys with PRFs negotiated by IKEv2, and have no upper bound on their length. Therefore, KMAC implementations used with IKEv2 MUST at minimum accept values of K up to and including 4096 bits in length. Implementations MAY restrict the size of pre-shared key inputs such that they do not exceed 4096 bits. There is no algorithm-defined minimum size for the key input to KMAC, but and list the recommended key sizes to be used within the context of IKEv2 and IPsec, aligned to the security strength of each algorithm. Using a key smaller than the security strength of the chosen KMAC algorithm undermines the security properties of that algorithm. Where IKEv2 is used to create security associations, the size of most PRF keys is automatically managed at the protocol level, and there is no risk of selecting an undersized key in these cases. However, the size of keys used for PRFs in IKEv2 cannot always be controlled. As an example, in the case of pre-shared keys used for authentication or protection against a quantum computer as in , those secrets are used as the key input to a PRF negotiated by IKEv2. Those pre-shared keys could be arbitrarily chosen by a user or derived from a password rather than securely generated, even though strongly discourages this practice. Keys chosen in this manner may be shorter than any recommended key size. IKEv2 implementations following the recommendation laid out in can impose constraints on suitable pre-shared keys. Additionally, Ni and Nr are variable length and are used as the key for KMAC. states that each of these nonces MUST be at least 128 bits in size, and MUST be at least half the preferred key size for the negotiated PRF. If an IKEv2 peer sends an undersized nonce, the message containing that nonce can be rejected in the same way as any malformed IKEv2 message would be. Conformant KMAC implementations SHOULD reject keys that do not meet the security strength of the corresponding algorithm. The input string S can be a variety of lengths in practice, but in the context of IKE and IPsec the length will always be a multiple of eight, as IKE and IPsec only operate on entire octets. Similarly, KMAC's output length parameter L will always be a multiple of eight. Since the length of output required from KMAC is always known in advance, KMAC with arbitrary-length output as described in Section 4.3.1 of is never used, and thus L is never set to 0. KMAC's customization string C is always empty in the context of this document.

Padding Since the length of the input string S for KMAC varies, and KMAC operates on fixed-size input blocks, padding is required to use KMAC in IKEv2 and IPsec. The padding scheme for KMAC is specified in . A KMAC implementation conformant to that document is sufficient; no additional padding is required to use these algorithms in IKEv2 or IPsec.

KMAC Key Padding When KMAC is used as the PRF for an IKE SA, the size of the key input K is variable. If the size of a KMAC key is greater than the preferred key size as shown in , the key is used in its entirety without any kind of shortening or truncation. As described in , keys are always padded up to a multiple of the rate of the underlying Keccak sponge function; that is, 168 bytes and 136 bytes for KMAC128 and KMAC256 respectively. Any KMAC implementation conformant with is suitable for use in IKEv2 and IPsec; no protocol-specific additional padding of keys is required.

Parameters and security strengths for KMAC describes the general properties of KMAC, with the HMAC-SHA2 algorithms also listed for comparison purposes. The maximum security strengths listed are taken from . Note that these are maximum security strengths. Keys that contain insufficient entropy to meet an algorithm's stated maximum security strength constrain the maximum security of the chosen algorithm to be no higher than the bits of entropy represented in the key. Algorithm Name Output Length (bits) Maximum Security Strength (bits) HMAC-SHA-256 256 256 HMAC-SHA-384 384 256 HMAC-SHA-512 512 256 KMAC128 Variable 128 KMAC256 Variable 256 presents the parameters of KMAC when it is used as a PRF in IKEv2, with the HMAC-SHA2 algorithms also listed for comparison purposes. Algorithm Name PRF variant Preferred Key Size (bits) Output Length (bits) HMAC-SHA-256 PRF_HMAC_SHA2_256 256 256 HMAC-SHA-384 PRF_HMAC_SHA2_384 384 384 HMAC-SHA-512 PRF_HMAC_SHA2_512 512 512 KMAC128 PRF_KMAC_128 256 256, or length of output required for prf+ KMAC256 PRF_KMAC_256 512 512, or length of output required for prf+ The security strength of these algorithms is equal to the maximum security strength indicated for that algorithm in , unless the entropy of the supplied key is insufficient to meet that strength. Note that the preferred key size for both KMAC variants is double the security strength of each algorithm. This is to align with the requirement in that, for PRFs with variable-length output, the output length of the PRF when used in the context of "prf" (rather than "prf+") must match the preferred key size of the PRF. When key material is extracted from IKEv2's prf+ Key Derivation Function (KDF) for use with KMAC as a PRF in IKEv2, the length of keys extracted MUST conform to the preferred key sizes listed in . EDNOTE: The KMAC output lengths have been aligned with HMAC, but if we're not depending on collision resistance, could they be reduced to 128/256 bits respectively? This would also mean that the key size could be reduced back down to 128/256 bits; they only need to be 256/512 bits to maintain conformance with . presents the parameters of KMAC when it is used for data origin authentication and integrity protection in IKEv2 and IPsec, with the HMAC-SHA2 algorithms also listed for comparison purposes. Algorithm Name Integrity variant Key Size (bits) Output Length (bits) HMAC-SHA-256 AUTH_HMAC_SHA2_256_128 256 128 HMAC-SHA-384 AUTH_HMAC_SHA2_384_192 384 192 HMAC-SHA-512 AUTH_HMAC_SHA2_512_256 512 256 KMAC128 AUTH_KMAC_128 256 128 KMAC256 AUTH_KMAC_256 512 256 When used for authentication and integrity protection, KMAC message authentication codes are produced using a smaller value for the "requested output length" parameter L. In this case, the security strength of each given algorithm is constrained by its output length. When key material is extracted from IKEv2's prf+ KDF for use with KMAC for data origin authentication and integrity protection in IKEv2 or IPsec, the length of keys extracted MUST conform to the key sizes listed in .

KMAC as a PRF in IKEv2 IKEv2 Security Associations (SAs) make use of a PRF for authentication purposes, and as a part of the prf+ Key Derivation Function (KDF). KMAC can act as the PRF for an IKE SA, but it is treated slightly differently to existing PRFs as it is capable of producing different output lengths depending on the context in which it is used. With KMAC, the key K is either a fixed-length key (such as SK_d) that is the preferred key size for the variant of KMAC being used, or the length of K is dependent on other factors. When the PRF is used with nonce inputs as the key K (e.g. when generating SKEYSEED), or when the PRF is used with a pre-shared key as the input key K, the length of K depends on implementation-specific details, user configuration options, etc.

KMAC as a PRF When used in IKEv2 as a PRF outside the prf+ construction, KMAC's output length L is 256 for KMAC128, and 512 for KMAC256. That is, the output length is the same size as the preferred key size of the given KMAC algorithm. Note that the situation is different when KMAC is used within the prf+ construction, as described in .

KMAC in prf+ defines an iterative function called "prf+" that can be used with a PRF to produce a pseudorandom stream of arbitrary length. Typically prf+ is used to derive SA keys from SKEYSEED or SK_d. However, as described in , prf+ isn't necessary when using a PRF that can produce variable-length output (like KMAC), as a single call to the PRF can produce as many pseudorandom bits as needed. When a PRF with variable-length output is negotiated as an IKE SA's PRF, specifies the following construction to replace the definition of prf+ in :

• prf+ (K,S) = prf (K, S | 0x01)

When KMAC is negotiated as an IKE SA's PRF, this construction is used. The L input parameter for KMAC is set to the length of the keying material required.

KMAC for integrity protection in ESP, AH and IKEv2 IKE and IPsec SAs can make use of an integrity protection algorithm to provide data origin authentication and integrity protection services. KMAC can be used to provide these services. As described in , Authenticated Encryption with Associated Data (AEAD) ciphers are the fastest and most modern approach to providing these services in conjunction with confidentiality protection. KMAC MUST NOT be negotiated in IKEv2 in conjunction with an AEAD cipher. KMAC MAY be used as an integrity protection algorithm with: ESP in conjunction with a non-AEAD cipher ESP and null encryption (ENCR_NULL) IKEv2 in conjunction with a non-AEAD cipher AH When using KMAC, the L input parameter is always set to the same value as the key size and security strength of the chosen KMAC algorithm. That is, the output length of KMAC128 is always set to 128 bits, and the output length of KMAC256 is always set to 256 bits.

Use of SHAKE in the Digital Signature authentication method in IKEv2 SHAKE can be used to generate digests for use with signature algorithms. specifies algorithm identifiers for using RSASSA-PSS or ECDSA with SHAKE in X.509 certificates. specifies the "Digital Signature" (14) authentication method, which allows IKEv2 to support any signature algorithm without the need to specify an authentication method for every new combination of signature algorithm and hash function. The Digital Signature authentication method is the only way to utilise SHAKE with signatures in IKEv2, so if a peer uses SHAKE in this context, it MUST specify the Digital Signature authentication method in its corresponding AUTH payload. The Digital Signature authentication method specifies use of a SIGNATURE_HASH_ALGORITHMS notification by each IKEv2 peer to announce the hash functions it supports for use with signatures. This specification defines values in for announcing support for SHAKE128 and SHAKE256 in the SIGNATURE_HASH_ALGORITHMS notification. When an IKEv2 implementation supports SHA-3 in this context, and local policy permits use of SHAKE to generate or verify signatures, it MUST include the corresponding values in its SIGNATURE_HASH_ALGORITHMS notification.

Considerations for implementers and for future IPsec documents KMAC's API differs from most PRF and Integrity Algorithm transforms as described in . Care should be taken with the output length parameter L in particular, as its behavior can be counter-intuitive when compared to other integrity algorithms where a truncated output is used as an authenticator value. Unlike SHAKE, KMAC outputs of different lengths are not related. That is, the value of L is factored into the calculation of the output value, and thus all bits of the output value are affected. This means that implementations cannot simply discard a portion of a KMAC output as a substitute for requesting the correct value for L. For example, a KMAC256 implementation used as the PRF transform for IKEv2 cannot be used as an Integrity transform simply by discarding bits from that implementation's output; a different value of L must be supplied. shows an example for the case where the key, input and (in the case of KMAC) customization string are all the empty string. Transform Name Output Length (bits) Output (hex) PRF_HMAC_SHA2_256 256 b613679a0814d9ec772f95d778c35fc5... AUTH_HMAC_SHA2_256_128 128 b613679a0814d9ec772f95d778c35fc5 PRF_KMAC_128 256 5c135c615152fb4d9784dd1155f9b603... AUTH_KMAC_128 128 e6aff27fef95903eb939bc3745730d34 This is also true for prf+ when used with KMAC. Typically prf+ is used iteratively to obtain at least as much key material as is required, and the amount of key material obtained will be a multiple of the output size of the negotiated PRF. This process will often produce more key material than required, and the excess is simply discarded. When KMAC is used, the amount of key material required is supplied to the PRF, and exactly the right amount of key material will be returned. Requesting more key material than required and discarding any excess will produce different keys, and interoperability will not be possible. Future authors of IPsec documents should be careful to consider whether related outputs from a PRF are required for their specification, and if so, describe how to handle KMAC and similar PRFs.

Security Considerations SHA-3 and SHA-2 are both believed to be secure at time of writing. Views on the security of cryptographic algorithms evolve over time, so implementers should pay attention to IETF RFCs reporting on recommendations for the use of cryptographic algorithms in IKEv2 and IPsec, such as any documents that update and . Quantum computing has a significant impact on the security of all IETF security protocols, as a cryptographically-relevant quantum computer (CRQC) could use Shor's algorithm to break many traditional asymmetric cryptographic algorithms. A CRQC can theoretically also attack hash functions, including SHA-3 and SHA-2, using Grover's algorithm. However, the impact of Grover's algorithm is significantly less dramatic than the impact of Shor's Algorithm. The worst-case impact of Grover's algorithm would be a reduction in security strength by a factor of two. However, since Grover's algorithm is difficult to parallelise, the security reduction for SHA-3 and SHA-2 caused by Grover's algorithm is expected to be far less significant in practice. See for a discussion on the practical cost of using Grover's algorithm to attack hash functions. The security properties offered by KMAC depend on limiting access to the keys used with those algorithms. Since KMAC depends on a symmetric key, the key must be known by at least two parties in order to be useful. Sharing the key beyond two parties may erode the security offered by KMAC. In the case of IKEv2 and IPsec, this typically means that access to keys must be limited to the peers participating in the security association that uses those keys. IKEv2 can be used to enforce this for IPsec SAs and most keys used in IKE SAs, but pre-shared keys are a notable exception here. Providing more than two peers with access to a single pre-shared key may undermine the security offered by that pre-shared key, and hence the security offered by KMAC. When IKEv2 is used to create IPsec SAs, the keys for KMAC are all ultimately derived from an ephemeral shared secret produced using one or more negotiated key exchange algorithms, with the exception of static pre-shared keys used in IKEv2 for authentication and/or protection against quantum computers. If the negotiated key exchange algorithm or encryption algorithm offers fewer bits of security than the negotiated PRF, this effectively caps the bits of security offered by the PRF as well. Negotiating a key exchange algorithm or encryption algorithm that offers more bits of security than the negotiated PRF does not improve the security offered by that PRF. As such, it is important to ensure that IKEv2 peers configure algorithm policies such that every algorithm negotiated always meets an acceptable minimum security strength. Where static keys are used with KMAC, these MUST contain at least as much entropy as the security strength of the chosen algorithm. This can be achieved using a random number generator suitable for use with cryptography.

IANA Considerations For negotiating use of KMAC as a PRF for IKEv2, IANA is requested to assign two Transform IDs in the "Transform Type 2 - Pseudorandom Function Transform IDs" registry: Number Name Status Reference TBD PRF_KMAC_128   [This draft] TBD PRF_KMAC_256   [This draft] For negotiating use of KMAC for integrity protection in IKEv2 and IPsec protocols, IANA is requested to assign two Transform IDs in the "Transform Type 3 - Integrity Algorithm Transform IDs" registry: Number Name Status Reference TBD AUTH_KMAC_128   [This draft] TBD AUTH_KMAC_256   [This draft] For indicating support for use of SHAKE in conjunction with a signature algorithm, IANA is requested to assign two Transform IDs in the "IKEv2 Hash Algorithms" registry: Value Hash Algorithm Reference TBD SHAKE128 [This draft] TBD SHAKE256 [This draft]

This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology ELVIS-PLUS This document specifies the use of variable-length output Pseudo- Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2). Current IKEv2 specification relies on traditional PRFs with fixed output length for key derivation and uses iterative application of a PRF (called "prf+") in cases when longer output is required. Appearance of PRFs that can output as much bits as requested allows to streamline the key derivation functions of IKEv2. This document updates RFC 7296 and RFC 7815 for the cases when variable-length output Pseudo-Random Functions are used in IKEv2 and its extensions. 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. 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. The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms. National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology European Telecommunications Standards Institute This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulating Security Payload (ESP). The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys. This specification describes the use of Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512. [STANDARDS-TRACK] Digital signatures are used to sign messages, X.509 certificates, and Certificate Revocation Lists (CRLs). This document updates the "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" (RFC 3279) and describes the conventions for using the SHAKE function family in Internet X.509 certificates and revocation lists as one-way hash functions with the RSA Probabilistic signature and Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithms. The conventions for the associated subject public keys are also described.

Test Vectors The following test cases include inputs and outputs for scenarios where KMAC is used in IKEv2 and IPsec. A key, input, customization string, and output are always supplied. These correspond to the K, S, C, and Z parameters described in . Note that in each context, the customization string is always empty. All inputs and outputs are encoded as hexadecimal values. Data supplied to KMAC does not include quotation marks or null terminators. In some cases a description is supplied, which describes the case being tested in more detail. These descriptions are test vector metadata, and are not ever supplied to the relevant algorithm.

PRF Test Vectors These test cases correspond to use of the KMAC transform in IKEv2 as a PRF producing fixed-length output, as described in .

KMAC128 PRF Test Vectors

KMAC256 PRF Test Vectors

prf+ Test Vectors These test cases correspond to use of KMAC in IKEv2 with the modified version of prf+, as described in .

KMAC128 prf+ Test Vectors

KMAC256 prf+ Test Vectors

Integrity Protection Test Vectors These test cases correspond to use of KMAC as the integrity protection transform for either an IKE SA or an IPsec SA, as described in .

KMAC128 Integrity Protection Test Vectors

KMAC256 Integrity Protection Test Vectors

Acknowledgments TODO