idnits 2.17.1 draft-ietf-ipsecme-ikev2-multiple-ke-12.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 (1 December 2022) is 513 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 611, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 956, but not defined == Missing Reference: 'RFC8247' is mentioned on line 949, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-ipsecme-g-ikev2-07 Summary: 0 errors (**), 0 flaws (~~), 5 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: 4 June 2023 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 1 December 2022 17 Multiple Key Exchanges in IKEv2 18 draft-ietf-ipsecme-ikev2-multiple-ke-12 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. 27 The primary application of this feature in IKEv2 is the ability to 28 perform one or more post-quantum key exchanges in conjunction with 29 the classical (Elliptic Curve) Diffie-Hellman (EC)DH key exchange, so 30 that the resulting shared key is resistant against quantum computer 31 attacks. Since there is currently no post-quantum key exchange that 32 is as well-studied as (EC)DH, performing multiple key exchanges with 33 different post-quantum algorithms along with the well-established 34 classical key exchange algorithms addresses this concern, since the 35 overall security is at least as strong as each individual primitive. 37 Another possible application for this extension is the ability to 38 combine several key exchanges in situations when no single key 39 exchange algorithm is trusted by both initiator and responder. 41 This document utilizes the IKE_INTERMEDIATE exchange, by means of 42 which multiple key exchanges are performed when an IKE SA is being 43 established. It also introduces a new IKEv2 exchange 44 IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA 45 is up (during rekeys or creating additional Child SAs). 47 This document updates RFC7296 by renaming a transform type 4 from 48 "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and 49 renaming a field in the Key Exchange Payload from "Diffie-Hellman 50 Group Num" to "Key Exchange Method". It also renames an IANA 51 registry for this transform type from "Transform Type 4 - Diffie- 52 Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange 53 Method Transform IDs". These changes generalize key exchange 54 algorithms that can be used in IKEv2. 56 Status of This Memo 58 This Internet-Draft is submitted in full conformance with the 59 provisions of BCP 78 and BCP 79. 61 Internet-Drafts are working documents of the Internet Engineering 62 Task Force (IETF). Note that other groups may also distribute 63 working documents as Internet-Drafts. The list of current Internet- 64 Drafts is at https://datatracker.ietf.org/drafts/current/. 66 Internet-Drafts are draft documents valid for a maximum of six months 67 and may be updated, replaced, or obsoleted by other documents at any 68 time. It is inappropriate to use Internet-Drafts as reference 69 material or to cite them other than as "work in progress." 71 This Internet-Draft will expire on 4 June 2023. 73 Copyright Notice 75 Copyright (c) 2022 IETF Trust and the persons identified as the 76 document authors. All rights reserved. 78 This document is subject to BCP 78 and the IETF Trust's Legal 79 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 80 license-info) in effect on the date of publication of this document. 81 Please review these documents carefully, as they describe your rights 82 and restrictions with respect to this document. Code Components 83 extracted from this document must include Revised BSD License text as 84 described in Section 4.e of the Trust Legal Provisions and are 85 provided without warranty as described in the Revised BSD License. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 90 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3 91 1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . 4 92 1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 5 93 1.4. Document Organization . . . . . . . . . . . . . . . . . . 7 94 2. Multiple Key Exchanges . . . . . . . . . . . . . . . . . . . 8 95 2.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 8 96 2.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 10 97 2.2.1. IKE_SA_INIT Round: Negotiation . . . . . . . . . . . 10 98 2.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges . . 15 99 2.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 16 100 2.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 16 101 2.2.5. Interaction with IKEv2 Extensions . . . . . . . . . . 19 102 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 103 3.1. Additional Considerations and Changes . . . . . . . . . . 21 104 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 105 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 106 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 107 6.1. Normative References . . . . . . . . . . . . . . . . . . 24 108 6.2. Informative References . . . . . . . . . . . . . . . . . 25 109 Appendix A. Sample Multiple Key Exchanges . . . . . . . . . . . 26 110 A.1. IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange 111 Payloads . . . . . . . . . . . . . . . . . . . . . . . . 26 112 A.2. No Additional Key Exchange Used . . . . . . . . . . . . . 28 113 A.3. Additional Key Exchange in the CREATE_CHILD_SA Exchange 114 only . . . . . . . . . . . . . . . . . . . . . . . . . . 29 115 A.4. No Matching Proposal for Additional Key Exchanges . . . . 31 116 Appendix B. Design Criteria . . . . . . . . . . . . . . . . . . 31 117 Appendix C. Alternative Design . . . . . . . . . . . . . . . . . 33 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 120 1. Introduction 122 1.1. Problem Description 124 Internet Key Exchange Protocol (IKEv2) as specified in [RFC7296] uses 125 the Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) 126 algorithm, which shall be referred to as (EC)DH collectively, to 127 establish a shared secret between an initiator and a responder. The 128 security of the (EC)DH algorithms relies on the difficulty to solve a 129 discrete logarithm problem in multiplicative (and respectively 130 elliptic curve) groups when the order of the group parameter is large 131 enough. While solving such a problem remains infeasible with current 132 computing power, it is believed that general purpose quantum 133 computers will be able to solve this problem, implying that the 134 security of IKEv2 is compromised. There are, however, a number of 135 cryptosystems that are conjectured to be resistant against quantum 136 computer attack. This family of cryptosystems is known as post- 137 quantum cryptography (PQC). It is sometimes also referred to as 138 quantum-safe cryptography (QSC) or quantum-resistant cryptography 139 (QRC). 141 1.2. Proposed Extension 143 This document describes a method to perform multiple successive key 144 exchanges in IKEv2. It allows integration of PQC in IKEv2, while 145 maintaining backwards compatibility, to derive a set of IKE keys that 146 is resistant to quantum computer attacks. This extension allows the 147 negotiation of one or more PQC algorithm to exchange data, in 148 addition to the existing (EC)DH key exchange data. It is believed 149 that the feature of using more than one post-quantum algorithms is 150 important as many of these algorithms are relatively new and there 151 may be a need to hedge the security risk with multiple key exchange 152 data from several distinct PQC algorithms. 154 IKE peers perform multiple successive key exchanges to establish an 155 IKE Security Association (SA). Each exchange produces a piece of 156 secret and these secrets are combined in a way such that: 158 (a) the final shared secret is computed from all of the component 159 key exchange secret; 161 (b) the shared secret as specified in [RFC7296] is obtained unless 162 both peers support and agree to use the additional key exchanges 163 introduced in this specification; and 165 (c) if any of the component key exchange method is a post-quantum 166 algorithm, the final shared secret is post-quantum secure. 168 Some post-quantum key exchange payloads may have sizes larger than 169 the standard maximum transmission unit (MTU) size, and therefore 170 there could be issues with fragmentation at the IP layer. In order 171 to allow using those larger payload sizes, this mechanism relies on 172 the IKE_INTERMEDIATE exchange as specified in [RFC9242]. With this 173 mechanism, the key exchange is initiated using a smaller, possibly 174 classical primitive, such as (EC)DH. Then, before the IKE_AUTH 175 exchange, one or more IKE_INTERMEDIATE exchanges are carried out, 176 each of which contains an additional key exchange. As the 177 IKE_INTERMEDIATE exchange is encrypted, the IKE fragmentation 178 protocol [RFC7383] can be used. The IKE SK_* values are updated 179 after each exchange as described in Section 2.2.2, and so the final 180 IKE SA keys depend on all the key exchanges, hence they are secure if 181 any of the key exchanges are secure. 183 While this extension is primarily aimed for IKE SAs due to the 184 potential fragmentation issue discussed above, it also applies to 185 CREATE_CHILD_SA exchanges as illustrated in Section 2.2.4 for 186 creating/rekeying of Child SAs and rekeying of IKE SAs. 188 Note that readers should consider the approach defined in this 189 document as providing a long term solution in upgrading the IKEv2 190 protocol to support post-quantum algorithms. A short term solution 191 to make IKEv2 key exchange quantum secure is to use post-quantum pre- 192 shared keys as specified in [RFC8784]. 194 Note also that the proposed approach of performing multiple 195 successive key exchanges in such a way that resulting session keys 196 depend on all of them is not limited to only addressing the threat of 197 quantum computer. It can also be used when all of the performed key 198 exchanges are classical (EC)DH primitives, where for some reasons 199 (e.g. policy requirements) it is essential to perform multiple of 200 them. 202 This specification does not attempt to address key exchanges with KE 203 payloads longer than 64 Kbytes; the current IKE payload format does 204 not allow such as possibility. At the time of writing, it appears 205 likely that there are a number of key exchanges available that would 206 not have such a requirement. However, if such a requirement is 207 needed, [I-D.tjhai-ikev2-beyond-64k-limit] discusses approaches that 208 could be taken to exchange huge payloads. 210 1.3. Changes 212 RFC EDITOR PLEASE DELETE THIS SECTION. 214 Changes in this draft in each version iterations. 216 draft-ietf-ipsecme-ikev2-multiple-ke-07 218 * Editorial changes. 220 draft-ietf-ipsecme-ikev2-multiple-ke-06 222 * Updated draft with the allocated IANA values. 224 * Editorial changes following AD review. 226 draft-ietf-ipsecme-ikev2-multiple-ke-05 228 * Updated the reference to RFC9242. 230 * Editorial changes. 232 draft-ietf-ipsecme-ikev2-multiple-ke-04 234 * Introduction and initial sections are reorganized. 236 * More clarifications for error handling added. 238 * ASCII arts displaying SA payload are added. 240 * Clarification for handling multiple round trips key exchange 241 methods added. 243 * DoS concerns added into Security Considerations section. 245 * Explicitly allow scenario when additional key exchanges are 246 performed only after peers are authenticated. 248 draft-ietf-ipsecme-ikev2-multiple-ke-03 250 * More clarifications added. 252 * Figure illustrating initial exchange added. 254 * Minor editorial changes. 256 draft-ietf-ipsecme-ikev2-multiple-ke-02 258 * Added a reference on the handling of KE payloads larger than 64KB. 260 draft-ietf-ipsecme-ikev2-multiple-ke-01 262 * References are updated. 264 draft-ietf-ipsecme-ikev2-multiple-ke-00 266 * Draft name changed as result of WG adoption and generalization of 267 the approach. 269 * New exchange IKE_FOLLOWUP_KE is defined for additional key 270 exchanges performed after CREATE_CHILD_SA. 272 * Nonces are removed from all additional key exchanges. 274 * Clarification that IKE_INTERMEDIATE must be negotiated is added. 276 draft-tjhai-ipsecme-hybrid-qske-ikev2-04 278 * Clarification about key derivation in case of multiple key 279 exchanges in CREATE_CHILD_SA is added. 281 * Resolving rekey collisions in case of multiple key exchanges is 282 clarified. 284 * Using multiple key exchanges CREATE_CHILD_SA is defined. 286 draft-tjhai-ipsecme-hybrid-qske-ikev2-02 288 * Use new transform types to negotiate additional key exchanges, 289 rather than using the KE payloads of IKE SA. 291 draft-tjhai-ipsecme-hybrid-qske-ikev2-01 293 * Use IKE_INTERMEDIATE to perform multiple key exchanges in 294 succession. 296 * Handle fragmentation by keeping the first key exchange (a standard 297 IKE_SA_INIT with a few extra notifies) small, and encrypting the 298 rest of the key exchanges. 300 * Simplify the negotiation of the 'extra' key exchanges. 302 draft-tjhai-ipsecme-hybrid-qske-ikev2-00 304 * Added a feature to allow more than one post-quantum key exchange 305 algorithms to be negotiated and used to exchange a post- quantum 306 shared secret. 308 * Instead of relying on TCP encapsulation to deal with IP level 309 fragmentation, a new key exchange payload that can be sent as 310 multiple fragments within IKE_SA_INIT message was introduced. 312 1.4. Document Organization 314 The remainder of this document is organized as follows. Section 2 315 describes how multiple key exchanges are performed between two IKE 316 peers and how keying materials are derived for both SAs and Child 317 SAs. Section 3 discusses IANA considerations for the namespaces 318 introduced in this document, and Section 4 discusses security 319 considerations. In the Appendices sections, some examples of 320 multiple key exchanges are illustrated in Appendix A, Appendix B 321 summarizes design criteria and a summary of alternative approaches 322 that have been considered, but later discarded, are described in 323 Appendix C. 325 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 326 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 327 "OPTIONAL" in this document are to be interpreted as described in BCP 328 14 [RFC2119] [RFC8174] when, and only when, they appear in all 329 capitals, as shown here. 331 2. Multiple Key Exchanges 333 2.1. Design Overview 335 Most post-quantum key agreement algorithms are relatively new, and 336 thus are not fully trusted. There are also many proposed algorithms, 337 with different trade-offs and relying on different hard problems. 338 The concern is that some of these hard problems may turn out to be 339 easier to solve than anticipated and thus the key agreement algorithm 340 may not be as secure as expected. A hybrid solution, when multiple 341 key exchanges are performed and the calculated shared key depends on 342 all of them, allows us to deal with this uncertainty by combining a 343 classical key exchange with a post-quantum one, as well as leaving 344 open the possibility of multiple post-quantum key exchanges. 346 In order to be able to use IKE fragmentation [RFC7383] for those key 347 exchanges that may have long public keys, this specification utilizes 348 the IKE_INTERMEDIATE exchange defined in [RFC9242]. The initial 349 IKE_SA_INIT messages do not have any inherent fragmentation support 350 within IKE; however, IKE_SA_INIT messages can include a relatively 351 short KE payload. The additional key exchanges are performed using 352 IKE_INTERMEDIATE messages that follow the IKE_SA_INIT exchange. This 353 is to allow the standard IKE fragmentation mechanisms (which cannot 354 be used in IKE_SA_INIT) to be available for the potentially large Key 355 Exchange payloads with post-quantum algorithm data. 357 Note that this document assumes, that each key exchange method 358 requires one round trip and consumes exactly one IKE_INTERMEDIATE 359 exchange. This assumption is valid for all classic key exchange 360 methods defined so far and for all post-quantum methods currently 361 known. For hypothetical future key exchange methods requiring 362 multiple round trips to complete, a separate document should define 363 how such methods are split into several IKE_INTERMEDIATE exchanges. 365 In order to minimize communication overhead, only the key shares that 366 are agreed to be used are actually exchanged. To negotiate 367 additional key exchanges seven new Transform Types are defined. 368 These transforms and Transform Type 4 share the same Transform IDs. 370 It is assumed that new Transform Type 4 identifiers will be assigned 371 later for various post-quantum key exchanges [IKEV2TYPE4ID]. This 372 specification does not make a distinction between classical (EC)DH 373 and post-quantum key exchanges, nor post-quantum algorithms which are 374 true key exchanges versus post-quantum algorithms that act as key 375 transport mechanisms; all are treated equivalently by the protocol. 376 This document renames a field in the Key Exchange Payload from 377 "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames 378 Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange 379 Method (KE)"; the corresponding renaming to the IANA registry is 380 described in Section 3. 382 The fact that newly defined transforms share the same registry for 383 possible Transform IDs with Transform Type 4, allows additional key 384 exchanges to be of any type - either post-quantum or classical (EC)DH 385 one. This approach allows any combination of the defined key 386 exchange methods to take place. This also allows IKE peers to 387 perform a single post-quantum key exchange in the IKE_SA_INIT without 388 additional key exchanges, provided that the IP fragmentation is not 389 an issue and that hybrid key exchange is not needed. 391 The SA payload in the IKE_SA_INIT message includes one or more newly 392 defined transforms which represent the extra key exchange policy 393 required by the initiator. The responder follows the usual IKEv2 394 negotiation rules: it selects a single transform of each type, and 395 returns all of them in the IKE_SA_INIT response message. 397 Then, provided that additional key exchanges are negotiated, the 398 initiator and the responder perform one or more IKE_INTERMEDIATE 399 exchanges. Following that, the IKE_AUTH exchange authenticates peers 400 and completes IKE SA establishment. 402 Initiator Responder 403 --------------------------------------------------------------------- 404 <-- IKE_SA_INIT (additional key exchanges negotiation) --> 406 <-- {IKE_INTERMEDIATE (additional key exchange)} --> 408 ... 410 <-- {IKE_INTERMEDIATE (additional key exchange)} --> 412 <-- {IKE_AUTH} --> 414 2.2. Protocol Details 416 In the simplest case, the initiator starts a single key exchange (and 417 has no interest in supporting multiple), and it is not concerned with 418 possible fragmentation of the IKE_SA_INIT messages (either because 419 the key exchange it selects is small enough not to fragment, or the 420 initiator is confident that fragmentation will be handled either by 421 IP fragmentation, or transport via TCP). 423 In this case, the initiator performs the IKE_SA_INIT for a single key 424 exchange using a Transform Type 4 (possibly with a post quantum 425 algorithm), and including the initator KE payload. If the responder 426 accepts the policy, it responds with an IKE_SA_INIT response, and IKE 427 continues as usual. 429 If the initiator desires to negotiate multiple key exchanges, then 430 the initiator uses the protocol behavior listed below. 432 2.2.1. IKE_SA_INIT Round: Negotiation 434 Multiple key exchanges are negotiated using the standard IKEv2 435 mechanism, via SA payload. For this purpose seven new transform 436 types, namely Additional Key Exchange 1 (with IANA assigned value 6), 437 Additional Key Exchange 2 (7), Additional Key Exchange 3 (8), 438 Additional Key Exchange 4 (9), Additional Key Exchange 5 (10), 439 Additional Key Exchange 6 (11) and Additional Key Exchange 7 (12) are 440 defined. They are collectively called Additional Key Exchange 441 transforms in this document and have slightly different semantics 442 than the existing IKEv2 transform types. They are interpreted as an 443 indication of additional key exchange methods that peers agree to 444 perform in a series of IKE_INTERMEDIATE exchanges following the 445 IKE_SA_INIT exchange. The allowed transform IDs for these transform 446 types are the same as the IDs for Transform Type 4, so they all share 447 a single IANA registry for transform IDs. 449 Key exchange method negotiated via Transform Type 4 always takes 450 place in the IKE_SA_INIT exchange, as defined in [RFC7296]. 451 Additional key exchanges negotiated via newly defined transforms MUST 452 take place in a series of IKE_INTERMEDIATE exchanges following the 453 IKE_SA_INIT exchange, performed in an order of the values of their 454 transform types, so that key exchange negotiated using Additional Key 455 Exchange i always precedes that of Additional Key Exchange i + 1. 456 Each additional key exchange method MUST be fully completed before 457 the next one is started. 459 Note that with these semantics, Additional Key Exchange transforms 460 are not associated with any particular type of key exchange and do 461 not have any specific per transform type transform IDs IANA registry. 463 Instead they all share a single registry for transform IDs, namely 464 "Key Exchange Method Transform IDs", which are also shared by 465 Transform Type 4. All key exchange algorithms (both classical or 466 post-quantum) should be added to this registry. This approach gives 467 peers flexibility in defining the ways they want to combine different 468 key exchange methods. 470 When forming a proposal the initiator adds transforms for the 471 IKE_SA_INIT exchange using Transform Type 4. In most cases they will 472 contain classical (EC)DH key exchange methods, however it is not a 473 requirement. Additional key exchange methods are proposed using 474 Additional Key Exchange transform types. All of these transform 475 types are optional, the initiator is free to select any of them for 476 proposing additional key exchange methods. Consequently, if none of 477 the Additional Key Exchange transforms is included in the proposal, 478 then this proposal indicates performing standard IKEv2, as defined in 479 [RFC7296]. On the other hand, if the initiator includes any 480 Additional Key Exchange transform in the proposal, the responder MUST 481 select one of the algorithms proposed using this type. Note that 482 this is not a new requirement, but that this behavior is already 483 specified in Section 2.7 of [RFC7296]. A transform ID NONE MAY be 484 added to those transform types which contain key exchange methods 485 that the initiator believes is optional according to its local 486 policy. 488 The responder performs the negotiation using the standard IKEv2 489 procedure described in Section 3.3 of [RFC7296]. However, for the 490 Additional Key Exchange types, the responder's choice MUST NOT 491 contain duplicated algorithms (those with identical Transform ID and 492 attributes), except for the transform ID of NONE. An algorithm is 493 represented as a transform, in some cases the transform could include 494 a set of associated attributes that define details of the algorithm. 495 In this case, two transforms can be the same, but the attributes must 496 be different. Additionally, the order of the attributes does not 497 affect the equality of the algorithm, so two transforms 498 (ID=alg1,ATTR1=attr1,ATTR2=attr2) and 499 (ID=alg1,ATTR2=attr2,ATTR1=attr1) define the same algorithm. If the 500 responder is unable to select non-duplicated algorithm for each 501 proposed key exchange (either because the proposal contains too few 502 choices or due to the local policy restrictions on using the proposed 503 algorithms), then the responder MUST reject the message with an error 504 notification of type NO_PROPOSAL_CHOSEN. If the responder's message 505 contains one or more duplicated choices, the initiator should log the 506 error and MUST treat the exchange as failed. The initiator MUST NOT 507 initiate any IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE) exchanges, so that 508 no new SA is created. If this happens in the CREATE_CHILD_SA 509 exchange, then the initiator MAY delete the IKE SA, over which the 510 invalid message was received, by sending a Delete payload. 512 If the responder selects NONE for some Additional Key Exchange types 513 (provided they are proposed by the initiator), then the corresponding 514 Additional Key Exchange(s) in the IKE_INTERMEDIATE exchange(s) MUST 515 NOT take place. Therefore if the initiator includes NONE in all of 516 the Additional Key Exchange transforms and the responder selects this 517 value for all of them, then no IKE_INTERMEDIATE messages performing 518 additional key exchanges will take place between the peers. Note 519 that the IKE_INTERMEDIATE exchanges may still take place for other 520 purposes. 522 The initiator MAY propose non-consecutive Additional Key Exchange 523 transforms, for example proposing Additional Key Exchange 2 and 524 Additional Key Exchange 5 transforms only. The responder MUST treat 525 all of the omitted Additional Key Exchange transforms as if they are 526 proposed with Transform ID NONE. 528 Below is an example of the SA payload in the initiator's IKE_SA_INIT 529 request message. Here the abbreviation AKEi is used to denote the 530 i-th Additional Key Exchange transform defined in this document, and 531 an abbreviation KE for the Key Exchange transform, that this document 532 renames from the Diffie-Hellman Group transform. Additionally, the 533 notations PQ_KEM_1, PQ_KEM_2 and PQ_KEM_3 are used to represent some 534 not-yet defined Transform IDs of some popular post-quantum key 535 exchange methods. 537 SA Payload 538 | 539 +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8, 540 | 9 transforms, SPI = 0x35a1d6f22564f89d ) 541 | 542 +-- Transform ENCR ( ID = ENCR_AES_GCM_16 ) 543 | +-- Attribute ( Key Length = 256 ) 544 | 545 +-- Transform KE ( ID = 4096-bit MODP Group ) 546 | 547 +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 ) 548 | 549 +-- Transform AKE2 ( ID = PQ_KEM_1 ) 550 | 551 +-- Transform AKE2 ( ID = PQ_KEM_2 ) 552 | 553 +-- Transform AKE3 ( ID = PQ_KEM_1 ) 554 | 555 +-- Transform AKE3 ( ID = PQ_KEM_2 ) 556 | 557 +-- Transform AKE5 ( ID = PQ_KEM_3 ) 558 | 559 +-- Transform AKE5 ( ID = NONE ) 561 In this example, the initiator proposes to perform initial key 562 exchange using 4096-bit MODP group followed by two mandatory 563 additional key exchanges (i.e. Transforms AKE2 and AKE3) using 564 PQ_KEM_1 and PQ_KEM_2 methods in any order, then followed by 565 additional key exchange (i.e. Transform AKE5) using PQ_KEM_3 method 566 that may be omitted. 568 The responder might return the following SA payload, indicating that 569 it agrees to perform two additional key exchanges PQ_KEM_2 followed 570 by PQ_KEM_1 and does not want to perform PQ_KEM_3 additionally. 572 SA Payload 573 | 574 +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8, 575 | 6 transforms, SPI = 0x8df52b331a196e7b ) 576 | 577 +-- Transform ENCR ( ID = ENCR_AES_GCM_16 ) 578 | +-- Attribute ( Key Length = 256 ) 579 | 580 +-- Transform KE ( ID = 4096-bit MODP Group ) 581 | 582 +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 ) 583 | 584 +-- Transform AKE2 ( ID = PQ_KEM_2 ) 585 | 586 +-- Transform AKE3 ( ID = PQ_KEM_1 ) 587 | 588 +-- Transform AKE5 ( ID = NONE ) 590 If the initiator includes any Additional Key Exchange transform types 591 into the SA payload in the IKE_SA_INIT exchange request message, then 592 it MUST also negotiate the use of the IKE_INTERMEDIATE exchange as 593 described in [RFC9242], by including INTERMEDIATE_EXCHANGE_SUPPORTED 594 notification in the same message. If the responder agrees to use 595 additional key exchanges while establishing initial IKE SA, it MUST 596 also return this notification in the IKE_SA_INIT response message, 597 thus confirming that IKE_INTERMEDIATE exchange is supported and will 598 be used for transferring additional key exchange data. If the 599 IKE_INTERMEDIATE exchange is not negotiated, then the peers MUST 600 treat any Additional Key Exchange transforms in the IKE_SA_INIT 601 exchange messages as unknown transform types and skip the proposals 602 they appear in. If no other proposals are present in the SA payload, 603 the peers will proceed as if no proposal is chosen (i.e. the 604 responder will send NO_PROPOSAL_CHOSEN notification). 606 Initiator Responder 607 --------------------------------------------------------------------- 608 HDR, SAi1(.. AKE*...), KEi, Ni, 609 N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> 610 HDR, SAr1(.. AKE*...), KEr, Nr, 611 [CERTREQ], 612 <--- N(INTERMEDIATE_EXCHANGE_SUPPORTED) 614 It is possible that an attacker manages to send a response to the 615 initiator's IKE_SA_INIT request before the legitimate responder does. 616 If the initiator continues to create the IKE SA using this response, 617 the attempt will fail. Implementers may wish to consider a possible 618 defense technique described in Section 2.4 of [RFC7296]. 620 2.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges 622 For each additional key exchange agreed to in the IKE_SA_INIT 623 exchange, the initiator and the responder perform IKE_INTERMEDIATE 624 exchange, as described in [RFC9242]. 626 Initiator Responder 627 --------------------------------------------------------------------- 628 HDR, SK {KEi(n)} --> 629 <-- HDR, SK {KEr(n)} 631 The initiator sends key exchange data in the KEi(n) payload. This 632 message is protected with the current SK_ei/SK_ai keys. The notation 633 KEi(n) denotes the n-th IKE_INTERMEDIATE KE payload from the 634 initiator and the integer n is sequential starting from 1. 636 On receiving this, the responder sends back key exchange payload 637 KEr(n), which denotes the n-th IKE_INTERMEDIATE KE payload from the 638 responder. As before, this message is protected with the current 639 SK_er/SK_ar keys. 641 The former "Diffie-Hellman Group Num" (now called "Key Exchange 642 Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th 643 negotiated additional key exchange. 645 Once this exchange is done, both sides compute an updated keying 646 material: 648 SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr) 650 where SK(n) is the resulting shared secret of this key exchange, Ni 651 and Nr are nonces from the IKE_SA_INIT exchange and SK_d(n-1) is the 652 last generated SK_d, (derived from IKE_SA_INIT for the first use of 653 IKE_INTERMEDIATE, otherwise from the previous IKE_INTERMEDIATE 654 exchange). The other keying materials SK_d, SK_ai, SK_ar, SK_ei, 655 SK_er, SK_pi, SK_pr are generated from the SKEYSEED(n) as follows: 657 {SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) | 658 SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr) 660 Both the initiator and the responder use these updated key values in 661 the next exchange (IKE_INTERMEDIATE or IKE_AUTH). 663 2.2.3. IKE_AUTH Exchange 665 After all IKE_INTERMEDIATE exchanges have completed, the initiator 666 and the responder perform an IKE_AUTH exchange. This exchange is the 667 standard IKE exchange as described in [RFC7296] with the modification 668 of AUTH payload calculation described in [RFC9242]. 670 2.2.4. CREATE_CHILD_SA Exchange 672 The CREATE_CHILD_SA exchange is used in IKEv2 for the purposes of 673 creating additional Child SAs, rekeying these and rekeying IKE SA 674 itself. When creating or rekeying Child SAs, the peers may 675 optionally perform a key exchange to add a fresh entropy into the 676 session keys. In case of IKE SA rekey, the key exchange is 677 mandatory. Peers supporting this specification may want to use 678 multiple key exchanges in these situations. 680 Using multiple key exchanges with CREATE_CHILD_SA exchange is 681 negotiated similarly as in the initial IKE exchange, see 682 Section 2.2.1. If the initiator includes any Additional Key Exchange 683 transform in the SA payload (along with Transform Type 4) and the 684 responder agrees to perform additional key exchanges, then the 685 additional key exchanges are performed in a series of new 686 IKE_FOLLOWUP_KE exchanges that follows the CREATE_CHILD_SA exchange. 687 The IKE_FOLLOWUP_KE exchange is introduced as a dedicated exchange 688 for transferring data of additional key exchanges following the key 689 exchange performed in the CREATE_CHILD_SA. Its Exchange Type value 690 is 44. 692 Key exchange negotiated via Transform Type 4 always takes place in 693 the CREATE_CHILD_SA exchange, as per IKEv2 specification. Additional 694 key exchanges are performed in an order of the values of their 695 transform types, so that key exchange negotiated using Transform Type 696 n always precedes key exchange negotiated using Transform Type n + 1. 697 Each additional key exchange method MUST be fully completed before 698 the next one is started. Note, that this document assumes, that each 699 key exchange method consumes exactly one IKE_FOLLOWUP_KE exchange. 700 For the methods requiring multiple round trips, a separate document 701 should define how such methods are split into several IKE_FOLLOWUP_KE 702 exchanges. 704 After an IKE SA is created the window size may be greater than one 705 and multiple concurrent exchanges may be in progress, it is essential 706 to link the IKE_FOLLOWUP_KE exchanges together with the corresponding 707 CREATE_CHILD_SA exchange. Due to the fact that once an IKE SA is 708 created, all IKE exchanges are independent and do not have built-in 709 means to link one with another, a new status type notification 710 ADDITIONAL_KEY_EXCHANGE is introduced for this purpose. Its Notify 711 Message Type value is 16441, and Protocol ID and SPI Size are both 712 set to 0. The data associated with this notification is a blob 713 meaningful only to the responder, so that the responder can correctly 714 link successive exchanges. For the initiator the content of this 715 notification is an opaque blob. 717 The responder MUST include this notification in a CREATE_CHILD_SA or 718 IKE_FOLLOWUP_KE response message in case the next IKE_FOLLOWUP_KE 719 exchange is expected, filling it with some data that would allow 720 linking the current exchange to the next one. The initiator MUST 721 send back this notification intact in the request message of the next 722 IKE_FOLLOWUP_KE exchange. 724 Below is an example of CREATE_CHILD_SA exchange followed by three 725 additional key exchanges. 727 Initiator Responder 728 --------------------------------------------------------------------- 729 HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> 730 <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, 731 N(ADDITIONAL_KEY_EXCHANGE)(link1)} 733 HDR(IKE_FOLLOWUP_KE), SK {KEi(1), 734 N(ADDITIONAL_KEY_EXCHANGE)(link1)} --> 735 <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1), 736 N(ADDITIONAL_KEY_EXCHANGE)(link2)} 738 HDR(IKE_FOLLOWUP_KE), SK {KEi(2), 739 N(ADDITIONAL_KEY_EXCHANGE)(link2)} --> 740 <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2), 741 N(ADDITIONAL_KEY_EXCHANGE)(link3)} 743 HDR(IKE_FOLLOWUP_KE), SK {KEi(3), 744 N(ADDITIONAL_KEY_EXCHANGE)(link3)} --> 745 <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(3)} 747 The former "Diffie-Hellman Group Num" (now called "Key Exchange 748 Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th 749 negotiated additional key exchange. 751 It is possible that due to some unexpected events (e.g. reboot) the 752 initiator may lose its state and forget that it is in the process of 753 performing additional key exchanges and thus never start the 754 remaining IKE_FOLLOWUP_KE exchanges. The responder MUST handle this 755 situation gracefully and delete the associated state if it does not 756 receive the next expected IKE_FOLLOWUP_KE request after some 757 reasonable period of time. Note that due to various factors such as 758 computational resource and key exchange algorithm used, it is not 759 possible to give a normative guidance on how long this timeout period 760 should be. In general, 5-20 seconds of waiting time should be 761 appropriate in most cases. 763 It is also possible that the initiator may take too long to prepare 764 and send the next IKE_FOLLOWUP_KE request or due to the network 765 conditions, the request is retransmitted. In this case, the message 766 may reach the responder when it has already deleted the associated 767 state following the advice above. If the responder receives an 768 IKE_FOLLOWUP_KE message for which it does not have a key exchange 769 state, it MUST send back a new error type notification 770 STATE_NOT_FOUND. This is a non-fatal error notification, its Notify 771 Message Type is 47, Protocol ID and SPI Size are both set to 0 and 772 the data is empty. If the initiator receives this notification in 773 response to IKE_FOLLOWUP_KE exchange performing additional key 774 exchange, it MUST cancel this exchange and MUST treat the whole 775 series of exchanges started from the CREATE_CHILD_SA exchange as 776 failed. In most cases, the receipt of this notification is caused by 777 premature deletion of the corresponding state on the responder (the 778 time period between IKE_FOLLOWUP_KE exchanges appeared too long from 779 the responder's point of view, e.g. due to a temporary network 780 failure). After receiving this notification the initiator MAY start 781 a new CREATE_CHILD_SA exchange which may eventually be followed by 782 the IKE_FOLLOWUP_KE exchanges, to retry the failed attempt. If the 783 initiator continues to receive STATE_NOT_FOUND notifications after 784 several retries, it MUST treat this situation as a fatal error and 785 delete IKE SA by sending a DELETE payload. 787 When rekeying the IKE SA or the Child SA, it is possible that the 788 peers start doing this at the same time, which is called simultaneous 789 rekeying. Sections 2.8.1 and 2.8.2 of [RFC7296] describe how IKEv2 790 handles this situation. In a nutshell IKEv2 follows the rule that if 791 in case of simultaneous rekeying, two identical new IKE SAs (or two 792 pairs of Child SAs) are created, then one of them should be deleted. 793 Which one is to be deleted is determined by comparing the values of 794 four nonces that are used in the colliding CREATE_CHILD_SA exchanges. 795 The IKE SA (or pair of Child SAs) that is created by the exchange in 796 which the smallest nonce is used should be deleted by the initiator 797 of this exchange. 799 With multiple key exchanges, the SAs are not yet created when the 800 CREATE_CHILD_SA is completed, they would be created only after the 801 series of IKE_FOLLOWUP_KE exchanges is finished. For this reason, if 802 additional key exchanges are negotiated in the CREATE_CHILD_SA 803 exchange in which the smallest nonce is used, then because there is 804 nothing to delete yet, the initiator of this exchange just stops the 805 rekeying process and it MUST NOT initiate the IKE_FOLLOWUP_KE 806 exchange. 808 In most cases, rekey collisions are resolved in the CREATE_CHILD_SA 809 exchange. However, a situation may occur when due to packet loss, 810 one of the peers receives the CREATE_CHILD_SA message requesting 811 rekey of SA that is already being rekeyed by this peer (i.e. the 812 CREATE_CHILD_SA exchange initiated by this peer has been already 813 completed and the series of IKE_FOLLOWUP_KE exchanges is in 814 progress). In this case, a TEMPORARY_FAILURE notification MUST be 815 sent in response to such a request. 817 If multiple key exchanges are negotiated in the CREATE_CHILD_SA 818 exchange, then the resulting keys are computed as follows. 820 In case of IKE SA rekey: 822 SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)) 824 In case of Child SA creation or rekey: 826 KEYMAT = prf+ (SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)) 828 In both cases, SK_d is from the existing IKE SA; SK(0), Ni, Nr are 829 the shared key and nonces from the CREATE_CHILD_SA respectively; 830 SK(1)...SK(n) are the shared keys from additional key exchanges. 832 2.2.5. Interaction with IKEv2 Extensions 834 It is believed that this specification requires no modification to 835 the IKEv2 extensions defined so far. In particular, IKE SA 836 resumption mechanism defined in [RFC5723] can be used to resume IKE 837 SAs created using this specification. 839 2.2.5.1. Interaction with Childless IKE SA 841 It is possible to establish IKE SAs with post-quantum algorithms only 842 using additional key exchanges, but without using IKE_INTERMEDIATE 843 exchanges. In this case, the IKE SA created from IKE_SA_INIT 844 exchange can be immediately rekeyed with CREATE_CHILD_SA using 845 additional key exchanges where IKE_FOLLOWUP_KE messages are used to 846 carry the key exchange payload. If classical key exchange method is 847 used in the IKE_SA_INIT message, the very first Child SA created in 848 IKE_AUTH will offer no resistance against the quantum threats. 849 Consequently, if the peers' local policy requires that all Child SAs 850 to be post-quantum secure, then the peers can avoid creating the very 851 first Child SA by adopting [RFC6023]. In this case, the initiator 852 sends two types of proposal in the IKE_SA_INIT request, one with and 853 another one without Additional Key Exchange transform(s). The 854 responder chooses the latter proposal type and includes 855 CHILDLESS_IKEV2_SUPPORTED notification in the IKE_SA_INIT response. 857 Assuming that the initiator supports childless IKE SA extension, then 858 both peers performs the modified IKE_AUTH exchange described in 859 [RFC6023] and no Child SA is created in this exchange. The peers 860 should then immediately rekey the IKE SA and subsequently create the 861 Child SAs, all with additional key exchanges using CREATE_CHILD_SA 862 exchange. 864 It is also possible for the initiator to send proposals without 865 Additional Key Exchange transform(s) in the IKE_SA_INIT message and 866 in this instance, the responder will have no information whether or 867 not the initiator supports the extension in this specification. This 868 may not be efficient as the responder will have to wait for the 869 subsequent CREATE_CHILD_SA request to determine whether or not the 870 initiator's request is appropriate for its local policy. 872 The support for childless IKE SA is not negotiated, but it is the 873 responder that indicates the support for this mode. As such, the 874 responder cannot enforce the initiator to use this mode and 875 therefore, it is entirely possible that the initiator does not 876 support this extension and sends IKE_AUTH request as per [RFC7296] 877 instead of [RFC6023]. In this case, the responder may respond with 878 non-fatal error such as NO_PROPOSAL_CHOSEN notify message type. 880 Note that if the initial IKE SA is used to transfer sensitive 881 information, then this information will not be protected using the 882 additional key exchanges, which may use post-quantum algorithms. In 883 this arrangement, the peers will have to use post-quantum algorithm 884 in Transform Type 4 in order to mitigate the risk of quantum attack. 886 3. IANA Considerations 888 This document adds new exchange type into the "IKEv2 Exchange Types" 889 registry: 891 44 IKE_FOLLOWUP_KE 893 This document renames Transform Type 4 defined in "Transform Type 894 Values" registry from "Diffie-Hellman Group (D-H)" to "Key Exchange 895 Method (KE)". 897 This document renames IKEv2 registry "Transform Type 4 - Diffie- 898 Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange 899 Method Transform IDs". 901 This document adds the following Transform Types to the "Transform 902 Type Values" registry: 904 Type Description Used In 905 ----------------------------------------------------------------- 906 6 Additional Key Exchange 1 (optional in IKE, AH, ESP) 907 7 Additional Key Exchange 2 (optional in IKE, AH, ESP) 908 8 Additional Key Exchange 3 (optional in IKE, AH, ESP) 909 9 Additional Key Exchange 4 (optional in IKE, AH, ESP) 910 10 Additional Key Exchange 5 (optional in IKE, AH, ESP) 911 11 Additional Key Exchange 6 (optional in IKE, AH, ESP) 912 12 Additional Key Exchange 7 (optional in IKE, AH, ESP) 914 This document defines a new Notify Message Type in the "Notify 915 Message Types - Status Types" registry: 917 16441 ADDITIONAL_KEY_EXCHANGE 919 and a new Notify Message Type in the "Notify Message Types - Error 920 Types" registry: 922 47 STATE_NOT_FOUND 924 3.1. Additional Considerations and Changes 926 The IANA is requested to add the following instructions for 927 designated experts for Transform Type 4 sub-registry. 929 While adding new KE methods, the following considerations must be 930 applied. A KE method must take exactly one round-trip (one IKE 931 exchange) and at the end of this exchange, both peers must be able to 932 derive the shared secret. In addition, any public value peers 933 exchanged during a KE method must fit into a single IKE message. If 934 these restrictions are not met for a KE method, then there must be 935 documentation on how this KE method is used in IKEv2. 937 The following changes to IANA are also requested. It is assumed that 938 RFCXXXX refers to this specification. 940 * Add a reference to RFCXXXX in the "Transform Type 4 - Diffie- 941 Hellman Group Transform IDs" registry. 943 * Replace the note on "Transform Type 4 - Diffie-Hellman Group 944 Transform IDs" registry with: This registry was originally named 945 "Transform Type 4 - Diffie-Hellman Group Transform IDs" and was 946 renamed to its current name by [RFCXXXX]. It has been referenced 947 in its original name in a number of RFCs prior to [RFCXXXX]. To 948 find out requirement levels for Key Exchange Methods for IKEv2, 949 see [RFC8247]. 951 * Add this note to "Transform Type Values" registry: Transform Type 952 "Transform Type 4 - Key Exchange Method Transform IDs" was 953 originally named "Transform Type 4 - Diffie-Hellman Group 954 Transform IDs" and was renamed to its current name by [RFCXXXX]. 955 It has been referenced in its original name in a number of RFCs 956 prior to [RFCXXXX]. All "Additional Key Exchange" entries use the 957 same "Transform Type 4 - Key Exchange Method Transform IDs" as the 958 "Key Exchange Method (KE)". 960 * Append RFCXXXX to the Reference column of Transform Type 4 in the 961 Transform Type Values registry. 963 * Append this note to "Transform Type 4 - Diffie-Hellman Group 964 Transform IDs" registry: All "Additional Key Exchange" entries use 965 these values as the "Key Exchange Method (KE)". 967 4. Security Considerations 969 The extension in this document is intended to mitigate two possible 970 threats in IKEv2, namely the compromise of (EC)DH key exchange using 971 Shor's algorithm while remaining backward compatible; and the 972 potential compromise of existing or future PQC key exchange 973 algorithms. To address the former threat, this extension allows the 974 establishment of a shared secret by using multiple key exchanges, 975 typically one classical (EC)DH and the other one post-quantum 976 algorithm. In order to address the latter threat, multiple key 977 exchanges using a post-quantum algorithm can be composed to form the 978 shared key. 980 Unlike key exchange methods (Transform Type 4), the Encryption 981 Algorithm (Transform Type 1), the Pseudorandom Function (Transform 982 Type 2) and the Integrity Algorithm (Transform Type 3) are not 983 susceptible to Shor's algorithm. However, they are susceptible to 984 Grover's attack [GROVER], which allows a quantum computer to perform 985 a brute force key search using quadratically fewer steps than the 986 classical counterpart. Simply increasing the key length can mitigate 987 this attack. It was previously believed that one needed to double 988 the key length of these algorithms. However, there are a number of 989 factors that suggest that it is quite unlikely to achieve the 990 quadratic speed up using Grover's algorithm. According to NIST 991 [NISTPQCFAQ], current applications can continue using AES algorithm 992 with the minimum key length of 128 bit. Nevertheless, if the data 993 needs to remain secure for many years to come, one may want to 994 consider using a longer key size for the algorithms in Transform 995 Types 1-3. 997 SKEYSEED is calculated from shared SK(x) using an algorithm defined 998 in Transform Type 2. While a quantum attacker may learn the value of 999 SK(x), if this value is obtained by means of a classical key 1000 exchange, other SK(x) values generated by means of a post-quantum 1001 algorithm ensure that the final SKEYSEED is not compromised. This 1002 assumes that the algorithm defined in the Transform Type 2 is quantum 1003 resistant. 1005 The ordering of the additional key exchanges should not matter in 1006 general, as only the final shared secret is of interest. 1007 Nonetheless, because the strength of the running shared secret 1008 increases with every additional key exchange, an implementer may want 1009 to first perform the most secure method (in some metrics) and 1010 followed by less secure one(s). 1012 The main focus of this document is to prevent a passive attacker 1013 performing a "harvest and decrypt" attack. In other words, an 1014 attacker that records messages exchanged today and proceeds to 1015 decrypt them once he owns a quantum computer. This attack is 1016 prevented due to the hybrid nature of the key exchange. Other 1017 attacks involving an active attacker using a quantum-computer are not 1018 completely solved by this document. This is for two reasons. 1020 The first reason is because the authentication step remains 1021 classical. In particular, the authenticity of the SAs established 1022 under IKEv2 is protected using a pre-shared key or digital signature 1023 algorithms. Whilst the pre-shared key option, provided the key is 1024 long enough, is post-quantum secure, the other algorithms are not. 1025 Moreover, in implementations where scalability is a requirement, the 1026 pre-shared key method may not be suitable. Post-quantum authenticity 1027 may be provided by using a post-quantum digital signature. 1029 Secondly, it should be noted that the purpose of post-quantum 1030 algorithms is to provide resistance to attacks mounted in the future. 1031 The current threat is that encrypted sessions are subject to 1032 eavesdropping and archived with decryption by quantum computers 1033 taking place at some point in the future. Until quantum computers 1034 become available there is no point in attacking the authenticity of a 1035 connection because there are no possibilities for exploitation. 1036 These only occur at the time of the connection, for example by 1037 mounting an on-path attack. Consequently there is less urgency for 1038 post-quantum authenticity compared to post-quantum confidentiality. 1040 Performing multiple key exchanges while establishing IKE SA increases 1041 the responder's susceptibility to DoS attacks, because of an 1042 increased amount of resources needed before the initiator is 1043 authenticated. This is especially true for post-quantum key exchange 1044 methods, where many of them are more memory and/or CPU intensive than 1045 the classical counterparts. 1047 Responders may consider recommendations from [RFC8019] to deal with 1048 increased DoS attack susceptibility. It is also possible that the 1049 responder only agrees to create initial IKE SA without performing 1050 additional key exchanges, provided the initiator includes such an 1051 option in its proposals. Then peers immediately rekey the initial 1052 IKE SA with the CREATE_CHILD_SA exchange and additional key exchanges 1053 performed via the IKE_FOLLOWUP_KE exchanges. In this case, at the 1054 point when resource-intensive operations are required, the peers have 1055 already authenticated each other. However, in the context of hybrid 1056 post-quantum key exchange this scenario would leave the initial IKE 1057 SA (and initial Child SA if it is created) unprotected against 1058 quantum computers. Nevertheless the rekeyed IKE SA (and Child SAs 1059 that will be created over it) will have a full protection. This is 1060 similar to the scenario described in [RFC8784]. Depending on the 1061 arrangement and peers' policy, this scenario may or may not be 1062 appropriate. For example, in the G-IKEv2 protocol 1063 [I-D.ietf-ipsecme-g-ikev2] the cryptographic materials are sent from 1064 the group controller to the group members when the initial IKE SA is 1065 created. 1067 5. Acknowledgements 1069 The authors would like to thank Frederic Detienne and Olivier Pelerin 1070 for their comments and suggestions, including the idea to negotiate 1071 the post-quantum algorithms using the existing KE payload. The 1072 authors are also grateful to Tobias Heider and Tobias Guggemos for 1073 valuable comments. Thanks to Paul Wouters for reviewing the 1074 document. 1076 6. References 1078 6.1. Normative References 1080 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1081 Requirement Levels", BCP 14, RFC 2119, 1082 DOI 10.17487/RFC2119, March 1997, 1083 . 1085 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1086 Kivinen, "Internet Key Exchange Protocol Version 2 1087 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1088 2014, . 1090 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1091 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1092 May 2017, . 1094 [RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key 1095 Exchange Protocol Version 2 (IKEv2)", RFC 9242, 1096 DOI 10.17487/RFC9242, May 2022, 1097 . 1099 6.2. Informative References 1101 [GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for 1102 Database Search", Proc. of the Twenty-Eighth Annual ACM 1103 Symposium on the Theory of Computing (STOC 1996), 1996. 1105 [I-D.ietf-ipsecme-g-ikev2] 1106 Smyslov, V. and B. Weis, "Group Key Management using 1107 IKEv2", Work in Progress, Internet-Draft, draft-ietf- 1108 ipsecme-g-ikev2-07, 6 October 2022, 1109 . 1112 [I-D.tjhai-ikev2-beyond-64k-limit] 1113 Tjhai, C., Heider, T., and V. Smyslov, "Beyond 64KB Limit 1114 of IKEv2 Payloads", Work in Progress, Internet-Draft, 1115 draft-tjhai-ikev2-beyond-64k-limit-03, 28 July 2022, 1116 . 1119 [IKEV2TYPE4ID] 1120 IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters: 1121 Transform Type 4 - Diffie-Hellman Group Transform IDs", 1122 . 1125 [NISTPQCFAQ] 1126 NIST, "Post-Quantum Cryptography Standardization: FAQs", 1127 . 1130 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 1131 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 1132 DOI 10.17487/RFC5723, January 2010, 1133 . 1135 [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A 1136 Childless Initiation of the Internet Key Exchange Version 1137 2 (IKEv2) Security Association (SA)", RFC 6023, 1138 DOI 10.17487/RFC6023, October 2010, 1139 . 1141 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 1142 (IKEv2) Message Fragmentation", RFC 7383, 1143 DOI 10.17487/RFC7383, November 2014, 1144 . 1146 [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange 1147 Protocol Version 2 (IKEv2) Implementations from 1148 Distributed Denial-of-Service Attacks", RFC 8019, 1149 DOI 10.17487/RFC8019, November 2016, 1150 . 1152 [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, 1153 "Mixing Preshared Keys in the Internet Key Exchange 1154 Protocol Version 2 (IKEv2) for Post-quantum Security", 1155 RFC 8784, DOI 10.17487/RFC8784, June 2020, 1156 . 1158 Appendix A. Sample Multiple Key Exchanges 1160 This appendix shows some examples of multiple key exchanges. These 1161 examples are non-normative and they describe some message flow 1162 scenarios that may occur in establishing an IKE or CHILD SA. Note 1163 that some payloads that are not relevant to multiple key exchanges 1164 may be omitted for brevity. 1166 A.1. IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange 1167 Payloads 1169 The exchanges below show that the initiator proposes the use of 1170 additional key exchanges to establish an IKE SA. The initiator 1171 proposes three sets of additional key exchanges and all of which are 1172 optional. So the responder can choose NONE for some or all of the 1173 additional exchanges if the proposed key exchange methods are not 1174 supported or for whatever reasons the responder decides not to 1175 perform the additional key exchange. 1177 Initiator Responder 1178 --------------------------------------------------------------------- 1179 HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> 1180 KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), 1181 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 1182 Proposal #1 1183 Transform ECR (ID = ENCR_AES_GCM_16, 1184 256-bit key) 1185 Transform PRF (ID = PRF_HMAC_SHA2_512) 1186 Transform KE (ID = Curve25519) 1187 Transform AKE1 (ID = PQ_KEM_1) 1188 Transform AKE1 (ID = PQ_KEM_2) 1189 Transform AKE1 (ID = NONE) 1190 Transform AKE2 (ID = PQ_KEM_3) 1191 Transform AKE2 (ID = PQ_KEM_4) 1192 Transform AKE2 (ID = NONE) 1193 Transform AKE3 (ID = PQ_KEM_5) 1194 Transform AKE3 (ID = PQ_KEM_6) 1195 Transform AKE3 (ID = NONE) 1196 <--- HDR(IKE_SA_INIT), SAr1(.. AKE*...), 1197 KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), 1198 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 1199 Proposal #1 1200 Transform ECR (ID = ENCR_AES_GCM_16, 1201 256-bit key) 1202 Transform PRF (ID = PRF_HMAC_SHA2_512) 1203 Transform KE (ID = Curve25519) 1204 Transform AKE1 (ID = PQ_KEM_2) 1205 Transform AKE2 (ID = NONE) 1206 Transform AKE3 (ID = PQ_KEM_5) 1208 HDR(IKE_INTERMEDIATE), SK {KEi(1)(PQ_KEM_2)} --> 1209 <--- HDR(IKE_INTERMEDIATE), SK {KEr(1)(PQ_KEM_2)} 1210 HDR(IKE_INTERMEDIATE), SK {KEi(2)(PQ_KEM_5)} --> 1211 <--- HDR(IKE_INTERMEDIATE), SK {KEr(2)(PQ_KEM_5)} 1213 HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } ---> 1214 <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2, 1215 TSi, TSr } 1217 In this particular example, the responder chooses to perform two 1218 additional key exchanges. It selects PQ_KEM_2, NONE and PQ_KEM_5 for 1219 the first, second and third additional key exchanges respectively. 1220 As per [RFC7296] specification, a set of keying materials are 1221 derived, in particular SK_d, SK_a[i/r], SK_e[i/r]. Both peers then 1222 perform an IKE_INTERMEDIATE exchange carrying PQ_KEM_2 payload which 1223 is protected with SK_e[i/r] and SK_a[i/r] keys. After the completion 1224 of this IKE_INTERMEDIATE exchange, the SKEYSEED is updated using 1225 SK(1), which is the PQ_KEM_2 shared secret, as follows. 1227 SKEYSEED(1) = prf(SK_d, SK(1) | Ni | Nr) 1229 The updated SKEYSEED value is then used to derive the following 1230 keying materials 1232 {SK_d(1) | SK_ai(1) | SK_ar(1) | SK_ei(1) | SK_er(1) | SK_pi(1) | 1233 SK_pr(1)} = prf+ (SKEYSEED(1), Ni | Nr | SPIi | SPIr) 1235 As per [RFC9242] specification, both peers compute IntAuth_i1 and 1236 IntAuth_r1 using the SK_pi(1) and SK_pr(1) keys respectively. These 1237 values are required in the IKE_AUTH phase of the exchange. 1239 In the next IKE_INTERMEDIATE exchange, the peers use SK_e[i/r](1) and 1240 SK_a[i/r](1) keys to protect the PQ_KEM_5 payload. After completing 1241 this exchange, keying materials are updated as below 1243 SKEYSEED(2) = prf(SK_d(1), SK(2) | Ni | Nr) 1244 {SK_d(2) | SK_ai(2) | SK_ar(2) | SK_ei(2) | SK_er(2) | SK_pi(2) | 1245 SK_pr(2)} = prf+ (SKEYSEED(2), Ni | Nr | SPIi | SPIr) 1247 where SK(2) is the shared secret from the third additional key 1248 exchange, i.e. PQ_KEM_5. Both peers then compute the values of 1249 IntAuth_[i/r]2 using the SK_p[i/r](2) keys. 1251 After the completion of the second IKE_INTERMEDIATE exchange, both 1252 peers continue to the IKE_AUTH exchange phase. As defined in 1253 [RFC9242], the values IntAuth_[i/r]2 are used to compute IntAuth 1254 which in turn is used to calculate the payload to be signed or MACed, 1255 i.e. InitiatorSignedOctets and ResponderSignedOctets. 1257 A.2. No Additional Key Exchange Used 1259 The initiator proposes two sets of optional additional key exchanges, 1260 but the responder does not support any of them. The responder 1261 chooses NONE for each set and consequently, IKE_INTERMEDIATE exchange 1262 does not takes place and the exchange proceeds to IKE_AUTH phase. 1263 The resulting keying materials are the same as those derived with 1264 [RFC7296]. 1266 Initiator Responder 1267 --------------------------------------------------------------------- 1268 HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> 1269 KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), 1270 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 1271 Proposal #1 1272 Transform ECR (ID = ENCR_AES_GCM_16, 1273 256-bit key) 1274 Transform PRF (ID = PRF_HMAC_SHA2_512) 1275 Transform KE (ID = Curve25519) 1276 Transform AKE1 (ID = PQ_KEM_1) 1277 Transform AKE1 (ID = PQ_KEM_2) 1278 Transform AKE1 (ID = NONE) 1279 Transform AKE2 (ID = PQ_KEM_3) 1280 Transform AKE2 (ID = PQ_KEM_4) 1281 Transform AKE2 (ID = NONE) 1282 <--- HDR(IKE_SA_INIT), SAr1(.. AKE*...), 1283 KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), 1284 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 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 = NONE) 1291 Transform AKE2 (ID = NONE) 1293 HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } ---> 1294 <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2, 1295 TSi, TSr } 1297 A.3. Additional Key Exchange in the CREATE_CHILD_SA Exchange only 1299 The exchanges below show that the initiator does not propose the use 1300 of additional key exchanges to establish an IKE SA, but they are 1301 required in order to establish a Child SA. In order to establish a 1302 fully quantum-resistant IPsec SA, the responder includes a 1303 CHILDLESS_IKEV2_SUPPORTED notification in their IKE_SA_INIT response 1304 message. The initiator understands and supports this notification, 1305 then exchanges a modified IKE_AUTH message with the responder and 1306 rekeys the IKE SA immediately with additional key exchanges. Any 1307 Child SA will have to be created via subsequent CREATED_CHILD_SA 1308 exchange. 1310 Initiator Responder 1311 --------------------------------------------------------------------- 1312 HDR(IKE_SA_INIT), SAi1, ---> 1313 KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED) 1314 <--- HDR(IKE_SA_INIT), SAr1, 1315 KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), 1316 N(CHILDLESS_IKEV2_SUPPORTED) 1318 HDR(IKE_AUTH), SK{ IDi, AUTH } ---> 1319 <--- HDR(IKE_AUTH), SK{ IDr, AUTH } 1321 HDR(CREATE_CHILD_SA), SK{ SAi(.. AKE*...), Ni, KEi(Curve25519) } ---> 1322 Proposal #1 1323 Transform ECR (ID = ENCR_AES_GCM_16, 1324 256-bit key) 1325 Transform PRF (ID = PRF_HMAC_SHA2_512) 1326 Transform KE (ID = Curve25519) 1327 Transform AKE1 (ID = PQ_KEM_1) 1328 Transform AKE1 (ID = PQ_KEM_2) 1329 Transform AKE2 (ID = PQ_KEM_5) 1330 Transform AKE2 (ID = PQ_KEM_6) 1331 Transform AKE2 (ID = NONE) 1332 <--- HDR(CREATE_CHILD_SA), SK{ SAr(.. AKE*...), 1333 Nr, KEr(Curve25519), 1334 N(ADDITIONAL_KEY_EXCHANGE)(link1) } 1335 Proposal #1 1336 Transform ECR (ID = ENCR_AES_GCM_16, 1337 256-bit key) 1338 Transform PRF (ID = PRF_HMAC_SHA2_512) 1339 Transform KE (ID = Curve25519) 1340 Transform AKE1 (ID = PQ_KEM_2) 1341 Transform AKE2 (ID = PQ_KEM_5) 1343 HDR(IKE_FOLLOWUP_KE), SK{ KEi(1)(PQ_KEM_2), ---> 1344 N(ADDITIONAL_KEY_EXCHANGE)(link1) } 1345 <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(1)(PQ_KEM_2), 1346 N(ADDITIONAL_KEY_EXCHANGE)(link2) } 1348 HDR(IKE_FOLLOWUP_KE), SK{ KEi(2)(PQ_KEM_5), ---> 1349 N(ADDITIONAL_KEY_EXCHANGE)(link2) } 1350 <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(2)(PQ_KEM_5) } 1352 A.4. No Matching Proposal for Additional Key Exchanges 1354 The initiator proposes the combination of PQ_KEM_1, PQ_KEM_2, 1355 PQ_KEM_3, and PQ_KEM_4 as the additional key exchanges. The 1356 initiator indicates that either PQ_KEM_1 or PQ_KEM_2 must be used to 1357 establish an IKE SA, but Additional Key Exchange 2 is optional so the 1358 responder can either select PQ_KEM_3 or PQ_KEM_4 or omit this key 1359 exchange by selecting NONE. The responder, although supports the 1360 optional PQ_KEM_3 and PQ_KEM_4 methods, does not support either 1361 PQ_KEM_1 or PQ_KEM_2 mandatory method and therefore responds with 1362 NO_PROPOSAL_CHOSEN notification. 1364 Initiator Responder 1365 --------------------------------------------------------------------- 1366 HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> 1367 KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), 1368 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 1369 Proposal #1 1370 Transform ECR (ID = ENCR_AES_GCM_16, 1371 256-bit key) 1372 Transform PRF (ID = PRF_HMAC_SHA2_512) 1373 Transform KE (ID = Curve25519) 1374 Transform AKE1 (ID = PQ_KEM_1) 1375 Transform AKE1 (ID = PQ_KEM_2) 1376 Transform AKE2 (ID = PQ_KEM_3) 1377 Transform AKE2 (ID = PQ_KEM_4) 1378 Transform AKE2 (ID = NONE) 1379 <--- HDR(IKE_SA_INIT), N(NO_PROPOSAL_CHOSEN) 1381 Appendix B. Design Criteria 1383 The design of the extension is driven by the following criteria: 1385 1) Need for PQC in IPsec. Quantum computers, which might become 1386 feasible in the near future, pose a threat to our classical 1387 public key cryptography. PQC, a family of public key 1388 cryptography that is believed to be resistant against these 1389 computers, needs to be integrated into the IPsec protocol suite 1390 to restore confidentiality and authenticity. 1392 2) Hybrid. There is currently no post-quantum key exchange that is 1393 trusted at the level that (EC)DH is trusted for against 1394 conventional (non-quantum) adversaries. A hybrid post-quantum 1395 algorithm to be introduced along with the well-established 1396 primitives addresses this concern, since the overall security is 1397 at least as strong as each individual primitive. 1399 3) Focus on post-quantum confidentiality. A passive attacker can 1400 store all monitored encrypted IPsec communication today and 1401 decrypt it once a quantum computer is available in the future. 1402 This attack can have serious consequences that will not be 1403 visible for years to come. On the other hand, an attacker can 1404 only perform active attacks such as impersonation of the 1405 communicating peers once a quantum computer is available, 1406 sometime in the future. Thus, this specification focuses on 1407 confidentiality due to the urgency of this problem and presents 1408 a defense against the serious attack described above, but it 1409 does not address authentication since it is less urgent at this 1410 stage. 1412 4) Limit amount of exchanged data. The protocol design should be 1413 such that the amount of exchanged data, such as public-keys, is 1414 kept as small as possible even if initiator and responder need 1415 to agree on a hybrid group or multiple public-keys need to be 1416 exchanged. 1418 5) Not post-quantum specific. Any cryptographic algorithm could be 1419 potentially broken in the future by currently unknown or 1420 impractical attacks: quantum computers are merely the most 1421 concrete example of this. The design does not categorize 1422 algorithms as "post-quantum" or "non post-quantum" nor does it 1423 create assumptions about the properties of the algorithms, 1424 meaning that if algorithms with different properties become 1425 necessary in the future, this extension can be used unchanged to 1426 facilitate migration to those algorithms. 1428 6) Limited amount of changes. A key goal is to limit the number of 1429 changes required when enabling a post-quantum handshake. This 1430 ensures easier and quicker adoption in existing implementations. 1432 7) Localized changes. Another key requirement is that changes to 1433 the protocol are limited in scope, in particular, limiting 1434 changes in the exchanged messages and in the state machine, so 1435 that they can be easily implemented. 1437 8) Deterministic operation. This requirement means that the hybrid 1438 post-quantum exchange, and thus, the computed keys, will be 1439 based on algorithms that both client and server wish to support. 1441 9) Fragmentation support. Some PQC algorithms could be relatively 1442 bulky and they might require fragmentation. Thus, a design goal 1443 is the adaptation and adoption of an existing fragmentation 1444 method or the design of a new method that allows for the 1445 fragmentation of the key shares. 1447 10) Backwards compatibility and interoperability. This is a 1448 fundamental requirement to ensure that hybrid post-quantum IKEv2 1449 and standard IKEv2 implementations as per [RFC7296] 1450 specification are interoperable. 1452 11) USA Federal Information Processing Standards (FIPS) compliance. 1453 IPsec is widely used in Federal Information Systems and FIPS 1454 certification is an important requirement. However, at the time 1455 of writing, none of the algorithms that is believed to be post- 1456 quantum is FIPS compliant yet. Nonetheless, it is possible to 1457 combine this post-quantum algorithm with a FIPS compliant key 1458 establishment method so that the overall design remains FIPS 1459 compliant [NISTPQCFAQ]. 1461 12) Ability to use this method with multiple classical (EC)DH key 1462 exchanges. In some situations peers have no single mutually 1463 trusted key exchange algorithm (e.g., due to local policy 1464 restrictions). The ability to combine two (or more) key 1465 exchange methods in such a way that the resulting shared key 1466 depends on all of them allows peers to communicate in this 1467 situation. 1469 Appendix C. Alternative Design 1471 This section gives an overview on a number of alternative approaches 1472 that have been considered, but later discarded. These approaches 1473 are: 1475 * Sending the classical and post-quantum key exchanges as a single 1476 transform 1478 A method to combine the various key exchanges into a single large 1479 KE payload was considered; this effort is documented in a previous 1480 version of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). 1481 This does allow us to cleanly apply hybrid key exchanges during 1482 the Child SA; however it does add considerable complexity, and 1483 requires an independent fragmentation solution. 1485 * Sending post-quantum proposals and policies in KE payload only 1487 With the objective of not introducing unnecessary notify payloads, 1488 a method to communicate the hybrid post-quantum proposal in the KE 1489 payload during the first pass of the protocol exchange was 1490 considered. Unfortunately, this design is susceptible to the 1491 following downgrade attack. Consider the scenario where there is 1492 an on-path attacker sitting between an initiator and a responder. 1493 The initiator proposes, through SAi payload, to use a hybrid post- 1494 quantum group and as a fallback a Diffie-Hellman group, and 1495 through KEi payload, the initiator proposes a list of hybrid post- 1496 quantum proposals and policies. The on-path attacker intercepts 1497 this traffic and replies with N(INVALID_KE_PAYLOAD) suggesting to 1498 downgrade to the fallback Diffie-Hellman group instead. The 1499 initiator then resends the same SAi payload and the KEi payload 1500 containing the public value of the fallback Diffie-Hellman group. 1501 Note that the attacker may forward the second IKE_SA_INIT message 1502 only to the responder, and therefore at this point in time, the 1503 responder will not have the information that the initiator prefers 1504 the hybrid group. Of course, it is possible for the responder to 1505 have a policy to reject an IKE_SA_INIT message that (a) offers a 1506 hybrid group but not offering the corresponding public value in 1507 the KEi payload; and (b) the responder has not specifically 1508 acknowledged that it does not supported the requested hybrid 1509 group. However, the checking of this policy introduces 1510 unnecessary protocol complexity. Therefore, in order to fully 1511 prevent any downgrade attacks, using KE payload alone is not 1512 sufficient and that the initiator MUST always indicate its 1513 preferred post-quantum proposals and policies in a notify payload 1514 in the subsequent IKE_SA_INIT messages following a 1515 N(INVALID_KE_PAYLOAD) response. 1517 * New payload types to negotiate hybrid proposal and to carry post- 1518 quantum public values 1520 Semantically, it makes sense to use a new payload type, which 1521 mimics the SA payload, to carry a hybrid proposal. Likewise, 1522 another new payload type that mimics the KE payload, could be used 1523 to transport hybrid public value. Although, in theory a new 1524 payload type could be made backwards compatible by not setting its 1525 critical flag as per Section 2.5 of [RFC7296], it is believed that 1526 it may not be that simple in practice. Since the original release 1527 of IKEv2 in RFC4306, no new payload type has ever been proposed 1528 and therefore, this creates a potential risk of having a backward 1529 compatibility issue from non-conformant IKEv2 implementations. 1530 Since there appears to be no other compelling advantages apart 1531 from a semantic one, the existing transform type and notify 1532 payloads are used instead. 1534 * Hybrid public value payload 1536 One way to transport the negotiated hybrid public payload, which 1537 contains one classical Diffie-Hellman public value and one or more 1538 post-quantum public values, is to bundle these into a single KE 1539 payload. Alternatively, these could also be transported in a 1540 single new hybrid public value payload, but following the same 1541 reasoning as above, this may not be a good idea from a backward 1542 compatibility perspective. Using a single KE payload would 1543 require an encoding or formatting to be defined so that both peers 1544 are able to compose and extract the individual public values. 1545 However, it is believed that it is cleaner to send the hybrid 1546 public values in multiple KE payloads--one for each group or 1547 algorithm. Furthermore, at this point in the protocol exchange, 1548 both peers should have indicated support of handling multiple KE 1549 payloads. 1551 * Fragmentation 1553 Handling of large IKE_SA_INIT messages has been one of the most 1554 challenging tasks. A number of approaches have been considered 1555 and the two prominent ones that have been discarded are outlined 1556 as follows. 1558 The first approach is to treat the entire IKE_SA_INIT message as a 1559 stream of bytes, which is then split it into a number of 1560 fragments, each of which is wrapped onto a payload that will fit 1561 into the size of the network MTU. The payload that wraps each 1562 fragment has a new payload type and it is envisaged that this new 1563 payload type will not cause a backward compatibility issue because 1564 at this stage of the protocol, both peers should have indicated 1565 support of fragmentation in the first pass of the IKE_SA_INIT 1566 exchange. The negotiation of fragmentation is performed using a 1567 notify payload, which also defines supporting parameters such as 1568 the size of fragment in octets and the fragment identifier. The 1569 new payload that wraps each fragment of the messages in this 1570 exchange is assigned the same fragment identifier. Furthermore, 1571 it also has other parameters such as a fragment index and total 1572 number of fragments. This approach has been discarded due to its 1573 blanket approach to fragmentation. In cases where only a few 1574 payloads need to be fragmented, this approach appears to be overly 1575 complicated. 1577 Another idea that has been discarded was fragmenting an individual 1578 payload without introducing a new payload type. The idea is to 1579 use the 9-th bit (the bit after the critical flag in the RESERVED 1580 field) in the generic payload header as a flag to mark that this 1581 payload is fragmented. As an example, if a KE payload is to be 1582 fragmented, it may look as follows. 1584 1 2 3 1585 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 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | Next Payload |C|F| RESERVED | Payload Length | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Diffie-Hellman Group Number | Fragment Identifier | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | Fragment Index | Total Fragments | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | Total KE Payload Data Length | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | | 1596 ~ Fragmented KE Payload ~ 1597 | | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 When the flag F is set, this means the current KE payload is a 1601 fragment of a larger KE payload. The Payload Length field denotes 1602 the size of this payload fragment in octets--including the size of 1603 the generic payload header. The two-octet RESERVED field 1604 following Diffie-Hellman Group Number was to be used as a fragment 1605 identifier to help assembly and disassembly of fragments. The 1606 Fragment Index and Total Fragments fields are self-explanatory. 1607 The Total KE Payload Data Length indicates the size of the 1608 assembled KE payload data in octets. Finally, the actual fragment 1609 is carried in Fragment KE Payload field. 1611 This approach has been discarded because it is believed that the 1612 working group may not want to use the RESERVED field to change the 1613 format of a packet and that implementers may not like the added 1614 complexity from checking the fragmentation flag in each received 1615 payload. More importantly, fragmenting the messages in this way 1616 may leave the system to be more prone to denial of service (DoS) 1617 attacks. By using IKE_INTERMEDIATE to transport the large post- 1618 quantum key exchange payloads, and using the generic IKEv2 1619 fragmentation protocol [RFC7383] solve the issue. 1621 * Group sub-identifier 1622 As discussed before, each group identifier is used to distinguish 1623 a post-quantum algorithm. Further classification could be made on 1624 a particular post-quantum algorithm by assigning additional value 1625 alongside the group identifier. This sub- identifier value may be 1626 used to assign different security parameter sets to a given post- 1627 quantum algorithm. However, this level of details does not fit 1628 the principles of the document where it should deal with generic 1629 hybrid key exchange protocol, not a specific ciphersuite. 1630 Furthermore, there are enough Diffie- Hellman group identifiers 1631 should this be required in the future. 1633 Authors' Addresses 1635 C. Tjhai 1636 Post-Quantum 1637 Email: cjt@post-quantum.com 1639 M. Tomlinson 1640 Post-Quantum 1641 Email: mt@post-quantum.com 1643 G. Bartlett 1644 Quantum Secret 1645 Email: graham.ietf@gmail.com 1647 S. Fluhrer 1648 Cisco Systems 1649 Email: sfluhrer@cisco.com 1651 D. Van Geest 1652 ISARA Corporation 1653 Email: daniel.vangeest@isara.com 1655 O. Garcia-Morchon 1656 Philips 1657 Email: oscar.garcia-morchon@philips.com 1659 Valery Smyslov 1660 ELVIS-PLUS 1661 Email: svan@elvis.ru