idnits 2.17.1 draft-ietf-ipsecme-qr-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (February 27, 2018) is 2249 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 263, but not defined == Outdated reference: A later version (-07) exists of draft-hoffman-c2pq-02 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Fluhrer 3 Internet-Draft D. McGrew 4 Intended status: Standards Track P. Kampanakis 5 Expires: August 31, 2018 Cisco Systems 6 V. Smyslov 7 ELVIS-PLUS 8 February 27, 2018 10 Postquantum Preshared Keys for IKEv2 11 draft-ietf-ipsecme-qr-ikev2-02 13 Abstract 15 The possibility of Quantum Computers pose a serious challenge to 16 cryptography algorithms deployed widely today. IKEv2 is one example 17 of a cryptosystem that could be broken; someone storing VPN 18 communications today could decrypt them at a later time when a 19 Quantum Computer is available. It is anticipated that IKEv2 will be 20 extended to support quantum secure key exchange algorithms; however 21 that is not likely to happen in the near term. To address this 22 problem before then, this document describes an extension of IKEv2 to 23 allow it to be resistant to a Quantum Computer, by using preshared 24 keys. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 31, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 63 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Upgrade procedure . . . . . . . . . . . . . . . . . . . . . . 10 66 5. PPK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 5.1. PPK_ID format . . . . . . . . . . . . . . . . . . . . . . 11 68 5.2. Operational Considerations . . . . . . . . . . . . . . . 12 69 5.2.1. PPK Distribution . . . . . . . . . . . . . . . . . . 12 70 5.2.2. Group PPK . . . . . . . . . . . . . . . . . . . . . . 12 71 5.2.3. PPK-only Authentication . . . . . . . . . . . . . . . 13 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 76 8.2. Informational References . . . . . . . . . . . . . . . . 16 77 Appendix A. Discussion and Rationale . . . . . . . . . . . . . . 17 78 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 81 1. Introduction 83 It is an open question whether or not it is feasible to build a 84 Quantum Computer (and if so, when one might be implemented), but if 85 it is, many of the cryptographic algorithms and protocols currently 86 in use would be insecure. A Quantum Computer would be able to solve 87 DH and ECDH problems in polynomial time [I-D.hoffman-c2pq], and this 88 would imply that the security of existing IKEv2 [RFC7296] systems 89 would be compromised. IKEv1 [RFC2409], when used with strong 90 preshared keys, is not vulnerable to quantum attacks, because those 91 keys are one of the inputs to the key derivation function. If the 92 preshared key has sufficient entropy and the PRF, encryption and 93 authentication transforms are postquantum secure, then the resulting 94 system is believed to be quantum resistant, that is, invulnerable to 95 an attacker with a Quantum Computer. 97 This document describes a way to extend IKEv2 to have a similar 98 property; assuming that the two end systems share a long secret key, 99 then the resulting exchange is quantum resistant. By bringing 100 postquantum security to IKEv2, this note removes the need to use an 101 obsolete version of the Internet Key Exchange in order to achieve 102 that security goal. 104 The general idea is that we add an additional secret that is shared 105 between the initiator and the responder; this secret is in addition 106 to the authentication method that is already provided within IKEv2. 107 We stir this secret into the SK_d value, which is used to generate 108 the key material (KEYMAT) keys and the SKEYSEED for the child SAs; 109 this secret provides quantum resistance to the IPsec SAs (and any 110 child IKE SAs). We also stir the secret into the SK_pi, SK_pr 111 values; this allows both sides to detect a secret mismatch cleanly. 113 It was considered important to minimize the changes to IKEv2. The 114 existing mechanisms to do authentication and key exchange remain in 115 place (that is, we continue to do (EC)DH, and potentially a PKI 116 authentication if configured). This document does not replace the 117 authentication checks that the protocol does; instead, it is done as 118 a parallel check. 120 1.1. Changes 122 RFC EDITOR PLEASE DELETE THIS SECTION. 124 Changes in this draft in each version iterations. 126 draft-ietf-ipsecme-qr-ikev2-02 128 o Added note that the PPK is stirred in the initial IKE SA setup 129 only. 131 o Added note about the initiator ignoring any content in the 132 PPK_IDENTITY notification from the responder. 134 o fixed Tero's suggestions from 2/6/1028 136 o Added IANA assigned message types where necessary. 138 o fixed minor text nits 140 draft-ietf-ipsecme-qr-ikev2-01 142 o Nits and minor fixes. 144 o prf is replaced with prf+ for the SK_d and SK_pi/r calculations. 146 o Clarified using PPK in case of EAP authentication. 148 o PPK_SUPPORT notification is changed to USE_PPK to better reflect 149 its purpose. 151 draft-ietf-ipsecme-qr-ikev2-00 153 o Migrated from draft-fluhrer-qr-ikev2-05 to draft-ietf-ipsecme-qr- 154 ikev2-00 that is a WG item. 156 draft-fluhrer-qr-ikev2-05 158 o Nits and editorial fixes. 160 o Made PPK_ID format and PPK Distributions subsection of the PPK 161 section. Also added an Operational Considerations section. 163 o Added comment about Child SA rekey in the Security Considerations 164 section. 166 o Added NO_PPK_AUTH to solve the cases where a PPK_ID is not 167 configured for a responder. 169 o Various text changes and clarifications. 171 o Expanded Security Considerations section to describe some security 172 concerns and how they should be addressed. 174 draft-fluhrer-qr-ikev2-03 176 o Modified how we stir the PPK into the IKEv2 secret state. 178 o Modified how the use of PPKs is negotiated. 180 draft-fluhrer-qr-ikev2-02 182 o Simplified the protocol by stirring in the preshared key into the 183 child SAs; this avoids the problem of having the responder decide 184 which preshared key to use (as it knows the initiator identity at 185 that point); it does mean that someone with a Quantum Computer can 186 recover the initial IKE negotiation. 188 o Removed positive endorsements of various algorithms. Retained 189 warnings about algorithms known to be weak against a Quantum 190 Computer. 192 draft-fluhrer-qr-ikev2-01 193 o Added explicit guidance as to what IKE and IPsec algorithms are 194 quantum resistant. 196 draft-fluhrer-qr-ikev2-00 198 o We switched from using vendor ID's to transmit the additional data 199 to notifications. 201 o We added a mandatory cookie exchange to allow the server to 202 communicate to the client before the initial exchange. 204 o We added algorithm agility by having the server tell the client 205 what algorithm to use in the cookie exchange. 207 o We have the server specify the PPK Indicator Input, which allows 208 the server to make a trade-off between the efficiency for the 209 search of the clients PPK, and the anonymity of the client. 211 o We now use the negotiated PRF (rather than a fixed HMAC-SHA256) to 212 transform the nonces during the KDF. 214 1.2. Requirements Language 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in RFC 2119 [RFC2119]. 220 2. Assumptions 222 We assume that each IKE peer has a list of Postquantum Preshared Keys 223 (PPK) along with their identifiers (PPK_ID), and any potential IKE 224 initiator has a selection of which PPK to use with any specific 225 responder. In addition, implementations have a configurable flag 226 that determines whether this postquantum preshared key is mandatory. 227 This PPK is independent of the preshared key (if any) that the IKEv2 228 protocol uses to perform authentication. The PPK specific 229 configuration that is assumed on each peer consists of the following 230 tuple: 232 Peer, PPK, PPK_ID, mandatory_or_not 234 3. Exchanges 236 If the initiator is configured to use a postquantum preshared key 237 with the responder (whether or not the use of the PPK is mandatory), 238 then he will include a notification USE_PPK in the IKE_SA_INIT 239 request message as follows: 241 Initiator Responder 242 ------------------------------------------------------------------ 243 HDR, SAi1, KEi, Ni, N(USE_PPK) ---> 245 N(USE_PPK) is a status notification payload with the type 16435; it 246 has a protocol ID of 0, no SPI and no notification data associated 247 with it. 249 If the initiator needs to resend this initial message with a cookie 250 (because the responder response included a COOKIE notification), then 251 the resend would include the USE_PPK notification if the original 252 message did. 254 If the responder does not support this specification or does not have 255 any PPK configured, then she ignores the received notification and 256 continues with the IKEv2 protocol as normal. Otherwise the responder 257 checks if she has a PPK configured, and if she does, then the 258 responder replies with the IKE_SA_INIT message including a USE_PPK 259 notification in the response: 261 Initiator Responder 262 ------------------------------------------------------------------ 263 <--- HDR, SAr1, KEr, Nr, [CERTREQ], N(USE_PPK) 265 When the initiator receives this reply, he checks whether the 266 responder included the USE_PPK notification. If the responder did 267 not and the flag mandatory_or_not indicates that using PPKs is 268 mandatory for communication with this responder, then the initiator 269 MUST abort the exchange. This situation may happen in case of 270 misconfiguration, when the initiator believes he has a mandatory to 271 use PPK for the responder, while the responder either doesn't support 272 PPKs at all or doesn't have any PPK configured for the initiator. 273 See Section 6 for discussion of the possible impacts of this 274 situation. 276 If the responder did not include the USE_PPK notification and using 277 PPKs for this responder is optional, then the initiator continues 278 with the IKEv2 protocol as normal, without using PPKs. 280 If the responder did include the USE_PPK notification, then the 281 initiator selects a PPK, along with its identifier PPK_ID. Then, she 282 computes this modification of the standard IKEv2 key derivation: 284 SKEYSEED = prf(Ni | Nr, g^ir) 285 {SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr' ) 286 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr } 288 SK_d = prf+ (PPK, SK_d') 289 SK_pi = prf+ (PPK, SK_pi') 290 SK_pr = prf+ (PPK, SK_pr') 292 That is, we use the standard IKEv2 key derivation process except that 293 the three subkeys SK_d, SK_pi, SK_pr are run through the prf+ again, 294 this time using the PPK as the key. Using prf+ construction ensures 295 that it is always possible to get the resulting keys of the same size 296 as the initial ones, even if the underlying prf has output size 297 different from its key size. Note, that at the time this document 298 was written, all prfs defined for use in IKEv2 [IKEV2-IANA-PRFS] had 299 output size equal to the (preferred) key size. For such prfs only 300 the first iteration of prf+ is needed: 302 SK_d = prf (PPK, SK_d' | 0x01) 303 SK_pi = prf (PPK, SK_pi' | 0x01) 304 SK_pr = prf (PPK, SK_pr' | 0x01) 306 Note that the PPK is used in SK_d, SK_pi and SK_pr calculation only 307 during the initial IKE SA setup. It MUST NOT be used when these 308 subkeys are calculated as result of IKE SA rekey, resumption or other 309 similar operation. 311 The initiator then sends the IKE_AUTH request message, including the 312 PPK_ID value as follows: 314 Initiator Responder 315 ------------------------------------------------------------------ 316 HDR, SK {IDi, [CERT,] [CERTREQ,] 317 [IDr,] AUTH, SAi2, 318 TSi, TSr, N(PPK_IDENTITY, PPK_ID), [N(NO_PPK_AUTH)]} ---> 320 PPK_IDENTITY is a status notification with the type 16436; it has a 321 protocol ID of 0, no SPI and a notification data that consists of the 322 identifier PPK_ID. 324 A situation may happen when the responder has some PPKs, but doesn't 325 have a PPK with the PPK_ID received from the initiator. In this case 326 the responder cannot continue with PPK (in particular, she cannot 327 authenticate the initiator), but she could be able to continue with 328 normal IKEv2 protocol if the initiator provided its authentication 329 data computed as in normal IKEv2, without using PPKs. For this 330 purpose, if using PPKs for communication with this responder is 331 optional for the initiator, then the initiator MAY include a 332 notification NO_PPK_AUTH in the above message. 334 NO_PPK_AUTH is a status notification with the type 16437; it has a 335 protocol ID of 0 and no SPI. A notification data consists of the 336 initiator's authentication data computed using SK_pi' (i.e. the data 337 that computed without using PPKs and would normally be placed in the 338 AUTH payload). Authentication Method for computing the 339 authentication data MUST be the same as indicated in the AUTH payload 340 and is not included in the notification. Note that if the initiator 341 decides to include NO_PPK_AUTH notification, then it means that the 342 initiator needs to perform authentication data computation twice that 343 may consume substantial computation power (e.g. if digital signatures 344 are involved). 346 When the responder receives this encrypted exchange, she first 347 computes the values: 349 SKEYSEED = prf(Ni | Nr, g^ir) 350 {SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr' } 351 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 353 She then uses the SK_ei/SK_ai values to decrypt/check the message and 354 then scans through the payloads for the PPK_ID attached to the 355 PPK_IDENTITY notification. If no PPK_IDENTITY notification is found 356 and the peers successfully exchanged USE_PPK notifications in the 357 IKE_SA_INIT exchange, then the responder MUST send back 358 AUTHENTICATION_FAILED notification and then fail the negotiation. 360 If the PPK_IDENTITY notification contains PPK_ID that is not known to 361 the responder or is not configured for use for the identity from IDi 362 payload, then the responder checks whether using PPKs for this 363 initiator is mandatory and whether the initiator included NO_PPK_AUTH 364 notification in the message. If using PPKs is mandatory or no 365 NO_PPK_AUTH notification found, then then the responder MUST send 366 back AUTHENTICATION_FAILED notification and then fail the 367 negotiation. Otherwise (when PPK is optional and the initiator 368 included NO_PPK_AUTH notification) the responder MAY continue regular 369 IKEv2 protocol, except that she uses the data from the NO_PPK_AUTH 370 notification as the authentication data (which usually resides in the 371 AUTH payload), for the purpose of the initiator authentication. 372 Note, that Authentication Method is still indicated in the AUTH 373 payload. 375 This table summarizes the above logic by the responder: 377 Received Received Have PPK 378 USE_PPK NO_PPK_AUTH PPK Mandatory Action 379 ------------------------------------------------------------------ 380 No * No * Standard IKEv2 protocol 381 No * Yes No Standard IKEv2 protocol 382 No * Yes Yes Abort negotiation 383 Yes No No * Abort negotiation 384 Yes Yes No Yes Abort negotiation 385 Yes Yes No No Standard IKEv2 protocol 386 Yes * Yes * Use PPK 388 If PPK is in use, then the responder extracts corresponding PPK and 389 computes the following values: 391 SK_d = prf+ (PPK, SK_d') 392 SK_pi = prf+ (PPK, SK_pi') 393 SK_pr = prf+ (PPK, SK_pr') 395 The responder then continues with the IKE_AUTH exchange (validating 396 the AUTH payload that the initiator included) as usual and sends back 397 a response, which includes the PPK_IDENTITY notification with no data 398 to indicate that the PPK is used in the exchange: 400 Initiator Responder 401 ------------------------------------------------------------------ 402 <-- HDR, SK {IDr, [CERT,] 403 AUTH, SAr2, 404 TSi, TSr, N(PPK_IDENTITY)} 406 When the initiator receives the response, then he checks for the 407 presence of the PPK_IDENTITY notification. If he receives one, he 408 marks the SA as using the configured PPK to generate SK_d, SK_pi, 409 SK_pr (as shown above); the content of the received PPK_IDENTITY (if 410 any) MUST be ignored. If the initiator does not receive the 411 PPK_IDENTITY, he MUST either fail the IKE SA negotiation sending the 412 AUTHENTICATION_FAILED notification in the Informational exchange (if 413 the PPK was configured as mandatory), or continue without using the 414 PPK (if the PPK was not configured as mandatory and the initiator 415 included the NO_PPK_AUTH notification in the request). 417 If EAP is used in the IKE_AUTH exchange, then the initiator doesn't 418 include AUTH payload in the first request message, however the 419 responder sends back AUTH payload in the first reply. The peers then 420 exchange AUTH payloads after EAP is successfully completed. As a 421 result, the responder sends AUTH payload twice - in the first 422 IKE_AUTH reply message and in the last one, while the initiator sends 423 AUTH payload only in the last IKE_AUTH request. See more details 424 about EAP authentication in IKEv2 in Section 2.16 of [RFC7296]. 426 The general rule for using PPK in the IKE_AUTH exchange, which covers 427 EAP authentication case too, is that the initiator includes 428 PPK_IDENTITY (and optionally NO_PPK_AUTH) notification in the request 429 message containing AUTH payload. Therefore, in case of EAP the 430 responder always computes the AUTH payload in the first IKE_AUTH 431 reply message without using PPK (by means of SK_pr'), since PPK_ID is 432 not yet known to the responder. Once the IKE_AUTH request message 433 containing PPK_IDENTITY notification is received, the responder 434 follows rules described above for non-EAP authentication case. 436 Initiator Responder 437 ------------------------------------------------------------------- 438 HDR, SK {IDi, [CERTREQ,] 439 [IDr,] SAi2, 440 TSi, TSr} --> 441 <-- HDR, SK {IDr, [CERT,] AUTH, 442 EAP} 443 HDR, SK {EAP} --> 444 <-- HDR, SK {EAP (success)} 445 HDR, SK {AUTH, 446 N(PPK_IDENTITY, PPK_ID) 447 [, N(NO_PPK_AUTH)]} --> 448 <-- HDR, SK {AUTH, SAr2, TSi, TSr 449 [, N(PPK_IDENTITY)]} 451 Note, that the IKE_SA_INIT exchange in case of PPK is as described 452 above (including exchange of the USE_PPK notifications), regardless 453 whether EAP is employed in the IKE_AUTH or not. 455 4. Upgrade procedure 457 This algorithm was designed so that someone can introduce PPKs into 458 an existing IKE network without causing network disruption. 460 In the initial phase of the network upgrade, the network 461 administrator would visit each IKE node, and configure: 463 o The set of PPKs (and corresponding PPK_IDs) that this node would 464 need to know. 466 o For each peer that this node would initiate to, which PPK will be 467 used. 469 o That the use of PPK is currently not mandatory. 471 With this configuration, the node will continue to operate with nodes 472 that have not yet been upgraded. This is due to the USE_PPK notify 473 and the NO_PPK_AUTH notify; if the initiator has not been upgraded, 474 he will not send the USE_PPK notify (and so the responder will know 475 that we will not use a PPK). If the responder has not been upgraded, 476 she will not send the USE_PPK notify (and so the initiator will know 477 to not use a PPK). If both peers have been upgraded, but the 478 responder isn't yet configured with the PPK for the initiator, then 479 the responder could do standard IKEv2 protocol if the initiator sent 480 NO_PPK_AUTH notification. If both the responder and initiator have 481 been upgraded and properly configured, they will both realize it, and 482 in that case, the link will be quantum secure. 484 As an optional second step, after all nodes have been upgraded, then 485 the administrator may then go back through the nodes, and mark the 486 use of PPK as mandatory. This will not affect the strength against a 487 passive attacker; it would mean that an attacker with a Quantum 488 Computer (which is sufficiently fast to be able to break the (EC)DH 489 in real time would not be able to perform a downgrade attack). 491 5. PPK 493 5.1. PPK_ID format 495 This standard requires that both the initiator and the responder have 496 a secret PPK value, with the responder selecting the PPK based on the 497 PPK_ID that the initiator sends. In this standard, both the 498 initiator and the responder are configured with fixed PPK and PPK_ID 499 values, and do the look up based on PPK_ID value. It is anticipated 500 that later standards will extend this technique to allow dynamically 501 changing PPK values. To facilitate such an extension, we specify 502 that the PPK_ID the initiator sends will have its first octet be the 503 PPK_ID Type value. This document defines two values for PPK_ID Type: 505 o PPK_ID_OPAQUE (1) - for this type the format of the PPK_ID (and 506 the PPK itself) is not specified by this document; it is assumed 507 to be mutually intelligible by both by initiator and the 508 responder. This PPK_ID type is intended for those implementations 509 that choose not to disclose the type of PPK to active attackers. 511 o PPK_ID_FIXED (2) - in this case the format of the PPK_ID and the 512 PPK are fixed octet strings; the remaining bytes of the PPK_ID are 513 a configured value. We assume that there is a fixed mapping 514 between PPK_ID and PPK, which is configured locally to both the 515 initiator and the responder. The responder can use to do a look 516 up the passed PPK_ID value to determine the corresponding PPK 517 value. Not all implementations are able to configure arbitrary 518 octet strings; to improve the potential interoperability, it is 519 recommended that, in the PPK_ID_FIXED case, both the PPK and the 520 PPK_ID strings be limited to the base64 character set, namely the 521 64 characters 0-9, A-Z, a-z, + and /. 523 The PPK_ID type value 0 is reserved; values 3-127 are reserved for 524 IANA; values 128-255 are for private use among mutually consenting 525 parties. 527 5.2. Operational Considerations 529 The need to maintain several independent sets of security credentials 530 can significantly complicate security administrators job, and can 531 potentially slow down widespread adoption of this solution. It is 532 anticipated, that administrators will try to simplify their job by 533 decreasing the number of credentials they need to maintain. This 534 section describes some of the considerations for PPK management. 536 5.2.1. PPK Distribution 538 PPK_IDs of the type PPK_ID_FIXED (and the corresponding PPKs) are 539 assumed to be configured within the IKE device in an out-of-band 540 fashion. While the method of distribution is a local matter and out 541 of scope of this document or IKEv2, [RFC6030] describes a format for 542 symmetric key exchange. That format could be reused with the Key Id 543 field being the PPK_ID (without the PPK_ID Type octet for a 544 PPK_ID_FIXED), the PPK being the secret, and the algorithm 545 ("Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin") as PIN. 547 5.2.2. Group PPK 549 This document doesn't explicitly require that PPK is unique for each 550 pair of peers. If it is the case, then this solution provides full 551 peer authentication, but it also means that each host must have that 552 many independent PPKs, how many peers it is going to communicate 553 with. As the number of hosts grows this will scale badly. 555 Even though it is NOT RECOMMENDED, it is possible to use a single PPK 556 for a group of users. Since each peer uses classical public key 557 cryptography in addition to PPK for key exchange and authentication, 558 members of the group can neither impersonate each other nor read 559 other's traffic, unless they use Quantum Computers to break public 560 key operations. 562 Although it's probably safe to use group PPK in short term, the fact, 563 that the PPK is known to a (potentially large) group of users makes 564 it more susceptible to theft. If an attacker equipped with a Quantum 565 Computer got access to a group PPK, then all the communications 566 inside the group are revealed. 568 5.2.3. PPK-only Authentication 570 If Quantum Computers become a reality, classical public key 571 cryptography will provide little security, so administrators may find 572 it attractive not to use it at all for authentication. This will 573 reduce the number of credentials they need to maintain to PPKs only. 574 Combining group PPK and PPK-only authentication is NOT RECOMMENDED, 575 since in this case any member of the group can impersonate any other 576 member even without help of Quantum Computers. 578 PPK-only authentication can be achieved in IKEv2 if NULL 579 Authentication method [RFC7619] is employed. Without PPK the NULL 580 Authentication method provides no authentication of the peers, 581 however since a PPK is stirred into the SK_pi and the SK_pr, the 582 peers become authenticated if a PPK is in use. Using PPKs MUST be 583 mandatory for the peers if they advertise support for PPK in 584 IKE_SA_INIT and use NULL Authentication. Addtionally, since the 585 peers are authenticated via PPK, the ID Type in the IDi/IDr payloads 586 SHOULD NOT be ID_NULL, despite using NULL Authentication method. 588 6. Security Considerations 590 Quantum computers are able to perform Grover's algorithm; that 591 effectively halves the size of a symmetric key. Because of this, the 592 user SHOULD ensure that the postquantum preshared key used has at 593 least 256 bits of entropy, in order to provide a 128-bit security 594 level. 596 With this protocol, the computed SK_d is a function of the PPK, and 597 assuming that the PPK has sufficient entropy (for example, at least 598 2^256 possible values), then even if an attacker was able to recover 599 the rest of the inputs to the prf function, it would be infeasible to 600 use Grover's algorithm with a Quantum Computer to recover the SK_d 601 value. Similarly, every child SA key is a function of SK_d, hence 602 all the keys for all the child SAs are also quantum resistant 603 (assuming that the PPK was high entropy and secret, and that all the 604 subkeys are sufficiently long). 606 Although this protocol preserves all the security properties of IKEv2 607 against adversaries with conventional computers, it allows an 608 adversary with a Quantum Computer to decrypt all traffic encrypted 609 with the initial IKE SA. In particular, it allows the adversary to 610 recover the identities of both sides. If there is IKE traffic other 611 than the identities that need to be protected against such an 612 adversary, implementations MAY rekey the initial IKE SA immediately 613 after negotiating it to generate a new SKEYSEED from the postquantum 614 SK_d. This would reduce the amount of data available to an attacker 615 with a Quantum Computer. 617 Alternatively, an initial IKE SA (which is used to exchange 618 identities) can take place, perhaps by using the protocol documented 619 in [RFC6023]. After the childless IKE SA is created, implementations 620 would immediately create a new IKE SA (which is used to exchange 621 everything else) by using a rekey mechanism for IKE SAs. Because the 622 rekeyed IKE SA keys are a function of SK_d, which is a function of 623 the PPK (among other things), traffic protected by that IKE SA is 624 secure against Quantum capable adversaries. 626 If some sensitive information (like keys) is to be transferred over 627 IKE SA, then implementations MUST rekey the initial IKE SA before 628 sending this information to get protection against Quantum Computers. 630 In addition, the policy SHOULD be set to negotiate only quantum- 631 resistant symmetric algorithms; while this RFC doesn't claim to give 632 advise as to what algorithms are secure (as that may change based on 633 future cryptographical results), below is a list of defined IKEv2 and 634 IPsec algorithms that should NOT be used, as they are known not to be 635 quantum resistant 637 o Any IKEv2 Encryption algorithm, PRF or Integrity algorithm with 638 key size less than 256 bits. 640 o Any ESP Transform with key size less than 256 bits. 642 o PRF_AES128_XCBC and PRF_AES128_CBC; even though they are defined 643 to be able to use an arbitrary key size, they convert it into a 644 128-bit key internally. 646 Section 3 requires the initiator to abort the initial exchange if 647 using PPKs is mandatory for it, but the responder didn't include the 648 USE_PPK notification in the response. In this situation when the 649 initiator aborts negotiation he leaves half-open IKE SA on the 650 responder (because IKE_SA_INIT completes successfully from 651 responder's point of view). This half-open SA will eventually expire 652 and be deleted, but if the initiator continues its attempts to create 653 IKE SA with a high enough rate, then the responder may consider it as 654 a Denial-of-Service attack and take some measures (see [RFC8019] for 655 more detail). It is RECOMMENDED that implementations in this 656 situation cache the negative result of negotiation for some time and 657 don't make attempts to create it again for some time, because this is 658 a result of misconfiguration and probably some re-configuration of 659 the peers is needed. 661 If using PPKs is optional for both peers and they authenticate 662 themselves using digital signatures, then an attacker in between, 663 equipped with a Quantum Computer capable of breaking public key 664 operations in real time, is able to mount downgrade attack by 665 removing USE_PPK notification from the IKE_SA_INIT and forging 666 digital signatures in the subsequent exchange. If using PPKs is 667 mandatory for at least one of the peers or PSK is used for 668 authentication, then the attack will be detected and the SA won't be 669 created. 671 If using PPKs is mandatory for the initiator, then an attacker 672 capable to eavesdrop and to inject packets into the network can 673 prevent creating IKE SA by mounting the following attack. The 674 attacker intercepts the the initial request containing the USE_PPK 675 notification and injects the forget response containing no USE_PPK. 676 If the attacker manages to inject this packet before the responder 677 sends a genuine response, then the initiator would abort the 678 exchange. To thwart this kind of attack it is RECOMMENDED, that if 679 using PPKs is mandatory for the initiator and the received response 680 doesn't contain the USE_PPK notification, then the initiator doesn't 681 abort exchange immediately, but instead waits some time for more 682 responses (possibly retransmitting the request). If all the received 683 responses contain no USE_PPK, then the exchange is aborted. 685 7. IANA Considerations 687 This document defines three new Notify Message Types in the "Notify 688 Message Types - Status Types" registry: 690 16435 USE_PPK 691 16436 PPK_IDENTITY 692 16437 NO_PPK_AUTH 694 This document also creates a new IANA registry for the PPK_ID types. 695 The initial values of this registry are: 697 PPK_ID Type Value 698 ----------- ----- 699 Reserved 0 700 PPK_ID_OPAQUE 1 701 PPK_ID_FIXED 2 702 Unassigned 3-127 703 Reserved for private use 128-255 705 Changes and additions to this registry are by Expert Review 706 [RFC5226]. 708 8. References 709 8.1. Normative References 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, 713 DOI 10.17487/RFC2119, March 1997, 714 . 716 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 717 Kivinen, "Internet Key Exchange Protocol Version 2 718 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 719 2014, . 721 8.2. Informational References 723 [I-D.hoffman-c2pq] 724 Hoffman, P., "The Transition from Classical to Post- 725 Quantum Cryptography", draft-hoffman-c2pq-02 (work in 726 progress), August 2017. 728 [IKEV2-IANA-PRFS] 729 "Internet Key Exchange Version 2 (IKEv2) Parameters, 730 Transform Type 2 - Pseudorandom Function Transform IDs", 731 . 734 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 735 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 736 . 738 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 739 IANA Considerations Section in RFCs", RFC 5226, 740 DOI 10.17487/RFC5226, May 2008, 741 . 743 [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A 744 Childless Initiation of the Internet Key Exchange Version 745 2 (IKEv2) Security Association (SA)", RFC 6023, 746 DOI 10.17487/RFC6023, October 2010, 747 . 749 [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric 750 Key Container (PSKC)", RFC 6030, DOI 10.17487/RFC6030, 751 October 2010, . 753 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 754 Method in the Internet Key Exchange Protocol Version 2 755 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 756 . 758 [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange 759 Protocol Version 2 (IKEv2) Implementations from 760 Distributed Denial-of-Service Attacks", RFC 8019, 761 DOI 10.17487/RFC8019, November 2016, 762 . 764 Appendix A. Discussion and Rationale 766 The idea behind this document is that while a Quantum Computer can 767 easily reconstruct the shared secret of an (EC)DH exchange, they 768 cannot as easily recover a secret from a symmetric exchange. This 769 makes the SK_d, and hence the IPsec KEYMAT and any child SA's 770 SKEYSEED, depend on both the symmetric PPK, and also the Diffie- 771 Hellman exchange. If we assume that the attacker knows everything 772 except the PPK during the key exchange, and there are 2^n plausible 773 PPKs, then a Quantum Computer (using Grover's algorithm) would take 774 O(2^(n/2)) time to recover the PPK. So, even if the (EC)DH can be 775 trivially solved, the attacker still can't recover any key material 776 (except for the SK_ei, SK_er, SK_ai, SK_ar values for the initial IKE 777 exchange) unless they can find the PPK, which is too difficult if the 778 PPK has enough entropy (for example, 256 bits). Note that we do 779 allow an attacker with a Quantum Computer to rederive the keying 780 material for the initial IKE SA; this was a compromise to allow the 781 responder to select the correct PPK quickly. 783 Another goal of this protocol is to minimize the number of changes 784 within the IKEv2 protocol, and in particular, within the cryptography 785 of IKEv2. By limiting our changes to notifications, and adjusting 786 the SK_d, SK_pi, SK_pr, it is hoped that this would be implementable, 787 even on systems that perform much of the IKEv2 processing is in 788 hardware. 790 A third goal was to be friendly to incremental deployment in 791 operational networks, for which we might not want to have a global 792 shared key or quantum resistant IKEv2 is rolled out incrementally. 793 This is why we specifically try to allow the PPK to be dependent on 794 the peer, and why we allow the PPK to be configured as optional. 796 A fourth goal was to avoid violating any of the security goals of 797 IKEv2. 799 Appendix B. Acknowledgements 801 We would like to thank Tero Kivinen, Paul Wouters, Graham Bartlett 802 and the rest of the IPSecME Working Group for their feedback and 803 suggestions for the scheme. 805 Authors' Addresses 807 Scott Fluhrer 808 Cisco Systems 810 Email: sfluhrer@cisco.com 812 David McGrew 813 Cisco Systems 815 Email: mcgrew@cisco.com 817 Panos Kampanakis 818 Cisco Systems 820 Email: pkampana@cisco.com 822 Valery Smyslov 823 ELVIS-PLUS 825 Phone: +7 495 276 0211 826 Email: svan@elvis.ru