| Internet-Draft | SHA-3 in IKEv2 and IPsec | October 2024 |
| Salter, et al. | Expires 7 April 2025 | [Page] |
This document specifies the use of HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3-512, 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-224, SHA3-256, SHA3-384 and SHA3-512 are also specified.¶
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 7 April 2025.¶
Copyright (c) 2024 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.¶
[FIPS-202] specifies both the SHA3-256, SHA3-384 and SHA3-512 cryptographic hash functions, and the SHAKE eXtendable-output functions (XOFs). HMAC [RFC2104] can be used with cryptographic hash functions to generate message authentication codes (MACs) that can be used for integrity protection for IKEv2 or IPsec, or as a PRF for IKEv2. [SP-800-185] specifies KMAC128 and KMAC256, which use variants of SHAKE128 and SHAKE256 respectively to create a MAC. Like the output of SHAKE, the MAC output of KMAC can be of any length required by the application.¶
This document specifies how to use HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3-512, KMAC128, and KMAC256 with IKEv2 and IPsec. It also allocates values used for announcing support of SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256 when generating and validating signatures in IKEv2.¶
EDNOTE: HMAC-SHA3-224 has been ignored as it doesn't have an equivalent in RFC 4868. draft-ietf-lamps-cms-sha3-hash includes support for SHA3-224 with ECDSA, hence its inclusion in the hash functions registry. Should SHA3-224/HMAC-SHA3-224 be specified for use in IKEv2/IPsec? Can/should the output be truncated safely for auth/integrity protection?¶
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 "HMAC" is used to refer to the Keyed-Hash Message Authentication Code algorithm generally, independent of specific cryptographic hash functions.¶
The term "HMAC-SHA3" is used to collectively refer to HMAC-SHA3-256, HMAC-SHA3-384 and HMAC-SHA3-512.¶
The term "KMAC" is used to collectively refer to KMAC-128 and KMAC-256.¶
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-224, SHA-256, SHA-384 and SHA-512.¶
The term "SHAKE" is used to collectively refer to SHAKE128 and SHAKE256.¶
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 customisable version of SHAKE, and KMAC, which is a PRF and keyed hash function that utilises 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 support for SHA-3 is required to implement these algorithms, some implementers may find it preferable to implement SHA-3, and only SHA-3, if interoperability with general-purpose IKEv2 and IPsec implementations is not required.¶
KMAC is more efficient than HMAC-SHA3, 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. This would imply that use of KMAC is strictly preferred over HMAC-SHA3 and that HMAC-SHA3 shouldn't be implemented. However, as HMAC doesn't produce variable-length output and is widely utilised in IPsec implementations already, upgrading these implementations to support HMAC-SHA3 may be a simpler task than upgrading them to support KMAC.¶
To make it easier to compare HMAC and KMAC, basic APIs for each are defined below. The symbols used in these APIs broadly conform to those described in [SP-800-185]. KMAC and HMAC implementations used in IKEv2 and IPsec do not need to conform to these APIs exactly, they're merely used in this document for illustrative purposes.¶
For the purposes of this document, the API for HMAC is defined as:¶
HMAC(K, X) -> Z¶
Each input and output is a bit string, where:¶
K is the key. It can be of any length, including zero.¶
X is the input string. It can be of any length, including zero.¶
Z is the output string of HMAC, which is a message authentication code. The size of Z is fixed for each HMAC algorithm, and is the same size as the digest produced by the hash function used by that algorithm.¶
For the purposes of this document, the API for KMAC is defined as:¶
KMAC(K, X, L, S) -> Z¶
where:¶
K is the key. It is a bit string of any length, including zero, up to but not including 2^2040 bits.¶
X 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 IKEv2, except when extracting key material using prf+ in IKEv2, where it depends on the length of key material needed by the negotiated cipher suite.¶
S is an optional customization string. It is a bit string of any length, including zero, up to but not including 2^2040 bits.¶
Z is the output string of KMAC, which is a message authentication code. It is a bit string of length L.¶
EDNOTE: the symbols chosen above mostly match those in SP 800-15. They also match draft-ietf-lamps-cms-sha3-hash. However, RFC 7296 uses S for the prf+ input string. Would it be better use change X to S, and change S to C?¶
Per [SP-800-185], the length of the 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 IKE PRF calls, although the length of these nonces combined cannot exceed 4096 bits. Shared secrets used for authentication in IKEv2 are used as keys with PRFs negotiated by IKE, and have no upper bound on their length. Therefore, KMAC and HMAC-SHA3 implementations used with IKEv2 MUST at minimum accept K inputs 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 inputs to KMAC and HMAC-SHA3, but Table 3 and Table 4 describe the size of keys to be used with IKEv2 and IPsec, aligned to the security strength of each algorithm. Using a key smaller than the security strength of the chosen KMAC or HMAC-SHA3 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 IKE cannot always be controlled. In the case of pre-shared keys used for authentication or protection against a quantum computer, those secrets are used as the key input to a PRF negotiated by IKE. That shared secret could be arbitrarily chosen by a user rather than securely generated, or derived from a password, even though [RFC7296] strongly discourages this practice. 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 or HMAC-SHA3. [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 IKE peer sends an undersized nonce, the message containing that nonce can be rejected in the same way as any malformed IKE message would be. Conformant KMAC and HMAC-SHA3 implementations SHOULD reject keys that do not meet the security strength of the corresponding algorithm.¶
The input string X can be a variety of lengths in practice, but will always be a multiple of eight. 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 S is fixed to a specific value depending on the context in which KMAC is used. Future specifications may define additional customization strings, but the set of valid strings used by KMAC in IKEv2 and IPsec will always be fixed-length context-dependent strings specified in IETF RFCs rather than dynamically created, e.g. via random data.¶
Since the length of the input string X for both HMAC-SHA3 and KMAC varies, and both HMAC-SHA3 and KMAC operate on fixed-size input blocks, padding is required to use HMAC-SHA3 and KMAC in IKEv2 and IPsec. The padding scheme for the SHA-3 cryptographic hash functions is specified in [FIPS-202], and the padding scheme for KMAC is specified in [SP-800-185]. An HMAC-SHA3 or KMAC implementation conformant to those documents is sufficient; no additional padding is required to use these algorithms in IKEv2 or IPsec.¶
When KMAC or HMAC-SHA3 are used as the PRF for an IKE SA, the size of the key input K is variable. HMAC and KMAC both permit use of variable key sizes, but handle these keys differently.¶
When HMAC is invoked, unless K is the same as the input block size for the cryptographic hash function being used, K is padded or compressed to match that block size. The "rate" of a sponge function is the number of input bits processed or output bits generated per invocation of that function, and serves as the input block size for HMAC. The rates, and hence input block sizes, for each SHA-3 cryptographic hash function when used with HMAC are described in [FIPS-202] and repeated below.¶
| Algorithm Name | Rate (bytes) |
|---|---|
| SHA3-256 | 136 |
| SHA3-384 | 104 |
| SHA3-512 | 72 |
Keys that match the rate of the relevant SHA-3 cryptographic hash function are used as-is.¶
Keys that are shorter than the rate are right-padded up to the rate of the hash function using zero bits. Note that this is required for the majority of keys used with HMAC-SHA3 in IKEv2 or IPsec.¶
Keys that are longer than the rate are hashed using the relevant SHA-3 cryptographic hash function. The resulting digest is then right-padded up to the rate of the hash function using zero bits.¶
The padding described above is that required by [RFC2104]. Any HMAC implementation conformant with that RFC is suitable for use in IKEv2 and IPsec, no protocol-specific additional padding of keys is required.¶
Unlike HMAC, if the size of a KMAC key is greater than the recommended key size, the key is used in its entirety without any kind of shortening or truncation. As described in [SP-800-185], 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 KMAC-128 and KMAC-256 respectively. Any KMAC implementation conformant with [SP-800-185] is suitable for use in IKEv2 and IPsec, no protocol-specific additional padding of keys is required.¶
Table 2 describes the general properties of the SHA-3 algorithms, with the SHA-2 algorithms also listed for comparison purposes. The maximum security strengths listed are taken from [SP-800-57]. Note that these are maximum security strengths. Using keys that are shorter than the maximum security strength will constrain the maximum security strength of the chosen algorithm to be no higher than the length of that key. Keys that contain insufficient entropy to meet the 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 |
| HMAC-SHA3-256 | 256 | >=256 |
| HMAC-SHA3-384 | 384 | >=256 |
| HMAC-SHA3-512 | 512 | >=256 |
| KMAC128 | Variable | 128 |
| KMAC256 | Variable | >=256 |
Table 3 describes the parameters of the SHA-3 algorithms as used as a PRF in IKEv2, with the SHA-2 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 |
| HMAC-SHA3-256 | PRF_HMAC_SHA3_256 | 256 | 256 |
| HMAC-SHA3-384 | PRF_HMAC_SHA3_384 | 384 | 384 |
| HMAC-SHA3-512 | PRF_HMAC_SHA3_512 | 512 | 512 |
| KMAC128 | PRF_KMAC_128 | 128 | 256, or length of output required for prf+ |
| KMAC256 | PRF_KMAC_256 | 256 | 512, or length of output required for prf+ |
Like their SHA-2 equivalents, the output of HMAC-SHA3 algorithms used in IKEv2 is used in its entirety without truncation. The security strength of these algorithms is the same as the maximum security strength for that algorithm, unless the entropy in the supplied key is insufficient to meet that strength.¶
When key material is extracted from IKEv2's prf+ KDF for use with SHA-3 in IKEv2, the length of keys extracted MUST conform to the preferred key sizes listed in Table 3.¶
EDNOTE: The KMAC output lengths have been aligned with HMAC, but if we're not depending on collision resistance, it seems like they could be reduced to 128/256 bits respectively? That would also mean that the PRF output would be suitable for use as a PRF key without requiring further modification, like HMAC.¶
Table 4 describes the parameters of the SHA-3 algorithms as used for authentication and integrity protection in IKEv2 and IPsec, with the SHA-2 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 |
| HMAC-SHA3-256 | AUTH_HMAC_SHA3_256_128 | 256 | 128 |
| HMAC-SHA3-384 | AUTH_HMAC_SHA3_384_192 | 384 | 192 |
| HMAC-SHA3-512 | AUTH_HMAC_SHA3_512_256 | 512 | 256 |
| KMAC128 | AUTH_KMAC_128 | 128 | 128 |
| KMAC256 | AUTH_KMAC_256 | 256 | 256 |
When used for authentication and integrity protection, HMAC-SHA3 message authentication codes are truncated, and 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 SHA-3 for authentication and integrity protection in IKEv2 or IPsec, the length of keys extracted MUST conform to the key sizes listed in Table 4.¶
IKEv2 Security Associations (SAs) make use of a PRF for authentication purposes, and as a part of the prf+ Key Derivation Function (KDF). HMAC-SHA3 and KMAC can both act as the PRF for an IKE SA, but KMAC is treated slightly differently to other PRFs as it is capable of producing different output lengths depending on the context in which it's used.¶
For both HMAC-SHA3 and KMAC, key K is either a fixed length key (such as SK_d) that is the same size as the output produced by that SHA-3 algorithm, or the length of K is dependent on other factors. For example, when used with the IKE SA keys SK_d, SK_pi or SK_pr, these keys are always 256 bits in length when the IKE SA's PRF is HMAC-SHA3-256. 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 HMAC key K, the length of the key K depends on implementation-specific details, user configuration options, etc.¶
When used as a PRF in IKEv2, the full output of each HMAC-SHA3 algorithm is used, rather than the truncated variants described below for integrity protection in IPsec. Since the output length of HMAC is fixed, prf+ is used as described in [RFC7296].¶
A notable difference to HMAC is that when KMAC is used as the PRF for an IKE SA, its "requested output length" parameter L and "customization string" parameter S are populated differently depending on whether KMAC is being used as a part of the prf+ KDF or not. The context string S is also populated differently depending on whether KMAC is used in prf+ or not. This process is described in more detail below.¶
EDNOTE: The customization string differences aren't strictly necessary and may make implementation a bit harder, but they seem valuable in that we're placing a clear divide between two places with different rules on how KMAC is used.¶
When used in IKEv2, KMAC's output length L is 128 for KMAC-128, and 256 for KMAC-256. That is, the output length is the same size as the security strength and preferred key size of the given KMAC algorithm. The only exception to this is when KMAC is used in prf+, as described below.¶
When KMAC is used outside the context of prf+, the customization string S is set to the ASCII character string "ikev2 prf", without null termination.¶
When KMAC is used in prf+, L is set to the length of the keying material required. That is, prf (K, S | 0x01) is the only step of the prf+ function that is ever required, as KMAC can produce a pseudorandom stream without the need to iteratively call prf as described in [RFC7296].¶
EDNOTE: the intent here is to keep prf+ (sort of) the same for KMAC, it's just that only one iteration is ever needed. Would this actually be more annoying from an implementer's point of view than just replacing prf+, though? The extra 0x01 is easy to forget if you simply redirect prf+ calls to KMAC instead.¶
When KMAC is used in prf+, the customization string S is set to the ASCII character string "ikev2 kdf", without null termination.¶
IPsec SAs can make use of an integrity protection algorithm to provide data origin authentication and integrity protection services. KMAC and HMAC-SHA3 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 and HMAC-SHA3 MUST NOT be negotiated in IKEv2 in conjunction with an AEAD cipher.¶
HMAC-SHA3 and 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¶
EDNOTE: You really should use ENCR-NULL over AH here. RFC 8221 recommends use of ENCR_NULL over AH - would it be worth reiterating that here?¶
When HMAC-SHA3 is used for authentication and integrity protection in ESP, AH, and IKEv2, the HMAC key K is 256 bits in length for HMAC-SHA3-256, 384 bits in length for HMAC-SHA3-384, and 512 bits in length for HMAC-SHA3-512.¶
The output string Z of HMAC is truncated such that the output length is halved. As described in [RFC2104], the left-most bits are retained, and the right-most bits are discarded. The output string is truncated for the same reasons described in [RFC4868] for HMAC-SHA2. Truncating the output of HMAC reduces the size expansion created by integrity protection offered by ESP and AH, and reduces the size of IKE messages. The output length is halved to match the birthday attack bound for HMAC.¶
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.¶
When used with ESP or AH, the "customization string" parameter S is set to the ASCII character string "ipsec", without null termination. When used with IKEv2 for authentication and integrity protection, the "customization string" parameter S is set to the ASCII character string "ikev2 auth", without null termination.¶
EDNOTE: Again, the customization string differences probably aren't strictly necessary, but placing IPsec and IKEv2 integrity/prf/prf+ into different domains seems like a good thing to do.¶
SHAKE and the SHA-3 cryptographic hash functions can generate digests for use with signature algorithms. For instance, [RFC8692] specifies algorithm identifiers for using RSASSA-PSS and ECDSA with SHAKE, and NIST have assigned OIDs for using RSA PKCS #1 v1.5 signatures with SHA-3 [NISTOIDS].¶
[RFC7427] specifies the "Digital Signature" (14) authentication method, that 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 SHA-3 with signatures in IKEv2, so if a peer uses SHA-3 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 IKE peer to announce the hash functions it supports for use with signatures. This specification defines values for announcing support for SHA-3 algorithms in the SIGNATURE_HASH_ALGORITHMS notification. When an IKEv2 implementation supports SHA-3 in this context, and local policy permits use of SHA-3 to generate or verify signatures, it MUST include the corresponding values in its SIGNATURE_HASH_ALGORITHMS notification.¶
SHA-3 and SHA-2 are both believed to be secure at time of writing. Views on the security of cryptographic algorithms evolves over time, so implementers should pay attention to IETF RFCs reporting on recommendations for 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 also attack hash functions, including SHA-3 and SHA-2, using Grover's algorithm. However, the impact of Grover's algorithm is less dramatic than the impact of Shor's Algorithm. The worst-case impact of Grover's algorithm is a reduction in security strength by a factor of two; using algorithms with a greater maximum security strength is sufficient to mitigate this. Grover's algorithm is likely to be difficult to parallelise, so the security reduction for SHA-3 and SHA-2 created by Grover's algorithm may be smaller in practice. See [GROVER] for a discussion on the practical cost of using Grover's algorithm to recover AES keys.¶
EDNOTE: More references would be helpful here, especially if they relate to hash functions specifically.¶
The security properties offered by both HMAC-SHA3 and KMAC depend on limiting access to the keys used with those algorithms. Since both algorithms depend 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 these algorithms. 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 HMAC or KMAC.¶
When IKEv2 is used to create IPsec SAs, the keys for HMAC-SHA3 and 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 IKE for authentication and/or protection against quantum computers. If the negotiated key exchange algorithm offers few 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 that offers more bits of security than the negotiated PRF does not improve the security offered by that PRF. Similarly, using an encryption algorithm whose security level does not align to the negotiated PRF will undermine the security offered by either the encryption algorithm or the PRF. As such, it is important to ensure that IKE peers configure algorithm policies such that every algorithm negotiated always meets an acceptable minimum security level. Where static keys are used with HMAC-SHA3 and KMAC, these MUST contain at least as much entropy as the security level of the chosen algorithm, and SHOULD be generated using a random number generator capable suitable for use with cryptography.¶
For negotiating use of HMAC-SHA3 and KMAC as PRFs for IKEv2, IANA is requested to assign five Transform IDs in the "Transform Type 2 - Pseudorandom Function Transform IDs" registry:¶
| Number | Name | Status | Reference |
|---|---|---|---|
| TBD | PRF_HMAC_SHA3_256 | [This draft] | |
| TBD | PRF_HMAC_SHA3_384 | [This draft] | |
| TBD | PRF_HMAC_SHA3_512 | [This draft] | |
| TBD | PRF_KMAC_128 | [This draft] | |
| TBD | PRF_KMAC_256 | [This draft] |
For negotiating use of HMAC-SHA3 and KMAC for integrity protection in IKEv2 and IPsec protocols, IANA is requested to assign five Transform IDs in the "Transform Type 3 - Integrity Algorithm Transform IDs" registry:¶
| Number | Name | Status | Reference |
|---|---|---|---|
| TBD | AUTH_HMAC_SHA3_256_128 | [This draft] | |
| TBD | AUTH_HMAC_SHA3_384_192 | [This draft] | |
| TBD | AUTH_HMAC_SHA3_512_256 | [This draft] | |
| TBD | AUTH_KMAC_128 | [This draft] | |
| TBD | AUTH_KMAC_256 | [This draft] |
For indicating support for the SHA-3 cryptographic hash functions and SHAKE XOFs in conjunction with a signature algorithm, IANA is requested to assign six Transform IDs in the "IKEv2 Hash Algorithms" registry:¶
| Value | Hash Algorithm | Reference |
|---|---|---|
| TBD | SHA3_224 | [This draft] |
| TBD | SHA3_256 | [This draft] |
| TBD | SHA3_384 | [This draft] |
| TBD | SHA3_512 | [This draft] |
| TBD | SHAKE_128 | [This draft] |
| TBD | SHAKE_256 | [This draft] |
The following test cases include inputs and outputs for scenarios where HMAC-SHA3 and KMAC are used in IKEv2 and IPsec.¶
A key, input, and output are always supplied, these correspond to the K, X and Z parameters described in Section 4. For KMAC, a customization string input is also supplied, which corresponds to the L parameter. Note that in each context, the customization string is fixed.¶
All inputs and outputs are encoded in hexadecimal. KMAC Customization strings also have an ASCII character string representation. 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 metada, and are not ever supplied to the relevant algorithm.¶
These test cases correspond to use of HMAC-SHA3 or KMAC as the PRF transform for an IKEv2 SA.¶
~~ Test Case HMAC-SHA3-256-PRF-1 ~~ Description: Preferred key size Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Output (hex): 10ae5299b538c806177afcfbd50a78cca7869b183d0f405af0fb4ffbec65ffc9 ~~ Test Case HMAC-SHA3-256-PRF-2 ~~ Description: Smaller key size Key (hex): 000102030405060708090a0b0c0d0e0f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Output (hex): 30bf304d335b068b999b3c8053583921f98bd603661ce68d9bb481702656f3a8 ~~ Test Case HMAC-SHA3-256-PRF-3 ~~ Description: Larger key size Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Output (hex): 9cc1974f3329ec6ae380e16b5df6068e2c954652a06e359aada1def787d9e298¶
~~ Test Case HMAC-SHA3-384-PRF-1 ~~ Description: Preferred key size Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Output (hex): c412ca3549716fafa30b7cc1f8333ec80875f7f42b1bd02e2467b01baf24bab5 37e030688caebcf14c2db2523e16bfc2 ~~ Test Case HMAC-SHA3-384-PRF-2 ~~ Description: Smaller key size Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Output (hex): beab6eed7c624690e25b84b66616192178fa06607e6971c4068d25df5944b6bc 21d374875260c9dedbc36914763da390 ~~ Test Case HMAC-SHA3-384-PRF-3 ~~ Description: Larger key size Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Output (hex): 39719a89ebd05084f39e67c2ab349b8283198b30da01b30ea532bf6c3beee012 c148a0feff45ff4a243f664311beecca¶
~~ Test Case HMAC-SHA3-512-PRF-1 ~~ Description: Preferred key size Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Output (hex): dd3900c31efb5ca7f8cc457a2343c09177c76c81f0650e026d72e50878d70b70 c2b3330e0d72c2dccccad98bf39d8a2283d9c6c3ec05edee08d9b6702745b103 ~~ Test Case HMAC-SHA3-512-PRF-2 ~~ Description: Smaller key size Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Output (hex): d31020b9deed7f237dacb5963c21d6a2fbd1f34497ad0a2ddef2aa0339e8f238 d8b5d56a53be7ac1612352c98a3905851bcb2c3a681ba273e15deff307710fe1 ~~ Test Case HMAC-SHA3-512-PRF-3 ~~ Description: Larger key size Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f 404142434445464748494a4b4c4d4e4f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Output (hex): 5f08ded1ad2757d9ebf55a3b05276edeb1d25db8a280c01f3e631eaa2c9d15b9 99f0c0aa60178bcd26df3d9da9b65a823564a7c34e096140a769e15bc47d5c30¶
~~ Test Case KMAC128-PRF-1 ~~ Description: Preferred key size Key (hex): 000102030405060708090a0b0c0d0e0f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Customization String (string): "ikev2 prf" Customization String (hex): 696b65763220707266 Output (hex): 942d56a4597c0d104497dc1c62be940a70198b32bfde8e2a5f57f55ec3fe5cef ~~ Test Case KMAC128-PRF-2 ~~ Description: Smaller key size Key (hex): 0001020304050607 Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Customization String (string): "ikev2 prf" Customization String (hex): 696b65763220707266 Output (hex): b050dd45ec09370cd2fe4b7c2a009618c5a426e81a4f11f6c538cf17027dbee3 ~~ Test Case KMAC128-PRF-3 ~~ Description: Larger key size Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Customization String (string): "ikev2 prf" Customization String (hex): 696b65763220707266 Output (hex): 3a8d2a5ead5cd4db448b76a241b078fb444e1faf36eef8e195e275778a169b5f¶
~~ Test Case KMAC256-PRF-1 ~~ Description: Preferred key size Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Customization String (string): "ikev2 prf" Customization String (hex): 696b65763220707266 Output (hex): 3a8d2a5ead5cd4db448b76a241b078fb444e1faf36eef8e195e275778a169b5f ~~ Test Case KMAC256-PRF-2 ~~ Description: Smaller key size Key (hex): 000102030405060708090a0b0c0d0e0f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Customization String (string): "ikev2 prf" Customization String (hex): 696b65763220707266 Output (hex): 942d56a4597c0d104497dc1c62be940a70198b32bfde8e2a5f57f55ec3fe5cef ~~ Test Case KMAC256-PRF-3 ~~ Description: Larger key size Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Customization String (string): "ikev2 prf" Customization String (hex): 696b65763220707266 Output (hex): beff64f08357a691290c7f67f6344a485941edd6d923bc554f8e4655702b090f¶
These test cases correspond to use of HMAC-SHA3 or KMAC with IKEv2's prf+ function.¶
~~ Test Case HMAC-SHA3-256-KDF-1 ~~ Description: IKEv2 KDF request single PRF output Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Number of output bits requested (integer): 256 Output (hex): 6aefdb97d1645cafec3590cd8a35366e67a7887b153c042b4eb609cc60391f97 ~~ Test Case HMAC-SHA3-256-KDF-2 ~~ Description: IKEv2 KDF request multiple PRF output Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Number of output bits requested (integer): 512 Output (hex): 6aefdb97d1645cafec3590cd8a35366e67a7887b153c042b4eb609cc60391f97 d43335b5856ed1f2dd67c2c35853069ce7ae354df11b90b7dfea743890cf281a ~~ Test Case HMAC-SHA3-256-KDF-3 ~~ Description: IKE SA key material ENCR=AES-128-GCM PRF=HMAC-SHA3-256 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): 553bc362cfd6286855545b1222ee5d6e2946930c584951d2aa047f14318de527 9c58cf057348463823a445a82106b16de3e9c9db06602ede34f1bbe4910e042d ddddc5cc48a13ce8716b99d6522e03ee765f0549f1985f7e8c96e91246295b0b 0a9bdb6039e47f880d4d690ff6cd95376353f03635812f93ab417b8388d94f57 b9b731b554b0a269 ~~ Test Case HMAC-SHA3-256-KDF-4 ~~ Description: IKE SA key material ENCR=AES-256-CBC INTEG=HMAC-SHA3-256 PRF=HMAC-SHA3-256 SK_d = 256 bits SK_a[i|r] = 256*2 bits SK_e[i|r] = 256*2 bits SK_p[i|r] = 256*2 bits Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 dfdedddcdbdad9d8d7d6d5d4d3d2d1d0 Number of output bits requested (integer): 1792 Output (hex): 553bc362cfd6286855545b1222ee5d6e2946930c584951d2aa047f14318de527 9c58cf057348463823a445a82106b16de3e9c9db06602ede34f1bbe4910e042d ddddc5cc48a13ce8716b99d6522e03ee765f0549f1985f7e8c96e91246295b0b 0a9bdb6039e47f880d4d690ff6cd95376353f03635812f93ab417b8388d94f57 b9b731b554b0a269264abec3d7cbb3f43cb94c2b0bcaa9133358633ddbd4fe72 517b1de586599c5451b596953fc71ace7c4f6431f980327e21b02cb3298ec154 b526a14e5e6461fea32829d9de1c40a8c9d919e0b8e0d2132d663507d764ce32 ~~ Test Case HMAC-SHA3-256-KDF-5 ~~ Description: ESP key material ENCR=AES-256-CBC INTEG=HMAC-SHA3-256 KEYMAT=(256*2) + (256*2) bits Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Number of output bits requested (integer): 1024 Output (hex): 6aefdb97d1645cafec3590cd8a35366e67a7887b153c042b4eb609cc60391f97 d43335b5856ed1f2dd67c2c35853069ce7ae354df11b90b7dfea743890cf281a 010bbf134b8f2d7d12c8eafbb0d4be0f8d0971357ea4e179b50e0d4316b56e80 51da1fd2be02168550150d40e6a36a3fbacdf9d639c1b00cdc58cb9af11dab7c¶
~~ Test Case HMAC-SHA3-384-KDF-1 ~~ Description: IKEv2 KDF request single PRF output Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Number of output bits requested (integer): 384 Output (hex): 2c41a30906e2809b86e9cd75fdf055a46534664e49b0979ff067508d522f441f cf47d15477119ba2e9b9e85399bff5d4 ~~ Test Case HMAC-SHA3-384-KDF-2 ~~ Description: IKEv2 KDF request multiple PRF output Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Number of output bits requested (integer): 768 Output (hex): 2c41a30906e2809b86e9cd75fdf055a46534664e49b0979ff067508d522f441f cf47d15477119ba2e9b9e85399bff5d4a1d827ea5b485abf569b2e83585e720e b7d7c50c4c90eadd1d9aeeaaf6921eae1f64d40a4efa56ef2cb02c1fe5d6b440 ~~ Test Case HMAC-SHA3-384-KDF-3 ~~ Description: IKE SA key material ENCR=AES-128-GCM PRF=HMAC-SHA3-384 SK_d = 384 bits SK_a[i|r] = nil SK_e[i|r] = 160*2 bits SK_p[i|r] = 384*2 bits Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 dfdedddcdbdad9d8d7d6d5d4d3d2d1d0 Number of output bits requested (integer): 1472 Output (hex): 73c5fc441670ce4766b1cbe9e17e1bd18e50903efcd49359c46cbb21da80c833 fe1a29789e0995c9fa58cd0759d3fb1765119115c72dad463a1d8b736b94dbd4 c1b6b31c40972eee5752ec22b12d4b42e8102358c7f7025313654ff909b4b87d 7357dfbbfaf2e2baf2d89e6575a9140484e8ef3681986bfe255a3bf5a1233a24 145336b7e192c9316967d809b14b1bc5986765010aa945c727ec4e3d63ec88dd 116994b90ffb2afd60e4c22ee85705aa1b57f50f878c21f3 ~~ Test Case HMAC-SHA3-384-KDF-4 ~~ Description: IKE SA key material ENCR=AES-256-CBC INTEG=HMAC-SHA3-384 PRF=HMAC-SHA3-384 SK_d = 384 bits SK_a[i|r] = 384*2 bits SK_e[i|r] = 256*2 bits SK_p[i|r] = 384*2 bits Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 dfdedddcdbdad9d8d7d6d5d4d3d2d1d0 Number of output bits requested (integer): 2432 Output (hex): 73c5fc441670ce4766b1cbe9e17e1bd18e50903efcd49359c46cbb21da80c833 fe1a29789e0995c9fa58cd0759d3fb1765119115c72dad463a1d8b736b94dbd4 c1b6b31c40972eee5752ec22b12d4b42e8102358c7f7025313654ff909b4b87d 7357dfbbfaf2e2baf2d89e6575a9140484e8ef3681986bfe255a3bf5a1233a24 145336b7e192c9316967d809b14b1bc5986765010aa945c727ec4e3d63ec88dd 116994b90ffb2afd60e4c22ee85705aa1b57f50f878c21f397ecf391e856e338 6969f3f0e74d09534e9bdbbc752eaad53b2c4aba329ef06036d55ff0c9885cb9 ac6e9ff4057c9f4f591103ad4cb04894d1193a9ad434407c54b285acc3576298 7ce8a0aca60afea4f9879f62085be44e638543ee66c41c8d5db02f2ae08b4d0b b3b906c5c568e718921a205a02a8356f ~~ Test Case HMAC-SHA3-384-KDF-5 ~~ Description: ESP key material ENCR=AES-256-CBC INTEG=HMAC-SHA3-384 KEYMAT=(256*2) + (384*2) bits Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Number of output bits requested (integer): 1280 Output (hex): 2c41a30906e2809b86e9cd75fdf055a46534664e49b0979ff067508d522f441f cf47d15477119ba2e9b9e85399bff5d4a1d827ea5b485abf569b2e83585e720e b7d7c50c4c90eadd1d9aeeaaf6921eae1f64d40a4efa56ef2cb02c1fe5d6b440 a2970d7be7d4b61a8b1fdde0850eac6848cfd46a28e3206465fce4cd030a7a8a 8398671e9b9b41dfd7eee81e37f4303f8055cb3ef2dae1b3723a49eda4c83077¶
~~ Test Case HMAC-SHA3-512-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): 399c608d085a547c072ace5dfd9881791178026f318e695b7c6b3dec968e24be 3a55003dd481ddf021d762beb3736747f1af27abb432e489f545400968b2150a ~~ Test Case HMAC-SHA3-512-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): 399c608d085a547c072ace5dfd9881791178026f318e695b7c6b3dec968e24be 3a55003dd481ddf021d762beb3736747f1af27abb432e489f545400968b2150a 42af3f427186715cab4c97d47e3f7c25aa701030b51d74744c262aa2675d5d1f 27e35f99d4eeef1d07d19c9656c804b396b7f2761ea65a2653b4711340e2986f ~~ Test Case HMAC-SHA3-512-KDF-3 ~~ Description: IKE SA key material ENCR=AES-128-GCM PRF=HMAC-SHA3-512 SK_d = 512 bits SK_a[i|r] = nil SK_e[i|r] = 160*2 bits SK_p[i|r] = 512*2 bits Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 dfdedddcdbdad9d8d7d6d5d4d3d2d1d0 Number of output bits requested (integer): 1856 Output (hex): 9c7d3c211a5ab9c7ac70c688aa44df6d213dcdc339a667d68766b9bf77591879 a60247a979b02edcdc7bd3a3584a4faf8ecd7d02a91671d8a51523e4d9425a5c 11e2cd1bfa8bf9d8a81bd63d4b16f897f768d7065ae2fa0392f30815c0010d9a 229953a8d7878d4ff5ddafb41303652d30a2e9eaa3578f1b735db7043a6ac1c8 cdeccaf15970c7c7279319944ccaf4607fab77280c982e653adf6bad77298877 7b7602e022a51a7358b7827059879b37bc8d86f1dc6f915aa1bfd0241bc5d2fe 2cacd8f8705a1a247a2b476f75d5c31753863140f7a48f13c7d935c6e21f5f49 b95f791cf7a4c2d5 ~~ Test Case HMAC-SHA3-512-KDF-4 ~~ Description: IKE SA key material ENCR=AES-256-CBC INTEG=HMAC-SHA3-512 PRF=HMAC-SHA3-512 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 dfdedddcdbdad9d8d7d6d5d4d3d2d1d0 Number of output bits requested (integer): 3072 Output (hex): 9c7d3c211a5ab9c7ac70c688aa44df6d213dcdc339a667d68766b9bf77591879 a60247a979b02edcdc7bd3a3584a4faf8ecd7d02a91671d8a51523e4d9425a5c 11e2cd1bfa8bf9d8a81bd63d4b16f897f768d7065ae2fa0392f30815c0010d9a 229953a8d7878d4ff5ddafb41303652d30a2e9eaa3578f1b735db7043a6ac1c8 cdeccaf15970c7c7279319944ccaf4607fab77280c982e653adf6bad77298877 7b7602e022a51a7358b7827059879b37bc8d86f1dc6f915aa1bfd0241bc5d2fe 2cacd8f8705a1a247a2b476f75d5c31753863140f7a48f13c7d935c6e21f5f49 b95f791cf7a4c2d55f65eac34b24d6b7612f2c09f00e02a6dd99d1d5caf2632c 2a4f3d83570837cb9c31a7c4440950ca5afbc17f6f1b9123fb02da95ca37540c 6ea9ecdfe1f6662ead42a2d1f14dbe13c91e5d6dfd697e729eee26f86976e0b2 f2e844beb7134bca666fb9207a01e90fff02336f1656b57b86d0ab84545392a9 82cc5b3b3f52b2ddb28de585fa8c7cfafd18d8f66ac4394c8ec7db5364c494be ~~ Test Case HMAC-SHA3-512-KDF-5 ~~ Description: ESP key material ENCR=AES-256-CBC INTEG=HMAC-SHA3-512 KEYMAT=(256*2) + (512*2) bits Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Number of output bits requested (integer): 1536 Output (hex): 399c608d085a547c072ace5dfd9881791178026f318e695b7c6b3dec968e24be 3a55003dd481ddf021d762beb3736747f1af27abb432e489f545400968b2150a 42af3f427186715cab4c97d47e3f7c25aa701030b51d74744c262aa2675d5d1f 27e35f99d4eeef1d07d19c9656c804b396b7f2761ea65a2653b4711340e2986f b500b7744b1c2cf5cfffef372b6c535c21897ee40b44589407936390ef44122d 7ed64063b04d9c0105b84220c9038379ffc861820e4c3ab9972a20ce31d6c468¶
~~ Test Case KMAC128-KDF-1 ~~ Description: IKEv2 KDF request single PRF output Key (hex): 000102030405060708090a0b0c0d0e0f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Number of output bits requested (integer): 256 Customization String (string): "ikev2 kdf" Customization String (hex): 696b657632206b6466 Output (hex): 364f2231443775dcdd1879fd4aa54f1adadaf0ac58e90285c5d95d3e2bbbc216 ~~ Test Case KMAC128-KDF-2 ~~ Description: IKEv2 KDF request multiple PRF output Key (hex): 000102030405060708090a0b0c0d0e0f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Number of output bits requested (integer): 512 Customization String (string): "ikev2 kdf" Customization String (hex): 696b657632206b6466 Output (hex): 4603b8e26567ccbb4e0498bdbc96ccad685849371efc9c3f34ee681b88bd2dc0 95e2c5745769f73873e4787228bde59d73567fc81a865f2d14208355fbd0e7b1 ~~ Test Case KMAC128-KDF-3 ~~ Description: IKE SA key material ENCR=AES-128-GCM PRF=KMAC128 SK_d = 128 bits SK_a[i|r] = nil SK_e[i|r] = 160*2 bits SK_p[i|r] = 128*2 bits Key (hex): 000102030405060708090a0b0c0d0e0f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 dfdedddcdbdad9d8d7d6d5d4d3d2d1d0 Number of output bits requested (integer): 704 Customization String (string): "ikev2 kdf" Customization String (hex): 696b657632206b6466 Output (hex): cd4f184a2868ee2b4f44d28a1e543a72489767f621c23f6645e477a7668c7d1d 9a7c143b5258d4258ded00fe78ea280033f4f52832876a61747358b759f135d3 f2b8908571defe8d0cbe497a8f7daf09710d1eac6ae6cd33 ~~ Test Case KMAC128-KDF-4 ~~ Description: IKE SA key material ENCR=AES-256-CBC INTEG=KMAC128 PRF=KMAC128 SK_d = 128 bits SK_a[i|r] = 128*2 bits SK_e[i|r] = 256*2 bits SK_p[i|r] = 128*2 bits Key (hex): 000102030405060708090a0b0c0d0e0f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 dfdedddcdbdad9d8d7d6d5d4d3d2d1d0 Number of output bits requested (integer): 1152 Customization String (string): "ikev2 kdf" Customization String (hex): 696b657632206b6466 Output (hex): 5346031edd514606a1faf3269571e9d0cfa632e9640f09499457276a2ec39c25 d042401ac90c6f53ee93a50913a4664f5c1e71469739d729a1f57d2f78832cb7 695a471756b1c27500267047985007c901575e6f43bd22c452d7b92ed5cb0328 d4a9ecccba37c28d5e1859291d256dd40ff346583532c75c80a13391b22815ae 7a2768d5c8b8a9f3283f11e7b7c1c627 ~~ Test Case KMAC128-KDF-5 ~~ Description: ESP key material ENCR=AES-256-CBC INTEG=KMAC128 KEYMAT=(256*2) + (128*2) bits Key (hex): 000102030405060708090a0b0c0d0e0f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Number of output bits requested (integer): 768 Customization String (string): "ikev2 kdf" Customization String (hex): 696b657632206b6466 Output (hex): 1ad3efce20c5ea7dc9ea91ab19aa05b6bb29cb81c3eeb9db4eab962f43772306 c33b221a3e244e2537d591631daf5c2ce3ae0e58ed8e5580cedbe7538d1727d1 d49a7b8a93f3d4c698e608e0b0534e51c871686308b1085031ae3765a29abb3c¶
~~ Test Case KMAC256-KDF-1 ~~ Description: IKEv2 KDF request single PRF output Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Number of output bits requested (integer): 512 Customization String (string): "ikev2 kdf" Customization String (hex): 696b657632206b6466 Output (hex): 918fcc9584938feadca44878aff97466df6de641863bfa2ff92e8d4f28109195 316a4786d33a7a3e7de2cf483d9750f0d5f1f2551b59992a621d44850fb4b730 ~~ Test Case KMAC256-KDF-2 ~~ Description: IKEv2 KDF request multiple PRF output Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Number of output bits requested (integer): 1024 Customization String (string): "ikev2 kdf" Customization String (hex): 696b657632206b6466 Output (hex): e5414718d74f02f7032c926d777e7553d5c74f073d622317b341ec2e8d7eeb13 77bb38ae552900eb5b075dbf7185cddbfe216a16e2692d313598dca7c6df8453 73eaa2d9623a07e6333706bd4655180b4b750af8bcdefa053a5601d25f808e41 ad07734f1b65201ae9e639893ea76ec8bb8b004b43ad48a9687cddda3ecf665c ~~ Test Case KMAC256-KDF-3 ~~ Description: IKE SA key material ENCR=AES-128-GCM PRF=KMAC256 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 Customization String (string): "ikev2 kdf" Customization String (hex): 696b657632206b6466 Output (hex): e22f0bf22b2a3f595c4af083b9ae7abb1102c22b10da628a569a005d71cb0f5c 69ddb319c9365c25e1f8ff9ec5b3a71f7cf96490ed7b835feea6c6331d25c0cc 94f562316504d02a16339a4b2bcbf57c4729ede14bfa334ea9bf3de2208c1176 0bad9e5e4b5623edd9a221fb8d1fba02b8bd64b63422c9e0bb2e2a6b0434c88b fb63a52f8eee6436 ~~ Test Case KMAC256-KDF-4 ~~ Description: IKE SA key material ENCR=AES-256-CBC INTEG=KMAC256 PRF=KMAC256 SK_d = 256 bits SK_a[i|r] = 256*2 bits SK_e[i|r] = 256*2 bits SK_p[i|r] = 256*2 bits Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 dfdedddcdbdad9d8d7d6d5d4d3d2d1d0 Number of output bits requested (integer): 1792 Customization String (string): "ikev2 kdf" Customization String (hex): 696b657632206b6466 Output (hex): 7cecf177da25eca206b2bd9b1d17710f08d6e09d8361f053116be41aaa583bd2 7ab4bb9ca8d5019787fac7227ed8ce01fa250a9ab4b638f98a4365dd84004b11 2c4810eeeb36d8493922f1fe8b75609d9f6d4c08aa1f16039b164600d8748913 bd0736b742eef9d7038df42ea748798b58e4d716d669a677115926c490ea46fa 948f2f0eee211e2200d401fffad14f05c82aa388b701ad83b576053c22a3f1f8 2966af987f37dae321ccc5867e50f19d9a7a07946e5ddd58ecf9668bbbbfa30c 78568cc0b5de273a8773ca15a2cc299da3331437850dd9dc5f126e76cbd0fcd7 ~~ Test Case KMAC256-KDF-5 ~~ Description: ESP key material ENCR=AES-256-CBC INTEG=KMAC256 KEYMAT=(256*2) + (256*2) bits Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Number of output bits requested (integer): 1024 Customization String (string): "ikev2 kdf" Customization String (hex): 696b657632206b6466 Output (hex): e5414718d74f02f7032c926d777e7553d5c74f073d622317b341ec2e8d7eeb13 77bb38ae552900eb5b075dbf7185cddbfe216a16e2692d313598dca7c6df8453 73eaa2d9623a07e6333706bd4655180b4b750af8bcdefa053a5601d25f808e41 ad07734f1b65201ae9e639893ea76ec8bb8b004b43ad48a9687cddda3ecf665c¶
These test cases correspond to use of HMAC-SHA3 as the integrity protection transform for an IKEv2 SA or an IPsec SA.¶
~~ Test Case HMAC-SHA3-256-IKEV2+IPSEC-INTEG-1 ~~ Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Output (hex): 10ae5299b538c806177afcfbd50a78cc¶
~~ Test Case HMAC-SHA3-384-IKEV2+IPSEC-INTEG-1 ~~ Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Output (hex): c412ca3549716fafa30b7cc1f8333ec80875f7f42b1bd02e¶
~~ Test Case HMAC-SHA3-512-IKEV2+IPSEC-INTEG-1 ~~ Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Output (hex): dd3900c31efb5ca7f8cc457a2343c09177c76c81f0650e026d72e50878d70b70¶
These test cases correspond to use of KMAC as the integrity protection transform for an IKEv2 SA. Note that, since different customization strings are used for integrity protection in IKEv2 and IPsec, different outputs are produced, so two sets of test vectors are supplied.¶
~~ Test Case KMAC128-IKEV2-INTEG-1 ~~ Key (hex): 000102030405060708090a0b0c0d0e0f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Customization String (string): "ikev2 auth" Customization String (hex): 696b6576322061757468 Output (hex): 535c4f72ea7967ddae5dc95732625801¶
~~ Test Case KMAC256-IKEV2-INTEG-1 ~~ Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Customization String (string): "ikev2 auth" Customization String (hex): 696b6576322061757468 Output (hex): 06215b3864e0e977bd45267a8e70c9ce¶
These test cases correspond to use of KMAC as the integrity protection transform for an IPsec SA. Note that, since different customization strings are used for integrity protection in IKEv2 and IPsec, different outputs are produced, so two sets of test vectors are supplied.¶
~~ Test Case KMAC128-IPSEC-INTEG-1 ~~ Key (hex): 000102030405060708090a0b0c0d0e0f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Customization String (string): "ipsec auth" Customization String (hex): 69707365632061757468 Output (hex): d78075faf484002a8bca0272dcc169ac¶
~~ Test Case KMAC256-IPSEC-INTEG-1 ~~ Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Input (hex): fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0efeeedecebeae9e8e7e6e5e4e3e2e1e0 Customization String (string): "ipsec auth" Customization String (hex): 69707365632061757468 Output (hex): 6baa9313bbd91f81876301d2a4b9af34¶