idnits 2.17.1 draft-tjhai-ipsecme-hybrid-qske-ikev2-01.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 == Line 323 has weird spacing: '...d using the k...' == Line 1346 has weird spacing: '...d using a...' == Line 1437 has weird spacing: '...ance to quant...' == 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). == 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: For implementations that mandate only the use of hybrid exchange, these MUST not revert to using the classical IKEv2 exchange. This should be a configurable parameter in implementations. -- The document date (January 15, 2018) is 2293 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 943 -- Looks like a reference, but probably isn't: '2' on line 943 == Missing Reference: 'N' is mentioned on line 943, but not defined == Unused Reference: 'ADPS' is defined on line 1497, but no explicit reference was found in the text == Unused Reference: 'IKEV2IANA' is defined on line 1521, but no explicit reference was found in the text == Unused Reference: 'LOGJAM' is defined on line 1526, but no explicit reference was found in the text ** Obsolete normative reference: RFC 8229 (Obsoleted by RFC 9329) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 3 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 19, 2018 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 January 15, 2018 16 Framework to Integrate Post-quantum Key Exchanges 17 into Internet Key Exchange Protocol Version 2 (IKEv2) 18 draft-tjhai-ipsecme-hybrid-qske-ikev2-01 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. This document also addresses the challenge of fragmentation 28 as a result of sending large post quantum key exchange data in the 29 first pair of message of the initial exchange phase. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 19, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3 67 1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . . 3 68 1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.4. Document organization . . . . . . . . . . . . . . . . . . 4 70 2. Design criteria . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. The Framework of Hybrid Post-quantum Key Exchange . . . . . . 6 72 3.1. Overall design . . . . . . . . . . . . . . . . . . . . . . 6 73 3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . . 7 74 3.2.1. First Protocol Round . . . . . . . . . . . . . . . . . 7 75 3.2.2. Second Protocol Round . . . . . . . . . . . . . . . . 10 76 3.2.3. Child SA Negotiation . . . . . . . . . . . . . . . . . 11 77 3.3. Computation of a Post-Quantum Shared Secret . . . . . . . 12 78 3.4. Post-Quantum Group Transform Type and Group Identifiers . 12 79 3.5. Hybrid Group Negotiation . . . . . . . . . . . . . . . . . 13 80 3.5.1. Protocol for the Initiator . . . . . . . . . . . . . . 14 81 3.5.2. Protocol from the Responder . . . . . . . . . . . . . . 17 82 3.6. Fragmentation Support . . . . . . . . . . . . . . . . . . 19 83 3.6.1. Fragmentation Problem Description . . . . . . . . . . 19 84 3.6.2. Fragmentation Solution . . . . . . . . . . . . . . . . 19 85 3.6.2.1. Fragmentation Pointer Payload . . . . . . . . . . 19 86 3.6.2.2. Fragmentation Body Payload . . . . . . . . . . . . 20 87 3.6.2.3. Fragmentation Semantics . . . . . . . . . . . . . 23 88 3.6.2.4. IKE AUTH Processing . . . . . . . . . . . . . . . 24 89 3.6.2.5. Design Rationale . . . . . . . . . . . . . . . . . 25 90 3.7. Protection against Downgrade Attacks . . . . . . . . . . . 25 91 4. Alternative Design . . . . . . . . . . . . . . . . . . . . . . 28 92 5. Security considerations . . . . . . . . . . . . . . . . . . . 31 93 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 94 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 34 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 97 1. Introduction 99 1.1. Problem Description 101 Internet Key Exchange Protocol (IKEv2) as specified in RFC 7296 102 [RFC7296] uses the Diffie-Hellman (DH) or Elliptic Curve Diffie- 103 Hellman (ECDH) algorithm to establish a shared secret between an 104 initiator and a responder. The security of the DH and ECDH 105 algorithms relies on the difficulty to solve a discrete logarithm 106 problem in multiplicative and elliptic curve groups respectively when 107 the order of the group parameter is large enough. While solving such 108 a problem remains difficult with current computing power, it is 109 believed that general purpose quantum computers will be able to solve 110 this problem, implying that the security of IKEv2 is compromised. 111 There are, however, a number of cryptosystems that are conjectured to 112 be resistant against quantum computer attack. This family of 113 cryptosystems are known as post-quantum cryptography (PQC). It is 114 sometime also referred to as quantum-safe cryptography (QSC) or 115 quantum-resistant cryptography (QRC). 117 1.2. Proposed Extension 119 This document describes a framework to integrate QSC for IKEv2, 120 whilst maintaining backwards compatibility, to exchange a shared 121 secret such that it has resistance to quantum computer attacks. Our 122 framework allows the negotiation of one or more QSC algorithm to 123 exchange data, in addition to the existing DH or ECDH key exchange 124 data. We believe that the feature of using more than one post 125 quantum algorithm is important as many of these algorithms are 126 relatively new and there may be a need to hedge the security risk 127 with multiple key exchange data from several distinct QSC algorithms. 129 The secrets established from each key exchange are combined in a way 130 such that should the post quantum secrets not be present, the derived 131 shared secret is equivalent to that of the standard IKEv2; on the 132 other hand, a post quantum shared secret is obtained if both 133 classical and post quantum key exchange data are present. This 134 framework also applies to key exchanges in IKE Security Associations 135 (SAs) for Encapsulating Security Payload (ESP) [ESP] or 136 Authentication Header (AH) [AH], i.e. Child SAs, in order to provide 137 a stronger guarantee of forward security. 139 One of the key challenges in this framework is fragmentation handling 140 during the first message pair of the initial exchange phase, i.e. 141 IKE_SA_INIT. Almost all of the known PQC algorithms to date have key 142 exchange data size that exceeds 1K octets. When transmitted 143 alongside other payloads, the total payload size could easily exceed 144 the common maximum transmission unit (MTU) size of 1500 octets, and 145 hence this may lead to IP level fragmentation. While IKEv2 has a 146 mechanism to handle fragmentation [RFC7383], it is applicable to 147 messages exchanged after IKE_SA_INIT. Of course, fragmentation will 148 not be an issue if messages are sent over TCP [RFC8229]; however, we 149 believe that a UDP-based solution will also be required. This 150 document describes a simple mechanism to fragment IKE_SA_INIT 151 messages, which also allows exchanges for payload larger than 65,535 152 octets. 154 Note that readers should consider the approach in this document as 155 providing a long term solution in upgrading the IKEv2 protocol to 156 support post quantum algorithms. A short term solution to make IKEv2 157 key exchange quantum secure is to use post quantum pre-shared keys as 158 discussed in [FMKS]. 160 1.3. Changes 162 Changes in this draft in each version iterations. 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, how keying materials are 179 derived and how downgrade attack is prevented. This section also 180 specifies we handle fragmentation in IKE_SA_INIT exchanges. A 181 number of alternative designs to Section 3, which we have considered 182 but not adopted, are discussed in Section 4. Lastly, Section 5 183 discusses security considerations. 185 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 186 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 187 document, are to be interpreted as described in RFC 2119 [RFC2119]. 189 2. Design criteria 191 The design of the proposed post-quantum IKEv2 is driven by the 192 following criteria: 194 1) Need for post-quantum cryptography in IPsec. Quantum computers 195 might become feasible in the next 5-10 years. If current 196 Internet communications are monitored and recorded today (D), 197 the communications could be decrypted as soon as a quantum- 198 computer is available (e.g., year Q) if key negotiation only 199 relies on non post-quantum primitives. This is a high threat 200 for any information that must remain confidential for a long 201 period of time T > Q-D. The need is obvious if we assume that Q 202 is 2040, D is 2020, and T is 30 years. Such a value of T is 203 typical in classified or healthcare data. 205 2) Hybrid. Currently, there does not exist a post-quantum key 206 exchange that is trusted at the level that ECDH is trusted 207 against conventional (non-quantum) adversaries. A hybrid 208 approach allows introducing promising post-quantum candidates 209 next to well-established primitives, since the overall security 210 is at least as strong as each individual primitive. 212 3) Focus on quantum-resistant confidentiality. A passive attacker 213 can eavesdrop IPsec communication today and decrypt it once a 214 quantum computer is available in the future. This is a very 215 serious attack for which we do not have a solution. An attacker 216 can only perform active attacks such as impersonation of the 217 communicating peers once a quantum computer is available, 218 sometime in the future. Thus, our design focuses on quantum- 219 resistant confidentiality due to the urgency of this problem. 220 This document does not address quantum-resistant authentication 221 since it is less urgent at this stage. 223 4) Limit amount of exchanged data. The protocol design should be 224 such that the amount of exchanged data, such as public-keys, is 225 kept as small as possible even if initiator and responder need 226 to agree on a hybrid group or multiple public-keys need to be 227 exchanged. 229 5) Future proof. Any cryptographic algorithm could be potentially 230 broken in the future by currently unknown or impractical 231 attacks: quantum computers are merely the most concrete example 232 of this. The design does not categorize algorithms as "post- 233 quantum" or "non post-quantum" and does not create assumptions 234 about the properties of the algorithms, meaning that if 235 algorithms with different properties become necessary in future, 236 this framework can be used unchanged to facilitate migration to 237 those algorithms. 239 6) Identification of hybrid algorithms. The usage of a hybrid 240 approach in which each hybrid combination of several classical 241 and post-quantum algorithms leads to a different group 242 identifier can lead to an exponential number of combinations. 243 Thus, the design should seek an approach in which a hybrid group 244 -- comprising multiple post-quantum algorithms -- can be 245 efficiently negotiated. 247 7) 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 8) 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 9) 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 10) 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 11) 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 12) 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 279 The proposed hybrid post-quantum IKEv2 protocol extends RFC7296 280 [RFC7296] by duplicating the initial exchange in [RFC7296]. In order 281 to minimize communication overhead, only the key shares that are 282 agreed to be used are actually exchanged. In order to achieve this, 283 the IKE_SA_INIT exchange now consists of two message exchange pairs. 284 The first pair of IKE_SA_INIT messages negotiates which classical 285 cryptographic algorithms are to be used, along with the supported PQC 286 algorithms by initiator and responder, and policies of the initiator 287 that specify its requirements on a hybrid group. The second 288 IKE_SA_INIT message pair, on the other hand, consists of each peer 289 sending the Diffie-Hellman public value along with the post-quantum 290 key-shares. Note that no Diffie-Hellman exchange or exchange of 291 post-quantum key-shares is performed in the first round of 292 IKE_SA_INIT exchange. Messages are described as message 1 for the 293 initiator's first message, message 2 for the responder's first 294 message, message 3 for the initiator's second message and message 4 295 for the responder's second message. 297 Initiator Responder 298 -------------------------------------------------------------- 299 <-- First round (hybrid group negotiation) --> 301 <-- Second round (hybrid quantum-safe key exchange) --> 303 This hybrid post-quantum IKEv2 key exchange can occur in IKE_SA_INIT 304 or CREATE_CHILD_SA message pair which contains various payloads for 305 negotiating cryptographic algorithms, exchanging nonces, and 306 performing a Diffie-Hellman shared secret exchange for an IKE SA or a 307 Child SA. These payloads are chained together forming a linked-list 308 and this flexible structure allows additional key exchange payloads 309 to be introduced. The additional key exchange uses algorithms that 310 are currently considered to be resistant to quantum computer attacks. 311 These algorithms are collectively referred to as post-quantum 312 algorithms in this document. 314 3.2. Overall Protocol 316 In the following we overview the two protocol rounds involved in the 317 hybrid post-quantum protocol. 319 3.2.1. First Protocol Round 321 In the first round, the IKE_SA_INIT request and response messages are 322 used to negotiate the hybrid group. The method to negotiate and 323 exchange post-quantum policies is achieved using the key exchange 324 payload (with a Diffie-Hellman Group Num of #TBA). The KE payload 325 with group number #TBA does not contain Diffie-Hellman or post- 326 quantum public values, but proposed post-quantum algorithms and the 327 policy for the post-quantum ciphers. 329 The initiator negotiates cryptographic suites as per RFC7296, the 330 only exception is, the Diffie-Hellman KE payload is not populated 331 with a keyshare, but rather the KE payload contains the proposed 332 post-quantum algorithms and policies. The Diffie-Hellman groups are 333 negotiated in the security association payload as per RFC7296 and the 334 public values sent in the next round of exchange. 336 When a responder that supports the hybrid exchange, receives an 337 IKE_SA_INIT message with a KE payload with group number #TBA, it 338 performs a lookup of the policies and algorithms contained within the 339 KE payload. Assuming that it supports one or more proposed post- 340 quantum algorithms, it then indicates these in the KE payload 341 response with group number #TBA. The responder also selects the 342 cryptographic suites, including the chosen Diffie-Hellman Group Num 343 in the security association payload as per RFC7296. In this exchange 344 the Diffie-Hellman public value is not sent in the KE payload. 346 The initiator can signal support of IKE_SA_INIT message fragmentation 347 by including a payload fragmentation Notify payload. The responder 348 can also include this Notify payload to indicate support of 349 IKE_SA_INIT message fragmentation. 351 The responder may choose to allocate state to the session, as the 352 initial message is used in authenticating the IKE SA messages. 353 Optionally, the responder may prefer not to allocate any state and 354 reply with a cookie instead. The cookie can provide two functions. 355 One being the standard RFC7296 behaviour. The other benefit of using 356 the cookie is to provide fast detection of a downgrade attack without 357 running into the risk of state exhaustion attacks. Whether or not 358 any states are allocated, the responder detects the post-quantum 359 cryptographic algorithms and policies that do not match and can then 360 abort the session prior to calculating the shared secrets. See 361 Section 3.7 for more information on cookie and downgrade attack 362 prevention. 364 Initiator Responder 365 -------------------------------------------------------------- 366 HDR, SAi1, KEi(#TBA), 367 Ni, [N(Pay Frag)] --> 369 <-- HDR, SAr1, KE(#TBA), 370 Nr, [N(Pay Frag),] 371 [N(COOKIE)] 373 By using the KE payload, peers that do not support the hybrid 374 exchange will reject the initial negotiation and assuming that a 375 Diffie-Hellman Group Num contained in the Diffie-Hellman Group 376 Transform IDs was acceptable, the peer will send an 377 INVALID_KE_PAYLOAD message to indicate its preferred Diffie-Hellman 378 group. Note that using the KE payload enables backward compatibility 379 with existing RFC7296 implementations. If this scenario occurs, the 380 initiator SHOULD retry the hybrid exchange. Dependent on policies, 381 the initiator may retry the exchange as per RFC7296, and if this 382 occurs then the N(PQ_ALGO_POLICIES) notify payload MUST be included 383 to prevent downgrade attacks. The N(PQ_ALGO_POLICIES) notify payload 384 contains the same post-quantum algorithms and policies that were sent 385 in the KE(#TBA) payload in the first round of IKE_SA_INIT request. 387 On receipt of the N(PQ_ALGO_POLICIES) payload, the responder MUST 388 validate these post-quantum algorithms and policies against its own 389 policies. This validation is required to ensure that the post- 390 quantum algorithms were not amended in the initial exchange, 391 resulting in a downgrade attack. 393 Should the proposed post-quantum algorithms not be acceptable to the 394 responder, the responder SHOULD indicate this by sending the 395 INVALID_KE_PAYLOAD Notify message to indicate its preferred Diffie- 396 Hellman group or the NO_PROPOSAL_CHOSEN Notify message if no Diffie- 397 Hellman group were acceptable. If the classical cryptographic suite 398 is acceptable, but the post-quantum algorithms are not, the responder 399 SHOULD indicate this by specifying the preferred Diffie-Hellman group 400 in the INVALID_KE_PAYLOAD notification. The initiator should then 401 revert to the classical IKEv2 exchange and include the 402 N(PQ_ALGO_POLICIES) payload to prevent downgrade attacks. Below is 403 an example that shows the proposed hybrid group is not supported by 404 the responder and that the responder prefers a Diffie-Hellman Group 405 19 (P-256), assuming that this group is in the list proposed 406 (although it is not preferred), in the previous message. 408 Initiator Responder 409 -------------------------------------------------------------- 410 HDR, SAi1, KEi(#TBA), 411 Ni, [N(Pay Frag)] --> 413 <-- HDR, N(INVALID_KE_PAYLOAD, 19) 414 HDR, SAi1, KEi(19), 415 N(PQ_ALGO_POLICIES), --> 416 Ni 418 For implementations that mandate only the use of hybrid exchange, 419 these MUST not revert to using the classical IKEv2 exchange. This 420 should be a configurable parameter in implementations. 422 As per RFC7296, should the responder not accept any of the 423 cryptographic suites that were sent in the security association 424 payload, a NO_PROPOSAL_CHOSEN message is responded, as depicted 425 below. 427 Initiator Responder 428 -------------------------------------------------------------- 429 HDR, SAi1, KEi(#TBA), 430 Ni, [N(Pay Frag)] --> 432 <-- HDR, N(NO_PROPOSAL_CHOSEN) 434 3.2.2. Second Protocol Round 436 In the second protocol round, the initiator sends again the 437 IKE_SA_INIT request. The main difference is that this message 438 includes the key-shares associated to each of the post-quantum 439 algorithms agreed in the previous round. Each key-share is 440 transported in a KE payload, and therefore there may exist multiple 441 KE payloads in the second round of the IKE_SA_INIT message. 442 Furthermore, these KE payloads may be fragmented if the key-shares 443 are large and both peers indicate the support of fragmentation. 445 In a general hybrid arrangement, the RFC7296 Diffie-Hellman public 446 value is sent in the first KE payload (denoted KEi1), with one or 447 more post-quantum key-share being sent in additional KE payloads 448 (denoted KEi2, KEi3, etc). However, this ordering is not mandatory. 450 If the responder sent a cookie in the first round of exchange, the 451 initiator MUST return this cookie. In addition to that, the 452 initiator MUST send the same post-quantum algorithms and policies 453 that were included in the KE payload of type #TBA sent in the first 454 round of the exchange, in a notify payload N(PQ_ALGO_POLICIES). The 455 responder MUST examine the post-quantum algorithms and policies, and 456 confirm that the presented KE payloads match those represented by the 457 cookie, see Section 3.7 for more information. Should an anomaly or a 458 mismatch be detected, the responder MUST abort the session. On the 459 other hand, if the validation passes, then the responder can proceed 460 to compute a shared secret as detailed in Section 3.3. 462 The responder also sends the IKE_SA-INIT response message including 463 its key-shares. As before, if agreed and if required, fragmentation 464 is handled as described in Section 3.6. Once the initiator has 465 received all key-shares from the responder, the initiator can compute 466 the same shared secret following the description in Section 3.3. 468 Below is an example message exchanged in the second round of 469 IKE_SA_INIT message. 471 Initiator Responder 472 -------------------------------------------------------------- 473 HDR, [N(COOKIE),] SAi1, 474 KEi1[, KEi2, ..., KEiX,] 475 Ni[, N(PQ_ALGO_POLICIES)] --> 477 <-- HDR, SAr1, KEr1[, KEr2, 478 ..., KErX,] Nr 480 For implementations that are to be used by peers that are pre- 481 configured with matching hybrid policies, resulting in the initial 482 exchange used to negotiate the post-quantum policies and algorithms 483 contained in the first round of exchanges being redundant, the 484 initiator can skip the first round of exchanges by sending the 485 IKE_SA_INIT containing the key-shares. However the initiator MUST be 486 sure that the responder will accept the presented key-shares. In this 487 instance the responder is open to abuse by fragmentation related 488 attacks and MUST revert to using the initial exchange, should it find 489 itself under any form of attack. 491 3.2.3. Child SA Negotiation 493 After the initial IKE SA is negotiated, either side may later 494 negotiate child SAs or rekey the IKE SA which may involve a fresh key 495 exchange. If a hybrid group is desired, then the initiator proposes 496 a Transform Type 4 (Diffie-Hellman) of (TBA); he includes the KE 497 payloads for the key exchange types that were negotiated for the 498 child SAs during the initial negotiation (see Section 3.5.1). The 499 responder replies with the corresponding KE payloads, and both use 500 the shared secrets to generate the child SA keying material (see 501 section 3.3). If hybrid groups were not initially negotiated as a 502 part of the initial key exchange, then child SAs MUST NOT propose a 503 hybrid group. 505 Specifically, the key exchange for creating a child SA using a hybrid 506 group is: 508 Initiator Responder 509 -------------------------------------------------------------- 510 HDR, SK{SA, Ni, KEi1, KEi2, 511 ..., KEiN, TSi, TSr} --> 512 <-- HDR, SK{SA, Nr, KEr1, KEr2, 513 ..., KErN, TSi, TSr} 515 where both SA payloads include a transform type 4 of (TBA), and the 516 KEi1, ..., KEiN, KEr1, ..., KErN are the KE types there were 517 initially negotiated. 519 3.3. Computation of a Post-Quantum Shared Secret 521 After the second protocol round detailed in Section 2.2., both 522 initiator and responder can compute the common shared secrets to 523 generate an SKEYSEED, from which all keying materials for protection 524 of the IKE SA are derived. The quantity SKEYSEED is computed as 525 follows: 527 SKEYSEED = prf(Ni | Nr, SS1 | SS2 | ...| SSN) 529 where prf, Ni and Nr are defined as in IKEv2 [RFC7296], SSi 530 represents the i-th shared secret computed from the i-th key exchange 531 algorithm contained in the hybrid group that was negotiated in the 532 protocol. Note that if at least one of these SSi is a classical 533 shared secret that is FIPS approved, then FIPS compliance design 534 criteria as outlined in Section 2 is achieved. The seven secrets 535 derived from SKEYSEED, namely SK_d, SK_ai, SK_ar, SK_ei, SK_er, 536 SK_pi, and SK_pr, are generated as defined in IKEv2 [RFC7296]. 538 For child SAs that are negotiated using a hybrid group, the keying 539 material is defined as: 541 KEYMAT = prf+(SK_d, SS1 | SS2 | ... | SSN | Ni | Nr) 543 where SSi represents the i-th shared secret computed from the i-th 544 key exchange algorithm that was performed during the negotiation of 545 the child SA. 547 When rekeying an IKE SA using a hybrid group, the new SKEYSEED is 548 computed as: 550 SKEYSEED = prf(SK_d (old), SS1 | SS2 | ... | SSN | Ni | Nr) 552 where SSi represents the i-th shared secret computed from the i-th 553 key exchange algorithm that was performed during the negotiation of 554 the new IKE SA. 556 3.4. Post-Quantum Group Transform Type and Group Identifiers 558 In generating keying material within IKEv2, both initiator and 559 responder negotiate up to four cryptographic algorithms in the SA 560 payload of an IKE_SA_INIT or a CREATE_CHILD_SA exchange. One of the 561 negotiated algorithms is a Diffie-Hellman algorithm, which is used 562 for key exchange. This negotiation is done using the Transform Type 563 4 (Diffie-Hellman Group) where each Diffie-Hellman group is assigned 564 a unique value. 566 In order to enable a post-quantum key exchange in IKEv2, the various 567 post-quantum algorithms MUST be negotiated between two IKEv2 peers. 568 To this end, this draft assigns new meanings to various transforms of 569 transform type 4 ("Diffie-Hellman group"). It assigns identifiers to 570 each of the various post-quantum algorithms (even though they are not 571 actually Diffie-Hellman groups, they are methods of performing key 572 exchange). In addition, it assigns two artificial values that are 573 not actually key exchange mechanisms, but are used as a part of the 574 negotiation. 576 We expect that in the future, IANA will assign permanent values to 577 these transforms. Until it does, we will use the following mappings 578 in the 'reserved for private use space': 580 0x9000 HYBRID - this signifies that we are negotiating a hybrid 581 group, the details are listed in the KE payload. 583 The following values are reserved for the below key exchanges: 0x9100 584 - 0xXXXX. The following abstract identifiers are used to illustrate 585 their usage in our framework. Actual identifiers will be maintained 586 by IANA and updated during the NIST standardization process. 588 Name Number Key exchange 589 -------------------------------------------------- 590 NIST_CANDIDATE_1 0x9100 The 1st candidate of 591 NIST PQC submission 592 NIST_CANDIDATE_2 0x9101 The 2nd candidate of 593 NIST PQC submission 595 Because we are using transforms in the private use space, both the 596 initiator and responder must include a vendor id with this payload: 598 d4 48 11 94 c0 c3 4c 9d d1 22 76 aa 9a 4e 80 d5 600 This payload is the MD5 hash of "IKEv2 Quantum Safe Key Exchange 601 v1"). If the other side does not include this vendor id, an 602 implementation MUST NOT process these private use transforms as 603 listed in this draft. 605 3.5. Hybrid Group Negotiation 607 Most post-quantum key agreement algorithms are relatively new, and 608 thus are not fully trusted. There are also many proposed algorithms, 609 with different trade-offs and relying on different hard problems. 610 The concern is that some of these hard problems may turn out to be 611 easier to solve than anticipated (and thus the key agreement 612 algorithm not be as secure as expected). 614 A hybrid solution allows us to deal with this uncertainty by 615 combining classical key exchanges with post-quantum key agreements. 616 However, there are many post-quantum proposals that when combined can 617 lead to many potential hybrid groups. Furthermore, different 618 organizations might have different requirements when using a hybrid 619 group. For instance, the type of underlying problem that is trusted, 620 the minimum number of algorithms that should be used in a hybrid 621 group, or the security strength of each of the algorithms. For these 622 reasons, hybrid groups might lead to many potential combinations 623 difficult to define, maintain and standardize. This motivates our 624 hybrid group negation protocol. 626 Our hybrid group negotiation protocol allows the initiator and 627 responder to agree on a common hybrid group based on their respective 628 policies. The protocol categorizes each type of key exchange into a 629 type T, which is based on the type of hard problem it relies upon. 630 We use the aforementioned abstract identifiers to illustrate the 631 idea. 633 Given this categorization of the key agreement protocols, initiator 634 and responder have security policies that define the minimum number 635 of post-quantum algorithms that they require in a hybrid group and 636 also the types of key agreement protocols that they support (and 637 therefore, trust). The initiator and responder can then engage in a 638 simple protocol that allows them to compute a common hybrid group 639 fulfilling their policies. The protocol for the initiator and 640 responder is described below. 642 Note that it would be possible for the responder to search for a 643 mutually acceptable combination without specifying the key exchange 644 types, however the algorithm to search for such a combination would 645 be considerably more complex. This design assumes that the security 646 policies of the initiator and the responder will rely on key 647 exchanges based upon distinct types of hard problems, and hence the 648 additional complexity of the more general algorithm is not warranted. 650 3.5.1. Protocol for the Initiator 652 To define the protocol, we first define a "DH_Group_List", this is a 653 list of groups of a specific type; it has the format: 655 1 2 3 656 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 657 +---------------------------------------------------------------+ 658 | T | N | 659 +---------------------------------------------------------------+ 660 | PQC_ID_1 | PQC_ID_2 | 661 ~ ... ~ ... ~ 662 | PQC_ID_N | 0 | 663 +---------------------------------------------------------------+ 665 where 666 o T is the type of the groups that are in this list, with this 667 proposed encoding: 669 - 0x0001 is classical 670 - 0x0002 is lattice 671 - 0x0003 is code-based 672 - 0x0004 is isogeny-based 673 - 0x0005 is symmetric (preshared key) 675 o N is the number of groups that make up the list. The semantics 676 of this proposal is that the initiator is proposing M different 677 types of groups; any selection of one group from K different 678 types will be acceptable. 680 o PQC_ID_1, PQC_ID_2, PQC_ID_N, such as NIST_CANDIDATE_1, is the 681 identifier for the PQC algorithm to be used for negotiation, in 682 order of preference. 684 o 0 is padding, present if N is odd. 686 The semantics of this list is that these are the groups of PQC 687 algorithms of type T that are acceptable to the initiator. 689 We now define a "DH_Group_Policy"; this is a list of group types that 690 are negotiated together. It has the format: 692 1 2 3 693 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 694 +---------------------------------------------------------------+ 695 | K | M | 696 +---------------------------------------------------------------+ 697 | DH Group List 1 | 698 +---------------------------------------------------------------+ 699 | DH Group List 2 | 700 ~ ... ~ 701 | DH Group List M | 702 +---------------------------------------------------------------+ 704 where: 705 o K is the minimum number of group lists that must be satisfied; 706 o M is the number of group lists; 707 o DH_Group_LIST_1, ..., DH_Group_List_M are the lists of 708 different types of DH groups, in order of preference. 710 The semantics of this proposal is that the initiator is proposing M 711 different types of groups; any selection of one group from K 712 different types will be acceptable. 714 For example, suppose our policy is "we must agree on at least 2 715 groups from the list (P-256, P-384), (NIST_CANDIDATE_1, 716 NIST_CANDIDATE_2; both of type lattice) and (NIST_CANDIDATE_1 of type 717 isogeny), where NIST_CANDIDATE_1 and NIST_CANDIDATE_2 of type lattice 718 are assigned group numbers 40 and 41 respectively, and 719 NIST_CANDIDATE_1 of type isogeny is assigned group number 60"; we 720 have the following list (in hexadecimal) 722 0002 0003 0001 0002 0013 0014 0002 723 0002 0028 0029 0004 0001 003c 0000 725 which is parsed as 726 0002 K = 2 727 0003 We have 3 group lists 728 0001 0002 First list is of type classical, and consists of two 729 groups 730 0013 0014 Group 19 (P-256) and group 20 (P-384) 731 0002 0002 Second list is of type lattice, and consists of two 732 groups 733 0028 0029 Group 40 (NIST_CANDIDATE_1 of type lattice) and group 734 41 (NIST_CANDIDATE_2 of type lattice) 735 0004 0001 Third list is of type isogeny, and consists of one 736 group 737 003c Group 60 (NIST_CANDIDATE_1 of type isogeny) 738 0000 Zero-pad 740 We can now give the format that the initiator sends to the responder 741 in the KEi payload. The initiator sends its group policy in one of 742 the following two formats: 744 1 2 3 745 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 746 +-------------------------------------------------------------+ 747 | DH_Group_Policy | 748 +-------------------------------------------------------------+ 750 1 2 3 751 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 752 +-------------------------------------------------------------+ 753 | DH_Group_Policy for initial IKE exchange | 754 +-------------------------------------------------------------+ 755 | DH_Group_Policy for child SAs | 756 +-------------------------------------------------------------+ 758 If the initiator uses the first format, then the same DH policy will 759 be negotiated for both the initial IKE exchange, as well as any child 760 SA exchanges. If the initiator uses the second format, then the 761 first policy listed will be used for the initial IKE exchange; the 762 second policy listed will be used for any child SA negotiations. 764 3.5.2. Protocol from the Responder 766 If the responder finds a combination of groups that are mutually 767 acceptable, then it responds with the KEr payload in one of the 768 following two formats: 770 1 2 3 771 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 772 +---------------------------------------------------------------+ 773 | 0 | N | 774 +---------------------------------------------------------------+ 775 | DH_1 | DH_2 | 776 ~ ... ~ ... ~ 777 | DH_N | 0 | 778 +---------------------------------------------------------------+ 779 1 2 3 780 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 781 +---------------------------------------------------------------+ 782 | 0 | N_Initial | 783 +---------------------------------------------------------------+ 784 | DH_1 | DH_2 | 785 ~ ... ~ ... ~ 786 | DH_N_Initial | 0 | 787 +---------------------------------------------------------------+ 788 | 0 | N_Child | 789 +---------------------------------------------------------------+ 790 | DH_1 | DH_2 | 791 ~ ... ~ ... ~ 792 | DH_N_Child | 0 | 793 +---------------------------------------------------------------+ 795 where 796 o 0 is a fixed 0000 pattern; 797 o N, N_Initial, N_Child is the number of groups that are 798 selected; 799 o DH_1, DH_2, ..., DH_N are the selected groups. 801 If the second format is selected, then the groups used for the 802 initial IKE SA and the groups used for child SAs are listed 803 separately. 805 We assume that the responder has a similar local policy governing 806 what it is willing to negotiate. To search the initiator's vector to 807 find such a mutually acceptable combination, the responder can run 808 the following algorithm. 810 1. Set list of accepted DH groups to empty 811 2. Set K to the maximum of (minimum number of group lists 812 specified by the initiator, minimum number of group lists 813 acceptable according to the responder policy). 814 3. For every DH_Group_list in the initiator proposal 815 a. Set T to the DH_Group_list type 816 b. Find for the responder DH_Group_list of type T 817 c. If the responder has such a group list 818 * Scan for a DH element that the two lists have in common 819 - If there is such a group 820 o Append that to the "list of accepted DH groups" 821 o (Optional) if the list is at least K elements 822 long, stop searching (and accept) 823 4. If the list of accepted DH groups is at least K elements long, 824 accept. Otherwise, fail. 826 3.6. Fragmentation Support 828 3.6.1. Fragmentation Problem Description 830 When the IKE message size exceeds the path MTU, the IKE messages are 831 fragmented at the IP level. IP fragments can be blocked or dropped 832 by network devices such as NAT/PAT gateways, firewalls, proxies and 833 load balancers. If IKE messages are dropped, the IKE and subsequent 834 IPsec Security Association (SA) will fail to be established. In many 835 instances the quantum safe key exchange data could be too large to 836 send in a single IKE message as the path MTU between hosts is set 837 below the total size of the IKE message. As this draft defines 838 multiple key exchanges in a single IKE message, there is a high 839 chance that IP fragmentation will occur in IKE_SA_INIT messages. 841 The maximum length of an IKE payload is 65,535 octets. It is 842 anticipated that some post quantum algorithms will require a key 843 exchange payload size that is greater than 65,535 octets. 844 Furthermore, CERT payloads in IKE_AUTH messages are expected to 845 exceed 65,565 octets when sending certificates containing post 846 quantum public keys and signatures. 848 To overcome these limitations we present a method to split any 849 payload into multiple fragments and optionally send these fragments 850 in separate IKE_SA_INIT messages. 852 3.6.2. Fragmentation Solution 854 To enable fragmentation of IKE payloads, we introduce new 855 FRAG_POINTER and FRAG_BODY payloads. Further, we introduce a method 856 of sending payload fragments in multiple IKE_SA_INIT messages as well 857 as a method of sending payload fragments in encrypted IKE messages 858 which then may or may not be fragmented using RFC 7383's IKEv2 859 message fragmentation. 861 3.6.2.1. Fragmentation Pointer Payload 863 In place of any payload within an IKE packet, the sender may replace 864 it with a FRAG_POINTER payload; this FRAG_POINTER type (rather than 865 the original payload type) will appear in the next payload field of 866 the previous payload (or IKE header). This payload has the following 867 format 868 1 2 3 869 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 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Next Payload |C| RESERVED | Payload Length | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Payload Type | Fragment Identifier | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Total Payload Length | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Fragment Length | RESERVED | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 where: 881 o C is the Critical flag for the original payload. 882 o Payload Type is the payload type of the original payload; e.g. if 883 this payload is a KE payload, this will be the value 34. 884 o Fragment Identifier is a 24 bit value that the sender does not 885 reuse often, that is, within the timeout period of this IKE 886 packet. It is intended to be used to allow the receiver to 887 correlate the fragments (contained in other packets) to the 888 payload within the original IKE packet. 889 o Total Payload Length is the length of the original payload. Note 890 that this draft allows the transmission of payloads greater than 891 64k, if necessary. 892 o Fragment Length is the amount of data contained within each 893 fragment (except for the last fragment, which may be smaller). 894 o RESERVED will be an all-0's field. 896 3.6.2.2. Fragmentation Body Payload 898 The sender can split the contents of any payload across one or more 899 FRAG_BODY payloads. This payload has the format: 901 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Next Payload |C| RESERVED | Payload Length | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Payload Type | Fragment Identifier | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Total Payload Length | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Fragment Length | Fragment Number | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | | 913 ~ Payload Data ~ 914 | | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 where: 918 o Next Payload is the identifier for the payload type of the next 919 payload in the message. There may be additional restrictions on 920 the value of Next Payload during the fragmentation of an 921 IKE_SA_INIT message, see Section 3.6.2.3 below. 922 o Payload Type, Fragment Identifier, Total Payload Length, Fragment 923 Length are the same as the corresponding fields in the 924 FRAG_POINTER payload. Take careful note, like the other fields 925 described here the Fragment Length field will be identical across 926 all fragments. Thus, if this is the last fragment, Fragment 927 Length could be longer than the size of the Payload Data field. 928 o Fragment Number is the current fragment message number, starting 929 from 1. This field MUST NOT be 0. 930 o Payload Data is the contents of the payload for this fragment. 931 For any fragment other than the last, this will be 'Fragment 932 Length' bytes long; for the last one, it will be (Total Payload 933 Length-1) % Fragment Length + 1 bytes long. Note that the Generic 934 Payload Header from the original payload MUST NOT be included in 935 the Payload Data of the fragment, but any additional payload 936 header fields after the Generic Payload Header MUST be included. 937 The Generic Payload Header cannot be included because it includes 938 the 16-bit Payload Length field, however the length of a 939 fragmented payload may require more than 16 bits to be stored. 941 The logical contents of the reassembled payload will be 943 Payload Data[1] | PayloadData[2] | ... | PayloadData[N] 945 where N = Total Payload Length / Fragment Length (rounded up). 947 As an example, the following KE payload could be fragmented into a 948 FRAG_POINTER and two FRAG_BODY payloads with Fragment Length of 1000 949 as follows: 950 1 2 3 951 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 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Next Payload |C| RESERVED | Payload Length | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Diffie-Hellman Group Num | RESERVED | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | | 958 ~ Key Exchange Data (1500 bytes) ~ 959 | | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 Figure 1: Key Exchange Payload to be Fragmented 962 1 2 3 963 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 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Next Payload |C| RESERVED | Payload Length | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | KE | Fragment Identifier | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Total Payload Length (1504) | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Fragment Length (1000) | RESERVED | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 Figure 2: Example FRAG_POINTER Payload for KE Payload 975 1 2 3 976 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 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Next Payload |C| RESERVED | Payload Length | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | KE | Fragment Identifier | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Total Payload Length (1504) | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Fragment Length (1000) | Fragment Number (1) | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Diffie-Hellman Group Num * | RESERVED | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | | 989 ~ Key Exchange Data[0..995] (996 bytes) ~ 990 | | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 Figure 3: Example FRAG_BODY Payload 1 for KE Payload 993 (*) Corresponds to the payload-specific header fields beginning 994 immediately after the Generic Payload Header of the Key Exchange 995 payload being fragmented. This is the beginning of the Payload 996 Data field in the FRAG_BODY payload. 998 1 2 3 999 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 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | Next Payload |C| RESERVED | Payload Length | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | KE | Fragment Identifier | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Total Payload Length (1504) | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Fragment Length (1000) | Fragment Number (2) | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | | 1010 ~ Key Exchange Data[996..1499] (504 bytes) ~ 1011 | | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 Figure 4: Example FRAG_BODY Payload 2 for KE Payload 1015 3.6.2.3. Fragmentation Semantics 1017 If the receiver supports this fragmentation extension, the sender may 1018 fragment any payload by replacing the payload with a FRAG_POINTER 1019 payload and one of more FRAG_BODY payloads. If IP fragmentation is 1020 not a concern (e.g. when IKEv2 fragmentation is achieved using 1021 encrypted fragment payloads, or it's known that IP fragmentation of 1022 IKE_SA_INIT won't be an issue) then the corresponding FRAG_BODY 1023 payloads MUST appear anywhere after the FRAG_POINTER in an IKE 1024 message. 1026 An IKE_SA_INIT message may be fragmented across multiple IKE messages 1027 using this payload fragmentation. In this case the sender first 1028 sends an IKE_SA_INIT message containing the FRAG_POINTER payloads and 1029 any unfragmented payloads. Then it sends one IKE_SA_INIT message per 1030 FRAG_BODY payload generated from the original IKE_SA_INIT message. 1031 Each IKE_SA_INIT message must be sent with a Message ID of 0. Each 1032 IKE_SA_INIT message subsequent to the first one MUST contain one 1033 FRAG_BODY payload, MAY contain a COOKIE notification and SHOULD NOT 1034 contain any other payloads. Since FRAG_POINTER support is negotiated 1035 in an initial IKE_SA_INIT round-trip which didn't generate any shared 1036 keys, the responder had the opportunity to send a COOKIE notify 1037 payload back to the initiator. This COOKIE can be used by the 1038 responder as a denial-of-service prevention measure. If the sender 1039 received a COOKIE notification payload in the initial exchange, it 1040 MUST include the COOKIE notify payload in each fragmented IKE_SA_INIT 1041 message that it sends. This allows the receiver to reject any 1042 IKE_SA_INIT messages without a COOKIE or with an unrecognized COOKIE, 1043 thus mitigating a DoS attack where an attacker sends malformed 1044 IKE_SA_INIT messages containing a FRAG_BODY payload which the 1045 receiver would enqueue, filling up its receiving buffers. Note, this 1046 does not prevent an attack where the attacker listens in on messages 1047 to determine a valid COOKIE and emits malformed IKE_SA_INIT messages 1048 with that cookie, or where it sends a valid initial round IKE_SA_INIT 1049 message to received a valid cookie and then emit malformed messages 1050 using that cookie. 1052 When the receiver receives an IKE payload with one or more 1053 FRAG_POINTER payloads, it waits until it processes all the 1054 corresponding FRAG_BODY payloads to transform the payloads into the 1055 original unfragmented payload which it processes as normal. If the 1056 IKE message was not a fragmented IKE_SA_INIT message, all 1057 corresponding FRAG_BODY payloads will be contained in the IKE 1058 message, if they are not the receiver MUST reject the IKE message. 1060 When the receiver receives an IKE_SA_INIT message, is may have to 1061 process several IKE_SA_INIT messages to reconstruct the original 1062 unfragmented message. If it receives the initial message containing 1063 the FRAG_POINTER payloads, it enqueues that message and awaits the 1064 corresponding IKE_SA_INIT messages containing the FRAG_POINTER 1065 payloads needed to reconstruct the original message. In addition, if 1066 it receives a FRAG_BODY message without receiving a corresponding 1067 FRAG_POINTER payload first, it may enqueue that payload. 1069 The receiver may vet the declared payload length, and reject it if it 1070 decides that the length is too long. 1072 Also note that we allow the FRAG_BODY payload to consist of the 1073 entire payload; this can happen if (for example) the MTU size is 1074 1500, and we want to transmit a 1300 byte KE payload, in addition to 1075 400 bytes of other IKE data. 1077 Once all the FRAG_BODY payloads have been received and reassembled, 1078 the IKE receiver may commence parsing the IKE packet. This proceeds 1079 as normal, except that when it sees a payload of type FRAG_POINTER, 1080 it looks into the FRAG_POINTER payload to see the actual payload type 1081 and length, and refers to the reassembly buffer for the actual 1082 payload data. 1084 Note about the criticality field; a FRAG_POINTER field may be marked 1085 as noncritical, which means that the IKE parser may ignore it if it 1086 does not understand the payload type within the FRAG_POINTER payload. 1087 However, even if it does that, it MUST still reassemble all the 1088 FRAG_BODY payloads (because of the IKE AUTH processing depends on 1089 them). 1091 3.6.2.4. IKE AUTH Processing 1093 When generating the IKE AUTH payload, the reassembled texts contained 1094 within the FRAG_BODY payloads is logically appended to the IKE 1095 message (and before the nonce). Specifically, we modify how 1096 InitiatorSignedOctets and ResponderSignedOctets are computed as 1097 follows: 1099 InitiatorSignedOctets = RealMessage1 | PayloadData1 | 1100 PayloadData2 | ... | PayloadDataN | 1101 NonceRData | MACedIDForI 1103 ResponderSignedOctets = RealMessage2 | PayloadData1 | 1104 PayloadData2 | ... | PayloadDataN | 1105 NonceIData | MACedIDForR 1107 where PayloadData1, ..., PayloadDataN are the fields from the 1108 FRAG_BODY payloads associated with the IKE message being 1109 authenticated, in the same order that the corresponding FRAG_POINTERS 1110 appear in, and for payloads from the same FRAG_POINTER, in increasing 1111 FRAGMENT_NUMBER order. 1113 3.6.2.5. Design Rationale 1115 The contents of the FRAG_POINTER/FRAG_BODY payloads were designed to 1116 make it easy to reassemble. The initial segments of the payloads 1117 were intentionally kept identical (to simply the processing if the 1118 FRAG_BODY arrived first); the receiver always knows how long the 1119 payload will be (allowing the allocation of buffers, if required); 1120 the receiver always knows the location in the payload data of each 1121 fragment (and so is able to save the data immediately into the 1122 buffer), and the receiver can compute the number of fragments up 1123 front (and hence can easily tell when all fragments have been 1124 received). 1126 The method of performing IKE AUTH processing was also designed to 1127 make it easy to implement; that PayloadData1 | PayloadData2 | ... | 1128 PayloadDataN is just the reassembled payloads concatenated together. 1130 3.7. Protection against Downgrade Attacks 1132 In RFC7296, man-in-the-middle (MitM) downgrade attack is prevented by 1133 always resending the full set of group proposal in subsequent 1134 IKE_SA_INIT messages if the responder chooses a different Diffie- 1135 Hellman group from the one in the initial IKE_SA_INIT message. The 1136 two-round nature of the protocol in this document presents some 1137 challenges in terms of downgrade attack protection. However, the 1138 general idea is the same as the one in RFC7296, in that the responder 1139 must have sufficient information to verify that the downgrade is a 1140 genuine one, rather than one instigated by a malicious attacker. 1141 Consider the following example: an initiator proposes to use a hybrid 1142 key exchange, and for backward compatibility also purposes a Diffie- 1143 Hellman group 19 (P-256 elliptic curve) through SAi payload, in the 1144 first round of the exchange. The initiator may receive an 1145 INVALID_KE_PAYLOAD notification response. This could be a genuine 1146 response from a responder that does not understand or support the 1147 selected hybrid key exchange, or it could also be a malicious 1148 downgrade response from an MitM attacker. The initiator, on the 1149 second round of the exchange, MUST send the same cipher proposals and 1150 policies as in the first exchange round to indicate that the 1151 initiator would have preferred to use the hybrid key exchange. The 1152 responder MUST check that the chosen proposal is indeed not caused by 1153 a downgrade attack. If the check fails, it indicates a potential 1154 downgrade attack and the connection SHALL be dropped immediately. 1156 In order to check the proposals and policies, the responder may 1157 choose to maintain states between IKE_SA_INIT rounds. However, this 1158 increases the risk of state exhaustion attack. Of course, the 1159 responder may decide not to allocate any states and rely on the 1160 authentication in IKE_AUTH for any tampering of the exchange. 1161 Unfortunately, this option does not offer the benefit of an early 1162 downgrade attack detection; the responder will have to spend 1163 resources computing entities such as shared secrets and 1164 authentication code before knowing whether or not there is a 1165 downgrade attack. Such a benefit may be obtained by encoding some 1166 information into a cookie (Section 2.6. RFC7296). 1168 Whilst this document does not mandate how information should be 1169 encoded to form the cookie, it could be efficiently done as follows 1171 Cookie = | Hash(KEi(#TBA) | ) 1173 where KEi(#TBA) is the KE payload in the first round of IKE_SA_INIT 1174 exchange, is a randomly entity generated by the responder 1175 which SHOULD be changed periodically as suggested in RFC7296, and the 1176 entity should be updated whenever is 1177 changed. In this scenario, the responder calculates a cookie value 1178 from the first round of the IKE_SA_INIT request message and sends it 1179 to the initiator as part of the first round IKE_SA_INIT response 1180 message. The initiator echoes back the cookie and a 1181 N(PQ_ALGO_POLICIES) notify payload along with other IKE_SA_INIT 1182 attributes. When the responder receives the second round of the 1183 IKE_SA_INIT message, it recalculates the cookie value and checks 1184 whether or not this value is the same as the one in the previous 1185 round of the exchange, which is available from N(PQ_ALGO_POLICIES). 1186 If they mismatch, it indicates an attempt to force a downgrade attack 1187 and therefore the connection SHALL be terminated. As before, any 1188 attempts of the attacker to modify the packets so that cookie 1189 validation passes will be detectable in IKE_AUTH stage. 1191 In the event of the value goes out-of-sync, as suggested in 1192 RFC7296, the responder MAY reject the request by responding with a 1193 new cookie, or it MAY keep using the old value of for a 1194 short time and accept cookies computed from either one. 1196 The complete two-round IKE_SA_INIT message exchange flow with cookie 1197 is shown below. In this particular example, the responder 1198 understands and accepts the hybrid key exchange proposed in the first 1199 IKE_SA_INIT round. 1201 Initiator Responder 1202 -------------------------------------------------------------- 1203 HDR, SAi1, KEi(#TBA), 1204 Ni, [N(Pay Frag)] --> 1205 <-- HDR, SAr1, KE(#TBA), 1206 Nr, N(COOKIE), 1207 [N(Pay Frag),] 1209 HDR, N(COOKIE), SAi1, 1210 KEi1[, KEi2, ..., KEiX,] 1211 Ni, N(PQ_ALGO_POLICIES) --> 1212 <-- HDR, SAr1, KEr1[, KEr2, 1213 ..., KErX,] Nr 1215 The following shows the flow whereby the responder does not support 1216 the proposed hybrid key exchange and proposes to switch to classical 1217 Diffie-Hellman key exchange of type P-256. Because the responder 1218 does not keep any states, it relies on the cookie and 1219 N(PQ_ALGO_POLICIES) to detect that it is a genuine downgrade. 1221 Initiator Responder 1222 -------------------------------------------------------------- 1223 HDR, SAi1, KEi(#TBA), 1224 Ni, [N(Pay Frag)] --> 1225 <-- HDR, N(INVALID_KE_PAYLOAD, 19), 1226 N(COOKIE) 1228 HDR, N(COOKIE), SAi1, 1229 KEi(19), Ni, 1230 N(PQ_ALGO_POLICIES) --> 1231 <-- HDR, SAr1, KEr(19), Nr 1233 The cookie does not protect against an adversary that amends the 1234 KE(#TBA) payload in the first IKE_SA_INIT request round and also then 1235 amends the N(PQ_ALGO_POLICIES) payload in the second IKE_SA_INIT 1236 request round to create a match. In this instance, IKE_AUTH 1237 authentication SHALL fail due to the InitiatorSignedOctets being 1238 inconsistent between both peers. 1240 The decision to use a cookie or allocate state SHOULD be a decision 1241 taken by the responder. This should be a configurable value, and/or 1242 activated when a certain threshold of half open connections is 1243 reached. The cookie is sent in addition to the other attributes 1244 contained in first round of IKE_SA_INIT response. 1246 The cookie does not mitigate an attack whereby an adversary cause the 1247 responder to perform many lookups for the post-quantum algorithms and 1248 policies, resulting in a denial-of-service (DoS) condition. In order 1249 to mitigate this type of attack, the RFC7296 cookie mechanism or a 1250 puzzle-solving mechanism as described in RFC8019 SHOULD be used. A 1251 responder MAY decide to combine DoS and downgrade prevention cookies, 1252 in which case, the combined cookie may be encoded as follows 1254 Cookie = | Hash(Ni | IPi | SPIi | 1255 KEi(#TBA) | ) 1257 where Ni, IPi and SPIi are as described in RFC7296. 1259 4. Alternative Design 1261 This section gives an overview on a number of alternative approaches 1262 that we have considered, but later discarded. These approaches are: 1264 o Sending post-quantum proposals and policies in KE payload only 1266 With the objective of not introducing unnecessary notify payloads, 1267 we considered communicating the hybrid post-quantum proposal in 1268 the KE payload during the first pass of the protocol exchange. 1269 Unfortunately, this design is susceptible to the following 1270 downgrade attack. Consider the scenario where there is an MitM 1271 attacker sitting between an initiator and a responder. The 1272 initiator proposes, through SAi payload, to use a hybrid post- 1273 quantum group and as a backup a Diffie-Hellman group, and through 1274 KEi payload, the initiator proposes a list of hybrid post-quantum 1275 proposals and policies. The MitM attacker intercepts this traffic 1276 and replies with N(INVALID_KE_PAYLOAD) suggesting to downgrade to 1277 the backup Diffie-Hellman group instead. The initiator then 1278 resends the same SAi payload and the KEi payload containing the 1279 public value of the backup Diffie-Hellman group. Note that the 1280 attacker may forward the second IKE_SA_INIT message only to the 1281 responder, and therefore at this point in time, the responder will 1282 not have the information that the initiator prefers the hybrid 1283 group. Of course, it is possible for the responder to have a 1284 policy to reject an IKE_SA_INIT message that (a) offers a hybrid 1285 group but not offering the corresponding public value in the KEi 1286 payload; and (b) the responder has not specifically acknowledged 1287 that it does not supported the requested hybrid group. However, 1288 the checking of this policy introduces unnecessary protocol 1289 complexity. Therefore, in order to fully prevent any downgrade 1290 attacks, using KE payload alone is not sufficient and that the 1291 initiator MUST always indicate its preferred post-quantum 1292 proposals and policies in a notify payload in the subsequent 1293 IKE_SA_INIT messages following a N(INVALID_KE_PAYLOAD) response. 1295 o New payload types to negotiate hybrid proposal and to carry post- 1296 quantum public values 1298 Semantically, it makes sense to use a new payload type, which 1299 mimics the SA payload, to carry a hybrid proposal. Likewise, 1300 another new payload type that mimics the KE payload, could be used 1301 to transport hybrid public value. Although, in theory a new 1302 payload type could be made backwards compatible by not setting its 1303 critical flag as per Section 2.5 of RFC7296, we believe that it 1304 may not be that simple in practice. Since the original release of 1305 IKEv2 in RFC4306, no new payload type has ever been proposed and 1306 therefore, this creates a potential risk of having a backward 1307 compatibility issue from non-conforming RFC IKEv2 implementations. 1308 Since we could not see any other compelling advantages apart from 1309 a semantic one, we use the existing KE and notify payloads 1310 instead. In fact, as described above, we use the KE payload in 1311 the first IKE_SA_INIT request round and the notify payload to 1312 carry the post-quantum proposals and policies. We use one or more 1313 of the existing KE payloads to carry the hybrid public values. 1315 o Hybrid public value payload 1317 One way to transport the negotiated hybrid public payload, which 1318 contains one classical Diffie-Hellman public value and one or more 1319 post-quantum public values, is to bundle these into a single KE 1320 payload. Alternatively, these could also be transported in a 1321 single new hybrid public value payload, but following the same 1322 reasoning as above, this may not be a good idea from a backward 1323 compatibility perspective. Using a single KE payload would 1324 require an encoding or formatting to be defined so that both peers 1325 are able to compose and extract the individual public values. 1326 However, we believe that it is cleaner to send the hybrid public 1327 values in multiple KE payloads--one for each group or algorithm. 1328 Furthermore, at this point in the protocol exchange, both peers 1329 should have indicated support of handling multiple KE payloads. 1331 o Fragmentation 1333 Handling of large IKE_SA_INIT messages has been one of the most 1334 challenging tasks. A number of approaches have been considered 1335 and the two prominent ones that we have discarded are outlined as 1336 follows. 1338 The first approach was to treat the entire IKE_SA_INIT message as 1339 a stream of bytes, which we then split it into a number of 1340 fragments, each of which is wrapped onto a payload that would fit 1341 into the size of the network MTU. The payload that wraps each 1342 fragment is a new payload type and it was envisaged that this new 1343 payload type will not cause a backward compatibility issue because 1344 at this stage of the protocol, both peers should have indicated 1345 support of fragmentation in the first pass of the IKE_SA_INIT 1346 exchange. The negotiation of fragmentation is performed using a 1347 notify payload, which also defines supporting parameters such as 1348 the size of fragment in octets and the fragment identifier. The 1349 new payload that wraps each fragment of the messages in this 1350 exchange is assigned the same fragment identifier. Furthermore, it 1351 also has other parameters such as a fragment index and total 1352 number of fragments. We decided to discard this approach due to 1353 its blanket approach to fragmentation. In cases where only a few 1354 payloads need to be fragmented, we felt that this approach is 1355 overly complicated. 1357 Another idea that was discarded was fragmenting an individual 1358 payload without introducing a new payload type. The idea was to 1359 use the 9-th bit (the bit after the critical flag in the RESERVED 1360 field) in the generic payload header as a flag to mark that this 1361 payload is fragmented. As an example, if a KE payload is to be 1362 fragmented, it may look as follows. 1364 1 2 3 1365 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 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Next Payload |C|F| RESERVED | Payload Length | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | Diffie-Hellman Group Number | Fragment Identifier | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Fragment Index | Total Fragments | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Total KE Payload Data Length | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | | 1376 ~ Fragmented KE Payload ~ 1377 | | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 When the flag F is set, this means the current KE payload is a 1381 fragment of a larger KE payload. The Payload Length field denotes 1382 the size of this payload fragment in octets--including the size of 1383 the generic payload header. The two-octet RESERVED field 1384 following Diffie-Hellman Group Number was to be used as a fragment 1385 identifier to help assembly and disassembly of fragments. The 1386 Fragment Index and Total Fragments fields are self-explanatory. 1387 The Total KE Payload Data Length indicates the size of the 1388 assembled KE payload data in octets. Finally, the actual fragment 1389 is carried in Fragment KE Payload field. 1391 We discarded this approach because we believe that the working 1392 group may not be happy using the RESERVED field to change the 1393 format of a packet and that implementers may not like the 1394 complexity added from checking the fragmentation flag in each 1395 received payload. Furthermore, we dismissed this idea in favour 1396 of the idea present in Section 3.6 due to the handling of the 1397 total IKEv2 payload size. There was not a clean method for the 1398 receiver to determine the total size of all the IKEv2 fragmented 1399 payloads. The method defined in Section 3.6 allows for a clean 1400 method for implementations to determine the IKE payload size and 1401 make a policy decision to allocate memory or discard the packet. 1403 o Group sub-identifier 1405 As discussed in Section 3.4, each group identifier is used to 1406 distinguish a post-quantum algorithm. Further classification 1407 could be made on a particular post-quantum algorithm by assigning 1408 additional value alongside the group identifier. This sub- 1409 identifier value may be used to assign different security 1410 parameter sets to a given post-quantum algorithm. However, this 1411 level of details does not fit the principles of the document where 1412 it should deal with generic hybrid key exchange protocol, not a 1413 specific ciphersuite. Furthermore, there are enough Diffie- 1414 Hellman group identifiers should this be required in the future. 1416 o State Keeping in Downgrade Attack Protection 1418 Another way of checking whether or not a downgrade attack is in 1419 effect is to have a responder to commit the state of the first- 1420 pass of the IKE_SA_INIT message onto memory or a temporary 1421 database. When the responder receives the second-pass of the 1422 exchange, it can verify it against the saved state to determine 1423 whether or not a downgrade attack is in effect. While this simple 1424 verification does offer protection against downgrade attack, it is 1425 susceptible to state exhaustion attack. While we do not discard 1426 this idea, it is RECOMMENDED to use the other two downgrade 1427 protection mechanisms described in Section 3.7. 1429 5. Security considerations 1431 The key length of the Encryption Algorithm (Transform Type 1), the 1432 Pseudorandom Function (Transform Type 2) and the Integrity Algorithm 1433 (Transform Type 3), all have to be of sufficient length to prevent 1434 attacks using Grover's algorithm [GROVER]. In order to use the 1435 extension proposed in this document, the key lengths of these 1436 transforms SHALL be at least 256 bits long in order to provide 1437 sufficient resistance to quantum attacks. Accordingly the post- 1438 quantum security level achieved is at least 128 bits. 1440 SKEYSEED is calculated from shared, KEx, using an algorithm defined 1441 in Transform Type 2. While a quantum attacker may learn the value of 1442 KEx', if this value is obtained by means of a classical key exchange, 1443 other KEx values generated by means of a quantum-resistant algorithm 1444 ensure that SKEYSEED is not compromised. This assumes that the 1445 algorithm defined in the Transform Type 2 is post-quantum. 1447 The main focus of this document is to prevent a passive attacker 1448 performing a "harvest and decrypt" attack. In other words, an 1449 attacker that records messages exchanges today and proceeds to 1450 decrypt them once he owns a quantum computer. This attack is 1451 prevented due to the hybrid nature of the key exchange. Other 1452 attacks involving an active attacker using a quantum-computer are not 1453 completely solved by this document since the authentication step 1454 remains classical. In particular, the authenticity of the SAs 1455 established under IKEv2 is protected using a pre-shared key, RSA, 1456 DSA, or ECDSA algorithms. Whilst the pre-shared key option, provided 1457 the key is long enough, is post-quantum, the other algorithms are 1458 not. Moreover, in implementations where scalability is a 1459 requirement, the pre-shared key method may not be suitable. Quantum- 1460 safe authenticity may be provided by using a quantum-safe digital 1461 signature and several quantum-safe digital signature methods are 1462 being explored by IETF. For example the hash based method, XMSS has 1463 the status of an Internet Draft, see [XMSS]. Currently, quantum-safe 1464 authentication methods are not specified in this document, but are 1465 planned to be incorporated in due course. 1467 It should be noted that the purpose of post-quantum algorithms is to 1468 provide resistance to attacks mounted in the future. The current 1469 threat is that encrypted sessions are subject to eavesdropping and 1470 archived with decryption by quantum computers taking place at some 1471 point in the future. Until quantum computers become available there 1472 is no point in attacking the authenticity of a connection because 1473 there are no possibilities for exploitation. These only occur at the 1474 time of the connection, for example by mounting a MitM attack. 1475 Consequently there is not such a pressing need for quantum-safe 1476 authenticity. 1478 The key exchange mechanism in this document provides a method for 1479 malicious parties to send multiple KE payloads, where each of which 1480 could be large, to a responder. As the standard behavior is for the 1481 responder to consume computational resources to compute and send 1482 multiple KE payloads back to the initiator, this allows for a simple 1483 method for malicious parties to cause a VPN gateway to perform 1484 excessive processing. In order to mitigate against this threat, 1485 implementations MAY make use of the DoS prevention COOKIE 1486 notification as defined in [RFC7296], to mitigate spoofed traffic and 1487 a puzzle-solving notification [RFC8019] to minimize the impact from 1488 hosts who use their own IP address. 1490 Cookie notification is used to prevent downgrade attacks. The cookie 1491 SHALL NOT be of arbitrary length, otherwise it will be susceptible to 1492 SLOTH attack as described in [BL]. It is RECOMMENDED that the length 1493 of the cookie be no longer than 64 octets. 1495 6. References 1497 [ADPS] Alkim, E., Ducas, L., Poppelmann, T., and Schwabe, P., 1498 "Post-quantum Key Exchange - a New Hope", 25th USENIX 1499 Security Symposium, pp. 327-343, 2016. 1501 [AH] Kent, S., "IP Authentication Header", RFC 4302, December 1502 2005, . 1504 [BL] Bhargavan, K. and Leurent, G., "Transcript Collision 1505 Attacks: Breaking Authentication in TLS, IKE, and SSH", 1506 Network and Distributed System Security Symposium, 2016. 1508 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1509 4303, December 2005, . 1512 [FMKS] Fluhrer, S., McGrew, D., Kampanakis, P., and Smyslov, V., 1513 "Postquantum Preshared Keys for IKEv2", Internet draft, 1514 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr- 1515 ikev2, 2017. 1517 [GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for 1518 Database Search", Proc. of the Twenty-Eighth Annual ACM 1519 Symposium on the Theory of Computing (STOC 1996), 1996 1521 [IKEV2IANA] 1522 IANA, "Internet Key Exchange Version 2 (IKEv2) 1523 Parameters", . 1526 [LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., 1527 Green, M., Halderman, J., Heninger, N., Springall, D., 1528 Thome, E., Valenta, L., VanderSloot, B., Wustrow, E., 1529 Beguelin, S., and Zimmermann, P., "Imperfect forward 1530 secrecy: How Diffie-Hellman fails in practice", Proc. 22rd 1531 ACM SIGSAC Conference on Computer and Communications 1532 Security, pp. 5-17, 2015. 1534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1535 Requirement Levels", RFC 2119, March 1997. 1537 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and 1538 Kivinen, T., "Internet Key Exchange Protocol Version 2 1539 (IKEv2)", RFC 7296, October 2014. 1541 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 1542 (IKEv2) Message Fragmentation", RFC 7383, November 2014. 1544 [RFC8019] Nir, Y., Smyslov, V., "Protecting Internet Key Exchange 1545 Protocol Version 2 (IKEv2) Implementations from 1546 Distributed Denial-of-Service Attacks", RFC 8019, November 1547 2016. 1549 [RFC8229] Pauly, T., Touati, S., and Mantha, R., "TCP Encapsulation 1550 of IKE and IPsec Packets", RFC8229, August 2017. 1552 [XMSS] Huelsing, A., Butin, D., Gazdag, S., and Mohaisen, A., 1553 "XMSS: Extended Hash-Based Signatures", Crypto Forum 1554 Research Group Internet Draft, 2017 1556 Acknowledgements 1558 The authors would like to thanks Frederic Detienne and Olivier 1559 Pelerin for their comments and suggestions, including the idea to 1560 negotiate the post-quantum algorithms using the existing KE payload. 1562 Authors' Addresses 1564 C. Tjhai 1565 Post-Quantum 1566 email: cjt [at] post-quantum.com 1568 M. Tomlinson 1569 Post-Quantum 1570 email: mt [at] post-quantum.com 1572 G. Bartlett 1573 Cisco Systems 1574 email: grbartle [at] cisco.com 1576 S. Fluhrer 1577 Cisco Systems 1578 email: sfluhrer [at] cisco.com 1580 D. Van Geest 1581 ISARA Corporation 1582 email: daniel.vangeest [at] isara.com 1584 Z. Zhang 1585 Onboard Security 1586 email: zzhang [at] onboardsecurity.com 1588 O. Garcia-Morchon 1589 Philips 1590 email: oscar.garcia-morchon [at] philips.com