| Internet-Draft | HQC in IKEv2 | October 2026 |
| Reddy, et al. | Expires 27 April 2027 | [Page] |
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.¶
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 27 April 2027.¶
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.¶
HQC [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.¶
[IKEV2-MLKEM] defines ML-KEM key exchange in IKEv2 [RFC7296]. 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 [RFC9794] with a traditional (EC)DH key exchange using the multiple key exchanges of [RFC9370].¶
HQC can also be combined with ML-KEM [IKEV2-MLKEM], with or without a traditional key exchange, using [RFC9370]. 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.¶
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.¶
This document uses the KEM functions KeyGen, Encaps, and Decaps of
[HQC]. 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 [RFC7296], "initiator" and "responder" refer to the roles in the exchange that carries the KE payload, not the original roles of the IKE SA.¶
| Name | Transform ID | NIST Security Category |
|---|---|---|
| hqc-1 | TBD1 | 1 |
| hqc-3 | TBD2 | 3 |
| hqc-5 | TBD3 | 5 |
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
[HQC]. Table 2 gives their lengths and the resulting KE
payload lengths. The KE payload length includes the 8-octet KE
payload header.¶
| 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 [RFC7296] and [RFC9370], in the same way as the
(EC)DH shared secret.¶
HQC KE payloads exceed the typical path MTU. IKE_SA_INIT messages cannot be fragmented using [RFC7383]. Therefore, HQC SHOULD NOT be used in IKE_SA_INIT, unless the IKE_SA_INIT exchange itself is carried over TCP [RFC9329], including the mode described in Section 3.2 of [IKEV2-RT]. Switching to TCP only after IKE_SA_INIT, as described in Section 3.1 of [IKEV2-RT], does not avoid IP fragmentation of HQC KE payloads in IKE_SA_INIT.¶
HQC SHOULD be negotiated as an additional key exchange using [RFC9370]. During initial IKE SA establishment, an additional HQC key exchange is carried in IKE_INTERMEDIATE [RFC9242]. 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 [RFC7383]. HQC can also be used as the first or only key exchange in CREATE_CHILD_SA as specified in [RFC9370].¶
IKE fragmentation under [RFC7383] 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 [RFC9370] alone does not imply support for IKE fragmentation.¶
Version 2025-08-22 of [HQC] does not define checks on a received
ek or ct beyond their lengths.¶
The responder MUST check that the length of ek matches
Table 2. 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
Table 2. 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 [RFC7296].¶
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.¶
The security considerations of [RFC7296], [RFC9242], and [RFC9370] 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 [RFC9370].¶
PQ/T hybrid use of HQC with (EC)DH is RECOMMENDED, following Section 13.3.1 of [RFC9958].¶
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 [HQC] 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 [IKEV2-MLKEM] and [IKEV2-DOWNGRADE] apply.¶
IANA is requested to add the following entries to the "Transform Type 4 - Key Exchange Method Transform IDs" registry.¶
| Number | Name | Recipient Tests | Reference |
|---|---|---|---|
| TBD1 | hqc-1 | RFC XXXX, Section 3.4 | RFC XXXX |
| TBD2 | hqc-3 | RFC XXXX, Section 3.4 | RFC XXXX |
| TBD3 | hqc-5 | RFC XXXX, Section 3.4 | RFC XXXX |
RFC Editor: Replace XXXX with the RFC number of this document.¶
This document follows the structure of [IKEV2-MLKEM]. The authors thank Valery Smyslov for his review and comments.¶