Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS Intended status: Standards Track Y. Nir Expires: 9 April 2026 Dell Technologies 6 October 2025 Using Classic McEliece in the Internet Key Exchange Protocol Version 2 (IKEv2) draft-smyslov-ipsecme-ikev2-mceliece-01 Abstract This document specifies how Classic McEliece Key Encapsulation Mechanism (KEM) is used to generate keys in the Internet Key Exchange version 2 (IKEv2) protocol. 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 9 April 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. Smyslov & Nir Expires 9 April 2026 [Page 1] Internet-Draft Classic McEliece in IKEv2 October 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 3. Classic McEliece KEM . . . . . . . . . . . . . . . . . . . . 3 4. Using Classic McEliece in IKEv2 . . . . . . . . . . . . . . . 4 4.1. Using Classic McEliece for Child SAs and for IKE SA Rekey . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Transport Considerations . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction IKEv2 ([RFC7296]) is a protocol for authentication and for generating keys for IPsec ([RFC4301]). Part of it is generating keys. Classic McEliece ([I-D.josefsson-mceliece]) provides a code-based Key Encapsulation Method (KEM) designed to be safe even against an adversary equipped with a quantum computer. The twelve parameter sets described in section 9 of [I-D.josefsson-mceliece] offers different balances between performance and output sizes. The information needed for key agreement (in the case of McEliece this is a public key and a ciphertext) is carried in Key Exchange (KE) payloads. With the most common parameter set from the draft, mceliece6688128, the public key requires (see section 8.2.7 of the McEliece document) 1044992 octets to encode. This is almost 16 times as big as a standard KE payload (or any other payload) can carry, so we need to use a big payload, as specified in the big payload draft ([I-D.nir-ipsecme-big-payload]). Because large payloads cannot be used in the IKE_SA_INIT exchange (see section 2.3 of [I-D.nir-ipsecme-big-payload]), the first key exchange has to use another algorithm, such as classic Diffie- Hellman or an elliptic curve variant. The McEliece exchange needs to be carried in an IKE_INTERMEDIATE exchange ([RFC9242]), after negotiating in the IKE_SA_INIT both support for big payloads and the additional key exchange exchange through the INTERMEDIATE_EXCHANGE_SUPPORTED notify message ([RFC9370]). The Classic Mceliece KEM can also be used in CREATE_CHILD_SA. For that, support for the intermediate exchange is not necessary. Smyslov & Nir Expires 9 April 2026 [Page 2] Internet-Draft Classic McEliece in IKEv2 October 2025 TBD if this document should make any recommendations about which DH group to use for the initial key exchange, or whether it should remain silent on the topic. 2. Terminology and Notation 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. It is assumed that readers are familiar with the IKEv2 protocol [RFC7296]. 3. Classic McEliece KEM Classic McEliece [I-D.josefsson-mceliece] is a code-based Key Encapsulation Mechanism (KEM) that is considered conservative and very thoroughly analysed. The [I-D.josefsson-mceliece] document specifies 12 parameter sets. Should we just leave it at that, or specify just one? The current SSH candidate draft specifies only mceliece6688128. The current TLS candidate draft specifies 3: mceliece6688128, mceliece6960119, and mceliece8192128. Official Classic McEliece site [MCELIECE] lists 5 parameter sets. What should we do? This is up to the working group. Until this is decided, we added a comparison table between the parameter sets here. Ultimately, there is nothing special about IKEv2. What is fitting for TLS and SSH is likely fitting for IKEv2 as well. Smyslov & Nir Expires 9 April 2026 [Page 3] Internet-Draft Classic McEliece in IKEv2 October 2025 +=================+=======+========+=========+============+=========+ | Parameter Set |Claimed|Public | Secret | Ciphertext | Shared | | |NIST |key | key | size | secret | | |Leve |size | size | (bytes) | size | | | |(bytes) | (bytes) | | (bytes) | +=================+=======+========+=========+============+=========+ | mceliece348864 |1 |261120 | 6492 | 96 | 32 | +=================+=======+========+=========+============+=========+ | mceliece460896 |3 |524160 | 13608 | 156 | 32 | +=================+=======+========+=========+============+=========+ | mceliece6688128 |5 |1044992 | 13932 | 208 | 32 | +=================+=======+========+=========+============+=========+ | mceliece6960119 |5 |1047319 | 13948 | 194 | 32 | +=================+=======+========+=========+============+=========+ | mceliece8192128 |5 |1357824 | 14120 | 208 | 32 | +=================+=======+========+=========+============+=========+ Table 1: Classic McEliece Parameter Set Summary 4. Using Classic McEliece in IKEv2 To negotiate the use of the McEliece KEM, an IKEv2 initiator and responder MUST negotiate three things in the IKE_SA_INIT exchange: * The support for big IKE payloads ([I-D.nir-ipsecme-big-payload]) * Support for IKE fragmentation ([RFC7383]) * The use of these groups, see Section 7, as ADDKE. This implies support for the IKE_INTERMEDIATE exchange. Since all of the above have to be specified in the IKE_SA_INIT request, the McEliece key exchange, a Responder MUST reject any McEliece group offered in an ADDKE payload if it does not support both big IKE payloads and fragmentation. Additionally, it MUST reject any McEliece group offered in an ADDKE payload if the initiator has not negotiated the support for both big payloads and for fragmentation. Within the IKE_INTERMEDIATE exchange, such payloads will normally encode the large public keys. A diagram is provided here for illustration:. The format below is the big payload version of the Key Exchange from section 3.4 of [RFC7296]. Smyslov & Nir Expires 9 April 2026 [Page 4] Internet-Draft Classic McEliece in IKEv2 October 2025 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|L| RESERVED | Payload Length... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...length continued | Key Exchange Method | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | McEliece KEM key data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ KEM key data continues... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * L is 1, indicating that the length field is 32-bit. * The Key Exchange Method is TBD, the value assigned by IANA (see Section 7) * The McEliece KEM key data is as described in section 6.3 of [I-D.josefsson-mceliece]. Note that when the KE payload is used to carry ciphertext, it can fit with the short payload format. It is not required to always use the big payload format to use Classic McEliece. 4.1. Using Classic McEliece for Child SAs and for IKE SA Rekey The Classic McEliece KEM can also be used in the CREATE_CHILD_SA exchange (or in the IKE_FOLLOWUP_KE exchange as defined in [RFC9370]) to rekey IKE SA and to create/rekey IPsec SAs. The format and size are just the same, so doing this also requires support for big payloads and for IKE fragmentation. However, if Classic McEliece is only used in these exchanges, there is no need to negotiate the IKE_INTERMEDIATE exchange. 5. Transport Considerations While an IKE SA that utilizes Classic McEliece can run over UDP, in most settings this will be problematic. The reason is that with tipical MTU size of 1500 bytes, an IKE message containing Classic McEliece public key will be splitted into several hundreds IKE fragment messages, which will be sent to the network at once. This may lead to network congestion causing loss of some messages, in which case all the fragment messages will be re-sent again (after timeout), since IKE fragment messages are not individually acknowledged. This will also lead to congestion and the process will Smyslov & Nir Expires 9 April 2026 [Page 5] Internet-Draft Classic McEliece in IKEv2 October 2025 repeat until all the fragment messages will be received, but this might not happen. For this reason peers may want to use TCP as a transport. Peers may choose between using TCP for both IKE and ESP as specified in [RFC9329] or using separate transports for them [I-D.smyslov-ipsecme-ikev2-reliable-transport]. The latter allows to avoid performance degradation when tunnelling TCP trafic and thus is RECOMMENDED. Note, that despite the fact, that TCP can tranfer messages of any size without having problems with IP fragmentation, in case of Classic McEliece peers still have to negotiate IKE fragmentation [RFC7383] as defined in Section 4, even when they choose to use TCP as a transport for IKE. This is due to the limitation imposed by [RFC9329] that individual IKE message in TCP stream cannot exceed 64 Kbytes. Thus, larger IKE messages need to be be fragmented to this size by IKE fragmentation mechanism before sending over TCP. 6. Security Considerations This inherits the security of IKEv2, the additional key exchange extension, the big payload extension, and of course, classic McEliece. Some discussion about choice of group for the initial key exchange should be added here. Probably more about McEliece here. 7. IANA Considerations IANA is requested to assign one (or is it three) values from the "Transform Type 4 - Key Exchange Method Transform IDs" registry with name "mceliece6688128" (and maybe also "mceliece6960119" and "mceliece8192128") and this document as reference. 8. Acknowledgements 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Smyslov & Nir Expires 9 April 2026 [Page 6] Internet-Draft Classic McEliece in IKEv2 October 2025 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC7296] 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, . [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, . [RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9242, DOI 10.17487/RFC9242, May 2022, . [RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May 2023, . [I-D.josefsson-mceliece] Josefsson, S., "Classic McEliece", Work in Progress, Internet-Draft, draft-josefsson-mceliece-03, 7 July 2025, . [I-D.nir-ipsecme-big-payload] Nir, Y., "A Larger Internet Key Exchange version 2 (IKEv2) Payload", Work in Progress, Internet-Draft, draft-nir- ipsecme-big-payload-06, 14 September 2025, . 9.2. Informative References [MCELIECE] "Classic McEliece", . [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, . Smyslov & Nir Expires 9 April 2026 [Page 7] Internet-Draft Classic McEliece in IKEv2 October 2025 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [I-D.smyslov-ipsecme-ikev2-reliable-transport] Smyslov, V. and T. Reddy.K, "Separate Transports for IKE and ESP", Work in Progress, Internet-Draft, draft-smyslov- ipsecme-ikev2-reliable-transport-04, 15 April 2025, . Authors' Addresses Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation Email: svan@elvis.ru Yoav Nir Dell Technologies 9 Andrei Sakharov St Haifa 3190500 Israel Email: ynir.ietf@gmail.com Smyslov & Nir Expires 9 April 2026 [Page 8]