]> Nokia

Bangalore Karnataka India kondtir@gmail.com

University of the Bundeswehr Munich

Neubiberg 85577 Germany hannes.tschofenig@gmx.net

Cisco Systems

sfluhrer@cisco.com

Security IP Security Maintenance and Extensions HQC IKEv2 KEM Post-Quantum Cryptography This document specifies how to use Hamming Quasi-Cyclic (HQC), a code-based Key Encapsulation Mechanism (KEM), in the Internet Key Exchange Protocol Version 2 (IKEv2). HQC can be used alone or together with other key exchanges to derive IKE and Child SA keys that resist attacks by quantum computers. This document registers three Key Exchange Method identifiers.

Introduction HQC is a code-based KEM selected by NIST for standardization as a backup to ML-KEM. It relies on a different hardness assumption than ML-KEM.

• Editor's note: This document is based on the HQC specification of 2025-08-22. Before publication as an RFC, the parameter set names, key and ciphertext encodings and sizes, shared secret size, and recipient tests need to be checked against the final NIST HQC standard and updated as necessary. The normative HQC reference also needs to be updated. Remove this note before publication.

defines ML-KEM key exchange in IKEv2 . This document defines HQC key exchange in IKEv2 in the same way. It defines HQC-1, HQC-3, and HQC-5 as IKEv2 Key Exchange Methods. HQC can be used alone or in a PQ/T hybrid with a traditional (EC)DH key exchange using the multiple key exchanges of . HQC can also be combined with ML-KEM , with or without a traditional key exchange, using . Combining code-based HQC with lattice-based ML-KEM provides algorithmic diversity against advances in cryptanalysis affecting either family. For example, peers can perform an (EC)DH key exchange in IKE_SA_INIT, ML-KEM-768 as Additional Key Exchange 1, and HQC-3 as Additional Key Exchange 2, with each additional key exchange carried in its own IKE_INTERMEDIATE exchange. These combinations use the existing multiple-key-exchange negotiation and key derivation mechanisms; they do not require separate Transform IDs for each combination.

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. This document uses the KEM functions KeyGen, Encaps, and Decaps of . ek is the HQC encapsulation key, dk is the HQC decapsulation key, ct is the HQC ciphertext, and K is the shared secret. As in Section 2.2 of , "initiator" and "responder" refer to the roles in the exchange that carries the KE payload, not the original roles of the IKE SA.

HQC in IKEv2

Key Exchange Method Transform IDs HQC Key Exchange Methods

Name	Transform ID	NIST Security Category
hqc-1	TBD1	1
hqc-3	TBD2	3
hqc-5	TBD3	5

Key Exchange Payload The initiator runs KeyGen to obtain ek and dk. The Key Exchange Data of the initiator's KE payload is ek. The responder runs Encaps on ek to obtain K and ct. The Key Exchange Data of the responder's KE payload is ct. The initiator runs Decaps on ct with dk to obtain K. ek and ct are the byte strings defined in Sections 3.5 and 3.6 of . gives their lengths and the resulting KE payload lengths. The KE payload length includes the 8-octet KE payload header. HQC KE payload lengths in octets

Name	ek	Initiator KE payload	ct	Responder KE payload
hqc-1	2241	2249	4433	4441
hqc-3	4514	4522	8978	8986
hqc-5	7237	7245	14421	14429

K is 32 octets. It is used as the shared secret in the key derivation of and , in the same way as the (EC)DH shared secret.

Use in IKE Exchanges HQC KE payloads exceed the typical path MTU. IKE_SA_INIT messages cannot be fragmented using . Therefore, HQC SHOULD NOT be used in IKE_SA_INIT, unless the IKE_SA_INIT exchange itself is carried over TCP , including the mode described in Section 3.2 of . Switching to TCP only after IKE_SA_INIT, as described in Section 3.1 of , does not avoid IP fragmentation of HQC KE payloads in IKE_SA_INIT. HQC SHOULD be negotiated as an additional key exchange using . During initial IKE SA establishment, an additional HQC key exchange is carried in IKE_INTERMEDIATE . For IKE SA rekeying and Child SA creation or rekeying, an additional HQC key exchange is carried in IKE_FOLLOWUP_KE. These exchanges can be fragmented using . HQC can also be used as the first or only key exchange in CREATE_CHILD_SA as specified in . IKE fragmentation under is available only if both peers have indicated their support by exchanging IKEV2_FRAGMENTATION_SUPPORTED notifications in IKE_SA_INIT. Support for multiple key exchanges under alone does not imply support for IKE fragmentation.

