idnits 2.17.1 draft-ietf-ipsecme-ikev2-multiple-ke-02.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: With multiple key exchanges the SAs are not yet created when the CRETE_CHILD_SA is completed, they would be created only after the series of IKE_FOLLOWUP_KE exchanges is finished. For this reason if additional key exchanges were negotiated in the CREATE_CHILD_SA initiated by the losing side, there is nothing to delete and this side just stops the rekeying process - this side MUST not initiate IKE_FOLLOWUP_KE exchange with next key exchange. -- The document date (January 10, 2021) is 1203 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) == Outdated reference: A later version (-10) exists of draft-ietf-ipsecme-ikev2-intermediate-05 == Outdated reference: A later version (-03) exists of draft-tjhai-ikev2-beyond-64k-limit-00 -- Obsolete informational reference (is this intentional?): RFC 8229 (Obsoleted by RFC 9329) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: July 14, 2021 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 January 10, 2021 17 Multiple Key Exchanges in IKEv2 18 draft-ietf-ipsecme-ikev2-multiple-ke-02 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 July 14, 2021. 59 Copyright Notice 61 Copyright (c) 2021 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 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3 78 1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . 3 79 1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.4. Document Organization . . . . . . . . . . . . . . . . . . 6 81 2. Design Criteria . . . . . . . . . . . . . . . . . . . . . . . 6 82 3. Multiple Key Exchanges . . . . . . . . . . . . . . . . . . . 8 83 3.1. Overall Design . . . . . . . . . . . . . . . . . . . . . 8 84 3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . 10 85 3.2.1. IKE_SA_INIT Round: Negotiation . . . . . . . . . . . 10 86 3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges . . 11 87 3.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 12 88 3.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 89 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 94 7.2. Informative References . . . . . . . . . . . . . . . . . 18 95 Appendix A. Alternative Design . . . . . . . . . . . . . . . . . 19 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 98 1. Introduction 100 1.1. Problem Description 102 Internet Key Exchange Protocol (IKEv2) as specified in [RFC7296] uses 103 the Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) 104 algorithm to establish a shared secret between an initiator and a 105 responder. The security of the DH and ECDH algorithms relies on the 106 difficulty to solve a discrete logarithm problem in multiplicative 107 and elliptic curve groups respectively when the order of the group 108 parameter is large enough. While solving such a problem remains 109 difficult with current computing power, it is believed that general 110 purpose quantum computers will be able to solve this problem, 111 implying that the security of IKEv2 is compromised. There are, 112 however, a number of cryptosystems that are conjectured to be 113 resistant against quantum computer attack. This family of 114 cryptosystems is known as post-quantum cryptography (PQC). It is 115 sometimes also referred to as quantum-safe cryptography (QSC) or 116 quantum-resistant cryptography (QRC). 118 1.2. Proposed Extension 120 This document describes a method to perform multiple successive key 121 exchanges in IKEv2. It allows integration of QSC in IKEv2, while 122 maintaining backwards compatibility, to derive a set of IKE keys that 123 is resistant to quantum computer attacks. This extension allows the 124 negotiation of one or more QSC algorithm to exchange data, in 125 addition to the existing DH or ECDH key exchange data. We believe 126 that the feature of using more than one post-quantum algorithms is 127 important as many of these algorithms are relatively new and there 128 may be a need to hedge the security risk with multiple key exchange 129 data from several distinct QSC algorithms. 131 The secrets established from each key exchange are combined in a way 132 such that should the post-quantum secrets not be present, the derived 133 shared secret is equivalent to that of the standard IKEv2; on the 134 other hand, a post-quantum shared secret is obtained if both 135 classical and post-quantum key exchange data are present. This 136 extension also applies to key exchanges in IKE Security Associations 137 (SAs) for Encapsulating Security Payload (ESP) [RFC4303] or 138 Authentication Header (AH) [RFC4302], i.e. Child SAs, in order to 139 provide a stronger guarantee of forward security. 141 Some post-quantum key exchange payloads may have sizes larger than 142 the standard maximum transmission unit (MTU) size, and therefore 143 there could be issues with fragmentation at the IP layer. IKE does 144 allow transmission over TCP where fragmentation is not an issue 145 [RFC8229]; however, we believe that a UDP-based solution will be 146 required too. IKE does have a mechanism to handle fragmentation 147 within UDP [RFC7383], however that is only applicable to messages 148 exchanged after the IKE_SA_INIT. To use this mechanism, this 149 specification relies on the IKE_INTERMEDIATE exchange as outlined in 150 [I-D.ietf-ipsecme-ikev2-intermediate]. With this mechanism, we do an 151 initial key exchange, using a smaller, possibly non-quantum resistant 152 primitive, such as ECDH. Then, before we do the IKE_AUTH exchange, 153 we perform one or more IKE_INTERMEDIATE exchanges, each of which 154 contains an additional key exchange. As the IKE_INTERMEDIATE 155 exchange is encrypted, the IKE fragmentation protocol [RFC7383] can 156 be used. The IKE SK_* values are updated after each exchange, and so 157 the final IKE SA keys depend on all the key exchanges, hence they are 158 secure if any of the key exchanges are secure. 160 Note that readers should consider the approach defined in this 161 document as providing a long term solution in upgrading the IKEv2 162 protocol to support post-quantum algorithms. A short term solution 163 to make IKEv2 key exchange quantum secure is to use post-quantum pre- 164 shared keys as discussed in [RFC8784]. 166 Note also, that the proposed approach of performing multiple 167 successive key exchanges in such a way that resulting session keys 168 depend on all of them is not limited to achieving quantum resistance 169 only. It can also be used when all the performed key exchanges are 170 classical (EC)DH ones, where for some reasons (e.g. policy 171 requirements) it is essential to perform multiple of them. 173 This draft does not attempt to address key exchanges with KE payloads 174 longer than 64k; the current IKE payload format does not allow that 175 as a possibility. At the current time, it appears likely that there 176 are a number of key exchanges available that would not require such a 177 requirement. However, if such a requirement is needed, 178 [I-D.tjhai-ikev2-beyond-64k-limit] discusses approaches that should 179 be taken to exchange huge payloads. 181 1.3. Changes 183 RFC EDITOR PLEASE DELETE THIS SECTION. 185 Changes in this draft in each version iterations. 187 draft-ietf-ipsecme-ikev2-multiple-ke-02 189 o Added a reference on the handling of KE payloads larger than 64KB. 191 draft-ietf-ipsecme-ikev2-multiple-ke-01 193 o References are updated. 195 o Draft name changed as result of WG adoption and generalization of 196 the approach. 198 o New exchange IKE_FOLLOWUP_KE is defined for additional key 199 exchanges performed after CREATE_CHILD_SA. 201 o Nonces are removed from all additional key exchanges. 203 o Clarification that IKE_INTERMEDIATE must be negotiated is added. 205 draft-tjhai-ipsecme-hybrid-qske-ikev2-04 207 o Clarification about key derivation in case of multiple key 208 exchanges in CREATE_CHILD_SA is added. 210 o Resolving rekey collisions in case of multiple key exchanges is 211 clarified. 213 draft-tjhai-ipsecme-hybrid-qske-ikev2-03 215 o Using multiple key exchanges CREATE_CHILD_SA is defined. 217 draft-tjhai-ipsecme-hybrid-qske-ikev2-02 219 o Use new transform types to negotiate additional key exchanges, 220 rather than using the KE payloads of IKE SA. 222 draft-tjhai-ipsecme-hybrid-qske-ikev2-01 224 o Use IKE_INTERMEDIATE to perform multiple key exchanges in 225 succession. 227 o Handle fragmentation by keeping the first key exchange (a standard 228 IKE_SA_INIT with a few extra notifies) small, and encrypting the 229 rest of the key exchanges. 231 o Simplify the negotiation of the 'extra' key exchanges. 233 draft-tjhai-ipsecme-hybrid-qske-ikev2-00 235 o We added a feature to allow more than one post-quantum key 236 exchange algorithms to be negotiated and used to exchange a post- 237 quantum shared secret. 239 o Instead of relying on TCP encapsulation to deal with IP level 240 fragmentation, we introduced a new key exchange payload that can 241 be sent as multiple fragments within IKE_SA_INIT message. 243 1.4. Document Organization 245 The remainder of this document is organized as follows. Section 2 246 summarizes design criteria. Section 3 describes how multiple key 247 exchanges are performed between two IKE peers and how keying 248 materials are derived for both SAs and Child SAs. A summary of 249 alternative approaches that have been considered, but later 250 discarded, are described in Appendix A. Section 4 discusses IANA 251 considerations for the namespaces introduced in this document, and 252 lastly Section 5 discusses security considerations. 254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 256 "OPTIONAL" in this document are to be interpreted as described in BCP 257 14 [RFC2119] [RFC8174] when, and only when, they appear in all 258 capitals, as shown here. 260 2. Design Criteria 262 The design of the proposed extension is driven by the following 263 criteria: 265 1) Need for post-quantum cryptography in IPsec. Quantum computers 266 might become feasible in the near future. If current Internet 267 communications are monitored and recorded today (D), the 268 communications could be decrypted as soon as a quantum- computer 269 is available (e.g., year Q) if key negotiation only relies on 270 non post-quantum primitives. This is a high threat for any 271 information that must remain confidential for a long period of 272 time T > Q-D. The need is obvious if we assume that Q is 2040, 273 D is 2020, and T is 30 years. Such a value of T is typical in 274 classified or healthcare data. 276 2) Hybrid. Currently, there does not exist a post-quantum key 277 exchange that is trusted at the level that ECDH is trusted 278 against conventional (non-quantum) adversaries. A hybrid post- 279 quantum algorithm to be introduced next to well-established 280 primitives, since the overall security is at least as strong as 281 each individual primitive. 283 3) Focus on quantum-resistant confidentiality. A passive attacker 284 can eavesdrop on IPsec communication today and decrypt it once a 285 quantum computer is available in the future. This is a very 286 serious attack for which we do not have a solution. An attacker 287 can only perform active attacks such as impersonation of the 288 communicating peers once a quantum computer is available, 289 sometime in the future. Thus, our design focuses on quantum- 290 resistant confidentiality due to the urgency of this problem. 291 This document does not address quantum-resistant authentication 292 since it is less urgent at this stage. 294 4) Limit amount of exchanged data. The protocol design should be 295 such that the amount of exchanged data, such as public-keys, is 296 kept as small as possible even if initiator and responder need 297 to agree on a hybrid group or multiple public-keys need to be 298 exchanged. 300 5) Future proof. Any cryptographic algorithm could be potentially 301 broken in the future by currently unknown or impractical 302 attacks: quantum computers are merely the most concrete example 303 of this. The design does not categorize algorithms as "post- 304 quantum" or "non post-quantum" nor does it create assumptions 305 about the properties of the algorithms, meaning that if 306 algorithms with different properties become necessary in the 307 future, this extension can be used unchanged to facilitate 308 migration to those algorithms. 310 6) Limited amount of changes. A key goal is to limit the number of 311 changes required when enabling a post-quantum handshake. This 312 ensures easier and quicker adoption in existing implementations. 314 7) Localized changes. Another key requirement is that changes to 315 the protocol are limited in scope, in particular, limiting 316 changes in the exchanged messages and in the state machine, so 317 that they can be easily implemented. 319 8) Deterministic operation. This requirement means that the hybrid 320 post-quantum exchange, and thus, the computed keys, will be 321 based on algorithms that both client and server wish to support. 323 9) Fragmentation support. Some PQC algorithms could be relatively 324 bulky and they might require fragmentation. Thus, a design goal 325 is the adaptation and adoption of an existing fragmentation 326 method or the design of a new method that allows for the 327 fragmentation of the key shares. 329 10) Backwards compatibility and interoperability. This is a 330 fundamental requirement to ensure that hybrid post-quantum IKEv2 331 and non-post-quantum IKEv2 implementations are interoperable. 333 11) Federal Information Processing Standards (FIPS) compliance. 334 IPsec is widely used in Federal Information Systems and FIPS 335 certification is an important requirement. However, algorithms 336 that are believed to be post-quantum are not FIPS compliant yet. 337 Still, the goal is that the overall hybrid post-quantum IKEv2 338 design can be FIPS compliant. 340 12) Ability to use this method with multiple classical (EC)DH key 341 exchanges. In some situations peers have no single mutually 342 trusted key exchange algorithm (e.g., due to local policy 343 restrictions). The ability to combine two (or more) key 344 exchange methods in such a way that the resulting shared key 345 depends on all of them allows peers to communicate in this 346 situation. 348 3. Multiple Key Exchanges 350 3.1. Overall Design 352 This design assigns new Transform Type 4 identifiers to the various 353 post-quantum key exchanges (which will be defined later). We 354 specifically do not make a distinction between classical (DH and 355 ECDH) and post-quantum key exchanges, nor post-quantum algorithms 356 which are true key exchanges versus post-quantum algorithms that act 357 as key transport mechanisms; all are treated equivalently by the 358 protocol. To be more specific, this document renames Transform Type 359 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and 360 renames a field in the Key Exchange Payload from "Diffie-Hellman 361 Group Num" to "Key Exchange Method". The corresponding IANA registry 362 is also renamed from "Diffie-Hellman Group Transform IDs" to "Key 363 Exchange Method Transform IDs". 365 In order to support IKE fragmentation for additional key exchanges 366 that may have long public keys, the proposed framework utilizes the 367 IKE_INTERMEDIATE exchange defined in 368 [I-D.ietf-ipsecme-ikev2-intermediate]. 370 In order to minimize communication overhead, only the key shares that 371 are agreed to be used are actually exchanged. In order to achieve 372 this several new Transform Types are defined, each sharing possible 373 Transform IDs with Transform Type 4. The IKE_SA_INIT message 374 includes one or more newly defined SA transforms that lists the extra 375 key exchange policy required by the initiator; the responder selects 376 a single transform of each type, and returns them in the response 377 IKE_SA_INIT message. Then, provided that additional key exchanges 378 are negotiated, the initiator and the responder perform one or more 379 IKE_INTERMEDIATE exchanges; each such exchange includes a KE payload 380 for one of the negotiated key exchanges. 382 Here is an overview of the initial exchanges: 384 Initiator Responder 385 --------------------------------------------------------------------- 386 <-- IKE_SA_INIT (additional key exchanges negotiation) --> 388 <-- {IKE_INTERMEDIATE (additional key exchange)} --> 390 ... 392 <-- {IKE_INTERMEDIATE (additional key exchange)} --> 394 <-- {IKE_AUTH} --> 396 The additional key exchanges may use algorithms that are currently 397 considered to be resistant to quantum computer attacks. These 398 algorithms are collectively referred to as post-quantum algorithms in 399 this document. However, it is also possible to use classical (EC)DH 400 primitives for non post-quantum requirements. 402 Most post-quantum key agreement algorithms are relatively new, and 403 thus are not fully trusted. There are also many proposed algorithms, 404 with different trade-offs and relying on different hard problems. 405 The concern is that some of these hard problems may turn out to be 406 easier to solve than anticipated and thus the key agreement algorithm 407 may not be as secure as expected. A hybrid solution allows us to 408 deal with this uncertainty by combining a classical key exchange with 409 a post-quantum one, as well as leaving open the possibility of 410 multiple post-quantum key exchanges. 412 The method that we use to perform additional key exchanges also 413 addresses the fragmentation issue. The initial IKE_INIT messages do 414 not have any inherent fragmentation support within IKE; however that 415 can include a relatively short KE payload (e.g. one for group 14, 19 416 or 31). The rest of the KE payloads are encrypted within 417 IKE_INTERMEDIATE messages; because they are encrypted, the standard 418 IKE fragmentation solution [RFC7383] is available. 420 The fact that all Additional Key Exchange Transform Types share the 421 same registry with Transform Type 4 allows additional key exchanges 422 to be of any type - either post-quantum ones or classical (EC)DH 423 ones. This approach allows any combination of defined key exchange 424 methods to take place. This also allows performing a single post- 425 quantum key exchange in the IKE_SA_INIT without additional key 426 exchanges, provided that IP fragmentation is not an issue and that 427 hybrid key exchange is not needed. 429 3.2. Overall Protocol 431 In the simplest case, the initiator is happy with a single key 432 exchange (and has no interest in supporting multiple), and it is not 433 concerned with possible fragmentation of the IKE_SA_INIT messages 434 (either because the key exchange it selects is small enough not to 435 fragment, or the initiator is confident that fragmentation will be 436 handled either by IP fragmentation, or transport via TCP). 438 In this case, the initiator performs the IKE_SA_INIT as standard, 439 inserting a preferred key exchange (which is possibly a post-quantum 440 algorithm) as the listed Transform Type 4, and including the 441 initiator KE payload. If the responder accepts the policy, it 442 responds with an IKE_SA_INIT response, and IKE continues as usual. 444 If the initiator desires to negotiate multiple key exchanges, or it 445 needs IKE to handle any possible fragmentation, then the initiator 446 uses the protocol listed below. 448 3.2.1. IKE_SA_INIT Round: Negotiation 450 Multiple key exchanges are negotiated using the standard IKEv2 451 mechanism, via SA payload. For this purpose several new transform 452 types, namely Additional Key Exchange 1, Additional Key Exchange 2, 453 Additional Key Exchange 3, etc., are defined. They are collectively 454 called Additional Key Exchanges and have slightly different semantics 455 than existing IKEv2 transform types. They are interpreted as 456 additional key exchanges that peers agreed to perform in a series of 457 IKE_INTERMEDIATE exchanges. The possible transform IDs for these 458 transform types are the same as IDs for the Transform Type 4, so they 459 all share a single IANA registry for transform IDs. 461 Key exchange methods negotiated via Transform Type 4 MUST always take 462 place in the IKE_SA_INIT exchange. Additional key exchanges 463 negotiated via newly defined transforms MUST take place in a series 464 of IKE_INTERMEDIATE exchanges, in an order of the values of their 465 transform types, so that key exchange negotiated using Transform Type 466 n always precedes that of Transform Type n + 1. Each 467 IKE_INTERMEDIATE exchange MUST bear exactly one key exchange method. 468 Note that with this semantics, Additional Key Exchanges transforms 469 are not associated with any particular type of key exchange and do 470 not have any specific per transform type transform IDs IANA registry. 471 Instead they all share a single registry for transform IDs - "Key 472 Exchange Method Transform IDs", as well as Transform Type 4. All new 473 key exchange algorithms (both classical or post-quantum) should be 474 added to this registry. This approach gives peers flexibility in 475 defining the ways they want to combine different key exchange 476 methods. 478 When forming a proposal the initiator adds transforms for the 479 IKE_SA_INIT exchange using Transform Type 4. In most cases they will 480 contain classical key exchange methods (DH or ECDH), however it is 481 not a requirement. Additional key exchange methods are proposed 482 using Additional Key Exchanges transform types. All these transform 483 types are optional, the initiator is free to select any of them for 484 proposing additional key exchange methods. Consequently, if none of 485 Additional Key Exchange transforms are included in the proposal, then 486 this proposal indicates performing standard IKEv2, as defined in 487 [RFC7296]. If the initiator includes any transform of type n (where 488 n is among Additional Key Exchanges) in the proposal, the responder 489 MUST select one of the algorithms proposed using this type. A 490 transform ID NONE may be added to those transform types which contain 491 key exchange methods that the initiator believes are optional. 493 If the initiator includes any Additional Key Exchanges transform 494 types into SA payload, it MUST also negotiate using IKE_INTERMEDIATE 495 exchange as described in [I-D.ietf-ipsecme-ikev2-intermediate], by 496 including INTERMEDIATE_EXCHANGE_SUPPORTED notification in the 497 IKE_SA_INIT request message. If the responder agrees to use 498 additional key exchanges, it MUST also return this notification, thus 499 confirming that IKE_INTERMEDIATE exchange is supported and will be 500 used for transferring additional key exchange data. The presence of 501 Additional Key Exchanges transform types in SA payload without 502 negotiation of using IKE_INTERMEDIATE exchange MUST be treated as 503 protocol error by both initiator and responder. 505 The responder performs negotiation using standard IKEv2 procedure 506 described in Section 3.3 of [RFC7296]. However, for the Additional 507 Key Exchange types the responder's choice MUST NOT contain equal 508 transform IDs (apart from NONE), and the ID selected for Transform 509 Type 4 MUST NOT appear in any of Additional Key Exchange transforms. 510 In other words, all selected key exchange methods must be different. 512 3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges 514 For each extra key exchange agreed to in the IKE_SA_INIT exchange, 515 the initiator and the responder perform one IKE_INTERMEDIATE 516 exchange, as described in [I-D.ietf-ipsecme-ikev2-intermediate]. 518 These exchanges are as follows: 520 Initiator Responder 521 --------------------------------------------------------------------- 522 HDR, SK {KEi(n)} --> 523 <-- HDR, SK {KEr(n)} 525 The initiator sends key exchange data in the KEi(n) payload. This 526 packet is protected with the current SK_ei/SK_ai keys. 528 On receiving this, the responder sends back key exchange payload 529 KEr(n); again, this packet is protected with the current SK_er/SK_ar 530 keys. 532 The former "Diffie-Hellman Group Num" (now called "Key Exchange 533 Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th 534 negotiated additional key exchange. Note that the negotiated 535 transform types (the encryption type, integrity type, prf type) are 536 not modified. 538 Once this exchange is done, then both sides compute an updated keying 539 material: 541 SKEYSEED(n) = prf(SK_d(n-1), KE(n) | Ni | Nr) 543 where KE(n) is the resulting shared secret of this key exchange, Ni 544 and Nr are nonces from the IKE_SA_INIT exchange and SK_d(n-1) is the 545 last generated SK_d, (derived from the previous IKE_INTERMEDIATE 546 exchange, or the IKE_SA_INIT if there have not already been any 547 IKE_INTERMEDIATE exchanges). Then, SK_d, SK_ai, SK_ar, SK_ei, SK_er, 548 SK_pi, SK_pr are updated as: 550 {SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) | 551 SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr) 553 Both the initiator and the responder use these updated key values in 554 the next exchange. 556 3.2.3. IKE_AUTH Exchange 558 After all IKE_INTERMEDIATE exchanges have completed, the initiator 559 and the responder perform an IKE_AUTH exchange. This exchange is the 560 standard IKE exchange, except that the initiator and responder signed 561 octets are modified as described in 562 [I-D.ietf-ipsecme-ikev2-intermediate]. 564 3.2.4. CREATE_CHILD_SA Exchange 566 The CREATE_CHILD_SA exchange is used in IKEv2 for the purpose of 567 creating additional Child SAs, rekeying them and rekeying IKE SA 568 itself. When creating or rekeying Child SAs, the peers may 569 optionally perform a Diffie-Hellman key exchange to add a fresh 570 entropy into the session keys. In case of IKE SA rekey, the key 571 exchange is mandatory. 573 If the IKE SA was created using multiple key exchange methods, the 574 peers may want to continue using multiple key exchanges in the 575 CREATE_CHILD_SA exchange too. If the initiator includes any 576 Additional Key Exchanges transform in the SA payload (along with 577 Transform Type 4) and the responder agrees to perform additional key 578 exchanges, then the additional key exchanges are performed in a 579 series of new IKE_FOLLOWUP_KE exchanges that follows the 580 CREATE_CHILD_SA exchange. The IKE_FOLLOWUP_KE exchange is introduced 581 as a dedicated exchange type to transfer data of additional key 582 exchanges following the key exchange performed in the 583 CREATE_CHILD_SA. Its Exchange Type is . 585 These key exchanges are performed in an order of the values of their 586 transform types, so that key exchange negotiated using Transform Type 587 n always precedes key exchange negotiated using Transform Type n + 1. 588 Each IKE_FOLLOWUP_KE exchange MUST bear exactly one key exchange 589 method. Key exchange negotiated via Transform Type 4 always takes 590 place in the CREATE_CHILD_SA exchange, as per IKEv2 specification. 592 Since after IKE SA is created the window size may be greater than one 593 and multiple concurrent exchanges may be in progress, it is essential 594 to link the IKE_FOLLOWUP_KE exchanges together and with the 595 corresponding CREATE_CHILD_SA exchange. A new status type 596 notification ADDITIONAL_KEY_EXCHANGE is used for this purpose. Its 597 Notify Message Type is , Protocol ID and SPI Size are 598 both set to 0. The data associated with this notification is a blob 599 meaningful only to the responder, so that the responder can correctly 600 link successive exchanges. For the initiator the content of this 601 notification is an opaque blob. 603 The responder MUST include this notification in a CREATE_CHILD_SA or 604 IKE_FOLLOWUP_KE response message in case the next exchange is 605 expected, filling it with some data that would allow linking this 606 exchange to the next one. The initiator MUST copy the received 607 notification with its content intact into the request message of the 608 next exchange. 610 Below is an example of three additional key exchanges. 612 Initiator Responder 613 --------------------------------------------------------------------- 614 HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> 615 <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, 616 N(ADDITIONAL_KEY_EXCHANGE)(link1)} 618 HDR(IKE_FOLLOWUP_KE), SK {KEi(1), 619 N(ADDITIONAL_KEY_EXCHANGE)(link1)} --> 620 <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1), 621 N(ADDITIONAL_KEY_EXCHANGE)(link2)} 623 HDR(IKE_FOLLOWUP_KE), SK {KEi(2), 624 N(ADDITIONAL_KEY_EXCHANGE)(link2)} --> 625 <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2), 626 N(ADDITIONAL_KEY_EXCHANGE)(link3)} 628 HDR(IKE_FOLLOWUP_KE), SK {KEi(3), 629 N(ADDITIONAL_KEY_EXCHANGE)(link3)} --> 630 <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(3)} 632 The former "Diffie-Hellman Group Num" (now called "Key Exchange 633 Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th 634 negotiated additional key exchange. 636 It is possible that due to some unexpected events (e.g. reboot) the 637 initiator could forget that it is in the process of performing 638 additional key exchanges and never starts next IKE_FOLLOWUP_KE 639 exchanges. The responder MUST handle this situation gracefully and 640 delete the associated state if it does not receive the next expected 641 IKE_FOLLOWUP_KE request after some reasonable period of time. 643 If responder receives IKE_FOLLOWUP_KE request containing 644 ADDITIONAL_KEY_EXCHANGE notification and the content of this notify 645 does not correspond to any active key exchange state the responder 646 has, it MUST send back a new error type notification STATE_NOT_FOUND. 647 This is a non-fatal error notification, its Notify Message Type is 648 , Protocol ID and SPI Size are both set to 0 and the 649 data is empty. If the initiator receives this notification in 650 response to IKE_FOLLOWUP_KE exchange performing additional key 651 exchange, it MUST cancel this exchange and MUST treat the whole 652 series of exchanges started from the CREATE_CHILD_SA exchange as 653 failed. In most cases, the receipt of this notification is caused by 654 premature deletion of the corresponding state on the responder (the 655 time period between IKE_FOLLOWUP_KE exchanges appeared too long from 656 responder's point of view, e.g. due to a temporary network failure). 657 After receiving this notification the initiator MAY start a new 658 CREATE_CHILD_SA exchange (eventually followed by the IKE_FOLLOWUP_KE 659 exchanges) to retry the failed attempt. If the initiator continues 660 to receive STATE_NOT_FOUND notifications after several retries, it 661 MUST treat this situation as a fatal error and delete IKE SA by 662 sending a DELETE payload. 664 When rekeying IKE SA or Child SA, it is possible that the peers start 665 doing this at the same time, which is called simultaneous rekeying. 666 Sections 2.8.1 and 2.8.2 of [RFC7296] describes how IKEv2 handles 667 this situation. In a nutshell IKEv2 follows the rule that if in case 668 of simultaneous rekeying two identical new IKE SAs (or two pairs of 669 Child SAs) are created, then one of them should be deleted. Which 670 one is to be deleted is determined by comparing the values of four 671 nonces, that were used in the colliding CREATE_CHILD_SA exchanges - 672 the IKE SA (or pair of Child SAs) that was created by the exchange in 673 which the smallest nonce was used should be deleted by the initiator 674 of this exchange. 676 With multiple key exchanges the SAs are not yet created when the 677 CRETE_CHILD_SA is completed, they would be created only after the 678 series of IKE_FOLLOWUP_KE exchanges is finished. For this reason if 679 additional key exchanges were negotiated in the CREATE_CHILD_SA 680 initiated by the losing side, there is nothing to delete and this 681 side just stops the rekeying process - this side MUST not initiate 682 IKE_FOLLOWUP_KE exchange with next key exchange. 684 In most cases, rekey collisions are resolved in the CREATE_CHILD_SA 685 exchange. However, a situation may occur when due to packet loss, 686 one of the peers receives CREATE_CHILD_SA message requesting rekeying 687 SA that is already being rekeyed by this peer (i.e. the 688 CREATE_CHILD_SA exchange initiated by this peer has been already 689 completed and the series of IKE_FOLLOWUP_KE exchanges is in 690 progress). In this case, a TEMPORARY_FAILURE notification MUST be 691 sent in response to such a request. 693 If multiple key exchanges were negotiated in the CREATE_CHILD_SA 694 exchange, then the resulting keys are computed as follows. In case 695 of IKE SA rekey: 697 SKEYSEED = prf(SK_d, KE | Ni | Nr | KE(1) | ... KE(n)) 699 In case of Child SA creation or rekey: 701 KEYMAT = prf+ (SK_d, KE | Ni | Nr | KE(1) | ... KE(n)) 703 In both cases SK_d is from existing IKE SA; KE, Ni, Nr are the shared 704 key and nonces from the CREATE_CHILD_SA respectively; KE(1)...KE(n) 705 are the shared keys from additional key exchanges. 707 4. IANA Considerations 709 This document adds new exchange type into the "IKEv2 Exchange Types" 710 registry: 712 IKE_FOLLOWUP_KE 714 This document renames Transform Type 4 defined in "Transform Type 715 Values" registry from "Diffie-Hellman Group (D-H)" to "Key Exchange 716 Method (KE)". 718 This document renames IKEv2 registry "Transform Type 4 - Diffie- 719 Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange 720 Method Transform IDs". 722 This document adds the following Transform Types to the "Transform 723 Type Values" registry: 725 Type Description Used In 726 ----------------------------------------------------------------- 727 Additional Key Exchange 1 (optional in IKE, AH, ESP) 728 Additional Key Exchange 2 (optional in IKE, AH, ESP) 729 Additional Key Exchange 3 (optional in IKE, AH, ESP) 730 Additional Key Exchange 4 (optional in IKE, AH, ESP) 731 Additional Key Exchange 5 (optional in IKE, AH, ESP) 732 Additional Key Exchange 6 (optional in IKE, AH, ESP) 733 Additional Key Exchange 7 (optional in IKE, AH, ESP) 735 This document defines a new Notify Message Type in the "Notify 736 Message Types - Status Types" registry: 738 ADDITIONAL_KEY_EXCHANGE 740 and a new Notify Message Type in the "Notify Message Types - Error 741 Types" registry: 743 STATE_NOT_FOUND 745 5. Security Considerations 747 The key length of the Encryption Algorithm (Transform Type 1), the 748 Pseudorandom Function (Transform Type 2) and the Integrity Algorithm 749 (Transform Type 3), all have to be of sufficient length to prevent 750 attacks using Grover's algorithm [GROVER]. In order to use the 751 extension proposed in this document, the key lengths of these 752 transforms SHALL be at least 256 bits long in order to provide 753 sufficient resistance to quantum attacks. Accordingly the post- 754 quantum security level achieved is at least 128 bits. 756 SKEYSEED is calculated from shared KE(x) using an algorithm defined 757 in Transform Type 2. While a quantum attacker may learn the value of 758 KE(x), if this value is obtained by means of a classical key 759 exchange, other KE(x) values generated by means of a quantum- 760 resistant algorithm ensure that the final SKEYSEED is not 761 compromised. This assumes that the algorithm defined in the 762 Transform Type 2 is post-quantum. 764 The main focus of this document is to prevent a passive attacker 765 performing a "harvest and decrypt" attack. In other words, an 766 attacker that records messages exchanges today and proceeds to 767 decrypt them once he owns a quantum computer. This attack is 768 prevented due to the hybrid nature of the key exchange. Other 769 attacks involving an active attacker using a quantum-computer are not 770 completely solved by this document. This is for two reasons. 772 The first reason is because the authentication step remains 773 classical. In particular, the authenticity of the SAs established 774 under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA 775 algorithms. Whilst the pre-shared key option, provided the key is 776 long enough, is post-quantum, the other algorithms are not. 777 Moreover, in implementations where scalability is a requirement, the 778 pre-shared key method may not be suitable. Quantum-safe authenticity 779 may be provided by using a quantum-safe digital signature and several 780 quantum-safe digital signature methods are being explored by IETF. 781 For example, if the implementation is able to reliably track state, 782 the hash based method, XMSS has the status of an RFC, see [RFC8391]. 783 Currently, quantum-safe authentication methods are not specified in 784 this document, but are planned to be incorporated in due course. 786 It should be noted that the purpose of post-quantum algorithms is to 787 provide resistance to attacks mounted in the future. The current 788 threat is that encrypted sessions are subject to eavesdropping and 789 archived with decryption by quantum computers taking place at some 790 point in the future. Until quantum computers become available there 791 is no point in attacking the authenticity of a connection because 792 there are no possibilities for exploitation. These only occur at the 793 time of the connection, for example by mounting a man-in-the-middle 794 (MitM) attack. Consequently there is not such a pressing need for 795 quantum-safe authenticity. 797 6. Acknowledgements 799 The authors would like to thanks Frederic Detienne and Olivier 800 Pelerin for their comments and suggestions, including the idea to 801 negotiate the post-quantum algorithms using the existing KE payload. 802 The authors are also grateful to Tobias Heider and Tobias Guggemos 803 for valuable comments. 805 7. References 807 7.1. Normative References 809 [I-D.ietf-ipsecme-ikev2-intermediate] 810 Smyslov, V., "Intermediate Exchange in the IKEv2 811 Protocol", draft-ietf-ipsecme-ikev2-intermediate-05 (work 812 in progress), September 2020. 814 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 815 Requirement Levels", BCP 14, RFC 2119, 816 DOI 10.17487/RFC2119, March 1997, 817 . 819 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 820 Kivinen, "Internet Key Exchange Protocol Version 2 821 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 822 2014, . 824 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 825 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 826 May 2017, . 828 7.2. Informative References 830 [GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for 831 Database Search", Proc. of the Twenty-Eighth Annual ACM 832 Symposium on the Theory of Computing (STOC 1996), 1996. 834 [I-D.tjhai-ikev2-beyond-64k-limit] 835 Tjhai, C., Heider, T., and V. Smyslov, "Beyond 64KB Limit 836 of IKEv2 Payload", draft-tjhai-ikev2-beyond-64k-limit-00 837 (work in progress), October 2020. 839 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 840 DOI 10.17487/RFC4302, December 2005, 841 . 843 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 844 RFC 4303, DOI 10.17487/RFC4303, December 2005, 845 . 847 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 848 (IKEv2) Message Fragmentation", RFC 7383, 849 DOI 10.17487/RFC7383, November 2014, 850 . 852 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 853 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 854 August 2017, . 856 [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. 857 Mohaisen, "XMSS: eXtended Merkle Signature Scheme", 858 RFC 8391, DOI 10.17487/RFC8391, May 2018, 859 . 861 [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, 862 "Mixing Preshared Keys in the Internet Key Exchange 863 Protocol Version 2 (IKEv2) for Post-quantum Security", 864 RFC 8784, DOI 10.17487/RFC8784, June 2020, 865 . 867 Appendix A. Alternative Design 869 This section gives an overview on a number of alternative approaches 870 that we have considered, but later discarded. These approaches are: 872 o Sending the classical and post-quantum key exchanges as a single 873 transform 875 We considered combining the various key exchanges into a single 876 large KE payload; this effort is documented in a previous version 877 of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This 878 does allow us to cleanly apply hybrid key exchanges during the 879 child SA; however it does add considerable complexity, and 880 requires an independent fragmentation solution. 882 o Sending post-quantum proposals and policies in KE payload only 884 With the objective of not introducing unnecessary notify payloads, 885 we considered communicating the hybrid post-quantum proposal in 886 the KE payload during the first pass of the protocol exchange. 887 Unfortunately, this design is susceptible to the following 888 downgrade attack. Consider the scenario where there is an MitM 889 attacker sitting between an initiator and a responder. The 890 initiator proposes, through SAi payload, to use a hybrid post- 891 quantum group and as a backup a Diffie-Hellman group, and through 892 KEi payload, the initiator proposes a list of hybrid post-quantum 893 proposals and policies. The MitM attacker intercepts this traffic 894 and replies with N(INVALID_KE_PAYLOAD) suggesting to downgrade to 895 the backup Diffie-Hellman group instead. The initiator then 896 resends the same SAi payload and the KEi payload containing the 897 public value of the backup Diffie-Hellman group. Note that the 898 attacker may forward the second IKE_SA_INIT message only to the 899 responder, and therefore at this point in time, the responder will 900 not have the information that the initiator prefers the hybrid 901 group. Of course, it is possible for the responder to have a 902 policy to reject an IKE_SA_INIT message that (a) offers a hybrid 903 group but not offering the corresponding public value in the KEi 904 payload; and (b) the responder has not specifically acknowledged 905 that it does not supported the requested hybrid group. However, 906 the checking of this policy introduces unnecessary protocol 907 complexity. Therefore, in order to fully prevent any downgrade 908 attacks, using KE payload alone is not sufficient and that the 909 initiator MUST always indicate its preferred post-quantum 910 proposals and policies in a notify payload in the subsequent 911 IKE_SA_INIT messages following a N(INVALID_KE_PAYLOAD) response. 913 o New payload types to negotiate hybrid proposal and to carry post- 914 quantum public values 916 Semantically, it makes sense to use a new payload type, which 917 mimics the SA payload, to carry a hybrid proposal. Likewise, 918 another new payload type that mimics the KE payload, could be used 919 to transport hybrid public value. Although, in theory a new 920 payload type could be made backwards compatible by not setting its 921 critical flag as per Section 2.5 of RFC7296, we believe that it 922 may not be that simple in practice. Since the original release of 923 IKEv2 in RFC4306, no new payload type has ever been proposed and 924 therefore, this creates a potential risk of having a backward 925 compatibility issue from non-conforming RFC IKEv2 implementations. 926 Since we could not see any other compelling advantages apart from 927 a semantic one, we use the existing transform type and notify 928 payloads instead. In fact, as described above, we use the KE 929 payload in the first IKE_SA_INIT request round and the notify 930 payload to carry the post-quantum proposals and policies. We use 931 one or more of the existing KE payloads to carry the hybrid public 932 values. 934 o Hybrid public value payload 936 One way to transport the negotiated hybrid public payload, which 937 contains one classical Diffie-Hellman public value and one or more 938 post-quantum public values, is to bundle these into a single KE 939 payload. Alternatively, these could also be transported in a 940 single new hybrid public value payload, but following the same 941 reasoning as above, this may not be a good idea from a backward 942 compatibility perspective. Using a single KE payload would 943 require an encoding or formatting to be defined so that both peers 944 are able to compose and extract the individual public values. 945 However, we believe that it is cleaner to send the hybrid public 946 values in multiple KE payloads--one for each group or algorithm. 948 Furthermore, at this point in the protocol exchange, both peers 949 should have indicated support of handling multiple KE payloads. 951 o Fragmentation 953 Handling of large IKE_SA_INIT messages has been one of the most 954 challenging tasks. A number of approaches have been considered 955 and the two prominent ones that we have discarded are outlined as 956 follows. 958 The first approach was to treat the entire IKE_SA_INIT message as 959 a stream of bytes, which we then split it into a number of 960 fragments, each of which is wrapped onto a payload that would fit 961 into the size of the network MTU. The payload that wraps each 962 fragment is a new payload type and it was envisaged that this new 963 payload type will not cause a backward compatibility issue because 964 at this stage of the protocol, both peers should have indicated 965 support of fragmentation in the first pass of the IKE_SA_INIT 966 exchange. The negotiation of fragmentation is performed using a 967 notify payload, which also defines supporting parameters such as 968 the size of fragment in octets and the fragment identifier. The 969 new payload that wraps each fragment of the messages in this 970 exchange is assigned the same fragment identifier. Furthermore, 971 it also has other parameters such as a fragment index and total 972 number of fragments. We decided to discard this approach due to 973 its blanket approach to fragmentation. In cases where only a few 974 payloads need to be fragmented, we felt that this approach is 975 overly complicated. 977 Another idea that was discarded was fragmenting an individual 978 payload without introducing a new payload type. The idea was to 979 use the 9-th bit (the bit after the critical flag in the RESERVED 980 field) in the generic payload header as a flag to mark that this 981 payload is fragmented. As an example, if a KE payload is to be 982 fragmented, it may look as follows. 984 1 2 3 985 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 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Next Payload |C|F| RESERVED | Payload Length | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Diffie-Hellman Group Number | Fragment Identifier | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Fragment Index | Total Fragments | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Total KE Payload Data Length | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | | 996 ~ Fragmented KE Payload ~ 997 | | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 When the flag F is set, this means the current KE payload is a 1001 fragment of a larger KE payload. The Payload Length field denotes 1002 the size of this payload fragment in octets--including the size of 1003 the generic payload header. The two-octet RESERVED field 1004 following Diffie-Hellman Group Number was to be used as a fragment 1005 identifier to help assembly and disassembly of fragments. The 1006 Fragment Index and Total Fragments fields are self-explanatory. 1007 The Total KE Payload Data Length indicates the size of the 1008 assembled KE payload data in octets. Finally, the actual fragment 1009 is carried in Fragment KE Payload field. 1011 We discarded this approach because we believe that the working 1012 group may not be happy using the RESERVED field to change the 1013 format of a packet and that implementers may not like the 1014 complexity added from checking the fragmentation flag in each 1015 received payload. More importantly, fragmenting the messages in 1016 this way may leave the system to be more prone to denial of 1017 service (DoS) attacks. By using IKE_INTERMEDIATE to transport the 1018 large post-quantum key exchange payloads, there is no longer any 1019 issue with fragmentation. 1021 o Group sub-identifier 1023 As discussed before, each group identifier is used to distinguish 1024 a post-quantum algorithm. Further classification could be made on 1025 a particular post-quantum algorithm by assigning additional value 1026 alongside the group identifier. This sub- identifier value may be 1027 used to assign different security parameter sets to a given post- 1028 quantum algorithm. However, this level of details does not fit 1029 the principles of the document where it should deal with generic 1030 hybrid key exchange protocol, not a specific ciphersuite. 1032 Furthermore, there are enough Diffie- Hellman group identifiers 1033 should this be required in the future. 1035 Authors' Addresses 1037 C. Tjhai 1038 Post-Quantum 1040 Email: cjt@post-quantum.com 1042 M. Tomlinson 1043 Post-Quantum 1045 Email: mt@post-quantum.com 1047 G. Bartlett 1048 Quantum Secret 1050 Email: graham.ietf@gmail.com 1052 S. Fluhrer 1053 Cisco Systems 1055 Email: sfluhrer@cisco.com 1057 D. Van Geest 1058 ISARA Corporation 1060 Email: daniel.vangeest@isara.com 1062 O. Garcia-Morchon 1063 Philips 1065 Email: oscar.garcia-morchon@philips.com 1067 Valery Smyslov 1068 ELVIS-PLUS 1070 Email: svan@elvis.ru