idnits 2.17.1 draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 14, 2019) is 1929 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 698, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-ipsecme-qr-ikev2-05 -- Obsolete informational reference (is this intentional?): RFC 8229 (Obsoleted by RFC 9329) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Tjhai 3 Internet-Draft M. Tomlinson 4 Intended status: Informational Post-Quantum 5 Expires: July 18, 2019 G. Bartlett 6 S. Fluhrer 7 Cisco Systems 8 D. Van Geest 9 ISARA Corporation 10 O. Garcia-Morchon 11 Philips 12 V. Smyslov 13 ELVIS-PLUS 14 January 14, 2019 16 Framework to Integrate Post-quantum Key Exchanges into Internet Key 17 Exchange Protocol Version 2 (IKEv2) 18 draft-tjhai-ipsecme-hybrid-qske-ikev2-03 20 Abstract 22 This document describes how to extend Internet Key Exchange Protocol 23 Version 2 (IKEv2) so that the shared secret exchanged between peers 24 has resistance against quantum computer attacks. The basic idea is 25 to exchange one or more post-quantum key exchange payloads in 26 conjunction with the existing (Elliptic Curve) Diffie-Hellman 27 payload. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 18, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 2 65 1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . 3 66 1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.4. Document Organization . . . . . . . . . . . . . . . . . . 4 68 2. Design Criteria . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. The Framework of Hybrid Post-Quantum Key Exchange . . . . . . 6 70 3.1. Overall design . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . 8 72 3.2.1. IKE_SA_INIT Round: Negotiation . . . . . . . . . . . 8 73 3.2.2. INTERMEDIATE Round: Additional Key Exchanges . . . . 9 74 3.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 10 75 3.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 10 76 4. Alternative Design . . . . . . . . . . . . . . . . . . . . . 11 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 81 7.2. Informative References . . . . . . . . . . . . . . . . . 17 82 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 1.1. Problem Description 89 Internet Key Exchange Protocol (IKEv2) as specified in RFC 7296 90 [RFC7296] uses the Diffie-Hellman (DH) or Elliptic Curve Diffie- 91 Hellman (ECDH) algorithm to establish a shared secret between an 92 initiator and a responder. The security of the DH and ECDH 93 algorithms relies on the difficulty to solve a discrete logarithm 94 problem in multiplicative and elliptic curve groups respectively when 95 the order of the group parameter is large enough. While solving such 96 a problem remains difficult with current computing power, it is 97 believed that general purpose quantum computers will be able to solve 98 this problem, implying that the security of IKEv2 is compromised. 99 There are, however, a number of cryptosystems that are conjectured to 100 be resistant against quantum computer attack. This family of 101 cryptosystems are known as post-quantum cryptography (PQC). It is 102 sometimes also referred to as quantum-safe cryptography (QSC) or 103 quantum-resistant cryptography (QRC). 105 1.2. Proposed Extension 107 This document describes a framework to integrate QSC for IKEv2, while 108 maintaining backwards compatibility, to derive a set of IKE keys that 109 have resistance to quantum computer attacks. Our framework allows 110 the negotiation of one or more QSC algorithm to exchange data, in 111 addition to the existing DH or ECDH key exchange data. We believe 112 that the feature of using more than one post-quantum algorithm is 113 important as many of these algorithms are relatively new and there 114 may be a need to hedge the security risk with multiple key exchange 115 data from several distinct QSC algorithms. 117 The secrets established from each key exchange are combined in a way 118 such that should the post-quantum secrets not be present, the derived 119 shared secret is equivalent to that of the standard IKEv2; on the 120 other hand, a post-quantum shared secret is obtained if both 121 classical and post-quantum key exchange data are present. This 122 framework also applies to key exchanges in IKE Security Associations 123 (SAs) for Encapsulating Security Payload (ESP) [RFC4303] or 124 Authentication Header (AH) [RFC4302], i.e. Child SAs, in order to 125 provide a stronger guarantee of forward security. 127 Some post-quantum key exchange payloads may have size larger than the 128 standard MTU size, and therefore there could be issues with 129 fragmentation at IP layer. IKE does allow transmission over TCP 130 where fragmentation is not an issue [RFC8229]; however, we believe 131 that a UDP-based solution will be required too. IKE does have a 132 mechanism to handle fragmentation within UDP [RFC7383], however that 133 is only applicable to messages exchanged after the IKE_SA_INIT. To 134 use this mechanism, we use the INTERMEDIATE exchange as outlined in 135 [I-D.smyslov-ipsecme-ikev2-aux]. With this mechanism, we do an 136 initial key exchange, using a smaller, possibly non-quantum resistant 137 primitive, such as ECDH. Then, before we do the IKE_AUTH exchange, 138 we perform one or more INTERMEDIATE exchanges, each of which includes 139 a secondary key exchange. As the INTERMEDIATE exchange is encrypted, 140 the IKE fragmentation protocol RFC7383 can be used. The IKE SK 141 values will be updated after each exchange, and so the final IKE SK 142 values will depend on all the key exchanges, hence they are secure if 143 any of the key exchanges are secure. 145 Note that readers should consider the approach in this document as 146 providing a long term solution in upgrading the IKEv2 protocol to 147 support post-quantum algorithms. A short term solution to make IKEv2 148 key exchange quantum secure is to use post-quantum pre-shared keys as 149 discussed in [I-D.ietf-ipsecme-qr-ikev2]. 151 1.3. Changes 153 Changes in this draft in each version iterations. 155 draft-tjhai-ipsecme-hybrid-qske-ikev2-02 157 o Use new transform types to negotiate additional key exchanges, 158 rather than using the KE payloads of IKE SA. 160 draft-tjhai-ipsecme-hybrid-qske-ikev2-01 162 o Use INTERMEDIATE to perform multiple key exchanges in succession. 164 o Handle fragmentation by keeping the first key exchange (a standard 165 IKE_SA_INIT with a few extra notifies) small, and encrypting the 166 rest of the key exchanges. 168 o Simplify the negotiation of the 'extra' key exchanges. 170 draft-tjhai-ipsecme-hybrid-qske-ikev2-00 172 o We added a feature to allow more than one post-quantum key 173 exchange algorithms to be negotiated and used to exchange a post- 174 quantum shared secret. 176 o Instead of relying on TCP encapsulation to deal with IP level 177 fragmentation, we introduced a new key exchange payload that can 178 be sent as multiple fragments within IKE_SA_INIT message. 180 1.4. Document Organization 182 The remainder of this document is organized as follows. Section 2 183 summarizes design criteria. Section 3 describes how post-quantum key 184 exchange is performed between two IKE peers and how keying materials 185 are derived for both SAs and child SAs. A summary of alternative 186 approaches that have been considered, but later discarded, are 187 described in Section 4. Section 5 discusses IANA considerations for 188 the namespaces introduced in this document, and lastly Section 6 189 discusses security considerations. 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 193 "OPTIONAL" in this document are to be interpreted as described in BCP 194 14 [RFC2119] [RFC8174] when, and only when, they appear in all 195 capitals, as shown here. 197 2. Design Criteria 199 The design of the proposed post-quantum IKEv2 is driven by the 200 following criteria: 202 1) Need for post-quantum cryptography in IPsec. Quantum computers 203 might become feasible in the next 5-10 years. If current 204 Internet communications are monitored and recorded today (D), 205 the communications could be decrypted as soon as a quantum- 206 computer is available (e.g., year Q) if key negotiation only 207 relies on non post-quantum primitives. This is a high threat 208 for any information that must remain confidential for a long 209 period of time T > Q-D. The need is obvious if we assume that Q 210 is 2040, D is 2020, and T is 30 years. Such a value of T is 211 typical in classified or healthcare data. 213 2) Hybrid. Currently, there does not exist a post-quantum key 214 exchange that is trusted at the level that ECDH is trusted 215 against conventional (non-quantum) adversaries. A hybrid 216 approach allows introducing promising post-quantum candidates 217 next to well-established primitives, since the overall security 218 is at least as strong as each individual primitive. 220 3) Focus on quantum-resistant confidentiality. A passive attacker 221 can eavesdrop on IPsec communication today and decrypt it once a 222 quantum computer is available in the future. This is a very 223 serious attack for which we do not have a solution. An attacker 224 can only perform active attacks such as impersonation of the 225 communicating peers once a quantum computer is available, 226 sometime in the future. Thus, our design focuses on quantum- 227 resistant confidentiality due to the urgency of this problem. 228 This document does not address quantum-resistant authentication 229 since it is less urgent at this stage. 231 4) Limit amount of exchanged data. The protocol design should be 232 such that the amount of exchanged data, such as public-keys, is 233 kept as small as possible even if initiator and responder need 234 to agree on a hybrid group or multiple public-keys need to be 235 exchanged. 237 5) Future proof. Any cryptographic algorithm could be potentially 238 broken in the future by currently unknown or impractical 239 attacks: quantum computers are merely the most concrete example 240 of this. The design does not categorize algorithms as "post- 241 quantum" or "non post-quantum" and does not create assumptions 242 about the properties of the algorithms, meaning that if 243 algorithms with different properties become necessary in the 244 future, this framework can be used unchanged to facilitate 245 migration to those algorithms. 247 6) Limited amount of changes. A key goal is to limit the number of 248 changes required when enabling a post-quantum handshake. This 249 ensures easier and quicker adoption in existing implementations. 251 7) Localized changes. Another key requirement is that changes to 252 the protocol are limited in scope, in particular, limiting 253 changes in the exchanged messages and in the state machine, so 254 that they can be easily implemented. 256 8) Deterministic operation. This requirement means that the hybrid 257 post-quantum exchange, and thus, the computed key, will be based 258 on algorithms that both client and server wish to support. 260 9) Fragmentation support. Some PQC algorithms could be relatively 261 bulky and they might require fragmentation. Thus, a design goal 262 is the adaptation and adoption of an existing fragmentation 263 method or the design of a new method that allows for the 264 fragmentation of the key shares. 266 10) Backwards compatibility and interoperability. This is a 267 fundamental requirement to ensure that hybrid post-quantum IKEv2 268 and a non-post-quantum IKEv2 implementations are interoperable. 270 11) FIPS compliance. IPsec is widely used in Federal Information 271 Systems and FIPS certification is an important requirement. 272 However, algorithms that are believed to be post-quantum are not 273 FIPS compliant yet. Still, the goal is that the overall hybrid 274 post-quantum IKEv2 design can be FIPS compliant. 276 3. The Framework of Hybrid Post-Quantum Key Exchange 278 3.1. Overall design 280 This design assigns new group identifiers (Transform Type 4) to the 281 various post-quantum key exchanges (which will be defined later). We 282 specifically do not make a distinction between classical (DH and 283 ECDH) and post-quantum key exchanges, nor post-quantum algorithms 284 which are true key exchanges versus post-quantum algorithms that act 285 as key transport mechanisms; all are treated equivalently by the 286 protocol. In order to support both hybrid key exchanges (that is, 287 relying on distinct key exchanges) and fragmentation, the proposed 288 hybrid post-quantum IKEv2 protocol extends IKE [RFC7296] by adding 289 additional key exchange messages (INTERMEDIATE) between the 290 IKE_SA_INIT and the IKE_AUTH exchanges. In order to minimize 291 communication overhead, only the key shares that are agreed to be 292 used are actually exchanged. In order to achieve this, the 293 IKE_SA_INIT exchange now includes notify payloads that negotiate the 294 extra key exchanges to be used. The initiator IKE_SA_INIT message 295 includes a notify that lists the extra key exchange policy required 296 by the initiator; the responder selects one of the listed policies, 297 and includes that as a notify in the response IKE_SA_INIT message. 298 Then, the initiator and the responder perform one (or possibly more) 299 INTERMEDIATE exchange; each such exchange includes a KE payload for 300 the key exchange that was negotiated. 302 Here is an overview of the initial exchanges: 304 Initiator Responder 305 -------------------------------------------------------- 306 <-- IKE_SA_INIT (and extra key exchange negotiation) --> 308 <-- {INTERMEDIATE (hybrid post-quantum key exchange)} --> 309 ... 310 <-- {INTERMEDIATE (hybrid post-quantum key exchange)} --> 312 <-- {IKE_AUTH} --> 314 The extra post-quantum key exchanges can use algorithms that are 315 currently considered to be resistant to quantum computer attacks. 316 These algorithms are collectively referred to as post-quantum 317 algorithms in this document. 319 Most post-quantum key agreement algorithms are relatively new, and 320 thus are not fully trusted. There are also many proposed algorithms, 321 with different trade-offs and relying on different hard problems. 322 The concern is that some of these hard problems may turn out to be 323 easier to solve than anticipated (and thus the key agreement 324 algorithm not be as secure as expected). A hybrid solution allows us 325 to deal with this uncertainty by combining a classical key exchanges 326 with a post-quantum one, as well as leaving open the possibility of 327 multiple post-quantum key exchanges. 329 The method that we use to perform hybrid key exchange also addresses 330 the fragmentation issue. The initial IKE_INIT messages do not have 331 any inherent fragmentation support within IKE; however that can 332 include a relatively short KE payload (e.g. one for group 14, 19 or 333 31). The rest of the KE payloads are encrypted within INTERMEDIATE 334 messages; because they are encrypted, the standard IKE fragmentation 335 solution [RFC7383] is available. 337 3.2. Overall Protocol 339 In the simplest case, the initiator is happy with a single key 340 exchange (and has no interest in supporting multiple), and he is not 341 concerned with possible fragmentation of the IKE_SA_INIT messages 342 (either because the key exchange he selects is small enough not to 343 fragment, or he is confident that fragmentation will be handled 344 either by IP fragmentation, or transport via TCP). In the following 345 we overview the two protocol rounds involved in the hybrid post- 346 quantum protocol. 348 In this case, the initiator performs the IKE_SA_INIT as standard, 349 inserting this preferred key exchange (which is possibly a post- 350 quantum algorithm) as the listed Transform Type 4, and including the 351 initiator KE payload. If the responder accepts the policy, he 352 responds with an IKE_SA_INIT response, and IKE continues as usual. 354 If the initiator desires to negotiate multiple key exchanges, or he 355 needs IKE to handle any possible fragmentation, then he uses the 356 protocol listed below. 358 3.2.1. IKE_SA_INIT Round: Negotiation 360 Multiple key exchanges are negotiated using the standard IKEv2 361 mechanism, via SA payload. For this purpose several new transform 362 types, namely Additional Key Exchange 1, Additional Key Exchange 2, 363 Additional Key Exchange 3, etc., are defined. They are collectively 364 called Additional Key Exchanges and have slightly different semantics 365 than existing IKEv2 transform types. They are interpreted as 366 additional key exchanges that peers agreed to perform in a series of 367 INTERMEDIATE exchanges. The possible transform IDs for these 368 transform types are the same as IDs for the transform type 4 (Diffie- 369 Hellman Group), so they all share a single IANA registry for 370 transform IDs. 372 Key exchange method negotiated via transform type 4 MUST always take 373 place in the IKE_SA_INIT exchange. Additional Key Exchanges 374 negotiated via newly defined transforms MUST take place in series of 375 INTERMEDIATE exchanges, in an order of the values of their transform 376 types, so that key exchange negotiated using transform type N always 377 precedes that of transform type N + 1. Each INTERMEDIATE exchange 378 MUST bear exactly one key exchange method. Note that with this 379 semantics, Additional Key Exchanges transforms are not associated 380 with any particular type of key exchange and don't have any specific 381 per transform type transform ID IANA registry. Instead they all 382 share a single registry for transform IDs - "Diffie-Hellman Group 383 Transform IDs", as well as Transform Type 4. All new key exchange 384 algorithms (both classical or quantum safe) should be added to this 385 registry. This approach gives peers flexibility in defining the ways 386 they want to combine different key exchange methods. 388 When forming a proposal the initiator adds transforms for the 389 IKE_SA_INIT exchange using transform type 4. In most cases they will 390 contain classical key exchange methods, however it is not a 391 requirement. Additional key exchange methods are proposed using 392 Additional Key Exchanges transform types. All these transform types 393 are optional, the initiator is free to select any of them for 394 proposing additional key exchange methods. Consequently, if none of 395 Additional Key Exchanges are included in the proposal, then this 396 proposal indicates performing standard IKEv2, as defined in 397 [RFC7296]. If the initiator includes any transform of type N (where 398 N is among Additional Key Exchanges) in the proposal, the responder 399 MUST select one of the algorithms proposed using this type. A 400 transform ID NONE may be added to those transform types which contain 401 key exchange methods that the initiator believes are optional. 403 The responder performs negotiation using standard IKEv2 procedure 404 described in Section 3.3 of [RFC7296]. However, for the Additional 405 Key Exchange types the responder's choice MUST NOT contain equal 406 transform IDs (apart from NONE), and the ID selected for Transform 407 Type 4 MUST NOT appear in any of Additional Key Exchange transforms. 408 In other words, all selected key exchange methods must be different. 410 3.2.2. INTERMEDIATE Round: Additional Key Exchanges 412 For each extra key exchange agreed to in the IKE_SA_INIT exchange, 413 the initiator and the responder perform an INTERMEDIATE exchange, as 414 described in [I-D.smyslov-ipsecme-ikev2-aux]. 416 This exchange is as follows: 418 Initiator Responder 419 ------------------------------------------------- 420 HDR, SK {Ni2, KEi2} --> 421 <-- HDR, SK {Nr2, KEr2} 423 The initiator sends a nonce in the Ni2 payload, and the key exchange 424 payload in the KEi2; the group id of the KEi2 payload MUST match the 425 negotiated extra key exchange. This packet is encrypted with the 426 current IKE SK keys. 428 On receiving this, the responder sends a nonce in the Nr2 payload, 429 and the key exchange payload KEr2; again, this packet is encrypted 430 with the current IKE SA keys. 432 Once this exchange is done, then both sides compute an updated keying 433 material: 435 SKEYSEED = prf(SK_d(old), KE2result | Ni2 | Nr2) 437 where KE2result is the shared secret of the key exchange. Then, 438 SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr are updated as: 440 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} 441 = prf+ (SKEYSEED, Ni2 | Nr2 | SPIi | SPIr) 443 Note that the negotiated transform types (the encryption type, hash 444 type, prf type) are not modified. 446 Both the initiator and the responder will use this updated key values 447 for the next message. 449 3.2.3. IKE_AUTH Exchange 451 After the INTERMEDIATE exchanges have completed, then the initiator 452 and the responder will perform an IKE_AUTH exchange. This exchange 453 is the standard IKE exchange, except that the initiator and responder 454 signed octets are modified as described in 455 [I-D.smyslov-ipsecme-ikev2-aux]. 457 3.2.4. CREATE_CHILD_SA Exchange 459 The CREATE_CHILD_SA exchange is used in IKEv2 for the purpose of 460 creating additional Child SAs, rekeying them and rekeying IKE SA 461 itself. When creating or rekeying Child SAs, the peers may 462 optionally perform a Diffie-Hellmann key exchange to add a fresh 463 entropy into the session keys, in case of IKE SA rekeying, the key 464 exchange is mandatory. 466 If the IKE SA was created using multiple key exchange methods, the 467 peers may want continue using multiple key exchanges in the 468 CREATE_CHILD_SA exchange too. If the initiator includes any 469 Additional Key Exchanges transform in the SA payload (along with 470 Transform Type 4) and the responder agrees to perform additional key 471 exchanges, then the additional key exchanges are performed in a 472 series of the INFORMATIONAL exchanges that follows the 473 CREATE_CHILD_SA exchange in an order of the values of their transform 474 types, so that key exchange negotiated using transform type N always 475 precedes key exchange negotiated using transform type N + 1. Each 476 INFORMATIONAL exchange MUST bear exactly one key exchange method. 477 Key exchange negotiated via Transform Type 4 always takes place in 478 the CREATE_CHILD_SA exchange, as per IKEv2 specification. 480 Since after IKE SA is created the window size may be greater than 481 one, and multiple concurrent exchanges may be active, it is essential 482 to link the INFORMATIONAL exchanges together and with the 483 CREATE_CHILD_SA exchange. A new status type notification 484 ADDITIONAL_KEY_EXCHANGE is used for this purpose. Its Notify Message 485 Type is , Protocol ID and SPI Size are both set to 0. 486 The data associated with this notification is a blob meaningful only 487 to the responder, so that the responder can correctly link successive 488 exchanges. For the initiator the content of this notification is an 489 opaque blob. 491 The responder MUST include this notification in a CREATE_CHILD_SA or 492 INFORMATIONAL response message in case next exchange is expected, 493 filling it with some data that would allow linking this exchange to 494 the next one. The initiator MUST copy the received notification with 495 its content intact into the request message of the next exchange. 497 Below is an example of three additional key exchanges. 499 Initiator Responder 500 ----------------------------------------------------------------------- 501 HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> 502 <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, 503 N(ADDITIONAL_KEY_EXCHANGE)(link1)} 505 HDR(INFORMATIONAL), SK {Ni2, KEi2, 506 N(ADDITIONAL_KEY_EXCHANGE)(link1)} --> 507 <-- HDR(INFORMATIONAL), SK {Nr2, KEr2, 508 N(ADDITIONAL_KEY_EXCHANGE)(link2)} 510 HDR(INFORMATIONAL), SK {Ni3, KEi3, 511 N(ADDITIONAL_KEY_EXCHANGE)(link2)} --> 512 <-- HDR(INFORMATIONAL), SK {Nr3, KEr3, 513 N(ADDITIONAL_KEY_EXCHANGE)(link3)} 515 HDR(INFORMATIONAL), SK {Ni4, KEi4, 516 N(ADDITIONAL_KEY_EXCHANGE)(link3)} --> 517 <-- HDR(INFORMATIONAL), SK {Nr4, KEr4} 519 4. Alternative Design 521 This section gives an overview on a number of alternative approaches 522 that we have considered, but later discarded. These approaches are: 524 o Sending the classical and post-quantum key exchanges as a single 525 transform 527 We considered combining the various key exchanges into a single 528 large KE payload; this effort is documented in a previous version 529 of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This 530 does allow us to cleanly apply hybrid key exchanges during the 531 child SA; however it does add considerable complexity, and 532 requires an independent fragmentation solution. 534 o Sending post-quantum proposals and policies in KE payload only 536 With the objective of not introducing unnecessary notify payloads, 537 we considered communicating the hybrid post-quantum proposal in 538 the KE payload during the first pass of the protocol exchange. 539 Unfortunately, this design is susceptible to the following 540 downgrade attack. Consider the scenario where there is an MitM 541 attacker sitting between an initiator and a responder. The 542 initiator proposes, through SAi payload, to use a hybrid post- 543 quantum group and as a backup a Diffie-Hellman group, and through 544 KEi payload, the initiator proposes a list of hybrid post-quantum 545 proposals and policies. The MitM attacker intercepts this traffic 546 and replies with N(INVALID_KE_PAYLOAD) suggesting to downgrade to 547 the backup Diffie-Hellman group instead. The initiator then 548 resends the same SAi payload and the KEi payload containing the 549 public value of the backup Diffie-Hellman group. Note that the 550 attacker may forward the second IKE_SA_INIT message only to the 551 responder, and therefore at this point in time, the responder will 552 not have the information that the initiator prefers the hybrid 553 group. Of course, it is possible for the responder to have a 554 policy to reject an IKE_SA_INIT message that (a) offers a hybrid 555 group but not offering the corresponding public value in the KEi 556 payload; and (b) the responder has not specifically acknowledged 557 that it does not supported the requested hybrid group. However, 558 the checking of this policy introduces unnecessary protocol 559 complexity. Therefore, in order to fully prevent any downgrade 560 attacks, using KE payload alone is not sufficient and that the 561 initiator MUST always indicate its preferred post-quantum 562 proposals and policies in a notify payload in the subsequent 563 IKE_SA_INIT messages following a N(INVALID_KE_PAYLOAD) response. 565 o New payload types to negotiate hybrid proposal and to carry post- 566 quantum public values 568 Semantically, it makes sense to use a new payload type, which 569 mimics the SA payload, to carry a hybrid proposal. Likewise, 570 another new payload type that mimics the KE payload, could be used 571 to transport hybrid public value. Although, in theory a new 572 payload type could be made backwards compatible by not setting its 573 critical flag as per Section 2.5 of RFC7296, we believe that it 574 may not be that simple in practice. Since the original release of 575 IKEv2 in RFC4306, no new payload type has ever been proposed and 576 therefore, this creates a potential risk of having a backward 577 compatibility issue from non-conforming RFC IKEv2 implementations. 578 Since we could not see any other compelling advantages apart from 579 a semantic one, we use the existing transform type and notify 580 payloads instead. In fact, as described above, we use the KE 581 payload in the first IKE_SA_INIT request round and the notify 582 payload to carry the post-quantum proposals and policies. We use 583 one or more of the existing KE payloads to carry the hybrid public 584 values. 586 o Hybrid public value payload 588 One way to transport the negotiated hybrid public payload, which 589 contains one classical Diffie-Hellman public value and one or more 590 post-quantum public values, is to bundle these into a single KE 591 payload. Alternatively, these could also be transported in a 592 single new hybrid public value payload, but following the same 593 reasoning as above, this may not be a good idea from a backward 594 compatibility perspective. Using a single KE payload would 595 require an encoding or formatting to be defined so that both peers 596 are able to compose and extract the individual public values. 597 However, we believe that it is cleaner to send the hybrid public 598 values in multiple KE payloads--one for each group or algorithm. 599 Furthermore, at this point in the protocol exchange, both peers 600 should have indicated support of handling multiple KE payloads. 602 o Fragmentation 604 Handling of large IKE_SA_INIT messages has been one of the most 605 challenging tasks. A number of approaches have been considered 606 and the two prominent ones that we have discarded are outlined as 607 follows. 609 The first approach was to treat the entire IKE_SA_INIT message as 610 a stream of bytes, which we then split it into a number of 611 fragments, each of which is wrapped onto a payload that would fit 612 into the size of the network MTU. The payload that wraps each 613 fragment is a new payload type and it was envisaged that this new 614 payload type will not cause a backward compatibility issue because 615 at this stage of the protocol, both peers should have indicated 616 support of fragmentation in the first pass of the IKE_SA_INIT 617 exchange. The negotiation of fragmentation is performed using a 618 notify payload, which also defines supporting parameters such as 619 the size of fragment in octets and the fragment identifier. The 620 new payload that wraps each fragment of the messages in this 621 exchange is assigned the same fragment identifier. Furthermore, 622 it also has other parameters such as a fragment index and total 623 number of fragments. We decided to discard this approach due to 624 its blanket approach to fragmentation. In cases where only a few 625 payloads need to be fragmented, we felt that this approach is 626 overly complicated. 628 Another idea that was discarded was fragmenting an individual 629 payload without introducing a new payload type. The idea was to 630 use the 9-th bit (the bit after the critical flag in the RESERVED 631 field) in the generic payload header as a flag to mark that this 632 payload is fragmented. As an example, if a KE payload is to be 633 fragmented, it may look as follows. 635 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Next Payload |C|F| RESERVED | Payload Length | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Diffie-Hellman Group Number | Fragment Identifier | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Fragment Index | Total Fragments | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Total KE Payload Data Length | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | | 647 ~ Fragmented KE Payload ~ 648 | | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 When the flag F is set, this means the current KE payload is a 652 fragment of a larger KE payload. The Payload Length field denotes 653 the size of this payload fragment in octets--including the size of 654 the generic payload header. The two-octet RESERVED field 655 following Diffie-Hellman Group Number was to be used as a fragment 656 identifier to help assembly and disassembly of fragments. The 657 Fragment Index and Total Fragments fields are self-explanatory. 658 The Total KE Payload Data Length indicates the size of the 659 assembled KE payload data in octets. Finally, the actual fragment 660 is carried in Fragment KE Payload field. 662 We discarded this approach because we believe that the working 663 group may not be happy using the RESERVED field to change the 664 format of a packet and that implementers may not like the 665 complexity added from checking the fragmentation flag in each 666 received payload. More importantly, fragmenting the messages in 667 this way may leave the system to be more prone to denial of 668 service (DoS) attacks. By using INTERMEDIATE to transport the 669 large post-quantum key exchange payloads, there is no longer any 670 issue with fragmentation. 672 o Group sub-identifier 674 As discussed before, each group identifier is used to distinguish 675 a post-quantum algorithm. Further classification could be made on 676 a particular post-quantum algorithm by assigning additional value 677 alongside the group identifier. This sub- identifier value may be 678 used to assign different security parameter sets to a given post- 679 quantum algorithm. However, this level of details does not fit 680 the principles of the document where it should deal with generic 681 hybrid key exchange protocol, not a specific ciphersuite. 682 Furthermore, there are enough Diffie- Hellman group identifiers 683 should this be required in the future. 685 5. IANA Considerations 687 This document also adds the following Transform Types to the 688 "Transform Type Values" registry: 690 Type Description Used In Reference 691 ------------------------------------------------------------------------ 692 6 Additional Key Exchange 1 (optional in IKE, AH and ESP) [RFCXXXX] 693 7 Additional Key Exchange 2 (optional in IKE, AH and ESP) [RFCXXXX] 694 8 Additional Key Exchange 3 (optional in IKE, AH and ESP) [RFCXXXX] 695 9 Additional Key Exchange 4 (optional in IKE, AH and ESP) [RFCXXXX] 696 10 Additional Key Exchange 5 (optional in IKE, AH and ESP) [RFCXXXX] 697 11 Additional Key Exchange 6 (optional in IKE, AH and ESP) [RFCXXXX] 698 12 Additional Key Exchange 7 (optional in IKE, AH and ESP) [RFCXXXX] 700 This document also defines a new Notify Message Types in the "Notify 701 Message Types - Status Types" registry: 703 ADDITIONAL_KEY_EXCHANGE 705 6. Security Considerations 707 The key length of the Encryption Algorithm (Transform Type 1), the 708 Pseudorandom Function (Transform Type 2) and the Integrity Algorithm 709 (Transform Type 3), all have to be of sufficient length to prevent 710 attacks using Grover's algorithm [GROVER]. In order to use the 711 extension proposed in this document, the key lengths of these 712 transforms SHALL be at least 256 bits long in order to provide 713 sufficient resistance to quantum attacks. Accordingly the post- 714 quantum security level achieved is at least 128 bits. 716 SKEYSEED is calculated from shared, KEx, using an algorithm defined 717 in Transform Type 2. While a quantum attacker may learn the value of 718 KEx', if this value is obtained by means of a classical key exchange, 719 other KEx values generated by means of a quantum-resistant algorithm 720 ensure that the final SKEYSEED is not compromised. This assumes that 721 the algorithm defined in the Transform Type 2 is post-quantum. 723 The main focus of this document is to prevent a passive attacker 724 performing a "harvest and decrypt" attack. In other words, an 725 attacker that records messages exchanges today and proceeds to 726 decrypt them once he owns a quantum computer. This attack is 727 prevented due to the hybrid nature of the key exchange. Other 728 attacks involving an active attacker using a quantum-computer are not 729 completely solved by this document. This is for two reasons. 731 The first reason is because the authentication step remains 732 classical. In particular, the authenticity of the SAs established 733 under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA 734 algorithms. Whilst the pre-shared key option, provided the key is 735 long enough, is post-quantum, the other algorithms are not. 736 Moreover, in implementations where scalability is a requirement, the 737 pre-shared key method may not be suitable. Quantum-safe authenticity 738 may be provided by using a quantum-safe digital signature and several 739 quantum-safe digital signature methods are being explored by IETF. 740 For example, if the implementation is able to reliably track state, 741 the hash based method, XMSS has the status of an RFC, see [RFC8391]. 742 Currently, quantum-safe authentication methods are not specified in 743 this document, but are planned to be incorporated in due course. 745 It should be noted that the purpose of post-quantum algorithms is to 746 provide resistance to attacks mounted in the future. The current 747 threat is that encrypted sessions are subject to eavesdropping and 748 archived with decryption by quantum computers taking place at some 749 point in the future. Until quantum computers become available there 750 is no point in attacking the authenticity of a connection because 751 there are no possibilities for exploitation. These only occur at the 752 time of the connection, for example by mounting a MitM attack. 753 Consequently there is not such a pressing need for quantum-safe 754 authenticity. 756 This draft does not attempt to address key exchanges with KE payloads 757 longer than 64k; the current IKE payload format does not allow that 758 as a possibility. If such huge KE payloads are required, a work 759 around (such as making the KE payload a URL and a hash of the real 760 payload) would be needed. At the current time, it appears likely 761 that there will be plenty of key exchanges available that would not 762 require such a workaround. 764 7. References 766 7.1. Normative References 768 [I-D.smyslov-ipsecme-ikev2-aux] 769 Smyslov, V., "Intermediate Exchange in the IKEv2 770 Protocol", draft-smyslov-ipsecme-ikev2-aux-02 (work in 771 progress), December 2018. 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, 775 DOI 10.17487/RFC2119, March 1997, 776 . 778 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 779 Kivinen, "Internet Key Exchange Protocol Version 2 780 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 781 2014, . 783 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 784 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 785 May 2017, . 787 7.2. Informative References 789 [GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for 790 Database Search", Proc. of the Twenty-Eighth Annual ACM 791 Symposium on the Theory of Computing (STOC 1996), 1996. 793 [I-D.ietf-ipsecme-qr-ikev2] 794 Fluhrer, S., McGrew, D., Kampanakis, P., and V. Smyslov, 795 "Postquantum Preshared Keys for IKEv2", draft-ietf- 796 ipsecme-qr-ikev2-05 (work in progress), December 2018. 798 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 799 DOI 10.17487/RFC4302, December 2005, 800 . 802 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 803 RFC 4303, DOI 10.17487/RFC4303, December 2005, 804 . 806 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 807 (IKEv2) Message Fragmentation", RFC 7383, 808 DOI 10.17487/RFC7383, November 2014, 809 . 811 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 812 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 813 August 2017, . 815 [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. 816 Mohaisen, "XMSS: eXtended Merkle Signature Scheme", 817 RFC 8391, DOI 10.17487/RFC8391, May 2018, 818 . 820 Acknowledgements 822 The authors would like to thanks Frederic Detienne and Olivier 823 Pelerin for their comments and suggestions, including the idea to 824 negotiate the post-quantum algorithms using the existing KE payload. 826 Authors' Addresses 828 C. Tjhai 829 Post-Quantum 831 Email: cjt@post-quantum.com 833 M. Tomlinson 834 Post-Quantum 836 Email: mt@post-quantum.com 838 G. Bartlett 839 Cisco Systems 841 Email: grbartle@cisco.com 843 S. Fluhrer 844 Cisco Systems 846 Email: sfluhrer@cisco.com 848 D. Van Geest 849 ISARA Corporation 851 Email: daniel.vangeest@isara.com 852 O. Garcia-Morchon 853 Philips 855 Email: oscar.garcia-morchon@philips.com 857 Valery Smyslov 858 ELVIS-PLUS 860 Email: svan@elvis.ru