Use of KMAC and SHAKE in the Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 13 March 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 [I-D.ietf-ipsecme-ikev2-prf-plus]. 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.¶

2. Introduction

This document specifies how to use KMAC128 and KMAC256, specified in [SP-800-185], 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 [I-D.ietf-ipsecme-ikev2-prf-plus].¶

This document also allocates values used for announcing support for SHAKE128 and SHAKE256, defined in [FIPS-202], when generating and validating signatures in IKEv2.¶

3. 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 [RFC2119] [RFC8174] 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 [FIPS-202] and [SP-800-185].¶

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

4. SHA-3 and Keccak

SHA-3 is a collection of cryptographic algorithms that all utilise the Keccak sponge construction. [FIPS-202] 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. [FIPS-202] 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. [SP-800-185] 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 [ML-KEM], [ML-DSA], [SLH-DSA], and [FALCON] 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 [RFC4868]. 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 [RFC8692]. As such, this document specifies use of KMAC and SHAKE in IPsec, but not the SHA-3 cryptographic hash functions.¶

5. 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 [RFC7296], which clash with the API described in [SP-800-185]. [RFC7296] uses S to describe the input string to prf+, whereas [SP-800-185] 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.¶

6. Constraints on KMAC inputs and outputs

Per [SP-800-185], 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 Table 2 and Table 3 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 [RFC8784], 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 [RFC7296] 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 [RFC7296] can impose constraints on suitable pre-shared keys.¶

Additionally, Ni and Nr are variable length and are used as the key for KMAC. [RFC7296] 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 [SP-800-185] 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.¶

7. 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 [SP-800-185]. A KMAC implementation conformant to that document is sufficient; no additional padding is required to use these algorithms in IKEv2 or IPsec.¶

8. Parameters and security strengths for KMAC

Table 1 describes the general properties of KMAC, with the HMAC-SHA2 algorithms also listed for comparison purposes. The maximum security strengths listed are taken from [SP-800-57]. 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.¶

Table 2 presents the parameters of KMAC when it is used as a PRF in IKEv2, with the HMAC-SHA2 algorithms also listed for comparison purposes.¶

The security strength of these algorithms is equal to the maximum security strength indicated for that algorithm in Table 1, 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 [I-D.ietf-ipsecme-ikev2-prf-plus] 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 Table 2.¶

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 [I-D.ietf-ipsecme-ikev2-prf-plus].¶

Table 3 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.¶

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 Table 3.¶

9. 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.¶

10. 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 [RFC8221], 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.¶

11. Use of SHAKE in the Digital Signature authentication method in IKEv2

SHAKE can be used to generate digests for use with signature algorithms. [RFC8692] specifies algorithm identifiers for using RSASSA-PSS or ECDSA with SHAKE in X.509 certificates.¶

[RFC7427] 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 Table 7 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.¶

12. Considerations for implementers and for future IPsec documents

KMAC's API differs from most PRF and Integrity Algorithm transforms as described in Section 5. 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. Table 4 shows an example for the case where the key, input and (in the case of KMAC) customization string are all the empty string.¶

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

13. 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 [RFC8221] and [RFC8247].¶

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 [GROVER] 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.¶

14. 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:¶

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:¶

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:¶

15. References

Appendix A. 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 Section 5. 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.¶

~~ Test Case KMAC128-PRF-1 ~~

Description:
Preferred key size

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Output (hex):
cf6727ddd39928f78af7844e0b18c6dc0d9795caccd6e592f39d881d5763d5af

~~ Test Case KMAC128-PRF-2 ~~

Description:
Smaller key size

Key (hex):
000102030405060708090a0b0c0d0e0f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Output (hex):
12a631badda8d9af5ecef703af5a8e421ac13e8eecdd4b840b60f8719f8bbe02

~~ Test Case KMAC128-PRF-3 ~~

Description:
Larger key size

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Output (hex):
3d2ace5443409145c5374e783a9b2299c2d1fcb3799c02a1a60ee3bdaa50071a

~~ Test Case KMAC256-PRF-1 ~~

Description:
Preferred key size

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Output (hex):
822d1fa78e6835e26891e6b08d49731ed1b11aac3c4c8074c528d4322154e79c
b664282d1ad322d2d1ceebc282f43857cafd66a6dee028457290485fa13e20be

~~ Test Case KMAC256-PRF-2 ~~

Description:
Smaller key size

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Output (hex):
5e821fad70266faa27c90ad48f6494b36f979457e60ff7e4f786646b6e5dbeda
90275a104caaaeed3a3a06a5f205c3594ff464bed2e044b30415026fa4851cc1

~~ Test Case KMAC256-PRF-3 ~~

