idnits 2.17.00 (12 Aug 2021) /tmp/idnits32577/draft-ietf-ipsecme-ikev2-multiple-ke-05.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 document date (28 March 2022) is 47 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 641, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-ipsecme-g-ikev2-05 == Outdated reference: A later version (-02) exists of draft-tjhai-ikev2-beyond-64k-limit-01 Summary: 0 errors (**), 0 flaws (~~), 3 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: 29 September 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 28 March 2022 17 Multiple Key Exchanges in IKEv2 18 draft-ietf-ipsecme-ikev2-multiple-ke-05 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 29 September 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 1.4. Document Organization . . . . . . . . . . . . . . . . . . 7 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 . . 15 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 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 91 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 94 7.2. Informative References . . . . . . . . . . . . . . . . . 22 96 Appendix A. Sample Multiple Key Exchanges . . . . . . . . . . . 24 97 A.1. No Additional Key Exchange Used . . . . . . . . . . . . . 24 98 A.2. Additional Key Exchange in the CREATE_CHILD_SA Exchange 99 only . . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 A.3. Not Matching Proposal for Additional Key Exchanges . . . 26 101 Appendix B. Alternative Design . . . . . . . . . . . . . . . . . 27 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 104 1. Introduction 106 1.1. Problem Description 108 Internet Key Exchange Protocol (IKEv2) as specified in [RFC7296] uses 109 the Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) 110 algorithm to establish a shared secret between an initiator and a 111 responder. The security of the DH and ECDH algorithms relies on the 112 difficulty to solve a discrete logarithm problem in multiplicative 113 and elliptic curve groups respectively when the order of the group 114 parameter is large enough. While solving such a problem remains 115 difficult with current computing power, it is believed that general 116 purpose quantum computers will be able to solve this problem, 117 implying that the security of IKEv2 is compromised. There are, 118 however, a number of cryptosystems that are conjectured to be 119 resistant against quantum computer attack. This family of 120 cryptosystems is known as post-quantum cryptography (PQC). It is 121 sometimes also referred to as quantum-safe cryptography (QSC) or 122 quantum-resistant cryptography (QRC). 124 1.2. Proposed Extension 126 This document describes a method to perform multiple successive key 127 exchanges in IKEv2. It allows integration of QSC in IKEv2, while 128 maintaining backwards compatibility, to derive a set of IKE keys that 129 is resistant to quantum computer attacks. This extension allows the 130 negotiation of one or more QSC algorithm to exchange data, in 131 addition to the existing DH or ECDH key exchange data. We believe 132 that the feature of using more than one post-quantum algorithms is 133 important as many of these algorithms are relatively new and there 134 may be a need to hedge the security risk with multiple key exchange 135 data from several distinct QSC algorithms. 137 The secrets established from each key exchange are combined in a way 138 such that should the post-quantum secrets not be present, the derived 139 shared secret is equivalent to that of the standard IKEv2; on the 140 other hand, a post-quantum shared secret is obtained if both 141 classical and post-quantum key exchange data are present. This 142 extension also applies to key exchanges in IKE Security Associations 143 (SAs) for Encapsulating Security Payload (ESP) [RFC4303] or 144 Authentication Header (AH) [RFC4302], i.e. Child SAs, in order to 145 provide a stronger guarantee of forward security. 147 Some post-quantum key exchange payloads may have sizes larger than 148 the standard maximum transmission unit (MTU) size, and therefore 149 there could be issues with fragmentation at the IP layer. IKE does 150 allow transmission over TCP where fragmentation is not an issue 151 [RFC8229]; however, we believe that a UDP-based solution will be 152 required too. IKE does have a mechanism to handle fragmentation 153 within UDP [RFC7383], however that is only applicable to messages 154 exchanged after the IKE_SA_INIT exchange. To use this mechanism, 155 this specification relies on the IKE_INTERMEDIATE exchange as 156 outlined in [I-D.ietf-ipsecme-ikev2-intermediate]. With this 157 mechanism, we do an initial key exchange, using a smaller, possibly 158 non-quantum resistant primitive, such as ECDH. Then, before we do 159 the IKE_AUTH exchange, we perform one or more IKE_INTERMEDIATE 160 exchanges, each of which contains an additional key exchange. As the 161 IKE_INTERMEDIATE exchange is encrypted, the IKE fragmentation 162 protocol [RFC7383] can be used. The IKE SK_* values are updated 163 after each exchange, and so the final IKE SA keys depend on all the 164 key exchanges, hence they are secure if any of the key exchanges are 165 secure. 167 Note that readers should consider the approach defined in this 168 document as providing a long term solution in upgrading the IKEv2 169 protocol to support post-quantum algorithms. A short term solution 170 to make IKEv2 key exchange quantum secure is to use post-quantum pre- 171 shared keys as discussed in [RFC8784]. 173 Note also, that the proposed approach of performing multiple 174 successive key exchanges in such a way that resulting session keys 175 depend on all of them is not limited to achieving quantum resistance 176 only. It can also be used when all the performed key exchanges are 177 classical (EC)DH ones, where for some reasons (e.g. policy 178 requirements) it is essential to perform multiple of them. 180 This draft does not attempt to address key exchanges with KE payloads 181 longer than 64k; the current IKE payload format does not allow that 182 as a possibility. At the current time, it appears likely that there 183 are a number of key exchanges available that would not require such a 184 requirement. However, if such a requirement is needed, 185 [I-D.tjhai-ikev2-beyond-64k-limit] discusses approaches that should 186 be taken to exchange huge payloads. 188 1.3. Changes 190 RFC EDITOR PLEASE DELETE THIS SECTION. 192 Changes in this draft in each version iterations. 194 draft-ietf-ipsecme-ikev2-multiple-ke-04 196 * Introduction and initial sections are reorganized. 198 * More clarifications for error handling added. 200 * ASCII arts displaying SA payload are added. 202 * Clarification for handling multiple round trips key exchange 203 methods added. 205 * DoS concerns added into Security Considerations section. 207 * Explicitly allow scenario when additional key exchanges are 208 performed only after peers are authenticated. 210 draft-ietf-ipsecme-ikev2-multiple-ke-03 212 * More clarifications added. 214 * Figure illustrating initial exchange added. 216 * Minor editorial changes. 218 draft-ietf-ipsecme-ikev2-multiple-ke-02 220 * Added a reference on the handling of KE payloads larger than 64KB. 222 draft-ietf-ipsecme-ikev2-multiple-ke-01 224 * References are updated. 226 draft-ietf-ipsecme-ikev2-multiple-ke-00 227 * Draft name changed as result of WG adoption and generalization of 228 the approach. 230 * New exchange IKE_FOLLOWUP_KE is defined for additional key 231 exchanges performed after CREATE_CHILD_SA. 233 * Nonces are removed from all additional key exchanges. 235 * Clarification that IKE_INTERMEDIATE must be negotiated is added. 237 draft-tjhai-ipsecme-hybrid-qske-ikev2-04 239 * Clarification about key derivation in case of multiple key 240 exchanges in CREATE_CHILD_SA is added. 242 * Resolving rekey collisions in case of multiple key exchanges is 243 clarified. 245 draft-tjhai-ipsecme-hybrid-qske-ikev2-03 247 * Using multiple key exchanges CREATE_CHILD_SA is defined. 249 draft-tjhai-ipsecme-hybrid-qske-ikev2-02 251 * Use new transform types to negotiate additional key exchanges, 252 rather than using the KE payloads of IKE SA. 254 draft-tjhai-ipsecme-hybrid-qske-ikev2-01 256 * Use IKE_INTERMEDIATE to perform multiple key exchanges in 257 succession. 259 * Handle fragmentation by keeping the first key exchange (a standard 260 IKE_SA_INIT with a few extra notifies) small, and encrypting the 261 rest of the key exchanges. 263 * Simplify the negotiation of the 'extra' key exchanges. 265 draft-tjhai-ipsecme-hybrid-qske-ikev2-00 267 * We added a feature to allow more than one post-quantum key 268 exchange algorithms to be negotiated and used to exchange a post- 269 quantum shared secret. 271 * Instead of relying on TCP encapsulation to deal with IP level 272 fragmentation, we introduced a new key exchange payload that can 273 be sent as multiple fragments within IKE_SA_INIT message. 275 1.4. Document Organization 277 The remainder of this document is organized as follows. Section 2 278 summarizes design criteria. Section 3 describes how multiple key 279 exchanges are performed between two IKE peers and how keying 280 materials are derived for both SAs and Child SAs. A summary of 281 alternative approaches that have been considered, but later 282 discarded, are described in Appendix B. Section 4 discusses IANA 283 considerations for the namespaces introduced in this document, and 284 lastly Section 5 discusses security considerations. 286 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 287 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 288 "OPTIONAL" in this document are to be interpreted as described in BCP 289 14 [RFC2119] [RFC8174] when, and only when, they appear in all 290 capitals, as shown here. 292 2. Design Criteria 294 The design of the proposed extension is driven by the following 295 criteria: 297 1) Need for post-quantum cryptography in IPsec. Quantum computers 298 might become feasible in the near future. If current Internet 299 communications are monitored and recorded today (D), the 300 communications could be decrypted as soon as a quantum- computer 301 is available (e.g., year Q) if key negotiation only relies on 302 non post-quantum primitives. This is a high threat for any 303 information that must remain confidential for a long period of 304 time T > Q-D. The need is obvious if we assume that Q is 2040, 305 D is 2020, and T is 30 years. Such a value of T is typical in 306 classified or healthcare data. 308 2) Hybrid. Currently, there does not exist a post-quantum key 309 exchange that is trusted at the level that ECDH is trusted 310 against conventional (non-quantum) adversaries. A hybrid post- 311 quantum algorithm to be introduced next to well-established 312 primitives, since the overall security is at least as strong as 313 each individual primitive. 315 3) Focus on quantum-resistant confidentiality. A passive attacker 316 can eavesdrop on IPsec communication today and decrypt it once a 317 quantum computer is available in the future. This is a very 318 serious attack for which we do not have a solution. An attacker 319 can only perform active attacks such as impersonation of the 320 communicating peers once a quantum computer is available, 321 sometime in the future. Thus, our design focuses on quantum- 322 resistant confidentiality due to the urgency of this problem. 323 This document does not address quantum-resistant authentication 324 since it is less urgent at this stage. 326 4) Limit amount of exchanged data. The protocol design should be 327 such that the amount of exchanged data, such as public-keys, is 328 kept as small as possible even if initiator and responder need 329 to agree on a hybrid group or multiple public-keys need to be 330 exchanged. 332 5) Future proof. Any cryptographic algorithm could be potentially 333 broken in the future by currently unknown or impractical 334 attacks: quantum computers are merely the most concrete example 335 of this. The design does not categorize algorithms as "post- 336 quantum" or "non post-quantum" nor does it create assumptions 337 about the properties of the algorithms, meaning that if 338 algorithms with different properties become necessary in the 339 future, this extension can be used unchanged to facilitate 340 migration to those algorithms. 342 6) Limited amount of changes. A key goal is to limit the number of 343 changes required when enabling a post-quantum handshake. This 344 ensures easier and quicker adoption in existing implementations. 346 7) Localized changes. Another key requirement is that changes to 347 the protocol are limited in scope, in particular, limiting 348 changes in the exchanged messages and in the state machine, so 349 that they can be easily implemented. 351 8) Deterministic operation. This requirement means that the hybrid 352 post-quantum exchange, and thus, the computed keys, will be 353 based on algorithms that both client and server wish to support. 355 9) Fragmentation support. Some PQC algorithms could be relatively 356 bulky and they might require fragmentation. Thus, a design goal 357 is the adaptation and adoption of an existing fragmentation 358 method or the design of a new method that allows for the 359 fragmentation of the key shares. 361 10) Backwards compatibility and interoperability. This is a 362 fundamental requirement to ensure that hybrid post-quantum IKEv2 363 and non-post-quantum IKEv2 implementations are interoperable. 365 11) Federal Information Processing Standards (FIPS) compliance. 366 IPsec is widely used in Federal Information Systems and FIPS 367 certification is an important requirement. However, algorithms 368 that are believed to be post-quantum are not FIPS compliant yet. 369 Still, the goal is that the overall hybrid post-quantum IKEv2 370 design can be FIPS compliant. 372 12) Ability to use this method with multiple classical (EC)DH key 373 exchanges. In some situations peers have no single mutually 374 trusted key exchange algorithm (e.g., due to local policy 375 restrictions). The ability to combine two (or more) key 376 exchange methods in such a way that the resulting shared key 377 depends on all of them allows peers to communicate in this 378 situation. 380 3. Multiple Key Exchanges 382 3.1. Design Overview 384 Most post-quantum key agreement algorithms are relatively new, and 385 thus are not fully trusted. There are also many proposed algorithms, 386 with different trade-offs and relying on different hard problems. 387 The concern is that some of these hard problems may turn out to be 388 easier to solve than anticipated and thus the key agreement algorithm 389 may not be as secure as expected. A hybrid solution, when multiple 390 key exchanges are performed and the calculated shared key depends on 391 all of them, allows us to deal with this uncertainty by combining a 392 classical key exchange with a post-quantum one, as well as leaving 393 open the possibility of multiple post-quantum key exchanges. 395 In order to be able to use IKE fragmentation [RFC7383] for those key 396 exchanges that may have long public keys, the proposed framework 397 utilizes the IKE_INTERMEDIATE exchange defined in 398 [I-D.ietf-ipsecme-ikev2-intermediate]. The initial IKE_INIT messages 399 do not have any inherent fragmentation support within IKE; however 400 that can include a relatively short KE payload. The additional key 401 exchanges are performed using IKE_INTERMEDIATE messages; because 402 these messages are encrypted, the standard IKE fragmentation 403 mechanism is available. 405 In order to minimize communication overhead, only the key shares that 406 are agreed to be used are actually exchanged. To negotiate 407 additional key exchanges seven new Transform Types are defined. 408 These transforms share allowed Transform IDs with Transform Type 4. 410 We assume that new Transform Type 4 identifiers will be assigned 411 later to the various post-quantum key exchanges. We specifically do 412 not make a distinction between classical (DH and ECDH) and post- 413 quantum key exchanges, nor post-quantum algorithms which are true key 414 exchanges versus post-quantum algorithms that act as key transport 415 mechanisms; all are treated equivalently by the protocol. To be more 416 specific, this document renames Transform Type 4 from "Diffie-Hellman 417 Group (D-H)" to "Key Exchange Method (KE)" and renames a field in the 418 Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange 419 Method". The corresponding IANA registry is also renamed from 420 "Diffie-Hellman Group Transform IDs" to "Key Exchange Method 421 Transform IDs". 423 The fact, that newly defined transforms share the same registry for 424 possible Transform IDs with Transform Type 4, allows additional key 425 exchanges to be of any type - either post-quantum or classical (EC)DH 426 one. This approach allows any combination of defined key exchange 427 methods to take place. This also allows performing a single post- 428 quantum key exchange in the IKE_SA_INIT without additional key 429 exchanges, provided that IP fragmentation is not an issue and that 430 hybrid key exchange is not needed. 432 The SA payload in the IKE_SA_INIT message includes one or more newly 433 defined transforms which represent the extra key exchange policy 434 required by the initiator. The responder follows the usual IKEv2 435 negotiation rules: it selects a single transform of each type, and 436 returns all of them in the IKE_SA_INIT response message. 438 Then, provided that additional key exchanges are negotiated, the 439 initiator and the responder perform one or more IKE_INTERMEDIATE 440 exchanges. Then the IKE_AUTH exchange authenticates peers and 441 completes IKE SA establishment. 443 Initiator Responder 444 --------------------------------------------------------------------- 445 <-- IKE_SA_INIT (additional key exchanges negotiation) --> 447 <-- {IKE_INTERMEDIATE (additional key exchange)} --> 449 ... 451 <-- {IKE_INTERMEDIATE (additional key exchange)} --> 453 <-- {IKE_AUTH} --> 454 Note, that this document assumes, that each key exchange method 455 requires one round trip and consumes exactly one IKE_INTERMEDIATE 456 exchange. This assumption is valid for all classic key exchange 457 methods defined so far and for all post-quantum methods currently 458 known. For hypothetical future key exchange methods requiring 459 multiple round trips to complete, a separate document should define 460 how such methods are splitted into several IKE_INTERMEDIATE 461 exchanges. 463 3.2. Protocol Details 465 In the simplest case, the initiator is happy with a single key 466 exchange (and has no interest in supporting multiple), and it is not 467 concerned with possible fragmentation of the IKE_SA_INIT messages 468 (either because the key exchange it selects is small enough not to 469 fragment, or the initiator is confident that fragmentation will be 470 handled either by IP fragmentation, or transport via TCP). 472 In this case, the initiator performs the IKE_SA_INIT as usual, 473 inserting a preferred key exchange (which is possibly a post-quantum 474 algorithm) as the listed Transform Type 4, and including the 475 initiator KE payload. If the responder accepts the policy, it 476 responds with an IKE_SA_INIT response, and IKE continues as usual. 478 If the initiator desires to negotiate multiple key exchanges, then 479 the initiator uses the protocol listed below. 481 3.2.1. IKE_SA_INIT Round: Negotiation 483 Multiple key exchanges are negotiated using the standard IKEv2 484 mechanism, via SA payload. For this purpose seven new transform 485 types, namely Additional Key Exchange 1 (), Additional 486 Key Exchange 2 (), Additional Key Exchange 3 (), Additional Key Exchange 4 (), Additional Key 488 Exchange 5 (), Additional Key Exchange 6 () 489 and Additional Key Exchange 7 () are defined. They are 490 collectively called Additional Key Exchange transforms in this 491 document and have slightly different semantics than existing IKEv2 492 transform types. They are interpreted as an indication of additional 493 key exchanges methods that peers agreed to perform in a series of 494 IKE_INTERMEDIATE exchanges following the IKE_SA_INIT exchange. The 495 allowed transform IDs for these transform types are the same as IDs 496 for the Transform Type 4, so they all share a single IANA registry 497 for transform IDs. 499 Key exchange method negotiated via Transform Type 4 always takes 500 place in the IKE_SA_INIT exchange, as defined in [RFC7296]. 501 Additional key exchanges negotiated via newly defined transforms MUST 502 take place in a series of IKE_INTERMEDIATE exchanges following the 503 IKE_SA_INIT exchange, performed in an order of the values of their 504 transform types, so that key exchange negotiated using Transform Type 505 n always precedes that of Transform Type n + 1. Each additional key 506 exchange method MUST be fully completed before the next one is 507 started. 509 Note that with this semantics, Additional Key Exchanges transforms 510 are not associated with any particular type of key exchange and do 511 not have any specific per transform type transform IDs IANA registry. 512 Instead they all share a single registry for transform IDs - "Key 513 Exchange Method Transform IDs", as well as Transform Type 4. All new 514 key exchange algorithms (both classical or post-quantum) should be 515 added to this registry. This approach gives peers flexibility in 516 defining the ways they want to combine different key exchange 517 methods. 519 When forming a proposal the initiator adds transforms for the 520 IKE_SA_INIT exchange using Transform Type 4. In most cases they will 521 contain classical key exchange methods (DH or ECDH), however it is 522 not a requirement. Additional key exchange methods are proposed 523 using Additional Key Exchanges transform types. All these transform 524 types are optional, the initiator is free to select any of them for 525 proposing additional key exchange methods. Consequently, if none of 526 Additional Key Exchange transforms are included in the proposal, then 527 this proposal indicates performing standard IKEv2, as defined in 528 [RFC7296]. If the initiator includes any Additional Key Exchanges 529 transform in the proposal, the responder MUST select one of the 530 algorithms proposed using this type. A transform ID NONE MAY be 531 added to those transform types which contain key exchange methods 532 that the initiator believes are optional according to its local 533 policy. 535 The responder performs negotiation using standard IKEv2 procedure 536 described in Section 3.3 of [RFC7296]. However, for the Additional 537 Key Exchange types the responder's choice MUST NOT contain equal 538 algorithms, except for transform ID of NONE. An algorithm is 539 represented as a transform, in some cases the transform could include 540 a set of associated attributes that define details of the algorithm. 541 In this case two ransforms can be the same, but the attributes must 542 be different. Additionally, the order of the attributes does not 543 affect the equality of the algorithm, so two transforms 544 (ID=alg1,ATTR1=attr1,ATTR2=attr2) and 545 (ID=alg1,ATTR2=attr2,ATTR1=attr1) define the same algorithm. 547 If the responder selected NONE for some Additional Key Exchange types 548 (provided they were proposed by the initiator), then the 549 corresponding IKE_INTERMEDIATE exchanges should not take place. The 550 IKE_INTERMEDIATE exchanges MUST only be performed for Additional Key 551 Exchange types containing non-NONE responders choices. It means that 552 if the initiator includes NONE in all Additional Key Exchange 553 transforms and the responder selects this value for all of them, then 554 no IKE_INTERMEDIATE exchanges will take place between the peers. 555 perform additional key exchanges will take place (note that they 556 still may take place for other purposes). 558 Below is an example of the SA payload in the initiator's IKE_SA_INIT 559 request message. Here we use an abbreviation AKE1, AKE 2 etc. to 560 denote Additional Key Exchange 1, Additional Key Exchange 2 etc. 561 transforms, that this document defines, and an abbreviation KE for 562 the Key Exchange transform, that this document renames from the 563 Diffie-Hellman Group transform. We also use not yet defined 564 Transform IDs PQ_KEM_1, PQ_KEM_2 and PQ_KEM_3 to denote some of 565 popular post-quantum key exchange methods. 567 SA Payload 568 | 569 +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8, 570 | 9 transforms, SPI = 0x35a1d6f22564f89d ) 571 | 572 +-- Transform ENCR ( ID = ENCR_AES_GCM_16 ) 573 | +-- Attribute ( Key Length = 256 ) 574 | 575 +-- Transform KE ( ID = 4096-bit MODP Group ) 576 | 577 +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 ) 578 | 579 +-- Transform AKE2 ( ID = PQ_KEM_1 ) 580 | 581 +-- Transform AKE2 ( ID = PQ_KEM_2 ) 582 | 583 +-- Transform AKE3 ( ID = PQ_KEM_1 ) 584 | 585 +-- Transform AKE3 ( ID = PQ_KEM_2 ) 586 | 587 +-- Transform AKE5 ( ID = PQ_KEM_3 ) 588 | 589 +-- Transform AKE5 ( ID = NONE ) 591 In this example the initiator proposes to perform initial key 592 exchange using 4096-bit MODP group following by two mandatory 593 additional key exchanges using PQ_KEM_1 and PQ_KEM_2 methods in any 594 order, following by additional key exchange using PQ_KEM_3 method 595 that may be omitted. 597 The responder might return the following SA payload, indicating that 598 it agrees to perform two additional key exchanges PQ_KEM_2 followed 599 by PQ_KEM_1 and doesn't want to perform PQ_KEM_3 additionally. 601 SA Payload 602 | 603 +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8, 604 | 6 transforms, SPI = 0x8df52b331a196e7b ) 605 | 606 +-- Transform ENCR ( ID = ENCR_AES_GCM_16 ) 607 | +-- Attribute ( Key Length = 256 ) 608 | 609 +-- Transform KE ( ID = 4096-bit MODP Group ) 610 | 611 +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 ) 612 | 613 +-- Transform AKE2 ( ID = PQ_KEM_2 ) 614 | 615 +-- Transform AKE3 ( ID = PQ_KEM_1 ) 616 | 617 +-- Transform AKE5 ( ID = NONE ) 619 If the initiator includes any Additional Key Exchanges transform 620 types into SA payload in the IKE_SA_INIT exchange request message, it 621 MUST also negotiate using IKE_INTERMEDIATE exchange as described in 622 [I-D.ietf-ipsecme-ikev2-intermediate], by including 623 INTERMEDIATE_EXCHANGE_SUPPORTED notification in the same message. If 624 the responder agrees to use additional key exchanges while 625 establishing initial IKE SA, it MUST also return this notification in 626 the IKE_SA_INIT response message, thus confirming that 627 IKE_INTERMEDIATE exchange is supported and will be used for 628 transferring additional key exchange data. If the IKE_INTERMEDIATE 629 exchange is not negotiated, then the peers MUST treat any Additional 630 Key Exchange transforms in the IKE_SA_INIT exchange messages as 631 unknown transform types and skip the proposals they appear in. If no 632 other proposals are present in the SA payload, the peers will proceed 633 as when no proposal is chosen (i.e. the responder will send 634 NO_PROPOSAL_CHOSEN notification). 636 Initiator Responder 637 --------------------------------------------------------------------- 638 HDR, SAi1(.. AKE*...), KEi1, Ni, 639 N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> 640 HDR, SAr1(.. AKE*...), KEr1, Nr, 641 [CERTREQ], 642 <--- N(INTERMEDIATE_EXCHANGE_SUPPORTED) 644 3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges 646 For each additional key exchange agreed to in the IKE_SA_INIT 647 exchange, the initiator and the responder perform IKE_INTERMEDIATE 648 exchange, as described in [I-D.ietf-ipsecme-ikev2-intermediate]. 650 Initiator Responder 651 --------------------------------------------------------------------- 652 HDR, SK {KEi(n)} --> 653 <-- HDR, SK {KEr(n)} 655 The initiator sends key exchange data in the KEi(n) payload. This 656 packet is protected with the current SK_ei/SK_ai keys. 658 On receiving this, the responder sends back key exchange payload 659 KEr(n); again, this packet is protected with the current SK_er/SK_ar 660 keys. 662 The former "Diffie-Hellman Group Num" (now called "Key Exchange 663 Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th 664 negotiated additional key exchange. 666 Once this exchange is done, both sides compute an updated keying 667 material: 669 SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr) 671 where SK(n) is the resulting shared secret of this key exchange, Ni 672 and Nr are nonces from the IKE_SA_INIT exchange and SK_d(n-1) is the 673 last generated SK_d, (derived from the previous IKE_INTERMEDIATE 674 exchange, or the IKE_SA_INIT if there have not already been any 675 IKE_INTERMEDIATE exchanges). Then, SK_d, SK_ai, SK_ar, SK_ei, SK_er, 676 SK_pi, SK_pr are updated as: 678 {SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) | 679 SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr) 681 Both the initiator and the responder use these updated key values in 682 the next exchange (IKE_INTERMEDIATE or IKE_AUTH). 684 3.2.3. IKE_AUTH Exchange 686 After all IKE_INTERMEDIATE exchanges have completed, the initiator 687 and the responder perform an IKE_AUTH exchange. This exchange is the 688 standard IKE exchange, except that the initiator and responder signed 689 octets are modified as described in 690 [I-D.ietf-ipsecme-ikev2-intermediate]. 692 3.2.4. CREATE_CHILD_SA Exchange 694 The CREATE_CHILD_SA exchange is used in IKEv2 for the purposes of 695 creating additional Child SAs, rekeying them and rekeying IKE SA 696 itself. When creating or rekeying Child SAs, the peers may 697 optionally perform a Diffie-Hellman key exchange to add a fresh 698 entropy into the session keys. In case of IKE SA rekey, the key 699 exchange is mandatory. Peers supporting this specification may want 700 to use multiple key exchanges in these situations. 702 Using multiple key exchanges with CREATE_CHILD_SA exchange is 703 negotiated similarly as in initial exchange, see Section 3.2.1. If 704 the initiator includes any Additional Key Exchanges transform in the 705 SA payload (along with Transform Type 4) and the responder agrees to 706 perform additional key exchanges, then the additional key exchanges 707 are performed in a series of new IKE_FOLLOWUP_KE exchanges that 708 follows the CREATE_CHILD_SA exchange. The IKE_FOLLOWUP_KE exchange 709 is introduced as a dedicated exchange for transferring data of 710 additional key exchanges following the key exchange performed in the 711 CREATE_CHILD_SA. Its Exchange Type is . 713 Key exchange negotiated via Transform Type 4 always takes place in 714 the CREATE_CHILD_SA exchange, as per IKEv2 specification. Additional 715 key exchanges are performed in an order of the values of their 716 transform types, so that key exchange negotiated using Transform Type 717 n always precedes key exchange negotiated using Transform Type n + 1. 718 Each additional key exchange method MUST be fully completed before 719 the next one is started. Note, that this document assumes, that each 720 key exchange method consumes exactly one IKE_FOLLOWUP_KE exchange. 721 For the methods requiring multiple round trips, a separate document 722 should define how such methods are splitted into several 723 IKE_FOLLOWUP_KE exchanges. 725 Since after IKE SA is created the window size may be greater than one 726 and multiple concurrent exchanges may be in progress, it is essential 727 to link the IKE_FOLLOWUP_KE exchanges together and with the 728 corresponding CREATE_CHILD_SA exchange. A new status type 729 notification ADDITIONAL_KEY_EXCHANGE is used for this purpose. Its 730 Notify Message Type is , Protocol ID and SPI Size are 731 both set to 0. The data associated with this notification is a blob 732 meaningful only to the responder, so that the responder can correctly 733 link successive exchanges. For the initiator the content of this 734 notification is an opaque blob. 736 The responder MUST include this notification in a CREATE_CHILD_SA or 737 IKE_FOLLOWUP_KE response message in case the next IKE_FOLLOWUP_KE 738 exchange is expected, filling it with some data that would allow 739 linking current exchange to the next one. The initiator MUST send 740 back this notification intact in the request message of the next 741 IKE_FOLLOWUP_KE exchange. 743 Below is an example of CREATE_CHILD_SA exchange followed by three 744 additional key exchanges. 746 Initiator Responder 747 --------------------------------------------------------------------- 748 HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> 749 <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, 750 N(ADDITIONAL_KEY_EXCHANGE)(link1)} 752 HDR(IKE_FOLLOWUP_KE), SK {KEi(1), 753 N(ADDITIONAL_KEY_EXCHANGE)(link1)} --> 754 <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1), 755 N(ADDITIONAL_KEY_EXCHANGE)(link2)} 757 HDR(IKE_FOLLOWUP_KE), SK {KEi(2), 758 N(ADDITIONAL_KEY_EXCHANGE)(link2)} --> 759 <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2), 760 N(ADDITIONAL_KEY_EXCHANGE)(link3)} 762 HDR(IKE_FOLLOWUP_KE), SK {KEi(3), 763 N(ADDITIONAL_KEY_EXCHANGE)(link3)} --> 764 <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(3)} 766 The former "Diffie-Hellman Group Num" (now called "Key Exchange 767 Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th 768 negotiated additional key exchange. 770 It is possible that due to some unexpected events (e.g. reboot) the 771 initiator may lose its state and forget that it is in the process of 772 performing additional key exchanges and thus never start the 773 remaining IKE_FOLLOWUP_KE exchanges. The responder MUST handle this 774 situation gracefully and delete the associated state if it does not 775 receive the next expected IKE_FOLLOWUP_KE request after some 776 reasonable period of time. 778 If responder receives IKE_FOLLOWUP_KE request containing 779 ADDITIONAL_KEY_EXCHANGE notification and the content of this notify 780 does not correspond to any active key exchange state the responder 781 has, it MUST send back a new error type notification STATE_NOT_FOUND. 782 This is a non-fatal error notification, its Notify Message Type is 783 , Protocol ID and SPI Size are both set to 0 and the 784 data is empty. If the initiator receives this notification in 785 response to IKE_FOLLOWUP_KE exchange performing additional key 786 exchange, it MUST cancel this exchange and MUST treat the whole 787 series of exchanges started from the CREATE_CHILD_SA exchange as 788 failed. In most cases, the receipt of this notification is caused by 789 premature deletion of the corresponding state on the responder (the 790 time period between IKE_FOLLOWUP_KE exchanges appeared too long from 791 the responder's point of view, e.g. due to a temporary network 792 failure). After receiving this notification the initiator MAY start 793 a new CREATE_CHILD_SA exchange (eventually followed by the 794 IKE_FOLLOWUP_KE exchanges) to retry the failed attempt. If the 795 initiator continues to receive STATE_NOT_FOUND notifications after 796 several retries, it MUST treat this situation as a fatal error and 797 delete IKE SA by sending a DELETE payload. 799 When rekeying IKE SA or Child SA, it is possible that the peers start 800 doing this at the same time, which is called simultaneous rekeying. 801 Sections 2.8.1 and 2.8.2 of [RFC7296] describe how IKEv2 handles this 802 situation. In a nutshell IKEv2 follows the rule that if in case of 803 simultaneous rekeying two identical new IKE SAs (or two pairs of 804 Child SAs) are created, then one of them should be deleted. Which 805 one is to be deleted is determined by comparing the values of four 806 nonces, that were used in the colliding CREATE_CHILD_SA exchanges - 807 the IKE SA (or pair of Child SAs) that was created by the exchange in 808 which the smallest nonce was used should be deleted by the initiator 809 of this exchange. 811 With multiple key exchanges the SAs are not yet created when the 812 CREATE_CHILD_SA is completed, they would be created only after the 813 series of IKE_FOLLOWUP_KE exchanges is finished. For this reason if 814 additional key exchanges were negotiated in the CREATE_CHILD_SA 815 initiated by the losing side, there is nothing to delete and this 816 side just stops the rekeying process - this side MUST NOT initiate 817 IKE_FOLLOWUP_KE exchange with next key exchange. 819 In most cases, rekey collisions are resolved in the CREATE_CHILD_SA 820 exchange. However, a situation may occur when due to packet loss, 821 one of the peers receives the CREATE_CHILD_SA message requesting 822 rekey of SA that is already being rekeyed by this peer (i.e. the 823 CREATE_CHILD_SA exchange initiated by this peer has been already 824 completed and the series of IKE_FOLLOWUP_KE exchanges is in 825 progress). In this case, TEMPORARY_FAILURE notification MUST be sent 826 in response to such a request. 828 If multiple key exchanges were negotiated in the CREATE_CHILD_SA 829 exchange, then the resulting keys are computed as follows. In case 830 of IKE SA rekey: 832 SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)) 834 In case of Child SA creation or rekey: 836 KEYMAT = prf+ (SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)) 838 In both cases SK_d is from existing IKE SA; SK(0), Ni, Nr are the 839 shared key and nonces from the CREATE_CHILD_SA respectively; 840 SK(1)...SK(n) are the shared keys from additional key exchanges. 842 3.2.5. Interaction with Childless IKE SA 844 It is also possible to establish a fully quantum-resistant IKE SAs 845 from additional key exchanges without using IKE_INTERMEDIATE 846 exchanges. In this case, the IKE SA created from IKE_SA_INIT 847 exchange can be immediately rekeyed with CREATE_CHILD_SA using 848 additional key exchanges and IKE_FOLLOWUP_KE message to carry the key 849 exchange payload. If only classical key exchange method is used in 850 the IKE_SA_INIT message, the very first Child SA created in IKE_AUTH 851 will not be quantum resistant. Consequently, if the peers' local 852 policy requires that all Child SAs should be fully-protected, then 853 the peers can avoid creating the very first Child SA by adopting 854 [RFC6023]. In this case, the peers exchange 855 CHILDLESS_IKEV2_SUPPORTED notification in the IKE_SA_INIT exchange 856 and a fully-protected Child SA can be created with CREATE_CHILD_SA 857 using additional key exchanges. 859 Note that if the initial IKE SA is used to transfer sensitive 860 information, then this information will not be protected using the 861 additional (e.g. quantum safe) key exchanges, so this scenario may be 862 inappropriate. One such example is in G-IKEv2 protocol 863 [I-D.ietf-ipsecme-g-ikev2] where cryptographic materials are 864 exchanged in IKE_SA_INIT messages between group member and the group 865 controller. 867 4. IANA Considerations 869 This document adds new exchange type into the "IKEv2 Exchange Types" 870 registry: 872 IKE_FOLLOWUP_KE 874 This document renames Transform Type 4 defined in "Transform Type 875 Values" registry from "Diffie-Hellman Group (D-H)" to "Key Exchange 876 Method (KE)". 878 This document renames IKEv2 registry "Transform Type 4 - Diffie- 879 Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange 880 Method Transform IDs". 882 This document adds the following Transform Types to the "Transform 883 Type Values" registry: 885 Type Description Used In 886 ----------------------------------------------------------------- 887 Additional Key Exchange 1 (optional in IKE, AH, ESP) 888 Additional Key Exchange 2 (optional in IKE, AH, ESP) 889 Additional Key Exchange 3 (optional in IKE, AH, ESP) 890 Additional Key Exchange 4 (optional in IKE, AH, ESP) 891 Additional Key Exchange 5 (optional in IKE, AH, ESP) 892 Additional Key Exchange 6 (optional in IKE, AH, ESP) 893 Additional Key Exchange 7 (optional in IKE, AH, ESP) 895 This document defines a new Notify Message Type in the "Notify 896 Message Types - Status Types" registry: 898 ADDITIONAL_KEY_EXCHANGE 900 and a new Notify Message Type in the "Notify Message Types - Error 901 Types" registry: 903 STATE_NOT_FOUND 905 5. Security Considerations 907 The key length of the Encryption Algorithm (Transform Type 1), the 908 Pseudorandom Function (Transform Type 2) and the Integrity Algorithm 909 (Transform Type 3), all have to be of sufficient length to prevent 910 attacks using Grover's algorithm [GROVER]. In order to use the 911 extension proposed in this document, the key lengths of these 912 transforms MUST be at least 256 bits long in order to provide 913 sufficient resistance to quantum attacks. Accordingly the post- 914 quantum security level achieved is at least 128 bits. 916 SKEYSEED is calculated from shared SK(x) using an algorithm defined 917 in Transform Type 2. While a quantum attacker may learn the value of 918 SK(x), if this value is obtained by means of a classical key 919 exchange, other SK(x) values generated by means of a quantum- 920 resistant algorithm ensure that the final SKEYSEED is not 921 compromised. This assumes that the algorithm defined in the 922 Transform Type 2 is post-quantum. 924 The main focus of this document is to prevent a passive attacker 925 performing a "harvest and decrypt" attack. In other words, an 926 attacker that records messages exchanged today and proceeds to 927 decrypt them once he owns a quantum computer. This attack is 928 prevented due to the hybrid nature of the key exchange. Other 929 attacks involving an active attacker using a quantum-computer are not 930 completely solved by this document. This is for two reasons. 932 The first reason is because the authentication step remains 933 classical. In particular, the authenticity of the SAs established 934 under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA 935 algorithms. Whilst the pre-shared key option, provided the key is 936 long enough, is post-quantum, the other algorithms are not. 937 Moreover, in implementations where scalability is a requirement, the 938 pre-shared key method may not be suitable. Quantum-safe authenticity 939 may be provided by using a quantum-safe digital signature and several 940 quantum-safe digital signature methods are being explored by IETF. 941 For example, if the implementation is able to reliably track state, 942 the hash based method, XMSS has the status of an RFC, see [RFC8391]. 943 Currently, quantum-safe authentication methods are not specified in 944 this document, but are planned to be incorporated in due course. 946 It should be noted that the purpose of post-quantum algorithms is to 947 provide resistance to attacks mounted in the future. The current 948 threat is that encrypted sessions are subject to eavesdropping and 949 archived with decryption by quantum computers taking place at some 950 point in the future. Until quantum computers become available there 951 is no point in attacking the authenticity of a connection because 952 there are no possibilities for exploitation. These only occur at the 953 time of the connection, for example by mounting a man-in-the-middle 954 (MitM) attack. Consequently there is not such a pressing need for 955 quantum-safe authenticity. 957 Performing multiple key exchanges while establishing IKEv2 SA 958 increases the responder's susceptibility to DoS attacks, because of 959 an increased amount of resources needed to spend before the initiator 960 is authenticated. This is especially true for post-quantum key 961 exchange methods, where many of them are more memory and/or CPU 962 intensive than the classical counterparts. 964 Responders may consider recommendations from [RFC8019] to deal with 965 increased DoS attack susceptibility. It is also possible that the 966 responder only agrees to create initial IKE SA without performing 967 additional key exchanges, provided the initiator includes such an 968 option in its proposals. Then peers immediately rekey initial IKE SA 969 with the CREATE_CHILD_SA exchange and additional key exchanges 970 performed via the IKE_FOLLOWUP_KE exchanges. In this case at the 971 point when resource-intensive operations are required, peers have 972 already authenticated each other. However, in the context of hybrid 973 post-quantum key exchange this scenario would leave initial IKE SA 974 (and initial Child SA if it is created) unprotected against quantum 975 computers. Nevertheless the rekeyed IKE SA (and Child SAs that will 976 be created over it) will have full protection. This is similar to 977 the scenario described in [RFC8784]. Depending on peers' policy, 978 this scenario may or may not be appropriate. 980 6. Acknowledgements 982 The authors would like to thank Frederic Detienne and Olivier Pelerin 983 for their comments and suggestions, including the idea to negotiate 984 the post-quantum algorithms using the existing KE payload. The 985 authors are also grateful to Tobias Heider and Tobias Guggemos for 986 valuable comments. Thanks to Paul Wouters for reviewing the 987 document. 989 7. References 991 7.1. Normative References 993 [I-D.ietf-ipsecme-ikev2-intermediate] 994 Smyslov, V., "Intermediate Exchange in the IKEv2 995 Protocol", Work in Progress, Internet-Draft, draft-ietf- 996 ipsecme-ikev2-intermediate-10, 5 March 2022, 997 . 1000 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1001 Requirement Levels", BCP 14, RFC 2119, 1002 DOI 10.17487/RFC2119, March 1997, 1003 . 1005 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1006 Kivinen, "Internet Key Exchange Protocol Version 2 1007 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1008 2014, . 1010 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1011 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1012 May 2017, . 1014 7.2. Informative References 1016 [GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for 1017 Database Search", Proc. of the Twenty-Eighth Annual ACM 1018 Symposium on the Theory of Computing (STOC 1996), 1996. 1020 [I-D.ietf-ipsecme-g-ikev2] 1021 Smyslov, V. and B. Weis, "Group Key Management using 1022 IKEv2", Work in Progress, Internet-Draft, draft-ietf- 1023 ipsecme-g-ikev2-05, 18 March 2022, . 1026 [I-D.tjhai-ikev2-beyond-64k-limit] 1027 Tjhai, C., Heider, T., and V. Smyslov, "Beyond 64KB Limit 1028 of IKEv2 Payloads", Work in Progress, Internet-Draft, 1029 draft-tjhai-ikev2-beyond-64k-limit-01, 9 July 2021, 1030 . 1033 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1034 DOI 10.17487/RFC4302, December 2005, 1035 . 1037 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1038 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1039 . 1041 [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A 1042 Childless Initiation of the Internet Key Exchange Version 1043 2 (IKEv2) Security Association (SA)", RFC 6023, 1044 DOI 10.17487/RFC6023, October 2010, 1045 . 1047 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 1048 (IKEv2) Message Fragmentation", RFC 7383, 1049 DOI 10.17487/RFC7383, November 2014, 1050 . 1052 [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange 1053 Protocol Version 2 (IKEv2) Implementations from 1054 Distributed Denial-of-Service Attacks", RFC 8019, 1055 DOI 10.17487/RFC8019, November 2016, 1056 . 1058 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1059 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1060 August 2017, . 1062 [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. 1063 Mohaisen, "XMSS: eXtended Merkle Signature Scheme", 1064 RFC 8391, DOI 10.17487/RFC8391, May 2018, 1065 . 1067 [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, 1068 "Mixing Preshared Keys in the Internet Key Exchange 1069 Protocol Version 2 (IKEv2) for Post-quantum Security", 1070 RFC 8784, DOI 10.17487/RFC8784, June 2020, 1071 . 1073 Appendix A. Sample Multiple Key Exchanges 1075 This appendix shows some examples of multiple key exchanges. These 1076 examples are purely for information purposes and they describe some 1077 message flow scenarios that may occur in establishing an IKE or CHILD 1078 SA. Note that some payloads that are not relevant to multiple key 1079 exchanges may be omitted for brevity. 1081 A.1. No Additional Key Exchange Used 1083 The initiator proposes two sets of optional additional key exchanges, 1084 but the responder does not support any of them. The responder 1085 chooses NONE for each set and consequently, IKE_INTERMEDIATE exchange 1086 does not takes place and the exchange proceeds to IKE_AUTH phase. 1087 The resulting keying materials are the same as those derived with 1088 [RFC7296]. 1090 Initiator Responder 1091 ------------------------------------------------------------------------ 1092 HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> 1093 KEi1, Ni, N(IKEV2_FRAG_SUPPORTED), 1094 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 1095 Proposal #1 1096 Transform ECR (ID = ENCR_AES_GCM_16, 1097 256-bit key) 1098 Transform PRF (ID = PRF_HMAC_SHA2_512) 1099 Transform KE (ID = Curve25519) 1100 Transform AKE1 (ID = PQ_KEM_1) 1101 Transform AKE1 (ID = PQ_KEM_2) 1102 Transform AKE1 (ID = NONE) 1103 Transform AKE2 (ID = PQ_KEM_3) 1104 Transform AKE2 (ID = PQ_KEM_4) 1105 Transform AKE2 (ID = NONE) 1106 <--- HDR(IKE_SA_INIT), SAr1(.. AKE*...), 1107 KEr1, Nr, N(IKEV2_FRAG_SUPPORTED), 1108 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 1109 Proposal #1 1110 Transform ECR (ID = ENCR_AES_GCM_16, 1111 256-bit key) 1112 Transform PRF (ID = PRF_HMAC_SHA2_512) 1113 Transform KE (ID = Curve25519) 1114 Transform AKE1 (ID = NONE) 1115 Transform AKE2 (ID = NONE) 1117 HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } ---> 1118 <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2, 1119 TSi, TSr } 1121 A.2. Additional Key Exchange in the CREATE_CHILD_SA Exchange only 1123 The exchanges below show that the initiator does not propose the use 1124 of additional key exchanges to establish an IKE SA, but they are 1125 required in order to establish a Child SA. In order to establish a 1126 fully quantum-resistant IPsec SA, both peers include 1127 CHILDLESS_IKEV2_SUPPORTED notification in their exchange so that the 1128 first Child SA is not created in IKE_AUTH, but instead the IKE SA is 1129 immediately rekeyed using CREATED_CHILD_SA. Any Child SA will have 1130 to be created via subsequent CREATED_CHILD_SA exchange. 1132 Initiator Responder 1133 ------------------------------------------------------------------------ 1134 HDR(IKE_SA_INIT), SAi1, ---> 1135 KEi1, Ni, N(IKEV2_FRAG_SUPPORTED), 1136 N(CHILDLESS_IKEV2_SUPPORTED) 1137 <--- HDR(IKE_SA_INIT), SAr1, 1138 KEr1, Nr, N(IKEV2_FRAG_SUPPORTED), 1139 N(CHILDLESS_IKEV2_SUPPORTED) 1140 HDR(IKE_AUTH), SK{ IDi, AUTH } ---> 1141 <--- HDR(IKE_AUTH), SK{ IDr, AUTH } 1142 HDR(CREATE_CHILD_SA), SK{ SAi(.. AKE*...), Ni, KEi } ---> 1143 Proposal #1 1144 Transform ECR (ID = ENCR_AES_GCM_16, 1145 256-bit key) 1146 Transform PRF (ID = PRF_HMAC_SHA2_512) 1147 Transform KE (ID = Curve25519) 1148 Transform AKE1 (ID = PQ_KEM_1) 1149 Transform AKE1 (ID = PQ_KEM_2) 1150 Transform AKE2 (ID = PQ_KEM_5) 1151 Transform AKE2 (ID = PQ_KEM_6) 1152 Transform AKE2 (ID = NONE) 1153 <--- HDR(CREATE_CHILD_SA), SK{ SAr(.. AKE*...), 1154 Nr, KEr, 1155 N(ADDITIONAL_KEY_EXCHANGE)(link1) } 1156 Proposal #1 1157 Transform ECR (ID = ENCR_AES_GCM_16, 1158 256-bit key) 1159 Transform PRF (ID = PRF_HMAC_SHA2_512) 1160 Transform KE (ID = Curve25519) 1161 Transform AKE1 (ID = PQ_KEM_2) 1162 Transform AKE2 (ID = PQ_KEM_5) 1164 HDR(IKE_FOLLOWUP_KE), SK{ KEi(1), ---> 1165 N(ADDITIONAL_KEY_EXCHANGE)(link1) } 1166 <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(1), 1167 N(ADDITIONAL_KEY_EXCHANGE)(link2) } 1168 HDR(IKE_FOLLOWUP_KE), SK{ KEi(2), ---> 1169 N(ADDITIONAL_KEY_EXCHANGE)(link2) } 1170 <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(2) } 1172 A.3. Not Matching Proposal for Additional Key Exchanges 1174 The initiator proposes the combination of PQ_KEM_1, PQ_KEM_2, 1175 PQ_KEM_3, and PQ_KEM_4 as the additional key exchanges. The 1176 initiator indicates, using the key exchange method NONE, that either 1177 PQ_KEM_1 or PQ_KEM_2 must be used to establish a security 1178 association. The responder, although supports the optional PQ_KEM_3 1179 and PQ_KEM_4 method, does not support either PQ_KEM_1 or PQ_KEM_2 1180 mandatory method and therefore responds with NO_PROPOSAL_CHOSEN 1181 notification. 1183 Initiator Responder 1184 ------------------------------------------------------------------------ 1185 HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> 1186 KEi1, Ni, N(IKEV2_FRAG_SUPPORTED), 1187 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 1188 Proposal #1 1189 Transform ECR (ID = ENCR_AES_GCM_16, 1190 256-bit key) 1191 Transform PRF (ID = PRF_HMAC_SHA2_512) 1192 Transform KE (ID = Curve25519) 1193 Transform AKE1 (ID = PQ_KEM_1) 1194 Transform AKE1 (ID = PQ_KEM_2) 1195 Transform AKE2 (ID = PQ_KEM_3) 1196 Transform AKE2 (ID = PQ_KEM_4) 1197 Transform AKE2 (ID = NONE) 1198 <--- HDR(IKE_SA_INIT), N(NO_PROPOSAL_CHOSEN) 1200 Appendix B. Alternative Design 1202 This section gives an overview on a number of alternative approaches 1203 that we have considered, but later discarded. These approaches are: 1205 * Sending the classical and post-quantum key exchanges as a single 1206 transform 1208 We considered combining the various key exchanges into a single 1209 large KE payload; this effort is documented in a previous version 1210 of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This 1211 does allow us to cleanly apply hybrid key exchanges during the 1212 child SA; however it does add considerable complexity, and 1213 requires an independent fragmentation solution. 1215 * Sending post-quantum proposals and policies in KE payload only 1217 With the objective of not introducing unnecessary notify payloads, 1218 we considered communicating the hybrid post-quantum proposal in 1219 the KE payload during the first pass of the protocol exchange. 1220 Unfortunately, this design is susceptible to the following 1221 downgrade attack. Consider the scenario where there is an MitM 1222 attacker sitting between an initiator and a responder. The 1223 initiator proposes, through SAi payload, to use a hybrid post- 1224 quantum group and as a backup a Diffie-Hellman group, and through 1225 KEi payload, the initiator proposes a list of hybrid post-quantum 1226 proposals and policies. The MitM attacker intercepts this traffic 1227 and replies with N(INVALID_KE_PAYLOAD) suggesting to downgrade to 1228 the backup Diffie-Hellman group instead. The initiator then 1229 resends the same SAi payload and the KEi payload containing the 1230 public value of the backup Diffie-Hellman group. Note that the 1231 attacker may forward the second IKE_SA_INIT message only to the 1232 responder, and therefore at this point in time, the responder will 1233 not have the information that the initiator prefers the hybrid 1234 group. Of course, it is possible for the responder to have a 1235 policy to reject an IKE_SA_INIT message that (a) offers a hybrid 1236 group but not offering the corresponding public value in the KEi 1237 payload; and (b) the responder has not specifically acknowledged 1238 that it does not supported the requested hybrid group. However, 1239 the checking of this policy introduces unnecessary protocol 1240 complexity. Therefore, in order to fully prevent any downgrade 1241 attacks, using KE payload alone is not sufficient and that the 1242 initiator MUST always indicate its preferred post-quantum 1243 proposals and policies in a notify payload in the subsequent 1244 IKE_SA_INIT messages following a N(INVALID_KE_PAYLOAD) response. 1246 * New payload types to negotiate hybrid proposal and to carry post- 1247 quantum public values 1249 Semantically, it makes sense to use a new payload type, which 1250 mimics the SA payload, to carry a hybrid proposal. Likewise, 1251 another new payload type that mimics the KE payload, could be used 1252 to transport hybrid public value. Although, in theory a new 1253 payload type could be made backwards compatible by not setting its 1254 critical flag as per Section 2.5 of RFC7296, we believe that it 1255 may not be that simple in practice. Since the original release of 1256 IKEv2 in RFC4306, no new payload type has ever been proposed and 1257 therefore, this creates a potential risk of having a backward 1258 compatibility issue from non-conforming RFC IKEv2 implementations. 1259 Since we could not see any other compelling advantages apart from 1260 a semantic one, we use the existing transform type and notify 1261 payloads instead. In fact, as described above, we use the KE 1262 payload in the first IKE_SA_INIT request round and the notify 1263 payload to carry the post-quantum proposals and policies. We use 1264 one or more of the existing KE payloads to carry the hybrid public 1265 values. 1267 * Hybrid public value payload 1269 One way to transport the negotiated hybrid public payload, which 1270 contains one classical Diffie-Hellman public value and one or more 1271 post-quantum public values, is to bundle these into a single KE 1272 payload. Alternatively, these could also be transported in a 1273 single new hybrid public value payload, but following the same 1274 reasoning as above, this may not be a good idea from a backward 1275 compatibility perspective. Using a single KE payload would 1276 require an encoding or formatting to be defined so that both peers 1277 are able to compose and extract the individual public values. 1278 However, we believe that it is cleaner to send the hybrid public 1279 values in multiple KE payloads--one for each group or algorithm. 1280 Furthermore, at this point in the protocol exchange, both peers 1281 should have indicated support of handling multiple KE payloads. 1283 * Fragmentation 1285 Handling of large IKE_SA_INIT messages has been one of the most 1286 challenging tasks. A number of approaches have been considered 1287 and the two prominent ones that we have discarded are outlined as 1288 follows. 1290 The first approach was to treat the entire IKE_SA_INIT message as 1291 a stream of bytes, which we then split it into a number of 1292 fragments, each of which is wrapped onto a payload that would fit 1293 into the size of the network MTU. The payload that wraps each 1294 fragment is a new payload type and it was envisaged that this new 1295 payload type will not cause a backward compatibility issue because 1296 at this stage of the protocol, both peers should have indicated 1297 support of fragmentation in the first pass of the IKE_SA_INIT 1298 exchange. The negotiation of fragmentation is performed using a 1299 notify payload, which also defines supporting parameters such as 1300 the size of fragment in octets and the fragment identifier. The 1301 new payload that wraps each fragment of the messages in this 1302 exchange is assigned the same fragment identifier. Furthermore, 1303 it also has other parameters such as a fragment index and total 1304 number of fragments. We decided to discard this approach due to 1305 its blanket approach to fragmentation. In cases where only a few 1306 payloads need to be fragmented, we felt that this approach is 1307 overly complicated. 1309 Another idea that was discarded was fragmenting an individual 1310 payload without introducing a new payload type. The idea was to 1311 use the 9-th bit (the bit after the critical flag in the RESERVED 1312 field) in the generic payload header as a flag to mark that this 1313 payload is fragmented. As an example, if a KE payload is to be 1314 fragmented, it may look as follows. 1316 1 2 3 1317 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 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | Next Payload |C|F| RESERVED | Payload Length | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | Diffie-Hellman Group Number | Fragment Identifier | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 | Fragment Index | Total Fragments | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | Total KE Payload Data Length | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | | 1328 ~ Fragmented KE Payload ~ 1329 | | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 When the flag F is set, this means the current KE payload is a 1333 fragment of a larger KE payload. The Payload Length field denotes 1334 the size of this payload fragment in octets--including the size of 1335 the generic payload header. The two-octet RESERVED field 1336 following Diffie-Hellman Group Number was to be used as a fragment 1337 identifier to help assembly and disassembly of fragments. The 1338 Fragment Index and Total Fragments fields are self-explanatory. 1339 The Total KE Payload Data Length indicates the size of the 1340 assembled KE payload data in octets. Finally, the actual fragment 1341 is carried in Fragment KE Payload field. 1343 We discarded this approach because we believe that the working 1344 group may not be happy using the RESERVED field to change the 1345 format of a packet and that implementers may not like the 1346 complexity added from checking the fragmentation flag in each 1347 received payload. More importantly, fragmenting the messages in 1348 this way may leave the system to be more prone to denial of 1349 service (DoS) attacks. By using IKE_INTERMEDIATE to transport the 1350 large post-quantum key exchange payloads, there is no longer any 1351 issue with fragmentation. 1353 * Group sub-identifier 1354 As discussed before, each group identifier is used to distinguish 1355 a post-quantum algorithm. Further classification could be made on 1356 a particular post-quantum algorithm by assigning additional value 1357 alongside the group identifier. This sub- identifier value may be 1358 used to assign different security parameter sets to a given post- 1359 quantum algorithm. However, this level of details does not fit 1360 the principles of the document where it should deal with generic 1361 hybrid key exchange protocol, not a specific ciphersuite. 1362 Furthermore, there are enough Diffie- Hellman group identifiers 1363 should this be required in the future. 1365 Authors' Addresses 1367 C. Tjhai 1368 Post-Quantum 1369 Email: cjt@post-quantum.com 1371 M. Tomlinson 1372 Post-Quantum 1373 Email: mt@post-quantum.com 1375 G. Bartlett 1376 Quantum Secret 1377 Email: graham.ietf@gmail.com 1379 S. Fluhrer 1380 Cisco Systems 1381 Email: sfluhrer@cisco.com 1383 D. Van Geest 1384 ISARA Corporation 1385 Email: daniel.vangeest@isara.com 1387 O. Garcia-Morchon 1388 Philips 1389 Email: oscar.garcia-morchon@philips.com 1391 Valery Smyslov 1392 ELVIS-PLUS 1393 Email: svan@elvis.ru