Post-quantum Hybrid Key Exchange with NTRU in the Internet Key Exchange Protocol Version 2 (IKEv2)

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 8 January 2026.¶

Copyright Notice

Copyright (c) 2025 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. Introduction

The IKEv2 as specified in [RFC7296], uses the Diffie-Hellman (DH) or the Elliptic Curve Diffie-Hellman (ECDH) algorithm to establish a shared secret between an initiator and a responder. However, the advent of a Cryptographically Relevant Quantum Computer (CRQC) defined in [I-D.D25] would pose a significant threat to the security of DH and ECDH. To address this problem, the Mixing Preshared Keys in IKEv2 specification [RFC8784] was introduced as a temporary option. After that, PQ/T Hybrid Key Encapsulation Mechanism (KEM) in IKEv2 was specified, which combines post-quantum and classical KEMs to ensure security against both classical and quantum adversaries. To enable PQ/T Hybrid KEMs in IKEv2, [RFC9370] extends the IKEv2 specification to allow multiple key exchanges to take place during the computation of a shared secret in the Security Association (SA) setup.¶

The Multiple Key Exchanges defined in [RFC9370] specifies how to perform up to seven additional key exchanges using the IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages, along with procedures for deriving new SKEYSEED and KEYMAT key materials.The reason RFC 9370 allows the use of multiple post-quantum KEMs is to hedge against the risk that any single KEM may be broken in the future. While RFC 9370 provides a general framework that enables hybrid KEMs, it does not define specific instantiations for concrete combinations of multiple KEMs. Currently, two Internet-Drafts aim to define such additional key exchange methods by building upon the framework established in [RFC9370]. First, [I-D.KR24] adds ML-KEM [FIPS203], also known as Kyber. Second, [I-D.W25] introduces FrodoKEM for reasons of algorithm diversity and cryptographic agility.¶

To improve the diversity of post-quantum KEM algorithms, this document proposes to include NTRU [I-D.F25]-specifically, the version of NIST Post-Quantum Cryptography (PQC) round 3 [NTRU] as one of the algorithms usable within the framework defined in [RFC9370]. The inclusion of NTRU increases algorithmic diversity for two main reasons. First, although NTRU is lattice-based, its security is based on the NTRU problem and does not rely on the (Module) Learning With Errors ((M)LWE) problems. Second, it provides a tighter security proof for the desired security notion: indistinguishability under adaptive chosen-ciphertext attacks (IND-CCA2). In addition to increasing algorithmic versatility, the absence of patents is beneficial to users. NTRU is patent-free, which has the advantage of allowing users to avoid patent issues. NTRU is also a valuable choice from an implementation perspective, as its overall performance is comparable to that of ML-KEM, with notably faster encapsulation.¶

2. NTRU in IKEv2

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Key Exchange Method Num    |           RESERVED             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       Key Exchange Data                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. Examples of Running Hybrid KEMS with NTRU

Following general exmaples given in Appendix A of [RFC9370], here is an example to show that the initiator proposes the use of additional key exchanges to establish an IKE SA. Here, the initiator proposes three sets of additional key exchanges. Namely, the first set is TBD36 (ml-kem-768), TBD37 (ml-kem-1024) [I-D.KR24] or NONE; the second set is TBD50 (ntruhps2048677), TBD52 (ntruhps4096821) or NONE. As both of the two additional key exchanes are optional, the responder can choose NONE for some or all of the additional exchanges if the proposed key exchange methods are not supported or for whatever reasons the responder decides not to perform the additional key exchange.¶

Initiator                     Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
    Proposal #1
    Transform ECR (ID = ENCR_AES_GCM_16,
                    256-bit key)
    Transform PRF (ID = PRF_HMAC_SHA2_512)
    Transform KE (ID = Curve25519)
    Transform ADDKE1 (ID = TBD36)
    Transform ADDKE1 (ID = TBD37)
    Transform ADDKE1 (ID = NONE)
    Transform ADDKE2 (ID = TBD50)
    Transform ADDKE2 (ID = TBD52)
    Transform ADDKE2 (ID = NONE)

                   <--- HDR(IKE_SA_INIT), SAr1(.. ADDKE*...),
                        KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
                        N(INTERMEDIATE_EXCHANGE_SUPPORTED)
                        Proposal #1
                          Transform ECR (ID = ENCR_AES_GCM_16,
                                         256-bit key)
                          Transform PRF (ID = PRF_HMAC_SHA2_512)
                          Transform KE (ID = Curve25519)
                          Transform ADDKE1 (ID = NONE)
                          Transform ADDKE2 (ID = TBD50)

HDR(IKE_INTERMEDIATE), SK {KEi(1)(TBD50)} -->
                   <--- HDR(IKE_INTERMEDIATE), SK {KEr(1)(TBD50)}

HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } --->
                      <--- HDR(IKE_AUTH), SK{IDr, AUTH, SAr2,TSi, TSr}

In the above specific example, the responder chooses to run one additional key exchanges. Namely, it selects NONE and TBD50 (ntruhps2048677), respectively for the first and second additional key exchanges. According to [RFC7296], a set of keying materials can be derived, in particular SK_d, SK_a[i/r], and SK_e[i/r]. After that, both peers will perform an IKE_INTERMEDIATE exchange, carrying TBD50 payload, which is protected with SK_e[i/r] and SK_a[i/r] keys. After the completion of this IKE_INTERMEDIATE exchange, the SKEYSEED is updated using SK(1), which is the TBD50 shared secret.¶

After the completion of both IKE_INTERMEDIATE exchanges, the initiator and the responder continue to the IKE_AUTH exchange phase.¶

4. Security Considerations

All security considerations from [RFC9242] and [RFC9370] apply to the NTRU exchanges described in this specification.¶

The NTRU public key generated by the initiator and the ciphertext generated by the responder use randomness (usually a seed) which MUST be independent of any other random seed used in the IKEv2 negotiation. For example, at the initiator, the NTRU and (EC)DH key pairs should not be generated from the same seed. Also, nonces used in the derivation of SKEYSEED and KEYMAT MUST NOT be reused, in order to ensure the pseudorandomness of key derivation using the pseudorandom function defined in [RFC9370].¶

5. IANA Considerations

IANA is requested to assign five values for the names "ntruhps2048677", "ntruhrss701", "ntruhps40961229", "ntruhrss1373", and "ntruhps4096821"in the IKEv2 "Transform Type 4 - Key Exchange Method Transform IDs" and has listed this document as the reference. The Recipient Tests field should also point to this document:¶

[EDNOTE: IANA KE code points for FrodoKEM might be assigned, we assume those code points in this spefication.¶

Acknowledgments

To be added later.¶

Authors' Addresses