idnits 2.17.00 (12 Aug 2021) /tmp/idnits22536/draft-tjhai-ipsecme-hybrid-qske-ikev2-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 1, 2018) is 1420 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-ipsecme-qr-ikev2 has been published as RFC 8784 == Outdated reference: A later version (-02) exists of draft-smyslov-ipsecme-ikev2-aux-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: January 2, 2019 G. Bartlett 6 S. Fluhrer 7 Cisco Systems 8 D. Van Geest 9 ISARA Corporation 10 Z. Zhang 11 Onboard Security 12 O. Garcia-Morchon 13 Philips 14 July 1, 2018 16 Framework to Integrate Post-quantum Key Exchanges into Internet Key 17 Exchange Protocol Version 2 (IKEv2) 18 draft-tjhai-ipsecme-hybrid-qske-ikev2-02 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 January 2, 2019. 46 Copyright Notice 48 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . 7 72 3.2.1. First Protocol Round . . . . . . . . . . . . . . . . 8 73 3.2.2. IKE_AUX round . . . . . . . . . . . . . . . . . . . . 10 74 3.2.3. IKE_AUX exchange . . . . . . . . . . . . . . . . . . 11 75 3.3. Post-quantum Group Transform Type and Group Identifiers . 11 76 3.4. Hybrid Group Negotiation . . . . . . . . . . . . . . . . 12 77 3.5. Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 12 78 4. Alternative Design . . . . . . . . . . . . . . . . . . . . . 12 79 5. Security considerations . . . . . . . . . . . . . . . . . . . 16 80 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 1.1. Problem Description 88 Internet Key Exchange Protocol (IKEv2) as specified in RFC 7296 89 [RFC7296] uses the Diffie-Hellman (DH) or Elliptic Curve Diffie- 90 Hellman (ECDH) algorithm to establish a shared secret between an 91 initiator and a responder. The security of the DH and ECDH 92 algorithms relies on the difficulty to solve a discrete logarithm 93 problem in multiplicative and elliptic curve groups respectively when 94 the order of the group parameter is large enough. While solving such 95 a problem remains difficult with current computing power, it is 96 believed that general purpose quantum computers will be able to solve 97 this problem, implying that the security of IKEv2 is compromised. 98 There are, however, a number of cryptosystems that are conjectured to 99 be resistant against quantum computer attack. This family of 100 cryptosystems are known as post-quantum cryptography (PQC). It is 101 ometime also referred to as quantum-safe cryptography (QSC) or 102 quantum-resistant cryptography (QRC). 104 1.2. Proposed Extension 106 This document describes a framework to integrate QSC for IKEv2, while 107 maintaining backwards compatibility, to derive a set of IKE keys that 108 have resistance to quantum computer attacks. Our framework allows 109 the negotiation of one or more QSC algorithm to exchange data, in 110 addition to the existing DH or ECDH key exchange data. We believe 111 that the feature of using more than one post-quantum algorithm is 112 important as many of these algorithms are relatively new and there 113 may be a need to hedge the security risk with multiple key exchange 114 data from several distinct QSC algorithms. 116 The secrets established from each key exchange are combined in a way 117 such that should the post-quantum secrets not be present, the derived 118 shared secret is equivalent to that of the standard IKEv2; on the 119 other hand, a post-quantum shared secret is obtained if both 120 classical and post-quantum key exchange data are present. This 121 framework also applies to key exchanges in IKE Security Associations 122 (SAs) for Encapsulating Security Payload (ESP) [ESP] or 123 Authentication Header (AH) [AH], i.e. Child SAs, in order to provide 124 a stronger guarantee of forward security. 126 Some post-quantum key exchange payloads may have size larger than the 127 standard MTU size, and therefore there could be issues with 128 fragmentation at IP layer. IKE does allow transmission over TCP 129 where fragmentation is not an issue [RFC8229]; however, we believe 130 that a UDP-based solution will be required too. IKE does have a 131 mechanism to handle fragmentation within UDP [RFC7383], however that 132 is only applicable to messages exchanged after the IKE_SA_INIT. To 133 use this mechanism, we use the IKE_AUX exchange as outlined in 134 [I-D.smyslov-ipsecme-ikev2-aux]. With this mechanism, we do an 135 initial key exchange, using a smaller, possibly non-quantum resistant 136 primitive, such as ECDH. Then, before we do the IKE_AUTH exchange, 137 we perform one or more IKE_AUX exchanges, each of which includes a 138 secondary key exchange. As the IKE_AUX exchange is encrypted, the 139 IKE fragmentation protocol RFC7383 can be used. The IKE SK values 140 will be updated after each exchange, and so the final IKE SK values 141 will depend on all the key exchanges, hence they are secure if any of 142 the key exchanges are secure. 144 Note that readers should consider the approach in this document as 145 providing a long term solution in upgrading the IKEv2 protocol to 146 support post-quantum algorithms. A short term solution to make IKEv2 147 key exchange quantum secure is to use post-quantum pre-shared keys as 148 discussed in [I-D.ietf-ipsecme-qr-ikev2]. 150 1.3. Changes 152 Changes in this draft in each version iterations. 154 draft-tjhai-ipsecme-hybrid-qske-ikev2-01 156 o Use IKE_AUX to perform multiple key exchanges in succession. 158 o Handle fragmentation by keeping the first key exchange (a standard 159 IKE_SA_INIT with a few extra notifies) small, and encrypting the 160 rest of the key exchanges. 162 o Simplify the negotiation of the 'extra' key exchanges. 164 draft-tjhai-ipsecme-hybrid-qske-ikev2-00 166 o We added a feature to allow more than one post-quantum key 167 exchange algorithms to be negotiated and used to exchange a post- 168 quantum shared secret. 170 o Instead of relying on TCP encapsulation to deal with IP level 171 fragmentation, we introduced a new key exchange payload that can 172 be sent as multiple fragments within IKE_SA_INIT message. 174 1.4. Document organization 176 The remainder of this document is organized as follows. Section 2 177 summarizes design criteria. Section 3 describes how post-quantum key 178 exchange is performed between two IKE peers and how keying materials 179 are derived. The rationale behind the approach of this extension is 180 described in Section 3. Section 4 discusses security considerations 181 an lastly, Section 5 discusses IANA considerations for the name 182 spaces introduced in this document. 184 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 185 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 186 document, are to be interpreted as described in RFC 2119 [RFC2119]. 188 2. Design criteria 190 The design of the proposed post-quantum IKEv2 is driven by the 191 following criteria: 193 1) Need for post-quantum cryptography in IPsec. Quantum computers 194 might become feasible in the next 5-10 years. If current 195 Internet communications are monitored and recorded today (D), 196 the communications could be decrypted as soon as a quantum- 197 computer is available (e.g., year Q) if key negotiation only 198 relies on non post-quantum primitives. This is a high threat 199 for any information that must remain confidential for a long 200 period of time T > Q-D. The need is obvious if we assume that Q 201 is 2040, D is 2020, and T is 30 years. Such a value of T is 202 typical in classified or healthcare data. 204 2) Hybrid. Currently, there does not exist a post-quantum key 205 exchange that is trusted at the level that ECDH is trusted 206 against conventional (non-quantum) adversaries. A hybrid 207 approach allows introducing promising post-quantum candidates 208 next to well-established primitives, since the overall security 209 is at least as strong as each individual primitive. 211 3) Focus on quantum-resistant confidentiality. A passive attacker 212 can eavesdrop on IPsec communication today and decrypt it once a 213 quantum computer is available in the future. This is a very 214 serious attack for which we do not have a solution. An attacker 215 can only perform active attacks such as impersonation of the 216 communicating peers once a quantum computer is available, 217 sometime in the future. Thus, our design focuses on quantum- 218 resistant confidentiality due to the urgency of this problem. 219 This document does not address quantum-resistant authentication 220 since it is less urgent at this stage. 222 4) Limit amount of exchanged data. The protocol design should be 223 such that the amount of exchanged data, such as public-keys, is 224 kept as small as possible even if initiator and responder need 225 to agree on a hybrid group or multiple public-keys need to be 226 exchanged. 228 5) Future proof. Any cryptographic algorithm could be potentially 229 broken in the future by currently unknown or impractical 230 attacks: quantum computers are merely the most concrete example 231 of this. The design does not categorize algorithms as "post- 232 quantum" or "non post-quantum" and does not create assumptions 233 about the properties of the algorithms, meaning that if 234 algorithms with different properties become necessary in the 235 future, this framework can be used unchanged to facilitate 236 migration to those algorithms. 238 6) Limited amount of changes. A key goal is to limit the number of 239 changes required when enabling a post-quantum handshake. This 240 ensures easier and quicker adoption in existing implementations. 242 7) Localized changes. Another key requirement is that changes to 243 the protocol are limited in scope, in particular, limiting 244 changes in the exchanged messages and in the state machine, so 245 that they can be easily implemented. 247 8) Deterministic operation. This requirement means that the hybrid 248 post-quantum exchange, and thus, the computed key, will be based 249 on algorithms that both client and server wish to support. 251 9) Fragmentation support. Some PQC algorithms could be relatively 252 bulky and they might require fragmentation. Thus, a design goal 253 is the adaptation and adoption of an existing fragmentation 254 method or the design of a new method that allows for the 255 fragmentation of the key shares. 257 10) Backwards compatibility and interoperability. This is a 258 fundamental requirement to ensure that hybrid post-quantum IKEv2 259 and a non-post-quantum IKEv2 implementations are interoperable. 261 11) FIPS compliance. IPsec is widely used in Federal Information 262 Systems and FIPS certification is an important requirement. 263 However, algorithms that are believed to be post-quantum are not 264 FIPS compliant yet. Still, the goal is that the overall hybrid 265 post-quantum IKEv2 design can be FIPS compliant. 267 3. The Framework of Hybrid Post-quantum Key Exchange 269 3.1. Overall design 271 This design assigns new group identifiers (Transform Type 4) to the 272 various post-quantum key exchanges (which will be defined later). We 273 specifically do not make a distinction between classical (DH and 274 ECDH) and post-quantum key exchanges, nor post-quantum algorithms 275 which are true key exchanges versus post-quantum algorithms that act 276 as key transport mechanisms; all are treated equivalently by the 277 protocol. In order to support both hybrid key exchanges (that is, 278 relying on distinct key exchanges) and fragmentation, the proposed 279 hybrid post-quantum IKEv2 protocol extends IKE [RFC7296] by adding 280 additional key exchange messages (IKE_AUX) between the IKE_SA_INIT 281 and the IKE_AUTH exchanges. In order to minimize communication 282 overhead, only the key shares that are agreed to be used are actually 283 exchanged. In order to achieve this, the IKE_SA_INIT exchange now 284 includes notify payloads that negotiate the extra key exchanges to be 285 used. The initiator IKE_SA_INIT message includes a notify that lists 286 the extra key exchange policy required by the initiator; the 287 responder selects one of the listed policies, and includes that as a 288 notify in the response IKE_SA_INIT message. Then, the initiator and 289 the responder perform one (or possibly more) IKE_AUX exchange; each 290 such exchange includes a KE payload for the key exchange that was 291 negotiated. 293 Here is an overview of the initial exchanges: 295 Initiator Responder 296 -------------------------------------------------------- 297 <-- IKE_SA_INIT (and extra key exchange negotiation) --> 299 <-- {IKE_AUX (hybrid post-quantum key exchange)} --> 300 ... 301 <-- {IKE_AUX (hybrid post-quantum key exchange)} --> 303 <-- {IKE_AUTH} --> 305 The extra post-quantum key exchanges can use algorithms that are 306 currently considered to be resistant to quantum computer attacks. 307 These algorithms are collectively referred to as post-quantum 308 algorithms in this document. 310 3.2. Overall Protocol 312 In the simplest case, the initiator is happy with a single key 313 exchange (and has no interest in supporting multiple), and he is not 314 concerned with possible fragmentation of the IKE_SA_INIT messages 315 (either because the key exchange he selects is small enough not to 316 fragment, or he is confident that fragmentation will be handled 317 either by IP fragmentation, or transport via TCP). In the following 318 we overview the two protocol rounds involved in the hybrid post- 319 quantum protocol. 321 In this case, the initiator performs the IKE_SA_INIT as standard, 322 inserting this prefered key exchange (which is possibly a post- 323 quantum algorithm) as the listed Transform Type 4, and including the 324 initiator KE payload. If the responder accepts the policy, he 325 responds with an IKE_SA_INIT response, and IKE continues as usual. 327 If the initiator desires to negotiate multiple key exchanges, or he 328 needs IKE to handle any possible fragmentation, then he uses the 329 protocol listed below. 331 3.2.1. First Protocol Round 333 In the first round, the IKE_SA_INIT request and response messages 334 negotiate the initial IKE SAs (as currently), as well as the key 335 exchanges that will be used within the IKE_AUX phase below. 337 The initiator negotiates cryptographic suites as per RFC7296, with 338 the listed Transform Type 4 (and KE payload) being either the first 339 key exchange on his desired list of key exchanges, or alternatively a 340 small classical one (in order to enable fragmentation support of the 341 later key exchanges). In addition, the initial IKE_SA_INIT message 342 will include the following two Notify payloads: 344 o The N(AUX_EXCHANGE_SUPPORTED) notify, as specified in 345 [I-D.smyslov-ipsecme-ikev2-aux]. This draft makes no requirements 346 about the included data. 348 o An N(EXTRA_KEY_EXCHANGE_POLICY) notify, which has a Protocol ID 349 and SPI Size of 0, and includes the below data. 351 This data will be the list of groups that the initiator is willing to 352 negotiate during the IKE_AUX phase below. The initiator signifies 353 this by specifying the specific list of the sets of key exchanges 354 that he will allow. The list MUST be ordered from most prefered to 355 least prefered. This is encoded as a series of 2 byte values; a 356 specified list of acceptable groups is given as the specific 357 Transform IDs, followed by a 0x00 value. For example, if the NewHope 358 post-quantum key exchange is 0x40, Round2 is 0x42, and SIKE is 0x47, 359 then the data payload: 361 0040 0000 362 0042 0047 0000 363 0042 0000 365 will signify that the initiator is willing to perform IKE_AUX with 366 either NewHope, Round2 followed by SIKE, or only Round2. 368 If the initiator is willing to skip the IKE_AUX phase, he can signify 369 that by including a 0000 value as a list; for example: 371 0040 0000 372 0042 0047 0000 373 0042 0000 374 0000 376 would signify either (NewHope), (Round2, SIKE), (Round2) or skipping 377 the IKE_AUX entirely. 379 When the responder that supports the hybrid exchange receives an 380 IKE_SA_INIT message with the AUX_EXHANGE_SUPPORTED and 381 EXTRA_KEY_EXCHANGE_POLICY notifies, then (after processing the IKE 382 message as normal), it scans through the policy listed within the 383 EXTRA_KEY_EXCHANGE_POLICY Notify payload. If the responder finds a 384 list of key exchanges that is consistent with its own policy, it 385 includes N(AUX_EXCHANGE_SUPPORTED) and N(EXTRA_KEY_EXCHANGE_LIST) 386 notifies, which both have 0 Protocol IDs and SPI sizes. The data for 387 the EXTRA_KEY_EXCHANGE_LIST notify would have data specifying the 388 list of acceptable Transform IDs as a series of 2 byte values. If 389 the responder's policy requires it to perform the extra key exchange, 390 but none of the key exchange lists are acceptable, it returns an 391 error in a notification with type NO_PROPOSAL_CHOSEN. 393 For example, if the single transform Round2 is accepted, then the 394 data payload will consist of: 396 0042 398 If the set Round2 and SIKE is accepted, then the data payload will 399 consist of: 401 0042 0047 403 If no IKE_AUX transforms is desired, then the data payload will be 404 empty (or alternatively no such notification is included, which 405 implies the same thing). 407 On success, the responder will create the IKE SA and SK values based 408 on SAi1, SAr1 and KE payloads as normal. 410 When the initiator receives the reply IKE_SA_INIT message, it checks 411 for the existence of the AUX_EXCHANGE_SUPPORTED and 412 EXTRA_KEY_EXCHANGE_LIST notifies. If those notifies are not present, 413 then the initiator treats it as if no extra key exchanges were chosen 414 (and then can proceed by either rejecting the exchange, or proceed 415 using the single negotiated key exchange, depending on local policy). 417 If those notifies are present, then the responder verifies that the 418 key exchanges listed within the EXTRA_KEY_EXCHANGE_LIST are one of 419 the options within its local policy; if so, it processes the 420 IKE_SA_INIT message as normal, and then proceeds to the IKE_AUX 421 round. 423 3.2.1.1. Note on responder policy check 425 One reason that the initiator may select the initial key exchange 426 (the type 4 transform within the SAi1 payload) is not for security, 427 but instead to simply establish keys to allow fragmentation of the 428 IKE_AUX message. Because of this possibility, if the receiver sees a 429 list of key exchanges listed within the EXTRA_KEY_EXCHANGE_LIST that 430 satisfies its policies, it SHOULD accept it (assuming that the SAi1 431 payload is otherwise acceptable), even if the key payload within the 432 SAi1 is not necessary according to its policy. 434 3.2.2. IKE_AUX round 436 For each extra key exchange agreed to in the IKE_SA_INIT exchange, 437 the initiator and the responder perform an IKE_SA_AUX exchange, as 438 described in [I-D.smyslov-ipsecme-ikev2-aux]. 440 This exchange is as follows: 442 Initiator Responder 443 ------------------------------------------------- 444 HDR, SK {Ni2, KEi2} --> 445 <-- HDR, SK {Nr2, KEr2} 447 The initiator sends a nonce in the Ni2 payload, and the key exchange 448 payload in the KEi2; the group id of the KEi2 payload MUST match the 449 negotiated extra key exchange. This packet is encrypted with the 450 current IKE SK keys. 452 On receiving this, the responder sends a nonce in the Nr2 payload, 453 and the key exchange payload KEr2; again, this packet is encrypted 454 with the current IKE SA keys. 456 Once this exchange is done, then both sides compute an updated keying 457 material: 459 SKEYSEED = prf(SK_d(old), KE2result | Ni2 | Nr2) 461 where KE2result is the shared secret of the key exchange. Then, 462 SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr are updated as: 464 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} 465 = prf+ (SKEYSEED, Ni2 | Nr2 | SPIi | SPIr) 467 Note that the negotiated transform types (the encryption type, hash 468 type, prf type) are not modified. 470 Both the initiator and the responder will use this updated key values 471 for the next message. 473 If the EXTRA_KEY_EXCHANGE_LIST has negotiated more than one key 474 exchange, then this exchange is performed once for every key exchange 475 on the list. 477 3.2.3. IKE_AUX exchange 479 After the IKE_AUX exchanges have completed, then the initiator and 480 the responder will perform an IKE_AUTH exchange. This exchange is 481 the standard IKE exchange, except that the initiator and responder 482 signed octets are modified as described in 483 [I-D.smyslov-ipsecme-ikev2-aux]. 485 3.3. Post-quantum Group Transform Type and Group Identifiers 487 In generating keying material within IKEv2, both initiator and 488 responder negotiate up to four cryptographic algorithms in the SA 489 payload of an IKE_SA_INIT or a CREATE_CHILD_SA exchange. One of the 490 negotiated algorithms is a Diffie-Hellman algorithm, which is used 491 for key exchange. This negotiation is done using the Transform Type 492 4 (Diffie-Hellman Group) where each Diffie-Hellman group is assigned 493 a unique value. 495 We expect that in the future, IANA will assign permanent values to 496 these transforms. Until it does, we will use the following values 497 for the below key exchanges (which will need to be specified in more 498 detail elsewhere). Official identifiers will be maintained by IANA 499 and updated during the NIST standardization process. 501 Name Number Key exchange 502 -------------------------------------------------- 503 NIST_CANDIDATE_1 0x9100 The 1st candidate of 504 NIST PQC submission 505 NIST_CANDIDATE_2 0x9101 The 2nd candidate of 506 NIST PQC submission 508 Because we are using transforms in the private use space, both the 509 initiator and responder must include a vendor id with this payload: 511 d4 48 11 94 c0 c3 4c 9d d1 22 76 aa 9a 4e 80 d5 513 This payload is the MD5 hash of "IKEv2 Quantum Safe Key Exchange 514 v1"). If the other side does not include this vendor id, an 515 implementation MUST NOT process these private use transforms as 516 listed in this draft. 518 3.4. Hybrid Group Negotiation 520 Most post-quantum key agreement algorithms are relatively new, and 521 thus are not fully trusted. There are also many proposed algorithms, 522 with different trade-offs and relying on different hard problems. 523 The concern is that some of these hard problems may turn out to be 524 easier to solve than anticipated (and thus the key agreement 525 algorithm not be as secure as expected). A hybrid solution allows us 526 to deal with this uncertainty by combining a classical key exchanges 527 with a post-quantum one, as well as leaving open the possibility of 528 multiple post-quantum key exchanges. 530 The method that we use to perform hybrid key exchange also addresses 531 the fragmentation issue. The initial IKE_INIT messages do not have 532 any inherent fragmentation support within IKE; however that can 533 include a relatively short KE payload (e.g. one for group 14, 19 or 534 31). The rest of the KE payloads are encrypted within IKE_AUX 535 messages; because they are encrypted, the standard IKE fragmentation 536 solution [RFC7383] is available. 538 3.5. Child SAs 540 This method of performing hybrid key exchanges, by performing 541 multiple exchanges in series, solves the issue by making the IKE SK 542 values be a function of all the key exchanges performed. Hence, we 543 achieve the goal of making the IKE exchange secure if any of the key 544 exchanges are secure. 546 This proposal allows the support of multiple post-quantum algorithms 547 (in case we don't have full confidence in any one); this is 548 implemented by having the initiator list all the combinations of 549 extra key exchanges he finds acceptable. It is not anticipated that 550 there will be a need for a large number of different combinations of 551 key exchanges, hence this relatively simple encoding method was 552 selected as a reasonable compromise between simplicity and 553 functionality. 555 This method also allows us to fragment large post-quantum key 556 exchanges; all the initiator needs to assure is that the initial key 557 exchange (which has the KE payloads exchanged during IKE_SA_INIT) is 558 small enough not to cause fragmentation. 560 4. Alternative Design 562 This section gives an overview on a number of alternative approaches 563 that we have considered, but later discarded. These approaches are: 565 o Sending the classical and post-quantum key exchanges as a single 566 transform 568 We considered combining the various key exchanges into a single 569 large KE payload; this effort is documented in a previous version 570 of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This 571 does allow us to cleanly apply hybrid key exchanges during the 572 child SA; however it does add considerable complexity, and 573 requires an independant fragmentation solution. 575 o Sending post-quantum proposals and policies in KE payload only 577 With the objective of not introducing unnecessary notify payloads, 578 we considered communicating the hybrid post-quantum proposal in 579 the KE payload during the first pass of the protocol exchange. 580 Unfortunately, this design is susceptible to the following 581 downgrade attack. Consider the scenario where there is an MitM 582 attacker sitting between an initiator and a responder. The 583 initiator proposes, through SAi payload, to use a hybrid post- 584 quantum group and as a backup a Diffie-Hellman group, and through 585 KEi payload, the initiator proposes a list of hybrid post-quantum 586 proposals and policies. The MitM attacker intercepts this traffic 587 and replies with N(INVALID_KE_PAYLOAD) suggesting to downgrade to 588 the backup Diffie-Hellman group instead. The initiator then 589 resends the same SAi payload and the KEi payload containing the 590 public value of the backup Diffie-Hellman group. Note that the 591 attacker may forward the second IKE_SA_INIT message only to the 592 responder, and therefore at this point in time, the responder will 593 not have the information that the initiator prefers the hybrid 594 group. Of course, it is possible for the responder to have a 595 policy to reject an IKE_SA_INIT message that (a) offers a hybrid 596 group but not offering the corresponding public value in the KEi 597 payload; and (b) the responder has not specifically acknowledged 598 that it does not supported the requested hybrid group. However, 599 the checking of this policy introduces unnecessary protocol 600 complexity. Therefore, in order to fully prevent any downgrade 601 attacks, using KE payload alone is not sufficient and that the 602 initiator MUST always indicate its preferred post-quantum 603 proposals and policies in a notify payload in the subsequent 604 IKE_SA_INIT messages following a N(INVALID_KE_PAYLOAD) response. 606 o New payload types to negotiate hybrid proposal and to carry post- 607 quantum public values 609 Semantically, it makes sense to use a new payload type, which 610 mimics the SA payload, to carry a hybrid proposal. Likewise, 611 another new payload type that mimics the KE payload, could be used 612 to transport hybrid public value. Although, in theory a new 613 payload type could be made backwards compatible by not setting its 614 critical flag as per Section 2.5 of RFC7296, we believe that it 615 may not be that simple in practice. Since the original release of 616 IKEv2 in RFC4306, no new payload type has ever been proposed and 617 therefore, this creates a potential risk of having a backward 618 compatibility issue from non-conforming RFC IKEv2 implementations. 619 Since we could not see any other compelling advantages apart from 620 a semantic one, we use the existing transform type and notify 621 payloads instead. In fact, as described above, we use the KE 622 payload in the first IKE_SA_INIT request round and the notify 623 payload to carry the post-quantum proposals and policies. We use 624 one or more of the existing KE payloads to carry the hybrid public 625 values. 627 o Hybrid public value payload 629 One way to transport the negotiated hybrid public payload, which 630 contains one classical Diffie-Hellman public value and one or more 631 post-quantum public values, is to bundle these into a single KE 632 payload. Alternatively, these could also be transported in a 633 single new hybrid public value payload, but following the same 634 reasoning as above, this may not be a good idea from a backward 635 compatibility perspective. Using a single KE payload would 636 require an encoding or formatting to be defined so that both peers 637 are able to compose and extract the individual public values. 638 However, we believe that it is cleaner to send the hybrid public 639 values in multiple KE payloads--one for each group or algorithm. 640 Furthermore, at this point in the protocol exchange, both peers 641 should have indicated support of handling multiple KE payloads. 643 o Fragmentation 645 Handling of large IKE_SA_INIT messages has been one of the most 646 challenging tasks. A number of approaches have been considered 647 and the two prominent ones that we have discarded are outlined as 648 follows. 650 The first approach was to treat the entire IKE_SA_INIT message as 651 a stream of bytes, which we then split it into a number of 652 fragments, each of which is wrapped onto a payload that would fit 653 into the size of the network MTU. The payload that wraps each 654 fragment is a new payload type and it was envisaged that this new 655 payload type will not cause a backward compatibility issue because 656 at this stage of the protocol, both peers should have indicated 657 support of fragmentation in the first pass of the IKE_SA_INIT 658 exchange. The negotiation of fragmentation is performed using a 659 notify payload, which also defines supporting parameters such as 660 the size of fragment in octets and the fragment identifier. The 661 new payload that wraps each fragment of the messages in this 662 exchange is assigned the same fragment identifier. Furthermore, 663 it also has other parameters such as a fragment index and total 664 number of fragments. We decided to discard this approach due to 665 its blanket approach to fragmentation. In cases where only a few 666 payloads need to be fragmented, we felt that this approach is 667 overly complicated. 669 Another idea that was discarded was fragmenting an individual 670 payload without introducing a new payload type. The idea was to 671 use the 9-th bit (the bit after the critical flag in the RESERVED 672 field) in the generic payload header as a flag to mark that this 673 payload is fragmented. As an example, if a KE payload is to be 674 fragmented, it may look as follows. 676 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Next Payload |C|F| RESERVED | Payload Length | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Diffie-Hellman Group Number | Fragment Identifier | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Fragment Index | Total Fragments | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Total KE Payload Data Length | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | | 688 ~ Fragmented KE Payload ~ 689 | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 When the flag F is set, this means the current KE payload is a 693 fragment of a larger KE payload. The Payload Length field denotes 694 the size of this payload fragment in octets--including the size of 695 the generic payload header. The two-octet RESERVED field 696 following Diffie-Hellman Group Number was to be used as a fragment 697 identifier to help assembly and disassembly of fragments. The 698 Fragment Index and Total Fragments fields are self-explanatory. 699 The Total KE Payload Data Length indicates the size of the 700 assembled KE payload data in octets. Finally, the actual fragment 701 is carried in Fragment KE Payload field. 703 We discarded this approach because we believe that the working 704 group may not be happy using the RESERVED field to change the 705 format of a packet and that implementers may not like the 706 complexity added from checking the fragmentation flag in each 707 received payload. More importantly, fragmenting the messages in 708 this way may leave the system to be more prone to denial of 709 service (DoS) attacks. By using IKE_AUX to transport the large 710 post-quantum key exchange payloads, there is no longer any issue 711 with fragmentation. 713 o Group sub-identifier 715 As discussed in Section 3.3, each group identifier is used to 716 distinguish a post-quantum algorithm. Further classification 717 could be made on a particular post-quantum algorithm by assigning 718 additional value alongside the group identifier. This sub- 719 identifier value may be used to assign different security 720 parameter sets to a given post-quantum algorithm. However, this 721 level of details does not fit the principles of the document where 722 it should deal with generic hybrid key exchange protocol, not a 723 specific ciphersuite. Furthermore, there are enough Diffie- 724 Hellman group identifiers should this be required in the future. 726 5. Security considerations 728 The key length of the Encryption Algorithm (Transform Type 1), the 729 Pseudorandom Function (Transform Type 2) and the Integrity Algorithm 730 (Transform Type 3), all have to be of sufficient length to prevent 731 attacks using Grover's algorithm [GROVER]. In order to use the 732 extension proposed in this document, the key lengths of these 733 transforms SHALL be at least 256 bits long in order to provide 734 sufficient resistance to quantum attacks. Accordingly the post- 735 quantum security level achieved is at least 128 bits. 737 SKEYSEED is calculated from shared, KEx, using an algorithm defined 738 in Transform Type 2. While a quantum attacker may learn the value of 739 KEx', if this value is obtained by means of a classical key exchange, 740 other KEx values generated by means of a quantum-resistant algorithm 741 ensure that the final SKEYSEED is not compromised. This assumes that 742 the algorithm defined in the Transform Type 2 is post-quantum. 744 The main focus of this document is to prevent a passive attacker 745 performing a "harvest and decrypt" attack. In other words, an 746 attacker that records messages exchanges today and proceeds to 747 decrypt them once he owns a quantum computer. This attack is 748 prevented due to the hybrid nature of the key exchange. Other 749 attacks involving an active attacker using a quantum-computer are not 750 completely solved by this document. This is for two reasons. 752 The first reason is because the authentication step remains 753 classical. In particular, the authenticity of the SAs established 754 under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA 755 algorithms. Whilst the pre-shared key option, provided the key is 756 long enough, is post-quantum, the other algorithms are not. 758 Moreover, in implementations where scalability is a requirement, the 759 pre-shared key method may not be suitable. Quantum-safe authenticity 760 may be provided by using a quantum-safe digital signature and several 761 quantum-safe digital signature methods are being explored by IETF. 762 For example, if the implementation is able to reliably track state, 763 the hash based method, XMSS has the status of an RFC, see [RFC8391]. 764 Currently, quantum-safe authentication methods are not specified in 765 this document, but are planned to be incorporated in due course. 767 It should be noted that the purpose of post-quantum algorithms is to 768 provide resistance to attacks mounted in the future. The current 769 threat is that encrypted sessions are subject to eavesdropping and 770 archived with decryption by quantum computers taking place at some 771 point in the future. Until quantum computers become available there 772 is no point in attacking the authenticity of a connection because 773 there are no possibilities for exploitation. These only occur at the 774 time of the connection, for example by mounting a MitM attack. 775 Consequently there is not such a pressing need for quantum-safe 776 authenticity. 778 This draft does not attempt to address key exchanges with KE payloads 779 longer than 64k; the current IKE payload format does not allow that 780 as a possibility. If such huge KE payloads are required, a work 781 around (such as making the KE payload a URL and a hash of the real 782 payload) would be needed. At the current time, it appears likely 783 that there will be plenty of key exchanges available that would not 784 require such a workaround. 786 6. References 788 [AH] Kent, S., "IP Authentication Header", RFC 4302, December 789 2005, . 791 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 792 RFC 4303, December 2005, 793 . 795 [GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for 796 Database Search", Proc. of the Twenty-Eighth Annual ACM 797 Symposium on the Theory of Computing (STOC 1996), 1996. 799 [I-D.ietf-ipsecme-qr-ikev2] 800 Fluhrer, S., McGrew, D., Kampanakis, P., and V. Smyslov, 801 "Postquantum Preshared Keys for IKEv2", draft-ietf- 802 ipsecme-qr-ikev2-03 (work in progress), June 2018. 804 [I-D.smyslov-ipsecme-ikev2-aux] 805 Smyslov, V., "Auxiliary Exchange in the IKEv2 Protocol", 806 draft-smyslov-ipsecme-ikev2-aux-00 (work in progress), 807 January 2018. 809 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 810 Requirement Levels", BCP 14, RFC 2119, 811 DOI 10.17487/RFC2119, March 1997, 812 . 814 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 815 Kivinen, "Internet Key Exchange Protocol Version 2 816 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 817 2014, . 819 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 820 (IKEv2) Message Fragmentation", RFC 7383, 821 DOI 10.17487/RFC7383, November 2014, 822 . 824 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 825 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 826 August 2017, . 828 [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. 829 Mohaisen, "XMSS: eXtended Merkle Signature Scheme", 830 RFC 8391, DOI 10.17487/RFC8391, May 2018, 831 . 833 Acknowledgements 835 The authors would like to thanks Frederic Detienne and Olivier 836 Pelerin for their comments and suggestions, including the idea to 837 negotiate the post-quantum algorithms using the existing KE payload. 839 Authors' Addresses 841 C. Tjhai 842 Post-Quantum 844 Email: cjt@post-quantum.com 846 M. Tomlinson 847 Post-Quantum 849 Email: mt@post-quantum.com 850 G. Bartlett 851 Cisco Systems 853 Email: grbartle@cisco.com 855 S. Fluhrer 856 Cisco Systems 858 Email: sfluhrer@cisco.com 860 D. Van Geest 861 ISARA Corporation 863 Email: daniel.vangeest@isara.com 865 Z. Zhang 866 Onboard Security 868 Email: zzhang@onboardsecurity.com 870 O. Garcia-Morchon 871 Philips 873 Email: oscar.garcia-morchon@philips.com