idnits 2.17.1 draft-fluhrer-qr-ikev2-04.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 19, 2017) is 2561 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBA' is mentioned on line 231, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 197, but not defined == Unused Reference: 'RFC2104' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'RFC7296' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC6023' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'SPDP' is defined on line 442, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: Informational P. Kampanakis 5 Expires: October 21, 2017 Cisco Systems 6 April 19, 2017 8 Postquantum Preshared Keys for IKEv2 9 draft-fluhrer-qr-ikev2-04 11 Abstract 13 The possibility of quantum computers pose a serious challenge to 14 cryptography algorithms widely today. IKEv2 is one example of a 15 cryptosystem that could be broken; someone storing VPN communications 16 today could decrypt them at a later time when a quantum computer is 17 available. It is anticipated that IKEv2 will be extended to support 18 quantum secure key exchange algorithms; however that is not likely to 19 happen in the near term. To address this problem before then, this 20 document describes an extension of IKEv2 to allow it to be resistant 21 to a Quantum Computer, by using preshared keys. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 21, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. PPK ID format . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. PPK Distribution . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Upgrade procedure . . . . . . . . . . . . . . . . . . . . . . 8 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 8.2. Informational References . . . . . . . . . . . . . . . . 10 69 Appendix A. Discussion and Rationale . . . . . . . . . . . . . . 10 70 Appendix B. Acknowledgement . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 It is an open question whether or not it is feasible to build a 76 quantum computer (and if so, when might one be implemented), but if 77 it is, many of the cryptographic algorithms and protocols currently 78 in use would be insecure. A quantum computer would be able to solve 79 DH and ECDH problems, and this would imply that the security of 80 existing IKEv2 systems would be compromised. IKEv1 when used with 81 strong preshared keys is not vulnerable to quantum attacks, because 82 those keys are one of the inputs to the key derivation function. If 83 the preshared key has sufficient entropy and the PRF, encryption and 84 authentication transforms are postquantum secure, then the resulting 85 system is believed to be quantum resistant, that is, believed to be 86 invulnerable to an attacker with a Quantum Computer. 88 This document describes a way to extend IKEv2 to have a similar 89 property; assuming that the two end systems share a long secret key, 90 then the resulting exchange is quantum resistant. By bringing 91 postquantum security to IKEv2, this note removes the need to use an 92 obsolete version of the Internet Key Exchange in order to achieve 93 that security goal. 95 The general idea is that we add an additional secret that is shared 96 between the initiator and the responder; this secret is in addition 97 to the authentication method that is already provided within IKEv2. 98 We stir in this secret into the SK_d value, which is used to generate 99 the key material (KEYMAT) keys and the SKEYSEED for the child SAs; 100 this secret provides quantum resistance to the IPsec SAs (and any 101 child IKE SAs). We also stir in the secret into the SK_pi, SK_pr 102 values; this allows both sides to detect a secret mismatch cleanly. 104 It was considered important to minimize the changes to IKEv2. The 105 existing mechanisms to do authentication and key exchange remain in 106 place (that is, we continue to do (EC)DH, and potentially a PKI 107 authentication if configured). This does not replace the 108 authentication checks that the protocol does; instead, it is done as 109 a parallel check. 111 1.1. Changes 113 Changes in this draft from the previous versions 115 draft-03 117 - Modified how we stir the PPK into the IKEv2 secret state 119 - Modified how the use of PPKs is negotiated 121 draft-02 123 - Simplified the protocol by stirring in the preshared key into the 124 child SAs; this avoids the problem of having the responder decide 125 which preshared key to use (as it knows the initiator identity at 126 that point); it does mean that someone with a Quantum Computer can 127 recover the initial IKE negotation. 129 - Removed positive endorsements of various algorithms. Retained 130 warnings about algorithms known to be weak against a Quantum Computer 132 draft-01 134 - Added explicit guidance as to what IKE and IPsec algorithms are 135 Quantum Resistant 137 draft-00 139 - We switched from using vendor ID's to transmit the additional data 140 to notifications 142 - We added a mandatory cookie exchange to allow the server to 143 communicate to the client before the initial exchange 144 - We added algorithm agility by having the server tell the client 145 what algorithm to use in the cookie exchange 147 - We have the server specify the PPK Indicator Input, which allows 148 the server to make a trade-off between the efficiency for the search 149 of the clients PPK, and the anonymity of the client. 151 - We now use the negotiated PRF (rather than a fixed HMAC-SHA256) to 152 transform the nonces during the KDF 154 1.2. Requirements Language 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 2. Assumptions 162 We assume that each IKE peer has a list of Postquantum Preshared Keys 163 (PPK) along with their identifiers (PPK_id), and any potential IKE 164 initiator has a selection of which PPK to use with with any specific 165 responder. In addition, the implementation has a configurable flag 166 that determines whether this postquantum preshared key is mandatory. 167 This PPK is independent of the preshared key (if any) that the IKEv2 168 protocol uses to perform authentication. 170 3. Exchanges 172 If the initiator is configured to use a postquantum preshared key 173 with the responder (whether or not the use of the PPK is optional), 174 then it will include a notify payload in the initial exchange as 175 follows: 177 Initiator Responder 178 ------------------------------------------------------------------ 179 HDR, SAi1, KEi, Ni, N(PPK_SUPPORT) ---> 181 N(PPK_SUPPORT) is a status notification payload with the type [TBA]; 182 it has a protocol ID of 0, and no SPI and no notification data 183 associated with it. 185 If the initiator needs to resend this initial message with a cookie 186 (because the responder response included a cookie notification), then 187 the resend would include the PPK_SUPPORT notification if the original 188 message did. 190 When the responder receives this initial exchange with the notify, 191 then it MUST check if has a PPK configured. If it does, it MUST 192 reply with the IKE initial exchange including a notification in 193 response. 195 Initiator Responder 196 ------------------------------------------------------------------ 197 <--- HDR, SAr1, KEr, Nr, [CERTREQ], N(PPK_SUPPORT) 199 If the responder does not have a PPK configured, then it continues 200 with the IKE protocol as normal, not including the notify. 202 When the initiator receives this reply, it checks whether the 203 responder included the PPK_SUPPORT notify. If the responder did not, 204 then the initiator MUST either proceed with the standard IKE 205 negotiation (without using a PPK), or abort the exchange (for 206 example, because the initiator has the PPK marked as mandatory). If 207 the responder did include the PPK_SUPPORT notify, then it selects a 208 PPK, along with its identifier PPK_id. Then, it computes this 209 modification of the standard IKE key derivation: 211 SKEYSEED = prf(Ni | Nr, g^ir) 212 {SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr' ) 213 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr } 214 SK_d = prf(PPK, SK_d') 215 SK_pi = prf(PPK, SK_pi') 216 SK_pr = prf(PPK, SK_pr') 218 That is, we use the standard IKE key derivation process except that 219 the three subkeys SK_d, SK_pi, SK_pr are run through the prf again, 220 this time using the PPK as the key. 222 The initiator then sends the initial encrypted message, including the 223 PPK_id value as follows: 225 Initiator Responder 226 ------------------------------------------------------------------ 227 HDR, SK {IDi, [CERT,] [CERTREQ,] 228 [IDr,] AUTH, SAi2, 229 TSi, TSr, N(PPK_IDENTITY)(PPK_id)} ---> 231 N(PPK_IDENITY) is a status notification payload with the type [TBA]; 232 it has a protocol ID of 0, and no SPI and has a notification data 233 that consists of the identifier PPK_id. 235 When the responder receives this encrypted exchange, it first 236 computes the values: 238 SKEYSEED = prf(Ni | Nr, g^ir) 239 {SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr' } 240 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 242 It then uses the SK_ei value to decrypt the message; and then finds 243 the PPK_id value attached to the notify. It then scans through the 244 payload for the PPK_id attached to the N(PPK_IDENTITY); if it has no 245 such PPK, it fails the negotiation. If it does have a PPK with that 246 identity, it further computes: 248 SK_d = prf(PPK, SK_d') 249 SK_pi = prf(PPK, SK_pi') 250 SK_pr = prf(PPK, SK_pr') 252 And computes the enchange (validating the AUTH payload that the 253 initiator included) as standard. 255 This table summarizes the above logic by the responder 257 Received PPK_SUPPORT Have PPK PPK Mandatory Action 258 ------------------------------------------------------------------ 259 No No * Standard IKE protocol 260 No Yes No Standard IKE protocol 261 No Yes Yes Abort negotiation 262 Yes No * Standard IKE protocol 263 Yes Yes * Include PPK_SUPPORT 265 When the initiator receives the response, then (if it is configured 266 to use a PPK with the responder), then it checks for the presense of 267 the notification. If it receives one, it marks the SA as using the 268 configured PPK to generate SK_d, SK_pi, SK_pr (as shown above); if it 269 does not receive one, it MUST either abort the exchange (if the PPK 270 was configured as mandatory), or it MUST continue without using the 271 PPK (if the PPK was configured as optional). 273 If the initial exchange had PPK_SUPPORT sent by both the initiator 274 and the responder, and the initiator does not include a PPK_NOTIFY 275 notification, then the responder SHOULD fail the exchange. 277 With this protocol, the computed SK_d is a function of the PPK, and 278 assuming that the PPK has sufficient entropy (for example, at least 279 2**256 possible values), then even if an attacker were able to 280 recover the rest of the inputs to the prf function, it would be 281 infeasible to use Grover's algorithm with a Quantum Computer to 282 recover the SK_d value. Similarly, every child SA key is a function 283 of SK_d, hence all the keys for all the child SAs are also quantum 284 resistant (assuming that the PPK was high entropy and secret, and 285 that all the subkeys are sufficiently long). However, this quantum 286 resistance does not extend to the initial SK_ei, SK_er keys; an 287 implementation MAY rekey the initial IKE SA immediately after 288 negotiating it; this would reduce the amount of data available to an 289 attacker with a Quantum Computer. 291 4. PPK ID format 293 This standard requires that both the initiator and the responder have 294 a secret PPK value, with the responder selecting the PPK based on the 295 PPK_ID that the initiator sends. In this initial standard, both the 296 initator and the responder are configured with fixed PPK and PPK_ID 297 values, and do the look up based on that. It is anticipated that 298 later standards will extend this technique to allow dynamically 299 changing PPK values. To facilitate such an extension, we specify 300 that the PPK_ID that the initiator sends will have its first octet be 301 the PPK ID Type value, which is encoded as follows: 303 PPK ID Type Value 305 PPK_ID_OPAQUE 0 306 PPK_ID_FIXED 1 307 RESERVED TO IANA 2-127 308 Reserved for private use 128-255 310 For PPK_ID_OPAQUE, the format of the PPK ID (and the PPK itself) is 311 not specified by this document; it is assumed to be mutually 312 intelligible by both by initiator and the responder. This PPK ID 313 type is intended for those implementations that choose not to 314 disclose the type of PPK to active attackers. 316 For PPK_ID_FIXED, the format of the PPK ID and the PPK are fixed 317 octet strings; the remaining bytes of the PPK_ID are a configured 318 value. We assume that there is a fixed mapping between PPK_ID and 319 PPK, which is configured locally to both the initiator and the 320 responder. The responder can use to do a look up the passed PPK_id 321 value to determine the corresponding PPK value. Not all 322 implementations are able to configure arbitrary octet strings; to 323 improve the potential interoperability, it is recommended that, in 324 the PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited 325 to the base64 character set, namely the 64 characters 0-9, A-Z, a-z, 326 + and /. 328 The PPK ID type values 2-127 are reserved for IANA; values 128-255 329 are for private use among mutually consenting parties. 331 5. PPK Distribution 333 PPK_id's of the type PPK_ID_FIXED (and the corresponding PPKs) are 334 assumed to be configured within the IKE device in an out-of-band 335 fashion. While the method of distribution is a local matter, one 336 suggestion would be to reuse the format within [RFC6030], with the 337 Key Id field being the PPK_ID (without the 0x01 prefix for a 338 PPK_ID_FIXED), and with the PPK being the secret, and the algorithm 339 as PIN ("Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin"). 341 6. Upgrade procedure 343 This algorithm was designed so that someone can introduce PPKs into 344 an existing IKE network without causing network disruption. 346 In the initial phase of the network upgrade, the network 347 administrator would visit each IKE node, and configure: 349 - The set of PPKs (and corresponding PPK_id's) that this node would 350 need to know 352 - For each peer that this node would initiate to, which PPK that we 353 would use 355 - That the use of PPK is currently optional 357 With this configuration, the node will continue to operate with nodes 358 that have not yet been upgraded. This is due to the PPK_SUPPORT 359 notify; if the initiator has not been upgraded, it will not send the 360 PPK_SUPPORT notify (and so the responder will know that we will not 361 use a PPK); if the responder has not been upgraded, it will not send 362 the PPK_SUPPORT notify (and so the initiator will know not to use a 363 PPK). And, if both peers have been upgraded, they will both realize 364 it, and in that case, the link will be quantum secure 366 As an optional second step, after all nodes have been upgraded, then 367 the administrator may then go back through the nodes, and mark the 368 use of PPK as mandatory. This will not affect the strength against a 369 passive attacker; it would mean that an attacker with a Quantum 370 Computer (which is sufficiently fast to be able to break the (EC)DH 371 in real time would not be able to perform a downgrade attack). 373 7. Security Considerations 375 Quantum computers are able to perform Grover's algorithm; that 376 effectively halves the size of a symmetric key. Because of this, the 377 user SHOULD ensure that the postquantum preshared key used has at 378 least 256 bits of entropy, in order to provide a 128 bit security 379 level. 381 Although this protocol preserves all the security properties of IKE 382 against adversaries with conventional computers, this protocol allows 383 an adversary with a Quantum Computer to decrypt all traffic encrypted 384 with the initial IKE SA. In particular, it allows the adversary to 385 recover the identities of both sides. If there is IKE traffic other 386 than the identities that need to be protected against such an 387 adversary, one suggestion would be to form an initial IKE SA (which 388 is used to exchange identities), perhaps by using the protocol 389 documented in RFC6023. Then, you would immediately create a child 390 IKE SA (which is used to exchange everything else). Because the 391 child IKE SA keys are a function of SK_d, which is a function of the 392 PPK (among other things), traffic protected by that SA is secure 393 against Quantum capable adversaries. 395 In addition, the policy SHOULD be set to negotiate only quantum- 396 resistant symmetric algorithms; while this RFC doesn't claim to give 397 advise as to what algorithms are secure (as that may change based on 398 future cryptographical results), here is a list of defined IKEv2 and 399 IPsec algorithms that should NOT be used, as they are known not to be 400 Quantum Resistant 402 Any IKE Encryption algorithm, PRF or Integrity algorithm with key 403 size <256 bits 405 Any ESP Transform with key size <256 bits 407 PRF_AES128_XCBC and PRF_AES128_CBC; even though they are defined to 408 be able to use an arbitrary key size, they convert it into a 128 bit 409 key internally 411 8. References 413 8.1. Normative References 415 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 416 Hashing for Message Authentication", RFC 2104, 417 DOI 10.17487/RFC2104, February 1997, 418 . 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, 422 DOI 10.17487/RFC2119, March 1997, 423 . 425 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 426 Kivinen, "Internet Key Exchange Protocol Version 2 427 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 428 2014, . 430 8.2. Informational References 432 [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A 433 Childless Initiation of the Internet Key Exchange Version 434 2 (IKEv2) Security Association (SA)", RFC 6023, 435 DOI 10.17487/RFC6023, October 2010, 436 . 438 [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric 439 Key Container (PSKC)", RFC 6030, DOI 10.17487/RFC6030, 440 October 2010, . 442 [SPDP] McGrew, D., "A Secure Peer Discovery Protocol (SPDP)", 443 2001, . 445 Appendix A. Discussion and Rationale 447 The idea behind this is that while a Quantum Computer can easily 448 reconstruct the shared secret of an (EC)DH exchange, they cannot as 449 easily recover a secret from a symmetric exchange this makes the 450 SK_d, and hence the IPsec KEYMAT and any child SA's SKEYSEED, depend 451 on both the symmetric PPK, and also the Diffie-Hellman exchange. If 452 we assume that the attacker knows everything except the PPK during 453 the key exchange, and there are 2**n plausible PPK's, then a Quantum 454 Computer (using Grover's algorithm) would take O(2**(n/2)) time to 455 recover the PPK. So, even if the (EC)DH can be trivially solved, the 456 attacker still can't recover any key material (except for the SK_ei, 457 SK_er, SK_ai, SK_ar values for the initial IKE exchange) unless they 458 can find the PPK, and that's too difficult if the PPK has enough 459 entropy (for example, 256 bits). Note that we do allow an attacker 460 with a Quantum Computer to rederive the keying material for the 461 initial IKE SA; this was a compromise to allow the responder to 462 select the correct PPK quickly. 464 Another goal of this protocol is to minimize the number of changes 465 within the IKEv2 protocol, and in particular, within the cryptography 466 of IKEv2. By limiting our changes to notifications, and translating 467 the nonces, it is hoped that this would be implementable, even on 468 systems that perform much of the IKEv2 processing is in hardware. 470 A third goal was to be friendly to incremental deployment in 471 operational networks, for which we might not want to have a global 472 shared key, and also if we're rolling this out incrementally. This 473 is why we specifically try to allow the PPK to be dependent on the 474 peer, and why we allow the PPK to be configured as optional. 476 A fourth goal was to avoid violating any of the security goals of 477 IKEv2. 479 Appendix B. Acknowledgement 481 We would like to thank Tero Kivine, Valery Smyslov, Paul Wouters and 482 the rest of the ipsecme working group for their feedback and 483 suggestions for the scheme 485 Authors' Addresses 487 Scott Fluhrer 488 Cisco Systems 490 Email: sfluhrer@cisco.com 492 David McGrew 493 Cisco Systems 495 Email: mcgrew@cisco.com 497 Panos Kampanakis 498 Cisco Systems 500 Email: pkampana@cisco.com