ipsecme T. Reddy Internet-Draft Nokia Intended status: Standards Track V. Smyslov Expires: 7 July 2026 ELVIS-PLUS 3 January 2026 PQ/T Hybrid Composite Key Exchange and Reliable Transport for IKEv2 draft-reddy-ipsecme-ikev2-hybrid-reliable-00 Abstract The eventual transition to post-quantum key exchange will require elimination of traditional key exchange for reduced protocol complexity and efficiency. IKEv2 therefore requires a mechanism that can operate in a PQC-only environment, without depending on traditional key exchange algorithms (e.g., MODP DH or ECDH). As IKEv2 permits arbitrary combinations of algorithms, unnecessary complexity and insecure hybrid constructions are easily implemented. This document defines PQ/T hybrid composite key exchange algorithms for IKEv2 and a single combined KE payload that carries both the traditional and post-quantum components. It also leverages the existing IKEv2 reliable transport mechanism so that large PQC key exchange messages can be reliably exchanged over TCP. Together, these mechanisms enable secure and efficient PQ/T hybrid deployments today and provide a clear path for IKEv2 to operate in environments where traditional algorithms have been replaced by PQC algorithms. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-reddy-ipsecme-ikev2-hybrid- reliable/. Discussion of this document takes place on the ipsecme Working Group mailing list (mailto:ipsecme@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ipsec/. Subscribe at https://www.ietf.org/mailman/listinfo/ipsecme/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Reddy & Smyslov Expires 7 July 2026 [Page 1] Internet-Draft PQ/T hybrid composite KE for IKEv2 January 2026 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 July 2026. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Reliable Transport Requirements . . . . . . . . . . . . . . . 5 4. PQ/T hybrid composite Key Exchange Algorithms . . . . . . . . 5 5. Combined Key Exchange Payload . . . . . . . . . . . . . . . . 6 6. Reliable Transport Negotiation . . . . . . . . . . . . . . . 6 6.1. SEPARATE_TRANSPORTS Negotiated . . . . . . . . . . . . . 6 6.2. No SEPARATE_TRANSPORTS . . . . . . . . . . . . . . . . . 7 7. Hybrid Derivation . . . . . . . . . . . . . . . . . . . . . . 7 8. Example Message Flow . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Normative References . . . . . . . . . . . . . . . . . . . . . 10 Informative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Reddy & Smyslov Expires 7 July 2026 [Page 2] Internet-Draft PQ/T hybrid composite KE for IKEv2 January 2026 1. Introduction The Internet Key Exchange version 2 ([IKEv2]) is a key agreement and security negotiation protocol used for IPsec key establishment. The emergence of CRQCs will render traditional key exchange algorithms obsolete. In a post-quantum future, many systems will be unable to rely on or even ship traditional key exchange algorithms. For IKEv2 to remain deployable in such an environment, it must support PQC-only key exchange without depending on traditional key exchange algorithms. However, because IKEv2 requires that its first key exchange occur in the IKE_SA_INIT exchange, any PQC KEM public key or ciphertext that does not fit within a single IKE_SA_INIT message (without IP fragmentation) cannot be sent directly in that exchange. When a PQC KEM does not fit in IKE_SA_INIT, the initial exchange must fall back to a traditional key exchange before any PQC public key or ciphertext can be sent. This creates an important limitation: even in a future where CRQCs exist and PQC algorithms are mandatory, IKEv2 peers are forced to use a traditional key exchange in IKE_SA_INIT whenever the PQC KEM exceeds the path MTU. In deployments that do not implement traditional key exchange algorithms, such fallback is unacceptable. Absent reliable transport, PQC-only operation is therefore impossible when PQC key exchange payloads exceed the path MTU. PQC-only deployments remain impossible for any PQC scheme whose keying material does not fit inside an unfragmented IKE_SA_INIT message, prolonging reliance on traditional key exchange algorithms far beyond their acceptable security horizon. While functional, these mechanisms increase round-trip latency and add protocol complexity. Recent guidance, including that discussed in Section 13.3.2 of [I-D.ietf-pquip-pqc-engineers], notes that protocol designs benefit from allowing a small number of known good configurations that make sense, instead of allowing arbitrary combinations of individual configuration choices that may interact in dangerous ways. Allowing arbitrary combinations of traditional and PQC algorithms can lead to interactions that have not been thoroughly evaluated. However, IKEv2 does not currently follow this guidance as [I-D.ietf-ipsecme-ikev2-mlkem] allows arbitrary combinations of DH groups and ML-KEM parameters through separate traditional and PQC negotiation paths, which may lead to untested or undesirable hybrid constructions and makes it difficult to enforce secure algorithm pairing. To address these issues, this document introduces: Reddy & Smyslov Expires 7 July 2026 [Page 3] Internet-Draft PQ/T hybrid composite KE for IKEv2 January 2026 * PQ/T hybrid composite key exchange algorithms for IKEv2, representing single, fixed, known good combinations of traditional and PQC KEM algorithms. * A combined KE payload format that carries both traditional and PQC components within a single payload. * Leverages the IKEv2 reliable transport mechanism defined in [I-D.ietf-ipsecme-ikev2-reliable-transport] so that IKEv2 peers can use TCP for large PQC key exchange messages. These updates remove the dependency on multi-round negotiation exchanges, eliminate the requirement to use traditional algorithms solely due to MTU limitations, reduce the risks associated with IP fragmentation of large PQC payloads, and provide a clear path for IKEv2 to operate securely and efficiently in a future where only PQC algorithms remain usable. 2. 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. This document uses terms defined in [RFC9794]. For the purposes of this document, it is helpful to be able to divide cryptographic algorithms into three classes: "Traditional asymmetric cryptographic algorithm": An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms, elliptic curve discrete logarithms, or related mathematical problems. "Post-quantum asymmetric cryptographic algorithm": An asymmetric cryptographic algorithm that is intended to be secure against attacks using quantum computers as well as classical computers. "Post-Quantum Traditional (PQ/T) hybrid scheme": A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm. Reddy & Smyslov Expires 7 July 2026 [Page 4] Internet-Draft PQ/T hybrid composite KE for IKEv2 January 2026 3. Reliable Transport Requirements PQC-only deployments (i.e., deployments that do not implement any traditional key exchange algorithms) cannot rely on UDP for IKE_SA_INIT when the PQC key exchange payload exceeds the path MTU. In these deployments, fallback to UDP would prevent the use of a PQC- only key exchange. Therefore, when a PQC-only key exchange method is offered or negotiated and the PQC key exchange payload exceeds the path MTU, the initiator MUST start IKE_SA_INIT over TCP, and peers MUST NOT fall back to UDP for IKE_SA_INIT. This requirement follows from the reliable transport mechanism defined in [I-D.ietf-ipsecme-ikev2-reliable-transport]. PQ/T hybrid composite key exchange produces a combined KE payload that may or may not exceed the path MTU, depending on the specific algorithm combination. When the combined KE payload exceeds the path MTU, the PQ/T hybrid composite key exchange MUST NOT be sent over UDP. If TCP is supported, the initiator MAY migrate to TCP and use the PQ/T hybrid composite key exchange; otherwise, the initiator MUST use a PQ/T hybrid non-composite key exchange. 4. PQ/T hybrid composite Key Exchange Algorithms This document defines PQ/T hybrid composite key-exchange methods that MUST be treated as single, atomic key-exchange identifier. Because IKEv2 treats key-exchange methods (Transform Type 4) as opaque and does not define their internal processing (see Section 2.14 of [IKEv2]), each hybrid method specifies how its traditional and PQC shared secrets are combined. Each PQ/T hybrid composite key exchange algorithm implies: * One traditional key exchange component * One PQC KEM component * One combined KE payload format * A PQ/T hybrid key-exchange algorithm specific combiner (see Section 7) This document defines the following PQ/T hybrid composite key exchange algorithms: * ecp256-mlkem768 * ecp384-mlkem1024 Reddy & Smyslov Expires 7 July 2026 [Page 5] Internet-Draft PQ/T hybrid composite KE for IKEv2 January 2026 * curve25519-mlkem768 Each PQ/T hybrid composite key exchange algorithm is represented as a single Transform ID of type 4 (Key Exchange Method) and is negotiated as a whole. 5. Combined Key Exchange Payload The KE payload carries both components of the PQ/T hybrid composite key exchange algorithm. Specifically, the initiator includes its traditional key exchange public key together with its PQC KEM public key: KEi = Traditional-Key-Exchange-Public-Key || PQC-KEM-Public-Key The responder returns its traditional key exchange public key along with the PQC ciphertext: KEr = Traditional-Key-Exchange-Public-Key || PQC-Ciphertext Because both the traditional and post-quantum key exchange values are conveyed within a single exchange, no ADDKE transforms are negotiated. Thus, the IKE_INTERMEDIATE and IKE_FOLLOWUP_KE exchanges are not needed for the purpose of key exchange, but peers can negotiate and use IKE_INTERMEDIATE for other purposes. The lengths of the traditional and PQC components are fixed and defined by the selected PQ/T hybrid composite Transform ID. No additional length fields are included in the KE payload. 6. Reliable Transport Negotiation PQ/T hybrid composite key exchange requires a reliable transport to avoid IP-layer fragmentation of large PQC key exchange values. Transport selection follows [I-D.ietf-ipsecme-ikev2-reliable-transport]. The initiator MUST follow the rules in the scenarios below. 6.1. SEPARATE_TRANSPORTS Negotiated If the initiator starts the IKE_SA_INIT exchange over TCP and includes a SEPARATE_TRANSPORTS Notify, and the responder also includes a SEPARATE_TRANSPORTS Notify, then the IKE SA is established using separate transports. In this configuration, all IKE messages are sent over TCP. ESP is sent over UDP (or directly over IP) if possible; if both UDP and IP are blocked, ESP is sent over TCP as described in [RFC9329]. Reddy & Smyslov Expires 7 July 2026 [Page 6] Internet-Draft PQ/T hybrid composite KE for IKEv2 January 2026 6.2. No SEPARATE_TRANSPORTS If the initiator starts the IKE_SA_INIT exchange over TCP and the responder accepts the TCP transport but does not include a SEPARATE_TRANSPORTS Notify, then the IKE SA operates in the mode defined by [RFC9329]. In this configuration, both IKE messages and ESP traffic are carried over the same TCP connection. PQ/T hybrid key exchange payloads can be sent in this configuration since the IKE messages are transported reliably. 7. Hybrid Derivation Each PQ/T hybrid key exchange method defined in this document produces two independent shared secrets: one from the traditional component (K_T) and one from the PQC component (K_PQ). Because IKEv2 treats key exchange methods as opaque, the function that combines these secrets is defined per hybrid KE method. The PQ/T hybrid key exchange methods in this document use the Universal Combiner defined in [I-D.irtf-cfrg-hybrid-kems]. Note that in all PQ/T hybrid composite KE algorithms defined in this document, the PQC component is listed second in the algorithm name but is passed first to the Universal Combiner. Let: * K_T = traditional ECDH shared secret * K_PQ = post-quantum shared secret The combined secret is computed as: label = "IKEv2-HYBRID-KE-v1" K_combined = UniversalCombiner(K_PQ, K_T, CT_PQ, "", PK_PQ, PK_T, label) Where: * K_PQ : PQC shared secret * K_T : traditional shared secret * CT_PQ : PQC ciphertext * PK_PQ : PQC public key * PK_T : traditional public key * label : protocol-specific domain separation string Reddy & Smyslov Expires 7 July 2026 [Page 7] Internet-Draft PQ/T hybrid composite KE for IKEv2 January 2026 The traditional component does not produce a ciphertext; therefore, the ciphertext argument corresponding to the traditional component is the empty string. The SKEYSEED value is computed as: SKEYSEED = prf(Ni | Nr, K_combined) This replaces the g^ir shared secret defined in [IKEv2]; all other aspects of SKEYSEED computation remain unchanged. Once SKEYSEED is derived, the remainder of the IKEv2 key hierarchy is computed exactly as specified in [IKEv2]. This construction aligns with the hybrid key exchange approach used in TLS [I-D.ietf-tls-hybrid-design], where traditional and post- quantum secrets are concatenated before key derivation to ensure security against both traditional and quantum adversaries. 8. Example Message Flow This section illustrates an IKEv2 exchange using a PQ/T hybrid composite key exchange algorithm. The initiator sends a combined KE payload containing both the traditional DH public key and the PQC public key. The responder returns its DH public key together with the PQC ciphertext. The exchange is shown using TCP, negotiated using the IKEv2 reliable transport mechanism. Both peers include the SEPARATE_TRANSPORTS Notify to indicate support for separate IKE and ESP transports. Reddy & Smyslov Expires 7 July 2026 [Page 8] Internet-Draft PQ/T hybrid composite KE for IKEv2 January 2026 Initiator Responder --------------------------------------------------------------------- IKE_SA_INIT (over TCP) HDR, SAi1, N(SEPARATE_TRANSPORTS), KEi( DH_pub_i || PQC_pub_i ), Ni ---> <--- HDR, SAr1, N(SEPARATE_TRANSPORTS), KEr( DH_pub_r || PQC_ct ), Nr IKE_AUTH HDR, SK { IDi, AUTH, SAi2, TSi, TSr } ---> <--- HDR, SK { IDr, AUTH, SAr2, TSi, TSr } Child SA established; ESP traffic uses UDP. --------------------------------------------------------------------- 9. Security Considerations PQ/T hybrid composite key exchange algorithms reduce the risk of insecure or unintended algorithm combinations by ensuring that only well-defined, vetted pairs of traditional and PQC algorithms are used. This prevents deployments from constructing ad-hoc hybrids that may provide weaker security than either component alone. As in standard IKEv2, the KE payload (including both the traditional and PQC components) is integrity-protected and authenticated during the IKE_AUTH exchange. This protection prevents modification of either component by an active attacker. This document leverages the IKEv2 reliable transport mechanism to avoid IP-layer fragmentation of large PQC payloads. Finally, by enabling a PQC-only key exchange within IKE_SA_INIT and by avoiding fallback to traditional key exchange due solely to MTU constraints, the mechanisms in this document ensure that IKEv2 remains secure and deployable even in environments where traditional algorithms have been deprecated or removed due to their vulnerability to quantum- capable adversaries. Reddy & Smyslov Expires 7 July 2026 [Page 9] Internet-Draft PQ/T hybrid composite KE for IKEv2 January 2026 10. IANA Considerations IANA is requested to assign three new values for the PQ/T hybrid composite key exchange algorithm names "ecp256-mlkem768", "ecp384-mlkem1024", and "curve25519-mlkem768" in the IKEv2 "Transform Type 4 Key Exchange Method Transform IDs" registry and list this document as the reference. +========+======================+===========+ | Number | Name | Reference | +========+======================+===========+ | TBD1 | ecp256-mlkem768 |[this RFC] | +--------+----------------------+-----------+ | TBD2 | ecp384-mlkem1024 |[this RFC] | +--------+----------------------+-----------+ | TBD3 | curve25519-mlkem768 |[this RFC] | +--------+----------------------+-----------+ Table 1: Updates to the IANA "Transform Type 4 - Key Exchange Method Transform IDs" registry Acknowledgments The authors thank Dan Wing for his contributions to this specification. References Normative References [I-D.ietf-ipsecme-ikev2-mlkem] Kampanakis, P., "Post-quantum Hybrid Key Exchange with ML- KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)", Work in Progress, Internet-Draft, draft-ietf- ipsecme-ikev2-mlkem-03, 29 September 2025, . [I-D.ietf-ipsecme-ikev2-reliable-transport] Smyslov, V. and T. Reddy.K, "Separate Transports for IKE and ESP", Work in Progress, Internet-Draft, draft-ietf- ipsecme-ikev2-reliable-transport-00, 6 October 2025, . [IKEv2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . Reddy & Smyslov Expires 7 July 2026 [Page 10] Internet-Draft PQ/T hybrid composite KE for IKEv2 January 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9329] Pauly, T. and V. Smyslov, "TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets", RFC 9329, DOI 10.17487/RFC9329, November 2022, . Informative References [I-D.ietf-pquip-pqc-engineers] Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek, T., and M. Ounsworth, "Post-Quantum Cryptography for Engineers", Work in Progress, Internet-Draft, draft-ietf- pquip-pqc-engineers-14, 25 August 2025, . [I-D.ietf-tls-hybrid-design] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key exchange in TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-hybrid-design-16, 7 September 2025, . [I-D.irtf-cfrg-hybrid-kems] Connolly, D., Barnes, R., and P. Grubbs, "Hybrid PQ/T Key Encapsulation Mechanisms", Work in Progress, Internet- Draft, draft-irtf-cfrg-hybrid-kems-07, 20 October 2025, . [RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for Post-Quantum Traditional Hybrid Schemes", RFC 9794, DOI 10.17487/RFC9794, June 2025, . Authors' Addresses Reddy & Smyslov Expires 7 July 2026 [Page 11] Internet-Draft PQ/T hybrid composite KE for IKEv2 January 2026 Tirumaleswar Reddy Nokia Bangalore Karnataka India Email: kondtir@gmail.com Valery Smyslov ELVIS-PLUS Russian Federation Email: svan@elvis.ru Reddy & Smyslov Expires 7 July 2026 [Page 12]