Description:
Larger key size

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Output (hex):
90088df6e0f76ead91359c0ebfe5404e2daae0cd291c1c5b333c3a691986ad1e
13ea9ea21ede97ba0a4fa73ad434bb342fe8dde5963a88760c924ddc432ee465

~~ Test Case KMAC128-KDF-1 ~~

Description:
IKEv2 KDF request single PRF output

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Number of output bits requested (integer):
256

Output (hex):
d9908c095281a5cc0ecdee82cf4110cc9c6c4d082da98068f0a3528c52dc13d9

~~ Test Case KMAC128-KDF-2 ~~

Description:
IKEv2 KDF request multiple PRF output

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Number of output bits requested (integer):
512

Output (hex):
08b62b326b8a0582de26ca13a04f7aea2db924ec44cbcb580605114fbd79259c
62ec67d1597a804915eb71429207c32a479abd6f36e348235406cb80ec2e62fe

~~ Test Case KMAC128-KDF-3 ~~

Description:
IKE SA key material
ENCR=ENCR_AES_GCM_16 with 128-bit key
PRF=PRF_KMAC_128
SK_d = 256 bits
SK_a[i|r] = nil
SK_e[i|r] = 160*2 bits
SK_p[i|r] = 256*2 bits

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0
dfdedddcdbdad9d8d7d6d5d4d3d2d1d0

Number of output bits requested (integer):
1088

Output (hex):
f70b4ba63562a2e16ec67b826875701ffc4c3f9ec37cbfaf6c9ede90a431b8b6
61941077c17b2a42b41a7ed2319bac7f8d3a87b7bde3d921cc28956430971843
07016bc769e4dd89a3225a21de5f0310c96149a2943f8bf7f50878b8c95d028e
e778287a88c583efd72c05d758d5ab03e57e1a60e15c1714acd180e6487abc77
775a3c8da6335e7e

~~ Test Case KMAC128-KDF-4 ~~

Description:
IKE SA key material
ENCR=ENCR_AES_CBC with 128-bit key
INTEG=AUTH_KMAC_128
PRF=PRF_KMAC_128
SK_d = 256 bits
SK_a[i|r] = 256*2 bits
SK_e[i|r] = 128*2 bits
SK_p[i|r] = 256*2 bits

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0
dfdedddcdbdad9d8d7d6d5d4d3d2d1d0

Number of output bits requested (integer):
1536

Output (hex):
3643851ddafb6b041845ce330640614bc40dfa95389e7b35b2276870f000a5e5
47b9a1dc432fc7effd7d9209ea339d2c6559f3dd877c7c40a1c78cec9a3e5af5
998bedd899198e760beee3e9b4dd1dfcdcff4db61ab59fbe2284b09c89d25816
7bebfe0f96814ddac9ab8942e1ce6f99ddd166bb48f8ae389b10fe57655f3c1e
ee15f1c4eecd16a0df6afef2f7a3f9366d41e90a09d12f144b588a6837c257f8
d42989b2ee76e256976989f162b64a0e07ae528e373cc0c6cec55da1ed685d33

~~ Test Case KMAC128-KDF-5 ~~

Description:
ESP key material
ENCR=ENCR_AES_CBC with 128-bit key
INTEG=AUTH_KMAC_128
KEYMAT=(128*2) + (256*2) bits

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Number of output bits requested (integer):
768

Output (hex):
a0c2628180c4f4e3d94bf12726fdc2034bc3c07f67c57e474ea5dfb6e4dec3e5
9eb7e0c1d808e87f294a82752d4f96e180612ea45a2a500ff4781ca4c1c820bb
46a5c6229775bcfbf3bfd1b8fc2ad692785cf5fc81d28664285ca6de479a1fb0

~~ Test Case KMAC256-KDF-1 ~~

Description:
IKEv2 KDF request single PRF output

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Number of output bits requested (integer):
512

Output (hex):
b88f902d658be5804ac40125a79904908663873cec5d1ba49dce81b4a1aae6c5
cb701fe392c81125ff73f6ca1649888b9c64644e903b96c75d07789000a35d00

~~ Test Case KMAC256-KDF-2 ~~

Description:
IKEv2 KDF request multiple PRF output

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Number of output bits requested (integer):
1024

Output (hex):
7a7e73ed49d734c0c356d44d1b5b006d0dee371def9d88a3ab21c2a2a327257d
b8293239eec50cf74abf3b44eabfa1f3474211e8745dab5f8d38fb1082ae6f7b
166727549bd80c8c181d99b173a5768d57c1e4d90add36d7cfb0f8a7abb1bba1
7492ad06292c2ed5c31b7de929f6036d0fb08bb755b671d47e941f36618cf3ee

~~ Test Case KMAC256-KDF-3 ~~

