Internet Engineering Task Force (IETF)C.CJ. TjhaiInternet-DraftRequest for Comments: 9370 M. Tomlinson Updates: 7296(if approved)Post-QuantumIntended status:Category: Standards Track G. BartlettExpires: 4 June 2023ISSN: 2070-1721 Quantum Secret S. Fluhrer Cisco Systems D. Van Geest ISARA Corporation O. Garcia-Morchon Philips V. Smyslov ELVIS-PLUS1 December 2022May 2023 Multiple Key Exchanges inIKEv2 draft-ietf-ipsecme-ikev2-multiple-ke-12the Internet Key Exchange Protocol Version 2 (IKEv2) Abstract 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.The primary application of this feature in IKEv2 is the ability to perform one or more post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman (EC)DH key exchange, so that the resulting shared key is resistant against quantum computer attacks. Since there is currently no post-quantum key exchange that is as well-studied as (EC)DH, performing multiple key exchanges with different post-quantum algorithms along with the well-established classical key exchange algorithms addresses this concern, since the overall security is at least as strong as each individual primitive. Another possible application for this extension is the ability to combine several key exchanges in situations when no single key exchange algorithm is trusted by both initiator and responder.This document utilizes the IKE_INTERMEDIATE exchange,by means of whichwhere multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2exchangeexchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA isup (during rekeysbeing rekeyed or is creating additional ChildSAs).SAs. This document updatesRFC7296RFC 7296 by renaming atransform typeTransform 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 thistransform typeTransform 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. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany 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 4 June 2023.https://www.rfc-editor.org/info/rfc9370. Copyright Notice Copyright (c)20222023 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)(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. . . . . . . . . . . . . . . . . . . . . . . . 31.1. Problem Description. . . . . . . . . . . . . . . . . . . 31.2. Proposed Extension. . . . . . . . . . . . . . . . . . . 41.3. Document Organization. . . . . . . . . . . . . . . . . . 72. Multiple Key Exchanges. . . . . . . . . . . . . . . . . . . 82.1. Design Overview. . . . . . . . . . . . . . . . . . . . . 82.2. Protocol Details. . . . . . . . . . . . . . . . . . . . 102.2.1. IKE_SA_INIT Round: Negotiation. . . . . . . . . . . 102.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges. . 152.2.3. IKE_AUTH Exchange. . . . . . . . . . . . . . . . . . 162.2.4. CREATE_CHILD_SA Exchange. . . . . . . . . . . . . . 162.2.5. Interaction with IKEv2 Extensions. . . . . . . . . . 193. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20 3.1. Additional Considerations and Changes . . . . . . . . . . 214. Security Considerations. . . . . . . . . . . . . . . . . . . 225. References. . . . . . . . . . . . . . . . . . . . . . . . . 245.1. Normative References. . . . . . . . . . . . . . . . . . 245.2. Informative References. . . . . . . . . . . . . . . . . 25Appendix A. Sample Multiple Key Exchanges. . . . . . . . . . . 26A.1. IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange Payloads. . . . . . . . . . . . . . . . . . . . . . . . 26A.2. No Additional Key Exchange Used. . . . . . . . . . . . . 28A.3. Additional Key Exchange in the CREATE_CHILD_SA Exchangeonly . . . . . . . . . . . . . . . . . . . . . . . . . . 29Only A.4. No Matching Proposal for Additional Key Exchanges. . . . 31Appendix B. Design Criteria. . . . . . . . . . . . . . . . . . 31Appendix C. Alternative Design. . . . . . . . . . . . . . . . . 33Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 36Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 371. Introduction 1.1. Problem Description The Internet Key Exchange Protocol(IKEv2)version 2 (IKEv2), as specified in[RFC7296][RFC7296], uses the Diffie-Hellman (DH) or the Elliptic CurveDiffie-HellmanDiffie- Hellman (ECDH) algorithm, which shall be referred to as(EC)DH"(EC)DH" collectively, to establish a shared secret between an initiator and a responder. The security of the (EC)DH algorithms relies on the difficulty to solve a discrete logarithm problem in multiplicative(and respectively(and, respectively, elliptic curve) groups when the order of the group parameter is large enough. While solving such a problem remains infeasible with current computing power, it is believed thatgeneral purposegeneral-purpose quantum computers will be able to solve this problem, implying that the security of IKEv2 is compromised. There are, however, a number of cryptosystems that are conjectured to be resistantagainst quantum computer attack.to quantum-computer attacks. This family of cryptosystems is known aspost- quantum cryptography (PQC)."post-quantum cryptography" (or "PQC"). It is sometimes also referred to asquantum-safe cryptography (QSC)"quantum-safe cryptography" (or "QSC") orquantum-resistant cryptography (QRC)."quantum-resistant cryptography" (or "QRC"). It is essential to have the ability to perform one or more post- quantum key exchanges in conjunction with an (EC)DH key exchange so that the resulting shared key is resistant to quantum-computer attacks. Since there is currently no post-quantum key exchange that is as well-studied as (EC)DH, performing multiple key exchanges with different post-quantum algorithms along with the well-established classical key-exchange algorithms addresses this concern, since the overall security is at least as strong as each individual primitive. 1.2. Proposed Extension This document describes a method to perform multiple successive key exchanges in IKEv2.ItThis method allows integration of PQC in IKEv2, while maintainingbackwardsbackward compatibility, to derive a set of IKE keys that is resistant toquantum computerquantum-computer attacks. This extension allows the negotiation of one or more PQCalgorithmalgorithms to exchange data, in addition to the existing (EC)DH key exchange data. It is believed that the feature of using more than one post-quantumalgorithmsalgorithm isimportantimportant, as many of these algorithms are relativelynewnew, and there may be a need to hedge the security risk with multiple key exchange data from several distinct PQC algorithms. IKE peers perform multiple successive key exchanges to establish an IKESecurity Association (SA).SA. Each exchange producesa piece of secretsome shared secret, and these secrets are combined in a way such that: (a) the final shared secret is computed from all of the component key exchangesecret;secrets; (b)the shared secret as specified in [RFC7296] is obtainedunless both peers support and agree to use the additional key exchanges introduced in thisspecification;specification, the final shared secret equivalent to the shared secret specified in [RFC7296] is obtained; and (c) if any part of the component key exchange method is apost-quantumpost- quantum algorithm, the final shared secret is post-quantum secure. Some post-quantum key exchange payloads may have sizes larger than the standard maximum transmission unit (MTU)size, and thereforesize. Therefore, there could be issues with fragmentation at the IP layer. In order to allowusingthe use of those larger payload sizes, this mechanism relies on the IKE_INTERMEDIATE exchange as specified in [RFC9242]. With this mechanism, the key exchange is initiated using a smaller, possibly classical primitive, such as (EC)DH. Then, before the IKE_AUTH exchange, one or more IKE_INTERMEDIATE exchanges are carried out, each of which contains an additional key exchange. As the IKE_INTERMEDIATE exchange is encrypted, the IKE fragmentation protocol [RFC7383] can be used. The IKE SK_* values are updated after eachexchangeexchange, as described in Section2.2.2, and so2.2.2; thus, the final IKE SA keys depend on all the keyexchanges, hence theyexchanges. Hence, the keys are secure if any of the key exchanges are secure. While this extension is primarily aimedforat IKE SAs due to the potential fragmentation issue discussed above, it also applies to CREATE_CHILD_SA exchanges as illustrated in Section 2.2.4 for creating/rekeying of Child SAs and rekeying of IKE SAs. Note that readers should consider the approach defined in this document as providing along termlong-term solution in upgrading the IKEv2 protocol to support post-quantum algorithms. Ashort termshort-term solution to make IKEv2 key exchange quantum secure is to use post-quantum pre- shared keys as specified in [RFC8784]. Note also that the proposed approach of performing multiple successive key exchanges in such away thatway, when the resulting session keys depend on all ofthemthem, is not limited to only addressing the threat of quantumcomputer.computers. It can also be used when all of the performed key exchanges are classical (EC)DH primitives,wherewhere, forsomevarious reasons(e.g.(e.g., policyrequirements)requirements), it is essential to perform multipleof them.key exchanges. This specification does not attempt to address key exchanges with KE payloads longer than 64Kbytes;KB; the current IKE payload format does not allow suchasa possibility. At the time of writing, it appears likely that there are a number of key exchanges available that would not have such a requirement.However, if such a requirement is needed, [I-D.tjhai-ikev2-beyond-64k-limit][BEYOND-64K] discusses approaches that could be taken to exchange hugepayloads.payloads if such a requirement were needed. 1.3. Document Organization The remainder of this document is organized as follows. Section 2 describes how multiple key exchanges are performed between two IKE peers and how keying materials are derived for both SAs and Child SAs. Section 3 discusses IANA considerations for the namespaces introduced in thisdocument, anddocument. Section 4 discusses security considerations. In theAppendices sections,Appendices, some examples of multiple key exchanges are illustrated in AppendixA,A. Appendix B summarizes design criteria anda summary ofalternative approaches that have beenconsidered, butconsidered. These approaches are later discarded,areas described in Appendix C. 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. 2. Multiple Key Exchanges 2.1. Design Overview Most post-quantum key agreement algorithms are relativelynew, and thusnew. Thus, they are not fully trusted. There are also many proposedalgorithms, withalgorithms that have different trade-offs andrelyingthat rely on different hard problems. The concern is that some of these hard problems may turn out to be easier to solve thananticipated and thusanticipated; thus, the key agreement algorithm may not be as secure as expected. A hybrid solution, when multiple key exchanges are performed and the calculated shared key depends on all of them, allows us to deal with this uncertainty by combining a classical key exchange with a post-quantum one, as well as leaving open the possibility of combining it with multiplepost-quantumpost- quantum key exchanges. In order to be able to use IKE fragmentation [RFC7383] for those key exchanges that may have long public keys, this specification utilizes the IKE_INTERMEDIATE exchange defined in [RFC9242]. The initial IKE_SA_INIT messages do not have any inherent fragmentation support withinIKE; however,IKE. However, IKE_SA_INIT messages can include a relatively short KE payload. The additional key exchanges are performed using IKE_INTERMEDIATE messages that follow the IKE_SA_INIT exchange. This is to allow the standard IKE fragmentation mechanisms (which cannot be used in IKE_SA_INIT) to be available for the potentially large Key Exchange payloads with post-quantum algorithm data. Note that this documentassumes,assumes that each key exchange method requires one round trip and consumes exactly one IKE_INTERMEDIATE exchange. This assumption is valid for all classic key exchange methods defined so far and for all post-quantum methods currently known. For hypothetical future key exchange methodsrequiringthat require multiple round trips to complete, a separate document should define how such methods are split into several IKE_INTERMEDIATE exchanges. In order to minimize communication overhead, only the key shares that are agreedto be usedupon are actually exchanged. To negotiate additional keyexchangesexchanges, seven new Transform Types are defined. These transforms and Transform Type 4 share the same Transform IDs. It is assumed that new Transform Type 4 identifiers will be assigned later for various post-quantum key exchanges [IKEV2TYPE4ID]. This specification does not make a distinction between classical (EC)DH and post-quantum key exchanges, nor between post-quantum algorithmswhichthat are true key exchangesversusand post-quantum algorithms that act as key transportmechanisms;mechanisms: all are treated equivalently by the protocol. This document renames a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method".ItThis document also renames Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method(KE)"; the(KE)". The corresponding renaming to the IANA registry is described in Section 3. The fact that newly defined transforms share the same registry for possible Transform IDs with Transform Type4,4 allows additional key exchanges to be of anytype -type: either post-quantum or classical(EC)DH one.(EC)DH. This approach allows any combination of the defined key exchange methods to take place. This also allows IKE peers to perform a single post-quantum key exchange in the IKE_SA_INIT without additional key exchanges, provided that the IP fragmentation is not an issue and that hybrid key exchange is not needed. The SA payload in the IKE_SA_INIT message includes one or more newly defined transformswhichthat represent the extra key exchange policy required by the initiator. The responder follows the usual IKEv2 negotiation rules: it selects a single transform of eachtype,type and returns all of them in the IKE_SA_INIT response message. Then, provided that additional key exchanges are negotiated, the initiator and the responder perform one or more IKE_INTERMEDIATE exchanges. Following that, the IKE_AUTH exchange authenticates peers and completes IKE SA establishment. Initiator Responder --------------------------------------------------------------------- <-- IKE_SA_INIT (additional key exchanges negotiation) --> <-- {IKE_INTERMEDIATE (additional key exchange)} --> ... <-- {IKE_INTERMEDIATE (additional key exchange)} --> <-- {IKE_AUTH} --> 2.2. Protocol Details In the simplest case, the initiator starts a single key exchange (and has no interest in supporting multiple), and it is not concerned with possible fragmentation of the IKE_SA_INIT messages(either because(because either the key exchange that it selects is small enough not tofragment,fragment or the initiator is confident that fragmentation will be handled either by IPfragmentation,fragmentation or by transport via TCP). In this case, the initiator performs the IKE_SA_INIT for a single key exchange using a Transform Type 4 (possibly with apost quantum algorithm),post-quantum algorithm) and including theinitatorinitiator KE payload. If the responder accepts the policy, it responds with an IKE_SA_INIT response, and IKE continues as usual. If the initiatordesireswants to negotiate multiple key exchanges, then the initiator uses the protocol behavior listed below. 2.2.1. IKE_SA_INIT Round: Negotiation Multiple key exchanges are negotiated using the standard IKEv2mechanism,mechanism via SA payload. For thispurposepurpose, seven new transformtypes, namelytypes are defined: Additional Key Exchange 1(with IANA(ADDKE1) with IANA- assigned value6),6, Additional Key Exchange 2 (ADDKE2) (7), Additional Key Exchange 3 (ADDKE3) (8), Additional Key Exchange 4 (ADDKE4) (9), Additional Key Exchange 5 (ADDKE5) (10), Additional Key Exchange 6(11)(ADDKE6) (11), and Additional Key Exchange 7(12) are defined.(ADDKE7) (12). They are collectively calledAdditional"Additional Key Exchangetransforms(ADDKE) Transform Types" in this document and have slightly different semantics than the existing IKEv2transform types.Transform Types. They are interpreted as an indication of additional key exchange methods that peers agree to perform in a series of IKE_INTERMEDIATE exchanges following the IKE_SA_INIT exchange. The allowedtransformTransform IDs for these transform types are the same as the IDs for Transform Type 4, so they all share a single IANA registry fortransformTransform IDs.KeyThe key exchange method negotiated via Transform Type 4 always takes place in the IKE_SA_INIT exchange, as defined in [RFC7296]. Additional key exchanges negotiated via newly defined transforms MUST take place in a series of IKE_INTERMEDIATE exchanges following the IKE_SA_INIT exchange, performed in an order of the values of theirtransform types,Transform Types. This is so that the key exchange negotiated using Additional Key Exchange i always precedes that of Additional Key Exchange i + 1. Each additional key exchange method MUST be fully completed before the next one is started.Note that withWith these semantics,Additional Key Exchange transformsnote that ADDKE Transform Types are not associated with any particular type of key exchange and do not have any Transform IDs that are specific pertransform type transform IDsTransform Type IANA registry.InsteadInstead, they all share a single registry fortransformTransform IDs, namely"Key"Transform Type 4 - Key Exchange Method TransformIDs", which are also shared by Transform Type 4.IDs". All key exchange algorithms (both classical or post-quantum) should be added to this registry. This approach gives peers flexibility in defining the ways they want to combine different key exchange methods. When forming aproposalproposal, the initiator adds transforms for the IKE_SA_INIT exchange using Transform Type 4. In mostcasescases, they will contain classical (EC)DH key exchange methods,however itbut that is not a requirement. Additional key exchange methods are proposed usingAdditional Key Exchange transform types.ADDKE Transform Types. All of these transform types areoptional,optional; the initiator is free to select any of them for proposing additional key exchange methods. Consequently, if none of theAdditional Key Exchange transforms isADDKE Transform Types are included in the proposal, then this proposal indicates the performing of standard IKEv2, as defined in [RFC7296]. On the other hand, if the initiator includes anyAdditional Key Exchange transformADDKE Transform Type in the proposal, the responder MUST select one of the algorithms proposed using this type. Note that this is not a newrequirement, but thatrequirement; this behavior is already specified in Section 2.7 of [RFC7296]. AtransformTransform ID NONE MAY be added to those transform typeswhichthat contain key exchange methodsthatwhich the initiator believesisare optional according to its local policy. The responder performs the negotiation using the standard IKEv2 procedure described in Section 3.3 of [RFC7296]. However, for theAdditional Key Exchange types,ADDKE Transform Types, the responder's choice MUST NOT contain duplicated algorithms (those with an identical Transform ID and attributes), except for thetransformTransform ID of NONE. An algorithm is represented as atransform, intransform. In somecasescases, the transform could include a set of associated attributes that define details of the algorithm. In this case, two transforms can be the same, but the attributes must be different. Additionally, the order of the attributes does not affect the equality of the algorithm, so the following two transforms(ID=alg1,ATTR1=attr1,ATTR2=attr2) and (ID=alg1,ATTR2=attr2,ATTR1=attr1)define the samealgorithm.algorithm: "ID=alg1, ATTR1=attr1, ATTR2=attr2" and "ID=alg1, ATTR2=attr2, ATTR1=attr1". If the responder is unable to selectnon-duplicated algorithmalgorithms that are not duplicated for each proposed key exchange (either because the proposal contains too few choices or due to the local policy restrictions on using the proposed algorithms), then the responder MUST reject the message with an error notification of type NO_PROPOSAL_CHOSEN. If the responder's message contains one or more duplicated choices, the initiator should log the error and MUST treat the exchange as failed. The initiator MUST NOT initiate any IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE)exchanges,exchanges so that no new SA is created. If this happens in the CREATE_CHILD_SA exchange, then the initiator MAY delete the IKESA,SA over which the invalid message wasreceived,received by sending a Delete payload. If the responder selects NONE for someAdditional Key Exchange typesADDKE Transform Types (provided they are proposed by the initiator), thentheany correspondingAdditional Key Exchange(s) in the IKE_INTERMEDIATE exchange(s)additional key exchanges MUST NOT take place.ThereforeTherefore, if the initiator includes NONE in all of theAdditional Key Exchange transformsADDKE Transform Types and the responder selects this value for all of them, then no IKE_INTERMEDIATEmessagesexchanges performing additional key exchanges will take place between the peers. Note that the IKE_INTERMEDIATE exchanges may still take place for other purposes. The initiator MAY proposenon-consecutive Additional Key Exchange transforms,ADDKE Transform Types that are not consecutive, forexampleexample, proposingAdditional Key Exchange 2ADDKE2 andAdditional Key Exchange 5 transformsADDKE5 Transform Types only. The responder MUST treat all of the omittedAdditional Key ExchangeADDKE transforms as if theyarewere proposed with Transform ID NONE. Below is an example of the SA payload in the initiator's IKE_SA_INIT request message.HereHere, the abbreviationAKEi"KE" is usedto denote the i-th Additional Key Exchange transform defined in this document, and an abbreviation KEfor the Key Exchange transform,thatwhich this document renames from theDiffie-HellmanDiffie- Hellman Group transform. Additionally, the notations PQ_KEM_1,PQ_KEM_2PQ_KEM_2, and PQ_KEM_3 are used to representsome not-yet definedTransform IDs that have yet to be defined of some popular post-quantum key exchange methods. SA Payload | +--- Proposal #1 ( Proto ID = IKE(1), SPIsizeSize = 8, | 9 transforms, SPI = 0x35a1d6f22564f89d ) | +-- Transform ENCR ( ID = ENCR_AES_GCM_16 ) | +-- Attribute ( Key Length = 256 ) | +-- Transform KE ( ID = 4096-bit MODP Group ) | +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 ) | +-- TransformAKE2ADDKE2 ( ID = PQ_KEM_1 ) | +-- TransformAKE2ADDKE2 ( ID = PQ_KEM_2 ) | +-- TransformAKE3ADDKE3 ( ID = PQ_KEM_1 ) | +-- TransformAKE3ADDKE3 ( ID = PQ_KEM_2 ) | +-- TransformAKE5ADDKE5 ( ID = PQ_KEM_3 ) | +-- TransformAKE5ADDKE5 ( ID = NONE ) In this example, the initiator proposesto performperforming the initial key exchange using a 4096-bit MODPgroupGroup followed by two mandatory additional key exchanges(i.e. Transforms AKE2(i.e., ADDKE2 andAKE3)ADDKE3 Transform Types) using PQ_KEM_1 and PQ_KEM_2 methods in anyorder, thenorder followed by an additional key exchange(i.e.(i.e., ADDKE5 TransformAKE5)Type) using the PQ_KEM_3 method that may be omitted. The responder might return the following SA payload, indicating that it agrees to perform two additional keyexchangesexchanges, PQ_KEM_2 followed byPQ_KEM_1PQ_KEM_1, and that it does not want to additionally performPQ_KEM_3 additionally.PQ_KEM_3. SA Payload | +--- Proposal #1 ( Proto ID = IKE(1), SPIsizeSize = 8, | 6 transforms, SPI = 0x8df52b331a196e7b ) | +-- Transform ENCR ( ID = ENCR_AES_GCM_16 ) | +-- Attribute ( Key Length = 256 ) | +-- Transform KE ( ID = 4096-bit MODP Group ) | +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 ) | +-- TransformAKE2ADDKE2 ( ID = PQ_KEM_2 ) | +-- TransformAKE3ADDKE3 ( ID = PQ_KEM_1 ) | +-- TransformAKE5ADDKE5 ( ID = NONE ) If the initiator includes anyAdditional Key Exchange transform typesADDKE Transform Types into the SA payload in the IKE_SA_INIT exchange request message, then it MUST also negotiate the use of the IKE_INTERMEDIATEexchangeexchange, as described in[RFC9242],[RFC9242] by including an INTERMEDIATE_EXCHANGE_SUPPORTED notification in the same message. If the responder agrees to use additional key exchanges while establishing an initial IKE SA, it MUST also return this notification in the IKE_SA_INIT response message,thusconfirming that IKE_INTERMEDIATE exchange is supported and will be used for transferring additional key exchange data. If the IKE_INTERMEDIATE exchange is not negotiated, then the peers MUST treat anyAdditional Key Exchange transformsADDKE Transform Types in the IKE_SA_INIT exchange messages as unknown transform types and skip the proposals they appear in. If no other proposals are present in the SA payload, the peers will proceed as if no proposalishas been chosen(i.e.(i.e., the responder will send a NO_PROPOSAL_CHOSEN notification). Initiator Responder --------------------------------------------------------------------- HDR, SAi1(..AKE*...),ADDKE*...), KEi, Ni, N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> HDR, SAr1(..AKE*...),ADDKE*...), KEr, Nr, [CERTREQ], <--- N(INTERMEDIATE_EXCHANGE_SUPPORTED) It is possiblethatfor an attackermanagesto manage to send a response to the initiator's IKE_SA_INIT request before the legitimate responder does. If the initiator continues to create the IKE SA using this response, the attempt will fail. Implementers may wish to considera possible defense techniquestrategies as described in Section 2.4 of[RFC7296].[RFC7296] to handle such an attack. 2.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges For each additional key exchange agreed to in the IKE_SA_INIT exchange, the initiator and the responder perform an IKE_INTERMEDIATE exchange, as described in [RFC9242]. Initiator Responder --------------------------------------------------------------------- HDR, SK {KEi(n)} --> <-- HDR, SK {KEr(n)} The initiator sends key exchange data in the KEi(n) payload. This message is protected with the current SK_ei/SK_ai keys. The notationKEi(n)"KEi(n)" denotes the n-th IKE_INTERMEDIATE KE payload from theinitiator andinitiator; the integern"n" is sequential starting from 1. On receiving this, the responder sends back key exchange payloadKEr(n), whichKEr(n); "KEr(n)" denotes the n-th IKE_INTERMEDIATE KE payload from the responder.As before,Similar to how the request is protected, this message is protected with the current SK_er/SK_ar keys. The former "Diffie-Hellman Group Num" (now called "Key Exchange Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th negotiated additional key exchange. Once this exchange is done, both sides compute an updated keying material: SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)whereFrom this exchange, SK(n) is the resulting sharedsecret of this key exchange,secret. Ni and Nr are nonces from the IKE_SA_INITexchange andexchange. SK_d(n-1) is the last generatedSK_d,SK_d (derived from IKE_SA_INIT for the first use ofIKE_INTERMEDIATE, otherwiseIKE_INTERMEDIATE and, otherwise, from the previous IKE_INTERMEDIATE exchange). The other keyingmaterialsmaterials, SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi,SK_prand SK_pr, are generated from the SKEYSEED(n) as follows: {SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) | SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr) Both the initiator and the responder use these updated key values in the next exchange (IKE_INTERMEDIATE or IKE_AUTH). 2.2.3. IKE_AUTH Exchange After all IKE_INTERMEDIATE exchanges have completed, the initiator and the responder perform an IKE_AUTH exchange. This exchange is the standard IKEexchangeexchange, as described in[RFC7296][RFC7296], with the modification of AUTH payload calculation described in [RFC9242]. 2.2.4. CREATE_CHILD_SA Exchange The CREATE_CHILD_SA exchange is used in IKEv2 for the purposes of creating additional Child SAs, rekeying these Child SAs, and rekeying IKE SA itself. When creating or rekeying Child SAs, the peers may optionally perform a key exchange to add a fresh entropy into the session keys. In the case of an IKE SA rekey, the key exchange is mandatory. Peers supporting this specification may want to use multiple key exchanges in these situations. Using multiple key exchanges with a CREATE_CHILD_SA exchange is negotiatedsimilarly asin a similar fashion to the initial IKE exchange, see Section 2.2.1. If the initiator includes anyAdditional Key Exchange transformADDKE Transform Types in the SA payload (along with Transform Type4)4), and if the responder agrees to perform additional key exchanges, then the additional key exchanges are performed in a series of new IKE_FOLLOWUP_KE exchanges thatfollowsfollow the CREATE_CHILD_SA exchange. The IKE_FOLLOWUP_KE exchange is introducedas a dedicated exchangeespecially for transferring data of additional key exchanges following thekey exchangeone performed in the CREATE_CHILD_SA. Its Exchange Type value is 44.KeyThe key exchange negotiated via Transform Type 4 always takes place in the CREATE_CHILD_SA exchange, as per the IKEv2specification.specification [RFC7296]. Additional key exchanges are performed in an order of the values of theirtransform types,Transform Types so that the key exchange negotiated usingTransform Type nAdditional Key Exchange i always precedes the key exchange negotiated usingTransform Type nAdditional Key Exchange i + 1. Each additional key exchange method MUST be fully completed before the next one is started.Note,Note that this documentassumes,assumes that each key exchange method consumes exactly one IKE_FOLLOWUP_KE exchange. For the methodsrequiringthat require multiple round trips, a separate document should define how such methods are split into several IKE_FOLLOWUP_KE exchanges. After an IKE SA iscreatedcreated, the window size may be greater thanone andone; thus, multiple concurrent exchanges may be inprogress,progress. Therefore, it is essential to link the IKE_FOLLOWUP_KE exchanges together with the corresponding CREATE_CHILD_SA exchange.Due to the fact that onceOnce an IKE SA is created, all IKE exchanges are independent anddo notIKEv2 doesn't have a built-inmeansmechanism to linkonean exchange withanother, aanother one. A new status type notificationADDITIONAL_KEY_EXCHANGEcalled "ADDITIONAL_KEY_EXCHANGE" is introduced for this purpose. Its Notify Message Type value is 16441, and the Protocol ID and SPI Size are both set to 0. The data associated with this notification is a blob meaningful only to theresponder,responder so that the responder can correctly link successive exchanges. For theinitiatorinitiator, the content of this notification is an opaque blob. The responder MUST include this notification in a CREATE_CHILD_SA or IKE_FOLLOWUP_KE response message in case the next IKE_FOLLOWUP_KE exchange is expected, filling it with some data that would allow linking the current exchange to the next one. The initiator MUST send back this notification intact in the request message of the next IKE_FOLLOWUP_KE exchange. Below is an example of CREATE_CHILD_SA exchange followed by three additional key exchanges. Initiator Responder --------------------------------------------------------------------- HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, N(ADDITIONAL_KEY_EXCHANGE)(link1)} HDR(IKE_FOLLOWUP_KE), SK {KEi(1), N(ADDITIONAL_KEY_EXCHANGE)(link1)} --> <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1), N(ADDITIONAL_KEY_EXCHANGE)(link2)} HDR(IKE_FOLLOWUP_KE), SK {KEi(2), N(ADDITIONAL_KEY_EXCHANGE)(link2)} --> <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2), N(ADDITIONAL_KEY_EXCHANGE)(link3)} HDR(IKE_FOLLOWUP_KE), SK {KEi(3), N(ADDITIONAL_KEY_EXCHANGE)(link3)} --> <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(3)} The former "Diffie-Hellman Group Num" (now called "Key Exchange Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th negotiated additional key exchange.It is possible that dueDue to some unexpected events(e.g. reboot)(e.g., a reboot), it is possible that the initiator may lose itsstate andstate, forget that it is in the process of performing additional keyexchangesexchanges, andthusnever start the remaining IKE_FOLLOWUP_KE exchanges. The responder MUST handle this situation gracefully and delete the associated state if it does not receive the next expected IKE_FOLLOWUP_KE request after some reasonable period of time.Note that dueDue to various factors such as computational resource and key exchange algorithm used, note that it is not possible to giveanormative guidance on how long this timeout period should be. In general, 5-20 seconds of waiting time should be appropriate in most cases. Itis also possible that the initiatormay also take too long for the initiator to prepare and to send the next IKE_FOLLOWUP_KErequest orrequest, or, due to the network conditions, the requestiscould be lost and retransmitted. In this case, the message may reach the responder when it has already deleted the associatedstatestate, following the advice above. If the responder receives an IKE_FOLLOWUP_KE message for which it does not have a key exchange state, it MUST send back a new error type notificationSTATE_NOT_FOUND.called "STATE_NOT_FOUND". This isa non-fatalan errornotification, itsnotification that is not fatal to the IKE SA. Its Notify Message Type value is 47, its Protocol ID and SPI Size are both set to00, and the data is empty. If the initiator receives this notification in response to an IKE_FOLLOWUP_KE exchange performing an additional key exchange, it MUST cancel this exchange and MUST treat the whole series of exchanges started from the CREATE_CHILD_SA exchange as having failed. In most cases, the receipt of this notification is caused by the premature deletion of the corresponding state on the responder (the time period between IKE_FOLLOWUP_KE exchanges appeared to be too long from the responder's point of view,e.g.e.g., due to a temporary network failure). After receiving thisnotificationnotification, the initiator MAY start a new CREATE_CHILD_SAexchangeexchange, which may eventually be followed by the IKE_FOLLOWUP_KE exchanges, to retry the failed attempt. If the initiator continues to receive STATE_NOT_FOUND notifications after several retries, it MUST treat this situation as a fatal error and delete the IKE SA by sending a DELETE payload.WhenIt is possible that the peers start rekeying the IKE SA or the ChildSA, it is possible that the peers start doing thisSA at the same time, which is calledsimultaneous rekeying."simultaneous rekeying". Sections 2.8.1 and 2.8.2 of [RFC7296] describe how IKEv2 handles this situation. In anutshellnutshell, IKEv2 follows the rulethat ifthat, in the case of simultaneous rekeying, if two identical new IKE SAs (or two pairs of Child SAs) are created, then one of them should be deleted. Which oneistobe deleteddelete is determined by comparing the values of four nonces that are used in the colliding CREATE_CHILD_SA exchanges. The IKE SA (or pair of Child SAs)that iscreated by the exchange in which the smallest nonce is used should be deleted by the initiator of this exchange. With multiple key exchanges, the SAs are not yet created when the CREATE_CHILD_SA iscompleted,completed. Instead, they would be created only after the series of IKE_FOLLOWUP_KE exchanges is finished. For this reason, if additional key exchanges are negotiated in the CREATE_CHILD_SA exchange in which the smallest nonce is used,thenthen, because there is nothing to delete yet, the initiator of this exchange just stops the rekeyingprocessprocess, and it MUST NOT initiate the IKE_FOLLOWUP_KE exchange. In most cases, rekey collisions are resolved in the CREATE_CHILD_SA exchange. However, a situation may occurwhenwhen, due to packet loss, one of the peers receives the CREATE_CHILD_SA message requesting the rekey of an SA that is already being rekeyed by this peer(i.e.(i.e., the CREATE_CHILD_SA exchange initiated by this peer hasbeenalreadycompletedbeen completed, and the series of IKE_FOLLOWUP_KE exchanges is in progress). In this case, a TEMPORARY_FAILURE notification MUST be sent in response to such a request. If multiple key exchanges are negotiated in the CREATE_CHILD_SA exchange, then the resulting keys are computed as follows. In the case of an IKE SA rekey: SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)) In the case of a Child SA creation or rekey: KEYMAT = prf+ (SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)) In both cases, SK_d is from the existing IKE SA; SK(0), Ni, and Nr are the shared key and nonces from theCREATE_CHILD_SACREATE_CHILD_SA, respectively; SK(1)...SK(n) are the shared keys from additional key exchanges. 2.2.5. Interaction with IKEv2 Extensions It is believed that this specification requires no modification to the IKEv2 extensions defined so far. In particular, the IKE SA resumption mechanism defined in [RFC5723] can be used to resume IKE SAs created using this specification. 2.2.5.1. Interaction with Childless IKE SA It is possible to establish IKE SAs with post-quantum algorithms by only usingadditional key exchanges, butIKE_FOLLOWUP_KE exchanges and withoutusingthe use of IKE_INTERMEDIATE exchanges. In this case, the IKE SA that is created from the IKE_SA_INITexchangeexchange, can be immediately rekeyed with CREATE_CHILD_SAusingwith additional keyexchangesexchanges, where IKE_FOLLOWUP_KE messages are usedto carry thefor these additional keyexchange payload.exchanges. If the classical key exchange method is used in the IKE_SA_INIT message, the very first Child SA created in IKE_AUTH will offer no resistance against the quantum threats. Consequently, if the peers' local policy requiresthatall Child SAs to be post-quantum secure, then the peers can avoid creating the very first Child SA by adopting [RFC6023]. In this case, the initiator sends two types ofproposalproposals in the IKE_SA_INITrequest,request: one with and another one withoutAdditional Key Exchange transform(s).ADDKE Transform Types. The responder chooses the latter proposal type and includes a CHILDLESS_IKEV2_SUPPORTED notification in the IKE_SA_INIT response. Assuming that the initiator supports childless IKE SA extension,thenboth peersperformsperform the modified IKE_AUTH exchange described in[RFC6023][RFC6023], and no Child SA is created in this exchange. The peers should then immediately rekey the IKE SA and subsequently create the Child SAs, all with additional key exchanges using a CREATE_CHILD_SA exchange. It is also possible for the initiator to send proposals withoutAdditional Key Exchange transform(s)any ADDKE Transform Types in the IKE_SA_INITmessage and inmessage. In this instance, the responder will have no information about whether or not the initiator supports the extension in this specification. This may not beefficientefficient, as the responder will have to wait for the subsequent CREATE_CHILD_SA request to determine whether or not the initiator's request is appropriate for its local policy. The support for childless IKE SA is not negotiated, but it is the responder that indicates the support for this mode. As such, the responder cannot enforce that the initiatortouse thismode and therefore,mode. Therefore, it is entirely possible that the initiator does not support this extension and sends IKE_AUTH request as per [RFC7296] instead of [RFC6023]. In this case, the responder may respond withnon-fatalan error that is not fatal, such as the NO_PROPOSAL_CHOSEN notify message type. Note that if the initial IKE SA is used to transfer sensitive information, then this information will not be protected using the additional key exchanges, which may use post-quantum algorithms. In this arrangement, the peers will have to use post-quantum algorithm in Transform Type 4 in order to mitigate the risk of quantum attack. 3. IANA Considerations This document adds a new exchange type into the "IKEv2 Exchange Types" registry: 44 IKE_FOLLOWUP_KE This document renames Transform Type 4 defined in the "Transform Type Values" registry from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)". This document renames the IKEv2 registry originally titled "Transform Type 4 -Diffie- HellmanDiffie-Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". This document adds the following Transform Types to the "Transform Type Values" registry: +======+====================================+===============+ | Type | Description | Used In-----------------------------------------------------------------| +======+====================================+===============+ | 6 | Additional Key Exchange 1 (ADDKE1) | (optional in | | | | IKE, AH, ESP) | +------+------------------------------------+---------------+ | 7 | Additional Key Exchange 2 (ADDKE2) | (optional in | | | | IKE, AH, ESP) | +------+------------------------------------+---------------+ | 8 | Additional Key Exchange 3 (ADDKE3) | (optional in | | | | IKE, AH, ESP) | +------+------------------------------------+---------------+ | 9 | Additional Key Exchange 4 (ADDKE4) | (optional in | | | | IKE, AH, ESP) | +------+------------------------------------+---------------+ | 10 | Additional Key Exchange 5 (ADDKE5) | (optional in | | | | IKE, AH, ESP) | +------+------------------------------------+---------------+ | 11 | Additional Key Exchange 6 (ADDKE6) | (optional in | | | | IKE, AH, ESP) | +------+------------------------------------+---------------+ | 12 | Additional Key Exchange 7 (ADDKE7) | (optional in | | | | IKE, AH, ESP) | +------+------------------------------------+---------------+ Table 1: "Transform Type Values" Registry This document defines a new Notify Message Type in the"Notify"IKEv2 Notify Message Types - Status Types" registry: 16441 ADDITIONAL_KEY_EXCHANGEandThis document also defines a new Notify Message Type in the"Notify"IKEv2 Notify Message Types - Error Types" registry: 47 STATE_NOT_FOUND3.1. Additional Considerations and Changes TheIANAis requested to addhas added the following instructions for designated experts forTransformthe "Transform Type 4sub-registry.- Key Exchange Method Transform IDs" subregistry: * While adding newKEKey Exchange (KE) methods, the following considerations must be applied. A KE method must take exactly one round-trip (oneIKE exchange)IKEv2 exchange), and at the end of this exchange, both peers must be able to derive the shared secret. In addition, any public value that peers exchanged during a KE method must fit into a singleIKE message.IKEv2 payload. If these restrictions are not met for a KE method, then there must be documentation on how this KE method is used in IKEv2.The following changes toIANAarehas alsorequested.completed the following changes. It is assumed thatRFCXXXX[RFC9370] refers to this specification. *AddAdded a reference toRFCXXXX[RFC9370] in what was the "Transform Type 4 -Diffie- HellmanDiffie-Hellman Group Transform IDs" registry. *ReplaceReplaced thenoteNote on what was the "Transform Type 4 -Diffie-HellmanDiffie- Hellman Group Transform IDs" registrywith:with the following notes: This registry was originally named "Transform Type 4 -Diffie-HellmanDiffie- Hellman Group Transform IDs" and wasrenamed to its current name by [RFCXXXX]. It has beenreferencedin its originalusing that name in a number of RFCs published prior to[RFCXXXX].[RFC9370], which gave it the current title. This registry is used by the "Key Exchange Method (KE)" transform type and by all "Additional Key Exchange (ADDKE)" transform types. To find out requirement levels for Key Exchange Methods for IKEv2, see [RFC8247]. *Add this noteAppended [RFC9370] to the Reference column of Transform Type 4 in the "Transform Type Values"registry: Transform Typeregistry. * Added these notes to the "Transform Type4 - KeyValues" registry: "Key Exchange MethodTransform IDs"(KE)" transform type was originally named"Transform Type 4 - Diffie-Hellman"Diffie-Hellman GroupTransform IDs"(D-H)" and wasrenamed to its current name by [RFCXXXX]. It has beenreferencedin its originalby that name in a number of RFCs published prior to[RFCXXXX].[RFC9370], which gave it the current title. All "Additional KeyExchange"Exchange (ADDKE)" entries use the same "Transform Type 4 - Key Exchange Method Transform IDs" registry as the "Key Exchange Method(KE)". * Append RFCXXXX to the Reference column of Transform Type 4 in the Transform Type Values registry. * Append this note to "Transform Type 4 - Diffie-Hellman Group Transform IDs" registry: All "Additional Key Exchange" entries use these values as the "Key Exchange Method (KE)".(KE)" entry. 4. Security Considerations The extension in this document is intended to mitigate two possible threats inIKEv2, namelyIKEv2: the compromise of (EC)DH key exchange using Shor's algorithm while remaining backwardcompatible;compatible and the potential compromise of existing or future PQC key exchange algorithms. To address the former threat, this extension allows the establishment of a shared secret by using multiple keyexchanges, typicallyexchanges: typically, one classical (EC)DH and the other one post-quantum algorithm. In order to address the latter threat, multiple key exchanges using apost-quantumpost- quantum algorithm can becomposedperformed to form the shared key. Unlike key exchange methods (Transform Type 4), the Encryption Algorithm (Transform Type 1), the Pseudorandom Function (Transform Type2)2), and the Integrity Algorithm (Transform Type 3) are not susceptible to Shor's algorithm. However, they are susceptible to Grover's attack [GROVER], which allows a quantum computer to perform a brute force keysearchsearch, using quadratically fewer steps than the classical counterpart. Simply increasing the key length can mitigate this attack. It was previously believed that one needed to double the key length of these algorithms. However, there are a number of factors that suggest that it is quite unlikely to achieve the quadraticspeed upspeedup using Grover's algorithm. According to NIST [NISTPQCFAQ], current applications can continue using an AES algorithm with the minimum key length of 128bit.bits. Nevertheless, if the data needs to remain secure for many years to come, one may want to consider using a longer key size for the algorithms in Transform Types 1-3. SKEYSEED is calculated from sharedSK(x)SK(x), using an algorithm defined in Transform Type 2. While a quantum attacker may learn the value of SK(x), if this value is obtained by means of a classical key exchange, other SK(x) values generated by means of a post-quantum algorithm ensure that the final SKEYSEED is not compromised. This assumes that the algorithm defined in the Transform Type 2 is quantum resistant. The ordering of the additional key exchanges should not matter in general, as only the final shared secret is of interest. Nonetheless, because the strength of the running shared secret increases with every additional key exchange, an implementer may want to first perform the most secure method (in some metrics)andfollowed by less secureone(s).methods. The main focus of this document is to prevent a passive attacker from performing a"harvest and decrypt" attack. In"harvest-and-decrypt" attack: in other words,an attackerattackers thatrecordsrecord messages exchanged today andproceedsproceed to decrypt them oncehe owns athey have access to cryptographically relevant quantumcomputer.computers. This attack is prevented due to the hybrid nature of the key exchange. Other attacks involving an active attacker using a quantum-computer are not completely solved by this document. This is for tworeasons.reasons: * The first reason isbecausethat the authentication step remains classical. In particular, the authenticity of the SAs established under IKEv2 is protected by using a pre-shared key or digital signature algorithms.WhilstWhile the pre-shared key option, provided the key is long enough, is post-quantum secure, the other algorithms are not. Moreover, in implementations where scalability is a requirement, the pre-shared key method may not be suitable. Post-quantum authenticity may be provided by using a post-quantum digital signature. * Secondly, it should be noted that the purpose of post-quantum algorithms is to provide resistance to attacks mounted in the future. The current threat is that encrypted sessions are subject to eavesdropping and are archived with decryption by quantum computerstaking placeat some point in the future. Until quantum computers becomeavailableavailable, there is no point in attacking the authenticity of a connection because there are no possibilities for exploitation. These only occur at the time of the connection, forexampleexample, by mounting an on-path attack.ConsequentlyConsequently, there is less urgency for post-quantum authenticity compared topost-quantumpost- quantum confidentiality. Performing multiple key exchanges while establishing an IKE SA increases the responder's susceptibility to DoSattacks,attacks because of an increased amount of resources needed before the initiator is authenticated. This is especially true for post-quantum key exchange methods, where many of them are more memory and/or CPU intensive than the classical counterparts. Responders may consider recommendations from [RFC8019] to deal with increasedDoS attackDoS-attack susceptibility. It is also possible that the responder only agrees to create an initial IKE SA without performing additional keyexchanges, providedexchanges if the initiator includes such an option in its proposals.ThenThen, peers immediately rekey the initial IKE SA with the CREATE_CHILD_SAexchangeexchange, and additional key exchanges are performed via the IKE_FOLLOWUP_KE exchanges. In this case, at the point when resource-intensive operations are required, the peers have already authenticated each other. However, in the context of hybrid post-quantum keyexchangeexchanges, this scenario would leave the initial IKE SA (and initial ChildSASA, if it is created) unprotected against quantum computers.NeverthelessNevertheless, the rekeyed IKE SA (and Child SAs that will be created over it) will have a full protection. This is similar to the scenario described in [RFC8784]. Depending on the arrangement and peers' policy, this scenario may or may not be appropriate. For example, in the G-IKEv2 protocol[I-D.ietf-ipsecme-g-ikev2][G-IKEV2], the cryptographic materials are sent from the group controller to the group members when the initial IKE SA is created. 5. References 5.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, <https://www.rfc-editor.org/info/rfc2119>. [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, <https://www.rfc-editor.org/info/rfc7296>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9242, DOI 10.17487/RFC9242, May 2022, <https://www.rfc-editor.org/info/rfc9242>. 5.2. Informative References[GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for Database Search", Proc. of the Twenty-Eighth Annual ACM Symposium on the Theory of Computing (STOC 1996), 1996. [I-D.ietf-ipsecme-g-ikev2] Smyslov, V. and B. Weis, "Group Key Management using IKEv2", Work in Progress, Internet-Draft, draft-ietf- ipsecme-g-ikev2-07, 6 October 2022, <https://www.ietf.org/archive/id/draft-ietf-ipsecme- g-ikev2-07.txt>. [I-D.tjhai-ikev2-beyond-64k-limit][BEYOND-64K] Tjhai,C.,CJ., Heider, T., and V. Smyslov, "Beyond 64KB Limit of IKEv2 Payloads", Work in Progress, Internet-Draft, draft-tjhai-ikev2-beyond-64k-limit-03, 28 July 2022,<https://www.ietf.org/archive/id/draft-tjhai-ikev2-beyond- 64k-limit-03.txt>.<https://datatracker.ietf.org/doc/html/draft-tjhai-ikev2- beyond-64k-limit-03>. [G-IKEV2] Smyslov, V. and B. Weis, "Group Key Management using IKEv2", Work in Progress, Internet-Draft, draft-ietf- ipsecme-g-ikev2-09, 19 April 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme- g-ikev2-09>. [GROVER] Grover, L., "A fast quantum mechanical algorithm for database search", Proc. of the Twenty-Eighth Annual ACM Symposium on the Theory of Computing (STOC), pp. 212-219, DOI 10.48550/arXiv.quant-ph/9605043, May 1996, <https://doi.org/10.48550/arXiv.quant-ph/9605043>. [IKEV2TYPE4ID] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters: Transform Type 4 - Diffie-Hellman Group Transform IDs",<https://www.iana.org/assignments/ikev2-parameters/ ikev2-parameters.xhtml#ikev2-parameters-8>.<https://www.iana.org/assignments/ikev2-parameters/>. [NISTPQCFAQ] NIST, "Post-Quantum CryptographyStandardization: FAQs",Standard", January 2023, <https://csrc.nist.gov/Projects/post-quantum-cryptography/ faqs>. [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, DOI 10.17487/RFC5723, January 2010, <https://www.rfc-editor.org/info/rfc5723>. [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)", RFC 6023, DOI 10.17487/RFC6023, October 2010, <https://www.rfc-editor.org/info/rfc6023>. [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, <https://www.rfc-editor.org/info/rfc7383>. [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks", RFC 8019, DOI 10.17487/RFC8019, November 2016, <https://www.rfc-editor.org/info/rfc8019>. [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, "Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 8247, DOI 10.17487/RFC8247, September 2017, <https://www.rfc-editor.org/info/rfc8247>. [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, "Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security", RFC 8784, DOI 10.17487/RFC8784, June 2020, <https://www.rfc-editor.org/info/rfc8784>. Appendix A. Sample Multiple Key Exchanges This appendix shows some examples of multiple key exchanges. These examples arenon-normativenot normative, and they describe some message flow scenarios that may occur in establishing an IKE orCHILDChild SA. Note that some payloads that are not relevant to multiple key exchanges may be omitted for brevity. A.1. IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange Payloads The exchanges below show that the initiator proposes the use of additional key exchanges to establish an IKE SA. The initiator proposes three sets of additional keyexchanges andexchanges, all of which are optional.SoTherefore, 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(..AKE*...),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) TransformAKE1ADDKE1 (ID = PQ_KEM_1) TransformAKE1ADDKE1 (ID = PQ_KEM_2) TransformAKE1ADDKE1 (ID = NONE) TransformAKE2ADDKE2 (ID = PQ_KEM_3) TransformAKE2ADDKE2 (ID = PQ_KEM_4) TransformAKE2ADDKE2 (ID = NONE) TransformAKE3ADDKE3 (ID = PQ_KEM_5) TransformAKE3ADDKE3 (ID = PQ_KEM_6) TransformAKE3ADDKE3 (ID = NONE) <--- HDR(IKE_SA_INIT), SAr1(..AKE*...),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) TransformAKE1ADDKE1 (ID = PQ_KEM_2) TransformAKE2ADDKE2 (ID = NONE) TransformAKE3ADDKE3 (ID = PQ_KEM_5) HDR(IKE_INTERMEDIATE), SK {KEi(1)(PQ_KEM_2)} --> <--- HDR(IKE_INTERMEDIATE), SK {KEr(1)(PQ_KEM_2)} HDR(IKE_INTERMEDIATE), SK {KEi(2)(PQ_KEM_5)} --> <--- HDR(IKE_INTERMEDIATE), SK {KEr(2)(PQ_KEM_5)} HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } ---> <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2, TSi, TSr } In this particular example, the responder chooses to perform two additional key exchanges. It selects PQ_KEM_2,NONENONE, and PQ_KEM_5 for the first,secondsecond, and third additional keyexchangesexchanges, respectively. As per[RFC7296] specification,[RFC7296], a set of keying materialsareis derived, in particular SK_d, SK_a[i/r], and SK_e[i/r]. Both peers then perform an IKE_INTERMEDIATEexchangeexchange, carrying PQ_KEM_2payloadpayload, 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 PQ_KEM_2 shared secret, as follows. SKEYSEED(1) = prf(SK_d, SK(1) | Ni | Nr) The updated SKEYSEED value is then used to derive the following keyingmaterialsmaterials. {SK_d(1) | SK_ai(1) | SK_ar(1) | SK_ei(1) | SK_er(1) | SK_pi(1) | SK_pr(1)} = prf+ (SKEYSEED(1), Ni | Nr | SPIi | SPIr) As per[RFC9242] specification,[RFC9242], both peers compute IntAuth_i1 and IntAuth_r1 using the SK_pi(1) and SK_pr(1)keyskeys, respectively. These values are required in the IKE_AUTH phase of the exchange. In the next IKE_INTERMEDIATE exchange, the peers use SK_e[i/r](1) and SK_a[i/r](1) keys to protect the PQ_KEM_5 payload. After completing this exchange, keying materials are updated asbelowfollows: SKEYSEED(2) = prf(SK_d(1), SK(2) | Ni | Nr) {SK_d(2) | SK_ai(2) | SK_ar(2) | SK_ei(2) | SK_er(2) | SK_pi(2) | SK_pr(2)} = prf+ (SKEYSEED(2), Ni | Nr | SPIi | SPIr)whereIn this update, SK(2) is the shared secret from the third additional key exchange,i.e.i.e., PQ_KEM_5.BothThen, both peersthencompute the values of IntAuth_[i/r]2 using the SK_p[i/r](2) keys. After the completion of the second IKE_INTERMEDIATE exchange, both peers continue to the IKE_AUTH exchange phase. As defined in [RFC9242], the values IntAuth_[i/r]2 are used to computeIntAuth whichIntAuth, which, inturnturn, is used to calculatethe payload to be signed or MACed, i.e.InitiatorSignedOctets andResponderSignedOctets.ResponderSignedOctets blobs (see Section 3.3.2 of [RFC9242]). A.2. No Additional Key Exchange Used The initiator proposes two sets of optional additional key exchanges, but the responder does not support any of them. The responder chooses NONE for eachset and consequently,set. Consequently, the IKE_INTERMEDIATE exchange does nottakes placetake place, and the exchange proceeds to the IKE_AUTH phase. The resulting keying materials are the same as those derived with [RFC7296]. Initiator Responder --------------------------------------------------------------------- HDR(IKE_SA_INIT), SAi1(..AKE*...),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) TransformAKE1ADDKE1 (ID = PQ_KEM_1) TransformAKE1ADDKE1 (ID = PQ_KEM_2) TransformAKE1ADDKE1 (ID = NONE) TransformAKE2ADDKE2 (ID = PQ_KEM_3) TransformAKE2ADDKE2 (ID = PQ_KEM_4) TransformAKE2ADDKE2 (ID = NONE) <--- HDR(IKE_SA_INIT), SAr1(..AKE*...),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) TransformAKE1ADDKE1 (ID = NONE) TransformAKE2ADDKE2 (ID = NONE) HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } ---> <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2, TSi, TSr } A.3. Additional Key Exchange in the CREATE_CHILD_SA ExchangeonlyOnly The exchanges below show that the initiator does not propose the use of additional key exchanges to establish an IKE SA, but they are required in order to establish a Child SA. In order to establish a fully quantum-resistant IPsec SA, the responder includes a CHILDLESS_IKEV2_SUPPORTED notification in their IKE_SA_INIT response message. The initiator understands and supports this notification,thenexchanges a modified IKE_AUTH message with theresponderresponder, and rekeys the IKE SA immediately with additional key exchanges. Any Child SA will have to be created via a subsequent CREATED_CHILD_SA exchange. Initiator Responder --------------------------------------------------------------------- HDR(IKE_SA_INIT), SAi1, ---> KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED) <--- HDR(IKE_SA_INIT), SAr1, KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), N(CHILDLESS_IKEV2_SUPPORTED) HDR(IKE_AUTH), SK{ IDi, AUTH } ---> <--- HDR(IKE_AUTH), SK{ IDr, AUTH } HDR(CREATE_CHILD_SA), SK{ SAi(..AKE*...),ADDKE*...), Ni, KEi(Curve25519) } ---> Proposal #1 Transform ECR (ID = ENCR_AES_GCM_16, 256-bit key) Transform PRF (ID = PRF_HMAC_SHA2_512) Transform KE (ID = Curve25519) TransformAKE1ADDKE1 (ID = PQ_KEM_1) TransformAKE1ADDKE1 (ID = PQ_KEM_2) TransformAKE2ADDKE2 (ID = PQ_KEM_5) TransformAKE2ADDKE2 (ID = PQ_KEM_6) TransformAKE2ADDKE2 (ID = NONE) <--- HDR(CREATE_CHILD_SA), SK{ SAr(..AKE*...),ADDKE*...), Nr, KEr(Curve25519), N(ADDITIONAL_KEY_EXCHANGE)(link1) } Proposal #1 Transform ECR (ID = ENCR_AES_GCM_16, 256-bit key) Transform PRF (ID = PRF_HMAC_SHA2_512) Transform KE (ID = Curve25519) TransformAKE1ADDKE1 (ID = PQ_KEM_2) TransformAKE2ADDKE2 (ID = PQ_KEM_5) HDR(IKE_FOLLOWUP_KE), SK{ KEi(1)(PQ_KEM_2), ---> N(ADDITIONAL_KEY_EXCHANGE)(link1) } <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(1)(PQ_KEM_2), N(ADDITIONAL_KEY_EXCHANGE)(link2) } HDR(IKE_FOLLOWUP_KE), SK{ KEi(2)(PQ_KEM_5), ---> N(ADDITIONAL_KEY_EXCHANGE)(link2) } <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(2)(PQ_KEM_5) } A.4. No Matching Proposal for Additional Key Exchanges The initiator proposes the combination of PQ_KEM_1, PQ_KEM_2, PQ_KEM_3, and PQ_KEM_4 as the additional key exchanges. The initiator indicates that either PQ_KEM_1 or PQ_KEM_2 must be used to establish an IKE SA, butAdditional Key Exchange 2ADDKE2 Transform Type isoptional sooptional. Therefore, the responder can either select PQ_KEM_3 or PQ_KEM_4 or omit this key exchange by selecting NONE.The responder, althoughAlthough the responder supports the optional PQ_KEM_3 and PQ_KEM_4 methods, it does not support either the PQ_KEM_1 or the PQ_KEM_2 mandatorymethod and thereforemethod; therefore, it responds with a NO_PROPOSAL_CHOSEN notification. Initiator Responder --------------------------------------------------------------------- HDR(IKE_SA_INIT), SAi1(..AKE*...),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) TransformAKE1ADDKE1 (ID = PQ_KEM_1) TransformAKE1ADDKE1 (ID = PQ_KEM_2) TransformAKE2ADDKE2 (ID = PQ_KEM_3) TransformAKE2ADDKE2 (ID = PQ_KEM_4) TransformAKE2ADDKE2 (ID = NONE) <--- HDR(IKE_SA_INIT), N(NO_PROPOSAL_CHOSEN) Appendix B. Design Criteria The design of the extension is driven by the following criteria: 1) Need for PQC inIPsec.IPsec Quantum computers, which might become feasible in the near future, pose a threat to our classical public key cryptography. PQC, a family of public key cryptography that is believed to be resistantagainstto these computers, needs to be integrated into the IPsec protocol suite to restore confidentiality and authenticity. 2)Hybrid.Hybrid There is currently no post-quantum key exchange that is trusted at the level that (EC)DH is trusted for defending against conventional (non-quantum) adversaries. A hybrid post-quantum algorithm to beintroducedintroduced, along with the well-establishedprimitivesprimitives, addresses this concern, since the overall security is at least as strong as each individual primitive. 3) Focus on post-quantumconfidentiality.confidentiality A passive attacker can store all monitored encrypted IPsec communication today and decrypt it once a quantum computer is available in the future. This attack can have serious consequences that will not be visible for years to come. On the other hand, an attacker can only perform activeattacksattacks, such as impersonation of the communicatingpeerspeers, once a quantum computer isavailable,available sometime in the future. Thus, this specification focuses on confidentiality due to the urgency of this problem and presents a defense against the serious attack described above, but it does not address authenticationsincebecause it is less urgent at this stage. 4) Limit the amount of exchangeddata.data The protocol design should be such that the amount of exchanged data, such aspublic-keys,public keys, is kept as small aspossiblepossible, even if the initiator and the responder need to agree on a hybrid group or if multiplepublic-keyspublic keys need to be exchanged. 5) Not post-quantumspecific.specific Any cryptographic algorithm could be potentially broken in the future by currently unknown or impracticalattacks: quantumattacks. Quantum computers are merely the most concrete example of this. The design does not categorize algorithms as "post-quantum" or"non post-quantum""non- post-quantum", nor does it create assumptions about the properties of thealgorithms,algorithms; meaning that if algorithms with different properties become necessary in the future, this extension can be used unchanged to facilitate migration to those algorithms. 6) Limited amount ofchanges.changes A key goal is to limit the number of changes required when enabling a post-quantum handshake. This ensures easier and quicker adoption in existing implementations. 7) Localizedchanges.changes Another key requirement is that changes to the protocol are limited in scope, in particular, limiting changes in the exchanged messages and in the state machine, so that they can be easily implemented. 8) Deterministicoperation.operation This requirement means that the hybrid post-quantumexchange, andexchange and, thus, the computedkeys,keys will be based on algorithms that both client and server wish to support. 9) Fragmentationsupport.support Some PQC algorithms could be relatively bulky andtheymight require fragmentation. Thus, a design goal is the adaptation and adoption of an existing fragmentation method or the design of a new method that allows for the fragmentation of the key shares. 10)BackwardsBackward compatibility andinteroperability.interoperability This is a fundamental requirement to ensure that hybridpost-quantumpost- quantum IKEv2 and standard IKEv2 implementations as per [RFC7296]specificationare interoperable. 11) Compliance with USA Federal Information Processing Standards (FIPS)compliance.IPsec is widely used in Federal InformationSystemsSystems, and FIPS certification is an important requirement. However, at the time of writing, none of the algorithms that is believed to be post- quantum is yet FIPScompliant yet.compliant. Nonetheless, it is possible to combine this post-quantum algorithm with aFIPS compliantFIPS-compliant key establishment method so that the overall design remains FIPS compliant [NISTPQCFAQ]. 12) Ability to use this method with multiple classical (EC)DH keyexchanges.exchanges In somesituationssituations, peers have nosinglesingle, mutuallytrustedtrusted, key exchange algorithm (e.g., due to local policy restrictions). The ability to combine two (or more) key exchange methods in such a way that the resulting shared key depends on all of them allows peers to communicate in this situation. Appendix C. Alternative Design This section gives an overview on a number of alternative approaches that have beenconsidered,considered but later discarded. These approachesare:are as follows. * Sending the classical and post-quantum key exchanges as a single transform A method to combine the various key exchanges into a single large KE payload wasconsidered; thisconsidered. This effort is documented in a previous version of thisdraft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01).document (draft-tjhai-ipsecme-hybrid- qske-ikev2-01). Thisdoes allowmethod allows us to cleanly apply hybrid key exchanges during the ChildSA; howeverSA. However, it does add considerablecomplexity,complexity and requires an independent fragmentation solution. * Sending post-quantum proposals and policies in the KE payload only With the objective of not introducing unnecessary notify payloads, a method to communicate the hybrid post-quantum proposal in the KE payload during the first pass of the protocol exchange was considered. Unfortunately, this design is susceptible to the following downgrade attack. Consider the scenario where there is an on-path attacker sitting between an initiator and a responder.The initiator proposes, throughThrough the SAi payload,to usethe initiator proposes using a hybridpost- quantumpost-quantum groupandand, as afallbackfallback, a Diffie-Hellmangroup,group; and through the KEi payload, the initiator proposes a list of hybridpost- quantumpost-quantum proposals and policies. The on-path attacker intercepts this traffic and replies withN(INVALID_KE_PAYLOAD)N(INVALID_KE_PAYLOAD), suggestingtoa downgrade to the fallback Diffie-Hellman group instead. The initiator then resends the same SAi payload and the KEi payload containing the public value of the fallbackDiffie-HellmanDiffie- Hellman group. Note that the attacker may forward the second IKE_SA_INIT message only to theresponder, and thereforeresponder. Therefore, at this point in time, the responder will not have the information that the initiator prefers the hybrid group. Of course, it is possible for the responder to have a policy to reject an IKE_SA_INIT message that (a) offers a hybrid group but does notofferingoffer the corresponding public value in the KEipayload;payload and (b) the responder has not specifically acknowledged that it does notsupportedsupport the requested hybrid group. However, the checking of this policy introduces unnecessary protocol complexity. Therefore, in order to fully prevent any downgrade attacks, using a KE payload alone is notsufficientsufficient, andthatthe initiator MUST always indicate its preferred post-quantum proposals and policies in a notify payload in the subsequent IKE_SA_INIT messages followingaan N(INVALID_KE_PAYLOAD) response. * New payload types to negotiate hybridproposalproposals and to carry post- quantum public values Semantically, it makes sense to use a new payload type, which mimics the SA payload, to carry a hybrid proposal. Likewise, another new payload type that mimics the KEpayload,payload could be used to transport hybrid public value. Although, intheorytheory, a new payload type could be madebackwardsbackward compatible by not setting its critical flag as per Section 2.5 of [RFC7296], it is believed that it may not be that simple in practice. Since the original release of IKEv2 inRFC4306,RFC 4306, no new payload type has ever beenproposed andproposed; therefore, this creates a potential risk of having abackwardbackward- compatibility issue fromnon-conformantnonconformant IKEv2 implementations. Since there appears to be no other compelling advantages apart from a semantic one, the existingtransform typeTransform Type and notify payloads are used instead. * Hybrid public value payload One way to transport the negotiated hybrid public payload, which contains one classical Diffie-Hellman public value and one or more post-quantum public values, is to bundle these into a single KE payload. Alternatively, these could also be transported in a single new hybrid public valuepayload, butpayload. However, following the same reasoning asabove, thisabove may not be a good idea from abackwardbackward- compatibility perspective. Using a single KE payload would requireanencoding or formatting to be defined so that both peers are able to compose and extract the individual public values. However, it is believed that it is cleaner to send the hybrid public values in multiple KEpayloads--onepayloads: one for each group or algorithm. Furthermore, at this point in the protocol exchange, both peers should have indicated supportoffor handling multiple KE payloads. * FragmentationHandlingThe handling of large IKE_SA_INIT messages has been one of the most challenging tasks. A number of approaches have beenconsideredconsidered, and the two prominent ones that have been discarded are outlined as follows. The first approach is to treat the entire IKE_SA_INIT message as a stream of bytes, which is then splititinto a number of fragments, each of which is wrapped onto a payload that will fit into the size of the network MTU. The payload that wraps each fragment has a new payloadtypetype, and it is envisaged that this new payload type will not cause abackward compatibilitybackward-compatibility issuebecausebecause, at this stage of the protocol, both peers should have indicated support of fragmentation in the first pass of the IKE_SA_INIT exchange. The negotiation of fragmentation is performed using a notify payload, which also defines supportingparametersparameters, such as the size of fragment in octets and the fragment identifier. The new payload that wraps each fragment of the messages in this exchange is assigned the same fragment identifier. Furthermore, it also has otherparametersparameters, such as a fragment index and total number of fragments. This approach has been discarded due to its blanket approach to fragmentation. In cases where only a few payloads need to be fragmented, this approach appears to be overly complicated. Another idea that has been discardedwasis fragmenting an individual payload without introducing a new payload type. The idea is to use the 9-th bit (the bit after the critical flag in the RESERVED field) in the generic payload header as a flag to mark that this payload is fragmented. As an example, if a KE payload is to be fragmented, it may look as follows. 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|F| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diffie-Hellman Group Number | Fragment Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Index | Total Fragments | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total KE Payload Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Fragmented KE Payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Example of How to Fragment a KE Payload When the flag F is set,this meansthe current KE payload is a fragment of a larger KE payload. The Payload Length field denotes the size of this payload fragment inoctets--includingoctets: including the size of the generic payload header. Thetwo-octet2-octet RESERVED field followingDiffie-HellmanDiffie- Hellman Group Number was to be used as a fragment identifier to help the assembly and disassembly of fragments. The Fragment Index and Total Fragments fields are self-explanatory. The Total KE Payload Data Length indicates the size of the assembled KE payload data in octets. Finally, the actual fragment is carried in Fragment KE Payload field. This approach has been discarded because it is believed that the working group may not want to use the RESERVED field to change the format of apacketpacket, and that implementers may not like the added complexity from checking the fragmentation flag in each received payload. More importantly, fragmenting the messages in this way may leave the system to be more prone todenial of servicedenial-of-service (DoS) attacks.ByThis issue can be solved using IKE_INTERMEDIATE [RFC9242] to transport the largepost- quantumpost-quantum key exchangepayloads,payloads and using the generic IKEv2 fragmentation protocol[RFC7383] solve the issue.[RFC7383]. * Group sub-identifier As discussed before, each group identifier is used to distinguish a post-quantum algorithm. Further classification could be made on a particular post-quantum algorithm by assigning an additional value alongside the group identifier. Thissub- identifiersub-identifier value may be used to assign differentsecurity parametersecurity-parameter sets to a givenpost- quantumpost-quantum algorithm. However, this level ofdetailsdetail does not fit the principles of the document where it should deal with generic hybrid key exchangeprotocol,protocol and not a specific ciphersuite. Furthermore, there are enoughDiffie- HellmanDiffie-Hellman group identifiers should this be required in the future. Acknowledgements The authors would like to thank Frederic Detienne and Olivier Pelerin for their comments and suggestions, including the idea to negotiate the post-quantum algorithms using the existing KE payload. The authors are also grateful to Tobias Heider and Tobias Guggemos for valuable comments. Thanks to Paul Wouters for reviewing the document. Authors' AddressesC.CJ. Tjhai Post-Quantum Email: cjt@post-quantum.comM.Martin Tomlinson Post-Quantum Email: mt@post-quantum.comG.Graham Bartlett Quantum Secret Email: graham.ietf@gmail.comS.Scott Fluhrer Cisco Systems Email: sfluhrer@cisco.comD.Daniel Van Geest ISARA Corporation Email:daniel.vangeest@isara.com O.daniel.vangeest.ietf@gmail.com Oscar Garcia-Morchon Philips Email: oscar.garcia-morchon@philips.com Valery Smyslov ELVIS-PLUS Email: svan@elvis.ru