idnits 2.17.1 draft-ietf-ipsecme-ikev2-multiple-ke-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 June 2022) is 682 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 648, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 940, but not defined == Missing Reference: 'RFC8247' is mentioned on line 933, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-ipsecme-g-ikev2-06 == Outdated reference: A later version (-03) exists of draft-tjhai-ikev2-beyond-64k-limit-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) C. Tjhai 3 Internet-Draft M. Tomlinson 4 Updates: 7296 (if approved) Post-Quantum 5 Intended status: Standards Track G. Bartlett 6 Expires: 15 December 2022 Quantum Secret 7 S. Fluhrer 8 Cisco Systems 9 D. Van Geest 10 ISARA Corporation 11 O. Garcia-Morchon 12 Philips 13 V. Smyslov 14 ELVIS-PLUS 15 13 June 2022 17 Multiple Key Exchanges in IKEv2 18 draft-ietf-ipsecme-ikev2-multiple-ke-06 20 Abstract 22 This document describes how to extend the Internet Key Exchange 23 Protocol Version 2 (IKEv2) to allow multiple key exchanges to take 24 place while computing a shared secret during a Security Association 25 (SA) setup. The primary application of this feature in IKEv2 is the 26 ability to perform one or more post-quantum key exchanges in 27 conjunction with the classical (Elliptic Curve) Diffie-Hellman key 28 exchange, so that the resulting shared key is resistant against 29 quantum computer attacks. Another possible application is the 30 ability to combine several key exchanges in situations when no single 31 key exchange algorithm is trusted by both initiator and responder. 33 This document updates RFC7296 by renaming a transform type 4 from 34 "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and 35 renaming a field in the Key Exchange Payload from "Diffie-Hellman 36 Group Num" to "Key Exchange Method". It also renames an IANA 37 registry for this transform type from "Transform Type 4 - Diffie- 38 Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange 39 Method Transform IDs". These changes generalize key exchange 40 algorithms that can be used in IKEv2. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on 15 December 2022. 59 Copyright Notice 61 Copyright (c) 2022 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 66 license-info) in effect on the date of publication of this document. 67 Please review these documents carefully, as they describe your rights 68 and restrictions with respect to this document. Code Components 69 extracted from this document must include Revised BSD License text as 70 described in Section 4.e of the Trust Legal Provisions and are 71 provided without warranty as described in the Revised BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3 77 1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . 3 78 1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.4. Document Organization . . . . . . . . . . . . . . . . . . 6 80 2. Design Criteria . . . . . . . . . . . . . . . . . . . . . . . 7 81 3. Multiple Key Exchanges . . . . . . . . . . . . . . . . . . . 9 82 3.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 9 83 3.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 11 84 3.2.1. IKE_SA_INIT Round: Negotiation . . . . . . . . . . . 11 85 3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges . . 14 86 3.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 15 87 3.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 16 88 3.2.5. Interaction with Childless IKE SA . . . . . . . . . . 19 89 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 90 4.1. Additional Changes . . . . . . . . . . . . . . . . . . . 20 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 92 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 95 7.2. Informative References . . . . . . . . . . . . . . . . . 23 96 Appendix A. Sample Multiple Key Exchanges . . . . . . . . . . . 24 97 A.1. IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange 98 Payloads . . . . . . . . . . . . . . . . . . . . . . . . 24 99 A.2. No Additional Key Exchange Used . . . . . . . . . . . . . 26 100 A.3. Additional Key Exchange in the CREATE_CHILD_SA Exchange 101 only . . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 A.4. Not Matching Proposal for Additional Key Exchanges . . . 28 103 Appendix B. Alternative Design . . . . . . . . . . . . . . . . . 29 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 106 1. Introduction 108 1.1. Problem Description 110 Internet Key Exchange Protocol (IKEv2) as specified in [RFC7296] uses 111 the Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) 112 algorithm, which we shall refer to as (EC)DH collectively, to 113 establish a shared secret between an initiator and a responder. The 114 security of the (EC)DH algorithms relies on the difficulty to solve a 115 discrete logarithm problem in multiplicative (and respectively 116 elliptic curve) groups when the order of the group parameter is large 117 enough. While solving such a problem remains difficult with current 118 computing power, it is believed that general purpose quantum 119 computers will be able to solve this problem, implying that the 120 security of IKEv2 is compromised. There are, however, a number of 121 cryptosystems that are conjectured to be resistant against quantum 122 computer attack. This family of cryptosystems is known as post- 123 quantum cryptography (PQC). It is sometimes also referred to as 124 quantum-safe cryptography (QSC) or quantum-resistant cryptography 125 (QRC). 127 1.2. Proposed Extension 129 This document describes a method to perform multiple successive key 130 exchanges in IKEv2. It allows integration of PQC in IKEv2, while 131 maintaining backwards compatibility, to derive a set of IKE keys that 132 is resistant to quantum computer attacks. This extension allows the 133 negotiation of one or more PQC algorithm to exchange data, in 134 addition to the existing (EC)DH key exchange data. We believe that 135 the feature of using more than one post-quantum algorithms is 136 important as many of these algorithms are relatively new and there 137 may be a need to hedge the security risk with multiple key exchange 138 data from several distinct PQC algorithms. 140 The secrets established from each key exchange are combined in a way 141 such that should the post-quantum secrets not be present, the derived 142 shared secret is equivalent to that of the standard IKEv2; on the 143 other hand, a post-quantum shared secret is obtained if both 144 classical and post-quantum key exchange data are present. This 145 extension also applies to key exchanges in IKE Security Associations 146 (SAs) for Encapsulating Security Payload (ESP) [RFC4303] or 147 Authentication Header (AH) [RFC4302], i.e. Child SAs, in order to 148 provide a stronger guarantee of forward security. 150 Some post-quantum key exchange payloads may have sizes larger than 151 the standard maximum transmission unit (MTU) size, and therefore 152 there could be issues with fragmentation at the IP layer. In order 153 to allow using those larger payload sizes, this mechanism relies on 154 the IKE_INTERMEDIATE exchange as specified in [RFC9242]. With this 155 mechanism, we do an initial key exchange, using a smaller, possibly 156 classical primitive, such as (EC)DH. Then, before we do the IKE_AUTH 157 exchange, we perform one or more IKE_INTERMEDIATE exchanges, each of 158 which contains an additional key exchange. As the IKE_INTERMEDIATE 159 exchange is encrypted, the IKE fragmentation protocol [RFC7383] can 160 be used. The IKE SK_* values are updated after each exchange, and so 161 the final IKE SA keys depend on all the key exchanges, hence they are 162 secure if any of the key exchanges are secure. 164 Note that readers should consider the approach defined in this 165 document as providing a long term solution in upgrading the IKEv2 166 protocol to support post-quantum algorithms. A short term solution 167 to make IKEv2 key exchange quantum secure is to use post-quantum pre- 168 shared keys as specified in [RFC8784]. 170 Note also that the proposed approach of performing multiple 171 successive key exchanges in such a way that resulting session keys 172 depend on all of them is not limited to addressing the threat of 173 quantum computer only. It can also be used when all of the performed 174 key exchanges are classical (EC)DH primitives, where for some reasons 175 (e.g. policy requirements) it is essential to perform multiple of 176 them. 178 This specification does not attempt to address key exchanges with KE 179 payloads longer than 64k; the current IKE payload format does not 180 allow such as possibility. At the time of writing, it appears likely 181 that there are a number of key exchanges available that would not 182 require such a requirement. However, if such a requirement is 183 needed, [I-D.tjhai-ikev2-beyond-64k-limit] discusses approaches that 184 should be taken to exchange huge payloads. 186 1.3. Changes 188 RFC EDITOR PLEASE DELETE THIS SECTION. 190 Changes in this draft in each version iterations. 192 * Updated the reference to RFC9242. 194 * Editorial changes. 196 draft-ietf-ipsecme-ikev2-multiple-ke-04 198 * Introduction and initial sections are reorganized. 200 * More clarifications for error handling added. 202 * ASCII arts displaying SA payload are added. 204 * Clarification for handling multiple round trips key exchange 205 methods added. 207 * DoS concerns added into Security Considerations section. 209 * Explicitly allow scenario when additional key exchanges are 210 performed only after peers are authenticated. 212 draft-ietf-ipsecme-ikev2-multiple-ke-03 214 * More clarifications added. 216 * Figure illustrating initial exchange added. 218 * Minor editorial changes. 220 draft-ietf-ipsecme-ikev2-multiple-ke-02 222 * Added a reference on the handling of KE payloads larger than 64KB. 224 draft-ietf-ipsecme-ikev2-multiple-ke-01 226 * References are updated. 228 draft-ietf-ipsecme-ikev2-multiple-ke-00 230 * Draft name changed as result of WG adoption and generalization of 231 the approach. 233 * New exchange IKE_FOLLOWUP_KE is defined for additional key 234 exchanges performed after CREATE_CHILD_SA. 236 * Nonces are removed from all additional key exchanges. 238 * Clarification that IKE_INTERMEDIATE must be negotiated is added. 240 draft-tjhai-ipsecme-hybrid-qske-ikev2-04 242 * Clarification about key derivation in case of multiple key 243 exchanges in CREATE_CHILD_SA is added. 245 * Resolving rekey collisions in case of multiple key exchanges is 246 clarified. 248 draft-tjhai-ipsecme-hybrid-qske-ikev2-03 250 * Using multiple key exchanges CREATE_CHILD_SA is defined. 252 draft-tjhai-ipsecme-hybrid-qske-ikev2-02 254 * Use new transform types to negotiate additional key exchanges, 255 rather than using the KE payloads of IKE SA. 257 draft-tjhai-ipsecme-hybrid-qske-ikev2-01 259 * Use IKE_INTERMEDIATE to perform multiple key exchanges in 260 succession. 262 * Handle fragmentation by keeping the first key exchange (a standard 263 IKE_SA_INIT with a few extra notifies) small, and encrypting the 264 rest of the key exchanges. 266 * Simplify the negotiation of the 'extra' key exchanges. 268 draft-tjhai-ipsecme-hybrid-qske-ikev2-00 270 * We added a feature to allow more than one post-quantum key 271 exchange algorithms to be negotiated and used to exchange a post- 272 quantum shared secret. 274 * Instead of relying on TCP encapsulation to deal with IP level 275 fragmentation, we introduced a new key exchange payload that can 276 be sent as multiple fragments within IKE_SA_INIT message. 278 1.4. Document Organization 280 The remainder of this document is organized as follows. Section 2 281 summarizes design criteria. Section 3 describes how multiple key 282 exchanges are performed between two IKE peers and how keying 283 materials are derived for both SAs and Child SAs. A summary of 284 alternative approaches that have been considered, but later 285 discarded, are described in Appendix B. Section 4 discusses IANA 286 considerations for the namespaces introduced in this document, and 287 lastly Section 5 discusses security considerations. 289 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 290 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 291 "OPTIONAL" in this document are to be interpreted as described in BCP 292 14 [RFC2119] [RFC8174] when, and only when, they appear in all 293 capitals, as shown here. 295 2. Design Criteria 297 The design of the extension is driven by the following criteria: 299 1) Need for post-quantum cryptography in IPsec. Quantum computers 300 might become feasible in the near future. If current Internet 301 communications are monitored and recorded today (D), the 302 communications could be decrypted as soon as a quantum- computer 303 is available (e.g., year Q) if key negotiation only relies on 304 non post-quantum primitives. This is a high threat for any 305 information that must remain confidential for a long period of 306 time T > Q-D. The need is obvious if we assume that Q is 2040, 307 D is 2020, and T is 30 years. Such a value of T is typical in 308 classified or healthcare data. 310 2) Hybrid. Currently, there does not exist a post-quantum key 311 exchange that is trusted at the level that (EC)DH is trusted 312 against conventional (non-quantum) adversaries. A hybrid post- 313 quantum algorithm to be introduced next to well-established 314 primitives, since the overall security is at least as strong as 315 each individual primitive. 317 3) Focus on post-quantum confidentiality. A passive attacker can 318 eavesdrop on IPsec communication today and decrypt it once a 319 quantum computer is available in the future. This is a very 320 serious attack for which we do not have a solution. An attacker 321 can only perform active attacks such as impersonation of the 322 communicating peers once a quantum computer is available, 323 sometime in the future. Thus, our design focuses on 324 confidentiality due to the urgency of this problem. This 325 document does not address authentication since it is less urgent 326 at this stage. 328 4) Limit amount of exchanged data. The protocol design should be 329 such that the amount of exchanged data, such as public-keys, is 330 kept as small as possible even if initiator and responder need 331 to agree on a hybrid group or multiple public-keys need to be 332 exchanged. 334 5) Future proof. Any cryptographic algorithm could be potentially 335 broken in the future by currently unknown or impractical 336 attacks: quantum computers are merely the most concrete example 337 of this. The design does not categorize algorithms as "post- 338 quantum" or "non post-quantum" nor does it create assumptions 339 about the properties of the algorithms, meaning that if 340 algorithms with different properties become necessary in the 341 future, this extension can be used unchanged to facilitate 342 migration to those algorithms. 344 6) Limited amount of changes. A key goal is to limit the number of 345 changes required when enabling a post-quantum handshake. This 346 ensures easier and quicker adoption in existing implementations. 348 7) Localized changes. Another key requirement is that changes to 349 the protocol are limited in scope, in particular, limiting 350 changes in the exchanged messages and in the state machine, so 351 that they can be easily implemented. 353 8) Deterministic operation. This requirement means that the hybrid 354 post-quantum exchange, and thus, the computed keys, will be 355 based on algorithms that both client and server wish to support. 357 9) Fragmentation support. Some PQC algorithms could be relatively 358 bulky and they might require fragmentation. Thus, a design goal 359 is the adaptation and adoption of an existing fragmentation 360 method or the design of a new method that allows for the 361 fragmentation of the key shares. 363 10) Backwards compatibility and interoperability. This is a 364 fundamental requirement to ensure that hybrid post-quantum IKEv2 365 and standard IKEv2 implementations as per [RFC7296] 366 specification are interoperable. 368 11) Federal Information Processing Standards (FIPS) compliance. 369 IPsec is widely used in Federal Information Systems and FIPS 370 certification is an important requirement. However, algorithms 371 that are believed to be post-quantum are not FIPS compliant yet. 372 Still, the goal is that the overall hybrid post-quantum IKEv2 373 design can be FIPS compliant. 375 12) Ability to use this method with multiple classical (EC)DH key 376 exchanges. In some situations peers have no single mutually 377 trusted key exchange algorithm (e.g., due to local policy 378 restrictions). The ability to combine two (or more) key 379 exchange methods in such a way that the resulting shared key 380 depends on all of them allows peers to communicate in this 381 situation. 383 3. Multiple Key Exchanges 385 3.1. Design Overview 387 Most post-quantum key agreement algorithms are relatively new, and 388 thus are not fully trusted. There are also many proposed algorithms, 389 with different trade-offs and relying on different hard problems. 390 The concern is that some of these hard problems may turn out to be 391 easier to solve than anticipated and thus the key agreement algorithm 392 may not be as secure as expected. A hybrid solution, when multiple 393 key exchanges are performed and the calculated shared key depends on 394 all of them, allows us to deal with this uncertainty by combining a 395 classical key exchange with a post-quantum one, as well as leaving 396 open the possibility of multiple post-quantum key exchanges. 398 In order to be able to use IKE fragmentation [RFC7383] for those key 399 exchanges that may have long public keys, this specification utilizes 400 the IKE_INTERMEDIATE exchange defined in [RFC9242]. The initial 401 IKE_INIT messages do not have any inherent fragmentation support 402 within IKE; however that can include a relatively short KE payload. 403 The additional key exchanges are performed using IKE_INTERMEDIATE 404 messages; because these messages are encrypted, the standard IKE 405 fragmentation mechanism is available. 407 In order to minimize communication overhead, only the key shares that 408 are agreed to be used are actually exchanged. To negotiate 409 additional key exchanges seven new Transform Types are defined. 410 These transforms and Transform Type 4 share the same Transform IDs. 412 We assume that new Transform Type 4 identifiers will be assigned 413 later to the various post-quantum key exchanges. We specifically do 414 not make a distinction between classical (EC)DH and post-quantum key 415 exchanges, nor post-quantum algorithms which are true key exchanges 416 versus post-quantum algorithms that act as key transport mechanisms; 417 all are treated equivalently by the protocol. To be more specific, 418 this document renames Transform Type 4 from "Diffie-Hellman Group 419 (D-H)" to "Key Exchange Method (KE)" and renames a field in the Key 420 Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange 421 Method". The corresponding IANA registry is also renamed from 422 "Diffie-Hellman Group Transform IDs" to "Key Exchange Method 423 Transform IDs". 425 The fact, that newly defined transforms share the same registry for 426 possible Transform IDs with Transform Type 4, allows additional key 427 exchanges to be of any type - either post-quantum or classical (EC)DH 428 one. This approach allows any combination of the defined key 429 exchange methods to take place. This also allows IKE peers to 430 perform a single post-quantum key exchange in the IKE_SA_INIT without 431 additional key exchanges, provided that the IP fragmentation is not 432 an issue and that hybrid key exchange is not needed. 434 The SA payload in the IKE_SA_INIT message includes one or more newly 435 defined transforms which represent the extra key exchange policy 436 required by the initiator. The responder follows the usual IKEv2 437 negotiation rules: it selects a single transform of each type, and 438 returns all of them in the IKE_SA_INIT response message. 440 Then, provided that additional key exchanges are negotiated, the 441 initiator and the responder perform one or more IKE_INTERMEDIATE 442 exchanges. Following that, the IKE_AUTH exchange authenticates peers 443 and completes IKE SA establishment. 445 Initiator Responder 446 --------------------------------------------------------------------- 447 <-- IKE_SA_INIT (additional key exchanges negotiation) --> 449 <-- {IKE_INTERMEDIATE (additional key exchange)} --> 451 ... 453 <-- {IKE_INTERMEDIATE (additional key exchange)} --> 455 <-- {IKE_AUTH} --> 457 Note that this document assumes, that each key exchange method 458 requires one round trip and consumes exactly one IKE_INTERMEDIATE 459 exchange. This assumption is valid for all classic key exchange 460 methods defined so far and for all post-quantum methods currently 461 known. For hypothetical future key exchange methods requiring 462 multiple round trips to complete, a separate document should define 463 how such methods are splitted into several IKE_INTERMEDIATE 464 exchanges. 466 3.2. Protocol Details 468 In the simplest case, the initiator is happy with a single key 469 exchange (and has no interest in supporting multiple), and it is not 470 concerned with possible fragmentation of the IKE_SA_INIT messages 471 (either because the key exchange it selects is small enough not to 472 fragment, or the initiator is confident that fragmentation will be 473 handled either by IP fragmentation, or transport via TCP). 475 In this case, the initiator performs the IKE_SA_INIT as usual, 476 inserting a preferred key exchange (which is possibly a post-quantum 477 algorithm) as the listed Transform Type 4, and including the 478 initiator KE payload. If the responder accepts the policy, it 479 responds with an IKE_SA_INIT response, and IKE continues as usual. 481 If the initiator desires to negotiate multiple key exchanges, then 482 the initiator uses the protocol listed below. 484 3.2.1. IKE_SA_INIT Round: Negotiation 486 Multiple key exchanges are negotiated using the standard IKEv2 487 mechanism, via SA payload. For this purpose seven new transform 488 types, namely Additional Key Exchange 1 (), Additional 489 Key Exchange 2 (), Additional Key Exchange 3 (), Additional Key Exchange 4 (), Additional Key 491 Exchange 5 (), Additional Key Exchange 6 () 492 and Additional Key Exchange 7 () are defined. They are 493 collectively called Additional Key Exchange transforms in this 494 document and have slightly different semantics than the existing 495 IKEv2 transform types. They are interpreted as an indication of 496 additional key exchange methods that peers agree to perform in a 497 series of IKE_INTERMEDIATE exchanges following the IKE_SA_INIT 498 exchange. The allowed transform IDs for these transform types are 499 the same as the IDs for Transform Type 4, so they all share a single 500 IANA registry for transform IDs. 502 Key exchange method negotiated via Transform Type 4 always takes 503 place in the IKE_SA_INIT exchange, as defined in [RFC7296]. 504 Additional key exchanges negotiated via newly defined transforms MUST 505 take place in a series of IKE_INTERMEDIATE exchanges following the 506 IKE_SA_INIT exchange, performed in an order of the values of their 507 transform types, so that key exchange negotiated using Additional Key 508 Exchange i always precedes that of Additional Key Exchange i+1. Each 509 additional key exchange method MUST be fully completed before the 510 next one is started. 512 Note that with this semantics, Additional Key Exchange transforms are 513 not associated with any particular type of key exchange and do not 514 have any specific per transform type transform IDs IANA registry. 515 Instead they all share a single registry for transform IDs, namely 516 "Key Exchange Method Transform IDs", which are also shared by 517 Transform Type 4. All key exchange algorithms (both classical or 518 post-quantum) should be added to this registry. This approach gives 519 peers flexibility in defining the ways they want to combine different 520 key exchange methods. 522 When forming a proposal the initiator adds transforms for the 523 IKE_SA_INIT exchange using Transform Type 4. In most cases they will 524 contain classical (EC)DH key exchange methods, however it is not a 525 requirement. Additional key exchange methods are proposed using 526 Additional Key Exchange transform types. All of these transform 527 types are optional, the initiator is free to select any of them for 528 proposing additional key exchange methods. Consequently, if none of 529 the Additional Key Exchange transforms is included in the proposal, 530 then this proposal indicates performing standard IKEv2, as defined in 531 [RFC7296]. On the other hand, if the initiator includes any 532 Additional Key Exchange transform in the proposal, the responder MUST 533 select one of the algorithms proposed using this type. Note that 534 this is not a new requirement, but this behaviour is already 535 specified in Section 2.7 of [RFC7296]. A transform ID NONE MAY be 536 added to those transform types which contain key exchange methods 537 that the initiator believes is optional according to its local 538 policy. 540 The responder performs negotiation using the standard IKEv2 procedure 541 described in Section 3.3 of [RFC7296]. However, for the Additional 542 Key Exchange types, the responder's choice MUST NOT contain 543 duplicated algorithms, except for the transform ID of NONE. An 544 algorithm is represented as a transform, in some cases the transform 545 could include a set of associated attributes that define details of 546 the algorithm. In this case, two transforms can be the same, but the 547 attributes must be different. Additionally, the order of the 548 attributes does not affect the equality of the algorithm, so two 549 transforms (ID=alg1,ATTR1=attr1,ATTR2=attr2) and 550 (ID=alg1,ATTR2=attr2,ATTR1=attr1) define the same algorithm. 552 If the responder selects NONE for some Additional Key Exchange types 553 (provided they are proposed by the initiator), then the corresponding 554 IKE_INTERMEDIATE exchanges MUST NOT take place. Therefore if the 555 initiator includes NONE in all of the Additional Key Exchange 556 transforms and the responder selects this value for all of them, then 557 no IKE_INTERMEDIATE messages performing additional key exchanges will 558 take place between the peers. Note that the IKE_INTERMEDIATE 559 exchanges may still take place for other purposes. 561 The initiator MAY propose non-consecutive Additional Key Exchange 562 transforms, for example proposing Additional Key Exchange 2 and 563 Additional Key Exchange 5 transforms only. The responder MUST treat 564 all of the omitted Additional Key Exchange transforms as if they are 565 proposed with Transform ID NONE. 567 Below is an example of the SA payload in the initiator's IKE_SA_INIT 568 request message. Here we use an abbreviation AKEi to denote the i-th 569 Additional Key Exchange transform defined in this document, and an 570 abbreviation KE for the Key Exchange transform, that this document 571 renames from the Diffie-Hellman Group transform. We also use some 572 not-yet defined Transform IDs, namely PQ_KEM_1, PQ_KEM_2 and PQ_KEM_3 573 to denote some popular post-quantum key exchange methods. 575 SA Payload 576 | 577 +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8, 578 | 9 transforms, SPI = 0x35a1d6f22564f89d ) 579 | 580 +-- Transform ENCR ( ID = ENCR_AES_GCM_16 ) 581 | +-- Attribute ( Key Length = 256 ) 582 | 583 +-- Transform KE ( ID = 4096-bit MODP Group ) 584 | 585 +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 ) 586 | 587 +-- Transform AKE2 ( ID = PQ_KEM_1 ) 588 | 589 +-- Transform AKE2 ( ID = PQ_KEM_2 ) 590 | 591 +-- Transform AKE3 ( ID = PQ_KEM_1 ) 592 | 593 +-- Transform AKE3 ( ID = PQ_KEM_2 ) 594 | 595 +-- Transform AKE5 ( ID = PQ_KEM_3 ) 596 | 597 +-- Transform AKE5 ( ID = NONE ) 599 In this example, the initiator proposes to perform initial key 600 exchange using 4096-bit MODP group followed by two mandatory 601 additional key exchanges using PQ_KEM_1 and PQ_KEM_2 methods in any 602 order, then followed by additional key exchange using PQ_KEM_3 method 603 that may be omitted. 605 The responder might return the following SA payload, indicating that 606 it agrees to perform two additional key exchanges PQ_KEM_2 followed 607 by PQ_KEM_1 and does not want to perform PQ_KEM_3 additionally. 609 SA Payload 610 | 611 +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8, 612 | 6 transforms, SPI = 0x8df52b331a196e7b ) 613 | 614 +-- Transform ENCR ( ID = ENCR_AES_GCM_16 ) 615 | +-- Attribute ( Key Length = 256 ) 616 | 617 +-- Transform KE ( ID = 4096-bit MODP Group ) 618 | 619 +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 ) 620 | 621 +-- Transform AKE2 ( ID = PQ_KEM_2 ) 622 | 623 +-- Transform AKE3 ( ID = PQ_KEM_1 ) 624 | 625 +-- Transform AKE5 ( ID = NONE ) 627 If the initiator includes any Additional Key Exchange transform types 628 into the SA payload in the IKE_SA_INIT exchange request message, then 629 it MUST also negotiate the use of the IKE_INTERMEDIATE exchange as 630 described in [RFC9242], by including INTERMEDIATE_EXCHANGE_SUPPORTED 631 notification in the same message. If the responder agrees to use 632 additional key exchanges while establishing initial IKE SA, it MUST 633 also return this notification in the IKE_SA_INIT response message, 634 thus confirming that IKE_INTERMEDIATE exchange is supported and will 635 be used for transferring additional key exchange data. If the 636 IKE_INTERMEDIATE exchange is not negotiated, then the peers MUST 637 treat any Additional Key Exchange transforms in the IKE_SA_INIT 638 exchange messages as unknown transform types and skip the proposals 639 they appear in. If no other proposals are present in the SA payload, 640 the peers will proceed as if no proposal is chosen (i.e. the 641 responder will send NO_PROPOSAL_CHOSEN notification). 643 Initiator Responder 644 --------------------------------------------------------------------- 645 HDR, SAi1(.. AKE*...), KEi, Ni, 646 N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> 647 HDR, SAr1(.. AKE*...), KEr, Nr, 648 [CERTREQ], 649 <--- N(INTERMEDIATE_EXCHANGE_SUPPORTED) 651 3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges 653 For each additional key exchange agreed to in the IKE_SA_INIT 654 exchange, the initiator and the responder perform IKE_INTERMEDIATE 655 exchange, as described in [RFC9242]. 657 Initiator Responder 658 --------------------------------------------------------------------- 659 HDR, SK {KEi(n)} --> 660 <-- HDR, SK {KEr(n)} 662 The initiator sends key exchange data in the KEi(n) payload. This 663 message is protected with the current SK_ei/SK_ai keys. The notation 664 KEi(n) denotes the n-th IKE_INTERMEDIATE KE payload from the 665 initiator and the integer n is sequential starting from 1. 667 On receiving this, the responder sends back key exchange payload 668 KEr(n), which denotes the n-th IKE_INTERMEDIATE KE payload from the 669 responder. As before, this message is protected with the current 670 SK_er/SK_ar keys. 672 The former "Diffie-Hellman Group Num" (now called "Key Exchange 673 Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th 674 negotiated additional key exchange. 676 Once this exchange is done, both sides compute an updated keying 677 material: 679 SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr) 681 where SK(n) is the resulting shared secret of this key exchange, Ni 682 and Nr are nonces from the IKE_SA_INIT exchange and SK_d(n-1) is the 683 last generated SK_d, (derived from the previous IKE_INTERMEDIATE 684 exchange, or the IKE_SA_INIT if there have not already been any 685 IKE_INTERMEDIATE exchanges). The other keying materials SK_d, SK_ai, 686 SK_ar, SK_ei, SK_er, SK_pi, SK_pr are updated as: 688 {SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) | 689 SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr) 691 Both the initiator and the responder use these updated key values in 692 the next exchange (IKE_INTERMEDIATE or IKE_AUTH). 694 3.2.3. IKE_AUTH Exchange 696 After all IKE_INTERMEDIATE exchanges have completed, the initiator 697 and the responder perform an IKE_AUTH exchange. This exchange is the 698 standard IKE exchange, except that the initiator and responder signed 699 octets are modified as described in [RFC9242]. 701 3.2.4. CREATE_CHILD_SA Exchange 703 The CREATE_CHILD_SA exchange is used in IKEv2 for the purposes of 704 creating additional Child SAs, rekeying them and rekeying IKE SA 705 itself. When creating or rekeying Child SAs, the peers may 706 optionally perform a Diffie-Hellman key exchange to add a fresh 707 entropy into the session keys. In case of IKE SA rekey, the key 708 exchange is mandatory. Peers supporting this specification may want 709 to use multiple key exchanges in these situations. 711 Using multiple key exchanges with CREATE_CHILD_SA exchange is 712 negotiated similarly as in the initial IKE exchange, see 713 Section 3.2.1. If the initiator includes any Additional Key Exchange 714 transform in the SA payload (along with Transform Type 4) and the 715 responder agrees to perform additional key exchanges, then the 716 additional key exchanges are performed in a series of new 717 IKE_FOLLOWUP_KE exchanges that follows the CREATE_CHILD_SA exchange. 718 The IKE_FOLLOWUP_KE exchange is introduced as a dedicated exchange 719 for transferring data of additional key exchanges following the key 720 exchange performed in the CREATE_CHILD_SA. Its Exchange Type is . 723 Key exchange negotiated via Transform Type 4 always takes place in 724 the CREATE_CHILD_SA exchange, as per IKEv2 specification. Additional 725 key exchanges are performed in an order of the values of their 726 transform types, so that key exchange negotiated using Transform Type 727 n always precedes key exchange negotiated using Transform Type n + 1. 728 Each additional key exchange method MUST be fully completed before 729 the next one is started. Note, that this document assumes, that each 730 key exchange method consumes exactly one IKE_FOLLOWUP_KE exchange. 731 For the methods requiring multiple round trips, a separate document 732 should define how such methods are splitted into several 733 IKE_FOLLOWUP_KE exchanges. 735 Since after IKE SA is created the window size may be greater than one 736 and multiple concurrent exchanges may be in progress, it is essential 737 to link the IKE_FOLLOWUP_KE exchanges together and with the 738 corresponding CREATE_CHILD_SA exchange. A new status type 739 notification ADDITIONAL_KEY_EXCHANGE is used for this purpose. Its 740 Notify Message Type is , Protocol ID and SPI Size are 741 both set to 0. The data associated with this notification is a blob 742 meaningful only to the responder, so that the responder can correctly 743 link successive exchanges. For the initiator the content of this 744 notification is an opaque blob. 746 The responder MUST include this notification in a CREATE_CHILD_SA or 747 IKE_FOLLOWUP_KE response message in case the next IKE_FOLLOWUP_KE 748 exchange is expected, filling it with some data that would allow 749 linking current exchange to the next one. The initiator MUST send 750 back this notification intact in the request message of the next 751 IKE_FOLLOWUP_KE exchange. 753 Below is an example of CREATE_CHILD_SA exchange followed by three 754 additional key exchanges. 756 Initiator Responder 757 --------------------------------------------------------------------- 758 HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> 759 <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, 760 N(ADDITIONAL_KEY_EXCHANGE)(link1)} 762 HDR(IKE_FOLLOWUP_KE), SK {KEi(1), 763 N(ADDITIONAL_KEY_EXCHANGE)(link1)} --> 764 <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1), 765 N(ADDITIONAL_KEY_EXCHANGE)(link2)} 767 HDR(IKE_FOLLOWUP_KE), SK {KEi(2), 768 N(ADDITIONAL_KEY_EXCHANGE)(link2)} --> 769 <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2), 770 N(ADDITIONAL_KEY_EXCHANGE)(link3)} 772 HDR(IKE_FOLLOWUP_KE), SK {KEi(3), 773 N(ADDITIONAL_KEY_EXCHANGE)(link3)} --> 774 <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(3)} 776 The former "Diffie-Hellman Group Num" (now called "Key Exchange 777 Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th 778 negotiated additional key exchange. 780 It is possible that due to some unexpected events (e.g. reboot) the 781 initiator may lose its state and forget that it is in the process of 782 performing additional key exchanges and thus never start the 783 remaining IKE_FOLLOWUP_KE exchanges. The responder MUST handle this 784 situation gracefully and delete the associated state if it does not 785 receive the next expected IKE_FOLLOWUP_KE request after some 786 reasonable period of time. 788 If responder receives IKE_FOLLOWUP_KE request containing 789 ADDITIONAL_KEY_EXCHANGE notification and the content of this notify 790 does not correspond to any active key exchange state the responder 791 has, it MUST send back a new error type notification STATE_NOT_FOUND. 792 This is a non-fatal error notification, its Notify Message Type is 793 , Protocol ID and SPI Size are both set to 0 and the 794 data is empty. If the initiator receives this notification in 795 response to IKE_FOLLOWUP_KE exchange performing additional key 796 exchange, it MUST cancel this exchange and MUST treat the whole 797 series of exchanges started from the CREATE_CHILD_SA exchange as 798 failed. In most cases, the receipt of this notification is caused by 799 premature deletion of the corresponding state on the responder (the 800 time period between IKE_FOLLOWUP_KE exchanges appeared too long from 801 the responder's point of view, e.g. due to a temporary network 802 failure). After receiving this notification the initiator MAY start 803 a new CREATE_CHILD_SA exchange which may eventually be followed by 804 the IKE_FOLLOWUP_KE exchanges, to retry the failed attempt. If the 805 initiator continues to receive STATE_NOT_FOUND notifications after 806 several retries, it MUST treat this situation as a fatal error and 807 delete IKE SA by sending a DELETE payload. 809 When rekeying IKE SA or Child SA, it is possible that the peers start 810 doing this at the same time, which is called simultaneous rekeying. 811 Sections 2.8.1 and 2.8.2 of [RFC7296] describe how IKEv2 handles this 812 situation. In a nutshell IKEv2 follows the rule that if in case of 813 simultaneous rekeying, two identical new IKE SAs (or two pairs of 814 Child SAs) are created, then one of them should be deleted. Which 815 one is to be deleted is determined by comparing the values of four 816 nonces that are used in the colliding CREATE_CHILD_SA exchanges. The 817 IKE SA (or pair of Child SAs) that is created by the exchange in 818 which the smallest nonce is used should be deleted by the initiator 819 of this exchange. 821 With multiple key exchanges, the SAs are not yet created when the 822 CREATE_CHILD_SA is completed, they would be created only after the 823 series of IKE_FOLLOWUP_KE exchanges is finished. For this reason, if 824 additional key exchanges are negotiated in the CREATE_CHILD_SA 825 exchange in which the smallest nonce is used, then because there is 826 nothing to delete yet, the initiator of this exchange just stops the 827 rekeying process and it MUST NOT initiate the IKE_FOLLOWUP_KE 828 exchange. 830 In most cases, rekey collisions are resolved in the CREATE_CHILD_SA 831 exchange. However, a situation may occur when due to packet loss, 832 one of the peers receives the CREATE_CHILD_SA message requesting 833 rekey of SA that is already being rekeyed by this peer (i.e. the 834 CREATE_CHILD_SA exchange initiated by this peer has been already 835 completed and the series of IKE_FOLLOWUP_KE exchanges is in 836 progress). In this case, a TEMPORARY_FAILURE notification MUST be 837 sent in response to such a request. 839 If multiple key exchanges are negotiated in the CREATE_CHILD_SA 840 exchange, then the resulting keys are computed as follows. 842 In case of IKE SA rekey: 844 SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)) 846 In case of Child SA creation or rekey: 848 KEYMAT = prf+ (SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)) 850 In both cases, SK_d is from the existing IKE SA; SK(0), Ni, Nr are 851 the shared key and nonces from the CREATE_CHILD_SA respectively; 852 SK(1)...SK(n) are the shared keys from additional key exchanges. 854 3.2.5. Interaction with Childless IKE SA 856 It is also possible to establish a fully post-quantum secure IKE SAs 857 from additional key exchanges without using IKE_INTERMEDIATE 858 exchanges. In this case, the IKE SA created from IKE_SA_INIT 859 exchange can be immediately rekeyed with CREATE_CHILD_SA using 860 additional key exchanges where IKE_FOLLOWUP_KE messages are used to 861 carry the key exchange payload. If classical key exchange method is 862 used in the IKE_SA_INIT message, the very first Child SA created in 863 IKE_AUTH will offer no resistance against the quantum threats. 864 Consequently, if the peers' local policy requires that all Child SAs 865 should be fully-protected, then the peers can avoid creating the very 866 first Child SA by adopting [RFC6023]. In this case, the peers 867 exchange CHILDLESS_IKEV2_SUPPORTED notification in the IKE_SA_INIT 868 exchange and a fully-protected Child SA can be created with 869 CREATE_CHILD_SA using additional key exchanges. 871 Note that if the initial IKE SA is used to transfer sensitive 872 information, then this information will not be protected using the 873 additional key exchanges, which may use post-quantum algorithms. 874 Consider G-IKEv2 protocol [I-D.ietf-ipsecme-g-ikev2] where the 875 cryptographic materials are sent from the group controller to the 876 group members when the initial IKE SA is created. In this 877 arrangement, the peers will have to use post-quantum algorithm in 878 Transform Type 4 in order to mitigate the risk of quantum attack. 880 4. IANA Considerations 882 This document adds new exchange type into the "IKEv2 Exchange Types" 883 registry: 885 IKE_FOLLOWUP_KE 887 This document renames Transform Type 4 defined in "Transform Type 888 Values" registry from "Diffie-Hellman Group (D-H)" to "Key Exchange 889 Method (KE)". 891 This document renames IKEv2 registry "Transform Type 4 - Diffie- 892 Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange 893 Method Transform IDs". 895 This document adds the following Transform Types to the "Transform 896 Type Values" registry: 898 Type Description Used In 899 ----------------------------------------------------------------- 900 Additional Key Exchange 1 (optional in IKE, AH, ESP) 901 Additional Key Exchange 2 (optional in IKE, AH, ESP) 902 Additional Key Exchange 3 (optional in IKE, AH, ESP) 903 Additional Key Exchange 4 (optional in IKE, AH, ESP) 904 Additional Key Exchange 5 (optional in IKE, AH, ESP) 905 Additional Key Exchange 6 (optional in IKE, AH, ESP) 906 Additional Key Exchange 7 (optional in IKE, AH, ESP) 908 This document defines a new Notify Message Type in the "Notify 909 Message Types - Status Types" registry: 911 ADDITIONAL_KEY_EXCHANGE 913 and a new Notify Message Type in the "Notify Message Types - Error 914 Types" registry: 916 STATE_NOT_FOUND 918 4.1. Additional Changes 920 RFC EDITOR PLEASE DELETE THIS SECTION. 922 It is assumed that RFCXXXX refers to this specification. 924 * Add a reference to RFCXXXX in the "Transform Type 4 - Diffie- 925 Hellman Group Transform IDs" registry. 927 * Replace the note on "Transform Type 4 - Diffie-Hellman Group 928 Transform IDs" registry with: This registry was originally named 929 "Transform Type 4 - Diffie-Hellman Group Transform IDs" and was 930 renamed to its current name by [RFCXXXX]. It has been referenced 931 in its original name in a number of RFCs prior to [RFCXXXX]. To 932 find out requirement levels for Key Exchange Methods for IKEv2, 933 see [RFC8247]. 935 * Add this note to "Transform Type Values" registry: Transform Type 936 "Transform Type 4 - Key Exchange Method Transform IDs" was 937 originally named "Transform Type 4 - Diffie-Hellman Group 938 Transform IDs" and was renamed to its current name by [RFCXXXX]. 939 It has been referenced in its original name in a number of RFCs 940 prior to [RFCXXXX]. All "Additional Key Exchange" entries use the 941 same "Transform Type 4 - Key Exchange Method Transform IDs" as the 942 "Key Exchange Method (KE)". 944 * Append this note to "Transform Type 4 - Diffie-Hellman Group 945 Transform IDs" registry: All "Additional Key Exchange" entries use 946 these values as the "Key Exchange Method (KE)". 948 5. Security Considerations 950 The key length of the Encryption Algorithm (Transform Type 1), the 951 Pseudorandom Function (Transform Type 2) and the Integrity Algorithm 952 (Transform Type 3), all have to be of sufficient length to prevent 953 attacks using Grover's algorithm [GROVER]. In order to use the 954 extension proposed in this document, the key lengths of these 955 transforms MUST be at least 256 bits long in order to provide 956 sufficient resistance to quantum attacks. Accordingly the post- 957 quantum security level achieved is at least 128 bits. 959 SKEYSEED is calculated from shared SK(x) using an algorithm defined 960 in Transform Type 2. While a quantum attacker may learn the value of 961 SK(x), if this value is obtained by means of a classical key 962 exchange, other SK(x) values generated by means of a quantum- 963 resistant algorithm ensure that the final SKEYSEED is not 964 compromised. This assumes that the algorithm defined in the 965 Transform Type 2 is post-quantum. 967 The main focus of this document is to prevent a passive attacker 968 performing a "harvest and decrypt" attack. In other words, an 969 attacker that records messages exchanged today and proceeds to 970 decrypt them once he owns a quantum computer. This attack is 971 prevented due to the hybrid nature of the key exchange. Other 972 attacks involving an active attacker using a quantum-computer are not 973 completely solved by this document. This is for two reasons. 975 The first reason is because the authentication step remains 976 classical. In particular, the authenticity of the SAs established 977 under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA 978 algorithms. Whilst the pre-shared key option, provided the key is 979 long enough, is post-quantum secure, the other algorithms are not. 980 Moreover, in implementations where scalability is a requirement, the 981 pre-shared key method may not be suitable. Post-quantum authenticity 982 may be provided by using a post-quantum digital signature and several 983 of them have been being explored by IETF. For example, if the 984 implementation is able to reliably track state, the hash based 985 method, XMSS has the status of an RFC, see [RFC8391]. Currently, 986 post-quantum authentication methods are not specified in this 987 document, but are planned to be incorporated in due course. 989 Secondly, it should be noted that the purpose of post-quantum 990 algorithms is to provide resistance to attacks mounted in the future. 991 The current threat is that encrypted sessions are subject to 992 eavesdropping and archived with decryption by quantum computers 993 taking place at some point in the future. Until quantum computers 994 become available there is no point in attacking the authenticity of a 995 connection because there are no possibilities for exploitation. 996 These only occur at the time of the connection, for example by 997 mounting a man-in-the-middle (MitM) attack. Consequently there is 998 less urgency for post-quantum authenticity compared to post-quantum 999 confidentiality. 1001 Performing multiple key exchanges while establishing IKEv2 SA 1002 increases the responder's susceptibility to DoS attacks, because of 1003 an increased amount of resources needed before the initiator is 1004 authenticated. This is especially true for post-quantum key exchange 1005 methods, where many of them are more memory and/or CPU intensive than 1006 the classical counterparts. 1008 Responders may consider recommendations from [RFC8019] to deal with 1009 increased DoS attack susceptibility. It is also possible that the 1010 responder only agrees to create initial IKE SA without performing 1011 additional key exchanges, provided the initiator includes such an 1012 option in its proposals. Then peers immediately rekey the initial 1013 IKE SA with the CREATE_CHILD_SA exchange and additional key exchanges 1014 performed via the IKE_FOLLOWUP_KE exchanges. In this case, at the 1015 point when resource-intensive operations are required, the peers have 1016 already authenticated each other. However, in the context of hybrid 1017 post-quantum key exchange this scenario would leave the initial IKE 1018 SA (and initial Child SA if it is created) unprotected against 1019 quantum computers. Nevertheless the rekeyed IKE SA (and Child SAs 1020 that will be created over it) will have a full protection. This is 1021 similar to the scenario described in [RFC8784]. Depending on peers' 1022 policy, this scenario may or may not be appropriate. 1024 6. Acknowledgements 1026 The authors would like to thank Frederic Detienne and Olivier Pelerin 1027 for their comments and suggestions, including the idea to negotiate 1028 the post-quantum algorithms using the existing KE payload. The 1029 authors are also grateful to Tobias Heider and Tobias Guggemos for 1030 valuable comments. Thanks to Paul Wouters for reviewing the 1031 document. 1033 7. References 1035 7.1. Normative References 1037 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1038 Requirement Levels", BCP 14, RFC 2119, 1039 DOI 10.17487/RFC2119, March 1997, 1040 . 1042 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1043 Kivinen, "Internet Key Exchange Protocol Version 2 1044 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1045 2014, . 1047 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1048 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1049 May 2017, . 1051 [RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key 1052 Exchange Protocol Version 2 (IKEv2)", RFC 9242, 1053 DOI 10.17487/RFC9242, May 2022, 1054 . 1056 7.2. Informative References 1058 [GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for 1059 Database Search", Proc. of the Twenty-Eighth Annual ACM 1060 Symposium on the Theory of Computing (STOC 1996), 1996. 1062 [I-D.ietf-ipsecme-g-ikev2] 1063 Smyslov, V. and B. Weis, "Group Key Management using 1064 IKEv2", Work in Progress, Internet-Draft, draft-ietf- 1065 ipsecme-g-ikev2-06, 6 April 2022, . 1068 [I-D.tjhai-ikev2-beyond-64k-limit] 1069 Tjhai, C., Heider, T., and V. Smyslov, "Beyond 64KB Limit 1070 of IKEv2 Payloads", Work in Progress, Internet-Draft, 1071 draft-tjhai-ikev2-beyond-64k-limit-02, 28 January 2022, 1072 . 1075 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1076 DOI 10.17487/RFC4302, December 2005, 1077 . 1079 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1080 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1081 . 1083 [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A 1084 Childless Initiation of the Internet Key Exchange Version 1085 2 (IKEv2) Security Association (SA)", RFC 6023, 1086 DOI 10.17487/RFC6023, October 2010, 1087 . 1089 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 1090 (IKEv2) Message Fragmentation", RFC 7383, 1091 DOI 10.17487/RFC7383, November 2014, 1092 . 1094 [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange 1095 Protocol Version 2 (IKEv2) Implementations from 1096 Distributed Denial-of-Service Attacks", RFC 8019, 1097 DOI 10.17487/RFC8019, November 2016, 1098 . 1100 [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. 1101 Mohaisen, "XMSS: eXtended Merkle Signature Scheme", 1102 RFC 8391, DOI 10.17487/RFC8391, May 2018, 1103 . 1105 [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, 1106 "Mixing Preshared Keys in the Internet Key Exchange 1107 Protocol Version 2 (IKEv2) for Post-quantum Security", 1108 RFC 8784, DOI 10.17487/RFC8784, June 2020, 1109 . 1111 Appendix A. Sample Multiple Key Exchanges 1113 This appendix shows some examples of multiple key exchanges. These 1114 examples are purely for information purposes and they describe some 1115 message flow scenarios that may occur in establishing an IKE or CHILD 1116 SA. Note that some payloads that are not relevant to multiple key 1117 exchanges may be omitted for brevity. 1119 A.1. IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange 1120 Payloads 1122 The exchanges below show that the initiator proposes the use of 1123 additional key exchanges to establish an IKE SA. The initiator 1124 proposes three sets of additional key exchanges and all of which are 1125 optional. So the responder can choose NONE for some or all of the 1126 additional exchanges if the proposed key exchange methods are not 1127 supported or for whatever reasons the responder decides not to 1128 perform the additional key exchange. 1130 Initiator Responder 1131 ------------------------------------------------------------------------ 1132 HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> 1133 KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), 1134 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 1135 Proposal #1 1136 Transform ECR (ID = ENCR_AES_GCM_16, 1137 256-bit key) 1138 Transform PRF (ID = PRF_HMAC_SHA2_512) 1139 Transform KE (ID = Curve25519) 1140 Transform AKE1 (ID = PQ_KEM_1) 1141 Transform AKE1 (ID = PQ_KEM_2) 1142 Transform AKE1 (ID = NONE) 1143 Transform AKE2 (ID = PQ_KEM_3) 1144 Transform AKE2 (ID = PQ_KEM_4) 1145 Transform AKE2 (ID = NONE) 1146 Transform AKE3 (ID = PQ_KEM_5) 1147 Transform AKE3 (ID = PQ_KEM_6) 1148 Transform AKE3 (ID = NONE) 1149 <--- HDR(IKE_SA_INIT), SAr1(.. AKE*...), 1150 KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), 1151 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 1152 Proposal #1 1153 Transform ECR (ID = ENCR_AES_GCM_16, 1154 256-bit key) 1155 Transform PRF (ID = PRF_HMAC_SHA2_512) 1156 Transform KE (ID = Curve25519) 1157 Transform AKE1 (ID = PQ_KEM_2) 1158 Transform AKE2 (ID = NONE) 1159 Transform AKE3 (ID = PQ_KEM_5) 1161 HDR(IKE_INTERMEDIATE), SK {KEi(1)(PQ_KEM_2)} --> 1162 <--- HDR(IKE_INTERMEDIATE), SK {KEr(1)(PQ_KEM_2)} 1163 HDR(IKE_INTERMEDIATE), SK {KEi(2)(PQ_KEM_5)} --> 1164 <--- HDR(IKE_INTERMEDIATE), SK {KEr(2)(PQ_KEM_5)} 1166 HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } ---> 1167 <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2, 1168 TSi, TSr } 1170 In this particular example, the responder chooses to perform two 1171 additional key exchanges. It selects PQ_KEM_2, NONE and PQ_KEM_5 for 1172 the first, second and third additional key exchanges respectively. 1173 As per [RFC7296] specification, a set of keying materials are 1174 derived, in particular SK_d, SK_a[i/r], SK_e[i/r]. Both peers then 1175 perform an IKE_INTERMEDIATE exchange carrying PQ_KEM_2 payload which 1176 is protected with SK_e[i/r] and SK_a[i/r] keys. After the completion 1177 of this IKE_INTERMEDIATE exchange, the SKEYSEED is updated using 1178 SK(1), which is the PQ_KEM_2 shared secret, as follows 1180 SKEYSEED(1) = prf(SK_d, SK(1) | Ni | Nr). 1182 The updated SKEYSEED value is then used to derive the following 1183 keying materials 1185 {SK_d(1) | SK_ai(1) | SK_ar(1) | SK_ei(1) | SK_er(1) | SK_pi(1) | 1186 SK_pr(1)} = prf+ (SKEYSEED(1), Ni | Nr | SPIi | SPIr). 1188 As per [RFC9242] specification, both peers compute IntAuth_i1 and 1189 IntAuth_r1 using the SK_pi(1) and SK_pr(1) keys respectively. These 1190 values are required in the IKE_AUTH phase of the exchange. 1192 In the next IKE_INTERMEDIATE exchange, the peers use SK_e[i/r](1) and 1193 SK_a[i/r](1) keys to protect the PQ_KEM_5 payload. After completing 1194 this exchange, keying materials are updated as below 1196 SKEYSEED(2) = prf(SK_d(1), SK(2) | Ni | Nr) 1197 {SK_d(2) | SK_ai(2) | SK_ar(2) | SK_ei(2) | SK_er(2) | SK_pi(2) | 1198 SK_pr(2)} = prf+ (SKEYSEED(2), Ni | Nr | SPIi | SPIr) 1200 where SK(2) is the shared secret from the third additional key 1201 exchange, i.e. PQ_KEM_5. Both peers then computes the values of 1202 IntAuth_[i/r]2 using the SK_p[i/r](2) keys. 1204 After the completion of the second IKE_INTERMEDIATE exchange, both 1205 peers continue to the IKE_AUTH exchange phase. As defined in 1206 [RFC9242], the values IntAuth_[i/r]2 are used to compute IntAuth 1207 which in turn is used to calculate the payload to be signed or MACed, 1208 i.e. InitiatorSignedOctets and ResponderSignedOctets. 1210 A.2. No Additional Key Exchange Used 1212 The initiator proposes two sets of optional additional key exchanges, 1213 but the responder does not support any of them. The responder 1214 chooses NONE for each set and consequently, IKE_INTERMEDIATE exchange 1215 does not takes place and the exchange proceeds to IKE_AUTH phase. 1216 The resulting keying materials are the same as those derived with 1217 [RFC7296]. 1219 Initiator Responder 1220 ----------------------------------------------------------------------- 1221 HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> 1222 KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), 1223 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 1224 Proposal #1 1225 Transform ECR (ID = ENCR_AES_GCM_16, 1226 256-bit key) 1227 Transform PRF (ID = PRF_HMAC_SHA2_512) 1228 Transform KE (ID = Curve25519) 1229 Transform AKE1 (ID = PQ_KEM_1) 1230 Transform AKE1 (ID = PQ_KEM_2) 1231 Transform AKE1 (ID = NONE) 1232 Transform AKE2 (ID = PQ_KEM_3) 1233 Transform AKE2 (ID = PQ_KEM_4) 1234 Transform AKE2 (ID = NONE) 1235 <--- HDR(IKE_SA_INIT), SAr1(.. AKE*...), 1236 KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), 1237 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 1238 Proposal #1 1239 Transform ECR (ID = ENCR_AES_GCM_16, 1240 256-bit key) 1241 Transform PRF (ID = PRF_HMAC_SHA2_512) 1242 Transform KE (ID = Curve25519) 1243 Transform AKE1 (ID = NONE) 1244 Transform AKE2 (ID = NONE) 1246 HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } ---> 1247 <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2, 1248 TSi, TSr } 1250 A.3. Additional Key Exchange in the CREATE_CHILD_SA Exchange only 1252 The exchanges below show that the initiator does not propose the use 1253 of additional key exchanges to establish an IKE SA, but they are 1254 required in order to establish a Child SA. In order to establish a 1255 fully quantum-resistant IPsec SA, both peers include 1256 CHILDLESS_IKEV2_SUPPORTED notification in their exchange so that the 1257 first Child SA is not created in IKE_AUTH, but instead the IKE SA is 1258 immediately rekeyed using CREATED_CHILD_SA. Any Child SA will have 1259 to be created via subsequent CREATED_CHILD_SA exchange. 1261 Initiator Responder 1262 ----------------------------------------------------------------------- 1263 HDR(IKE_SA_INIT), SAi1, ---> 1264 KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), 1265 N(CHILDLESS_IKEV2_SUPPORTED) 1266 <--- HDR(IKE_SA_INIT), SAr1, 1267 KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), 1268 N(CHILDLESS_IKEV2_SUPPORTED) 1269 HDR(IKE_AUTH), SK{ IDi, AUTH } ---> 1270 <--- HDR(IKE_AUTH), SK{ IDr, AUTH } 1271 HDR(CREATE_CHILD_SA), SK{ SAi(.. AKE*...), Ni, KEi(Curve25519) } ---> 1272 Proposal #1 1273 Transform ECR (ID = ENCR_AES_GCM_16, 1274 256-bit key) 1275 Transform PRF (ID = PRF_HMAC_SHA2_512) 1276 Transform KE (ID = Curve25519) 1277 Transform AKE1 (ID = PQ_KEM_1) 1278 Transform AKE1 (ID = PQ_KEM_2) 1279 Transform AKE2 (ID = PQ_KEM_5) 1280 Transform AKE2 (ID = PQ_KEM_6) 1281 Transform AKE2 (ID = NONE) 1282 <--- HDR(CREATE_CHILD_SA), SK{ SAr(.. AKE*...), 1283 Nr, KEr(Curve25519), 1284 N(ADDITIONAL_KEY_EXCHANGE)(link1) } 1285 Proposal #1 1286 Transform ECR (ID = ENCR_AES_GCM_16, 1287 256-bit key) 1288 Transform PRF (ID = PRF_HMAC_SHA2_512) 1289 Transform KE (ID = Curve25519) 1290 Transform AKE1 (ID = PQ_KEM_2) 1291 Transform AKE2 (ID = PQ_KEM_5) 1293 HDR(IKE_FOLLOWUP_KE), SK{ KEi(1)(PQ_KEM_2), ---> 1294 N(ADDITIONAL_KEY_EXCHANGE)(link1) } 1295 <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(1)(PQ_KEM_2), 1296 N(ADDITIONAL_KEY_EXCHANGE)(link2) } 1297 HDR(IKE_FOLLOWUP_KE), SK{ KEi(2)(PQ_KEM_5), ---> 1298 N(ADDITIONAL_KEY_EXCHANGE)(link2) } 1299 <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(2)(PQ_KEM_5) } 1301 A.4. Not Matching Proposal for Additional Key Exchanges 1303 The initiator proposes the combination of PQ_KEM_1, PQ_KEM_2, 1304 PQ_KEM_3, and PQ_KEM_4 as the additional key exchanges. The 1305 initiator indicates that either PQ_KEM_1 or PQ_KEM_2 must be used to 1306 establish a security association, but Additional Key Exchange 2 is 1307 optional so the responder can either select PQ_KEM_3 or PQ_KEM_4 or 1308 omit this key exchange by selecting NONE. The responder, although 1309 supports the optional PQ_KEM_3 and PQ_KEM_4 methods, does not support 1310 either PQ_KEM_1 or PQ_KEM_2 mandatory method and therefore responds 1311 with NO_PROPOSAL_CHOSEN notification. 1313 Initiator Responder 1314 ----------------------------------------------------------------------- 1315 HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> 1316 KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), 1317 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 1318 Proposal #1 1319 Transform ECR (ID = ENCR_AES_GCM_16, 1320 256-bit key) 1321 Transform PRF (ID = PRF_HMAC_SHA2_512) 1322 Transform KE (ID = Curve25519) 1323 Transform AKE1 (ID = PQ_KEM_1) 1324 Transform AKE1 (ID = PQ_KEM_2) 1325 Transform AKE2 (ID = PQ_KEM_3) 1326 Transform AKE2 (ID = PQ_KEM_4) 1327 Transform AKE2 (ID = NONE) 1328 <--- HDR(IKE_SA_INIT), N(NO_PROPOSAL_CHOSEN) 1330 Appendix B. Alternative Design 1332 This section gives an overview on a number of alternative approaches 1333 that we have considered, but later discarded. These approaches are: 1335 * Sending the classical and post-quantum key exchanges as a single 1336 transform 1338 We considered combining the various key exchanges into a single 1339 large KE payload; this effort is documented in a previous version 1340 of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This 1341 does allow us to cleanly apply hybrid key exchanges during the 1342 child SA; however it does add considerable complexity, and 1343 requires an independent fragmentation solution. 1345 * Sending post-quantum proposals and policies in KE payload only 1347 With the objective of not introducing unnecessary notify payloads, 1348 we considered communicating the hybrid post-quantum proposal in 1349 the KE payload during the first pass of the protocol exchange. 1350 Unfortunately, this design is susceptible to the following 1351 downgrade attack. Consider the scenario where there is an MitM 1352 attacker sitting between an initiator and a responder. The 1353 initiator proposes, through SAi payload, to use a hybrid post- 1354 quantum group and as a backup a Diffie-Hellman group, and through 1355 KEi payload, the initiator proposes a list of hybrid post-quantum 1356 proposals and policies. The MitM attacker intercepts this traffic 1357 and replies with N(INVALID_KE_PAYLOAD) suggesting to downgrade to 1358 the backup Diffie-Hellman group instead. The initiator then 1359 resends the same SAi payload and the KEi payload containing the 1360 public value of the backup Diffie-Hellman group. Note that the 1361 attacker may forward the second IKE_SA_INIT message only to the 1362 responder, and therefore at this point in time, the responder will 1363 not have the information that the initiator prefers the hybrid 1364 group. Of course, it is possible for the responder to have a 1365 policy to reject an IKE_SA_INIT message that (a) offers a hybrid 1366 group but not offering the corresponding public value in the KEi 1367 payload; and (b) the responder has not specifically acknowledged 1368 that it does not supported the requested hybrid group. However, 1369 the checking of this policy introduces unnecessary protocol 1370 complexity. Therefore, in order to fully prevent any downgrade 1371 attacks, using KE payload alone is not sufficient and that the 1372 initiator MUST always indicate its preferred post-quantum 1373 proposals and policies in a notify payload in the subsequent 1374 IKE_SA_INIT messages following a N(INVALID_KE_PAYLOAD) response. 1376 * New payload types to negotiate hybrid proposal and to carry post- 1377 quantum public values 1379 Semantically, it makes sense to use a new payload type, which 1380 mimics the SA payload, to carry a hybrid proposal. Likewise, 1381 another new payload type that mimics the KE payload, could be used 1382 to transport hybrid public value. Although, in theory a new 1383 payload type could be made backwards compatible by not setting its 1384 critical flag as per Section 2.5 of RFC7296, we believe that it 1385 may not be that simple in practice. Since the original release of 1386 IKEv2 in RFC4306, no new payload type has ever been proposed and 1387 therefore, this creates a potential risk of having a backward 1388 compatibility issue from non-conforming RFC IKEv2 implementations. 1389 Since we could not see any other compelling advantages apart from 1390 a semantic one, we use the existing transform type and notify 1391 payloads instead. 1393 * Hybrid public value payload 1395 One way to transport the negotiated hybrid public payload, which 1396 contains one classical Diffie-Hellman public value and one or more 1397 post-quantum public values, is to bundle these into a single KE 1398 payload. Alternatively, these could also be transported in a 1399 single new hybrid public value payload, but following the same 1400 reasoning as above, this may not be a good idea from a backward 1401 compatibility perspective. Using a single KE payload would 1402 require an encoding or formatting to be defined so that both peers 1403 are able to compose and extract the individual public values. 1404 However, we believe that it is cleaner to send the hybrid public 1405 values in multiple KE payloads--one for each group or algorithm. 1406 Furthermore, at this point in the protocol exchange, both peers 1407 should have indicated support of handling multiple KE payloads. 1409 * Fragmentation 1411 Handling of large IKE_SA_INIT messages has been one of the most 1412 challenging tasks. A number of approaches have been considered 1413 and the two prominent ones that we have discarded are outlined as 1414 follows. 1416 The first approach was to treat the entire IKE_SA_INIT message as 1417 a stream of bytes, which we then split it into a number of 1418 fragments, each of which is wrapped onto a payload that would fit 1419 into the size of the network MTU. The payload that wraps each 1420 fragment is a new payload type and it was envisaged that this new 1421 payload type will not cause a backward compatibility issue because 1422 at this stage of the protocol, both peers should have indicated 1423 support of fragmentation in the first pass of the IKE_SA_INIT 1424 exchange. The negotiation of fragmentation is performed using a 1425 notify payload, which also defines supporting parameters such as 1426 the size of fragment in octets and the fragment identifier. The 1427 new payload that wraps each fragment of the messages in this 1428 exchange is assigned the same fragment identifier. Furthermore, 1429 it also has other parameters such as a fragment index and total 1430 number of fragments. We decided to discard this approach due to 1431 its blanket approach to fragmentation. In cases where only a few 1432 payloads need to be fragmented, we felt that this approach is 1433 overly complicated. 1435 Another idea that was discarded was fragmenting an individual 1436 payload without introducing a new payload type. The idea was to 1437 use the 9-th bit (the bit after the critical flag in the RESERVED 1438 field) in the generic payload header as a flag to mark that this 1439 payload is fragmented. As an example, if a KE payload is to be 1440 fragmented, it may look as follows. 1442 1 2 3 1443 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 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | Next Payload |C|F| RESERVED | Payload Length | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | Diffie-Hellman Group Number | Fragment Identifier | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Fragment Index | Total Fragments | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | Total KE Payload Data Length | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | | 1454 ~ Fragmented KE Payload ~ 1455 | | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 When the flag F is set, this means the current KE payload is a 1459 fragment of a larger KE payload. The Payload Length field denotes 1460 the size of this payload fragment in octets--including the size of 1461 the generic payload header. The two-octet RESERVED field 1462 following Diffie-Hellman Group Number was to be used as a fragment 1463 identifier to help assembly and disassembly of fragments. The 1464 Fragment Index and Total Fragments fields are self-explanatory. 1465 The Total KE Payload Data Length indicates the size of the 1466 assembled KE payload data in octets. Finally, the actual fragment 1467 is carried in Fragment KE Payload field. 1469 We discarded this approach because we believe that the working 1470 group may not be happy using the RESERVED field to change the 1471 format of a packet and that implementers may not like the 1472 complexity added from checking the fragmentation flag in each 1473 received payload. More importantly, fragmenting the messages in 1474 this way may leave the system to be more prone to denial of 1475 service (DoS) attacks. By using IKE_INTERMEDIATE to transport the 1476 large post-quantum key exchange payloads, and using the generic 1477 IKEv2 fragmentation protocol [RFC7383] solve the issue. 1479 * Group sub-identifier 1480 As discussed before, each group identifier is used to distinguish 1481 a post-quantum algorithm. Further classification could be made on 1482 a particular post-quantum algorithm by assigning additional value 1483 alongside the group identifier. This sub- identifier value may be 1484 used to assign different security parameter sets to a given post- 1485 quantum algorithm. However, this level of details does not fit 1486 the principles of the document where it should deal with generic 1487 hybrid key exchange protocol, not a specific ciphersuite. 1488 Furthermore, there are enough Diffie- Hellman group identifiers 1489 should this be required in the future. 1491 Authors' Addresses 1493 C. Tjhai 1494 Post-Quantum 1495 Email: cjt@post-quantum.com 1497 M. Tomlinson 1498 Post-Quantum 1499 Email: mt@post-quantum.com 1501 G. Bartlett 1502 Quantum Secret 1503 Email: graham.ietf@gmail.com 1505 S. Fluhrer 1506 Cisco Systems 1507 Email: sfluhrer@cisco.com 1509 D. Van Geest 1510 ISARA Corporation 1511 Email: daniel.vangeest@isara.com 1513 O. Garcia-Morchon 1514 Philips 1515 Email: oscar.garcia-morchon@philips.com 1517 Valery Smyslov 1518 ELVIS-PLUS 1519 Email: svan@elvis.ru