Description:
IKE SA key material
ENCR=ENCR_AES_GCM_16 with 256-bit key
PRF=PRF_KMAC_256
SK_d = 512 bits
SK_a[i|r] = nil
SK_e[i|r] = 288*2 bits
SK_p[i|r] = 512*2 bits

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0
dfdedddcdbdad9d8d7d6d5d4d3d2d1d0cfcecdcccbcac9c8c7c6c5c4c3c2c1c0
bfbebdbcbbbab9b8b7b6b5b4b3b2b1b0

Number of output bits requested (integer):
2112

Output (hex):
3eeee64fa54813632088254e90f8b2476d45f756a067a37248d975f8322b49bf
d599b09a5577fdb751209ac785312fc3d29186d28e93205ada52cdc33c3dee71
6c239402869888479fcb32003d6167d0baef87c58cde5df1e65477f9f057ae47
f67274d0d6c79fcf8183add89e518c4f881f7ecbff0e3e11a0d3d8464cb72e68
41ac4f4c1a1ae6733ef43ab4c57ba5135b0b4feb1500ce434ef1dc67738e7fb5
d6391a9d9e32bc93cc186e794b5a2bc07c2b12c7187797b37b3f4302a26bbc1c
1a1873d5cd0ab3d8a213046a32521934d75b45c16d4cf4ad33f11890860b0cf8
9e2c1731a0cb21813fc4f8af658c8d6185c248928e1e6d2e73c27d9e5477b88b
9fe3a5463a80e6ee

~~ Test Case KMAC256-KDF-4 ~~

Description:
IKE SA key material
ENCR=ENCR_AES_CBC with 256-bit key
INTEG=AUTH_KMAC_256
PRF=PRF_KMAC_256
SK_d = 512 bits
SK_a[i|r] = 512*2 bits
SK_e[i|r] = 256*2 bits
SK_p[i|r] = 512*2 bits

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0
dfdedddcdbdad9d8d7d6d5d4d3d2d1d0cfcecdcccbcac9c8c7c6c5c4c3c2c1c0
bfbebdbcbbbab9b8b7b6b5b4b3b2b1b0

Number of output bits requested (integer):
3072

Output (hex):
717678dca65d87b0d6940c2e6c58fea9f37d920623fd80f4292b1ba2fab73fe5
ce88bab849d0cee39c137266f92f561c345f6d0121906741bb70c335b52c5c0f
864539178b96372f1f7cdbf10b06abdc2ebe325e2b6bfe270a82be2f4529f4e8
a3ee17ffa848f151ce94928cc82c2c89ff0660eeedaac9e7ee6a9e8108d839dc
c838bad5094b9dbedb8f09303d0080b4fef5288c0cb7856748067d36fab22d2e
c50992ec88a56c2673cf3cbb8e72b2b98c9f72d95e8abed0b6b8f4433db9bf37
3cd06628a37a5188a12506c12500e9d7d26452eb6533d69bca0c158ab27377bc
8b29c73afa04c88cf6d62064333a3718242308136fae4a76ed7e553b5a813523
3d5b26d683a9ad53d883fa3b25572139617049afe39d75b9c6519c0e788fd973
90659b9f354e2c22eb0158dfd8eb3fafbab1ad886eba79a66e0f39688af9cf37
a0beef99692ff554e1bfc48df3da84b74f84bec12d84335bb31b258a8e3b46de
94fa140ce8863cbb8555f0a0745ae283cc6c2d57f6840fad6e09838ed1b1b4d9

~~ Test Case KMAC256-KDF-5 ~~

Description:
ESP key material
ENCR=ENCR_AES_CBC with 256-bit key
INTEG=AUTH_KMAC_256
KEYMAT=(256*2) + (512*2) bits

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Number of output bits requested (integer):
1536

Output (hex):
d17d6a54d87668652d703c96b153e9c0103ad537e72b5d285c844bafc13c893a
796975289457a9a930e309af7759be10ffbfa7ac8c695d74e23c724197f6a797
447d3712e17101942d5c024e8c1d16e97672c28134f5dd721c33b0256e5e2cd0
47ac01e9ca3a6a3b9a1f52d00283c4e9bdcbc2db18abc98464226a82fc42b649
d86a0a3ed4d008bc87c0822e161b5582535898e0046191dc21220beded524fac
ce48d513fe2a2227629caf69cc37b0c660b92382a6dcf95b8becacaa20145bf7

~~ Test Case KMAC128-INTEG-1 ~~

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Output (hex):
84c68523a2abc7fd0edb766e976168c1

~~ Test Case KMAC256-INTEG-1 ~~

Key (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f

Input (hex):
fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0

Output (hex):
931d2d1c1d4402ce4820745082e7a8ba84910399cf1dcb9dc1080bfb3e243691

Appendix B. Acknowledgments

TODO¶

Authors' Addresses