Recipient Tests Version 2025-08-22 of does not define checks on a received ek or ct beyond their lengths. The responder MUST check that the length of ek matches . If the check fails, the responder MUST reject ek and SHOULD return an INVALID_SYNTAX notification. The initiator MUST check that the length of ct matches . If the check fails, the initiator MUST reject the ciphertext, log the error, and stop creating the SA, without initiating IKE_AUTH or the next IKE_INTERMEDIATE exchange. If the error occurs in CREATE_CHILD_SA or IKE_FOLLOWUP_KE, the initiator MUST delete the existing IKE SA and send a Delete payload in a new INFORMATIONAL exchange. Deleting the IKE SA also closes its remaining Child SAs, as specified in Section 1.4.1 of . HQC Decaps uses implicit rejection. A modified ct yields a different K, and the exchange fails when the peers authenticate or use the derived keys.

Security Considerations The security considerations of , , and apply. This document provides post-quantum key establishment to protect against harvest-now-decrypt-later attacks. It does not change IKEv2 authentication. Resistance to active quantum attackers also requires an authentication method that provides post-quantum security, such as a sufficiently strong pre-shared key or a post-quantum signature scheme, as discussed in Section 4 of . PQ/T hybrid use of HQC with (EC)DH is RECOMMENDED, following Section 13.3.1 of . Each HQC key exchange MUST use a fresh ek and dk, and fresh encapsulation randomness. The randomness used for HQC key generation and encapsulation MUST be independent of the randomness used by any other key exchange in the same IKEv2 negotiation, including (EC)DH and other post-quantum KEMs. In a hybrid key exchange, HQC keys and the keys of any other component MUST NOT be generated from the same seed. HQC has a small decryption failure probability. This failure is where the two sides exchange valid keyshares, which are delivered properly, but the two sides generate distinct secrets. This probability is given in Section 4.1 of and is so low, decryption failure likely will never happen a single time in practice. Should a decryption failure happen, Decaps returns a pseudorandom K instead of an error. The peers then derive different keys, and the resulting IKE SA or Child SA does not work. An attacker can try to downgrade the peers to a traditional key exchange. The downgrade considerations of and apply.

IANA Considerations IANA is requested to add the following entries to the "Transform Type 4 - Key Exchange Method Transform IDs" registry. HQC Key Exchange Method registrations

Number	Name	Recipient Tests	Reference
TBD1	hqc-1	RFC XXXX,	RFC XXXX
TBD2	hqc-3	RFC XXXX,	RFC XXXX
TBD3	hqc-5	RFC XXXX,	RFC XXXX

RFC Editor: Replace XXXX with the RFC number of this document.

References Normative References 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. This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through. This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment. The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established. This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs. This document updates RFC 7296 by renaming a Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. HQC team 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. Informative References Amazon Web Services US NIST standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This document specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange. These options allow for negotiating IKE and Child SA keys which are resistant against cryptographically relevant quantum computers. This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association (SA) establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. TCP encapsulation for IKE and IPsec was defined in RFC 8229. This document clarifies the specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. This documents obsoletes RFC 8229. One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), and it details the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. ELVIS-PLUS Nokia The Internet Key Exchange protocol version 2 (IKEv2) can operate either over unreliable (UDP) transport or over reliable (TCP) transport. If TCP is used, then IPsec tunnels created by IKEv2 also use TCP. This document specifies how to decouple IKEv2 and IPsec transports so that IKEv2 can operate over TCP, while IPsec tunnels use unreliable transport. This feature allows IKEv2 to effectively exchange large blobs of data (e.g., when post-quantum algorithms are employed) while avoiding performance problems that arise when IPsec uses TCP. ELVIS-PLUS Cloudflare This document specifies an extension to the Internet Key Exchange protocol version 2 (IKEv2) in which the peers authenticate the full IKE_SA_INIT transcript. When both peers implement the extension and at least one relevant authentication credential is not compromised, this prevents certain downgrade attacks on IKEv2. This document updates RFC 7296.

Acknowledgments This document follows the structure of . The authors thank Valery Smyslov for his review and comments.