idnits 2.17.1 draft-fluhrer-qr-ikev2-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (October 28, 2016) is 2734 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBA' is mentioned on line 165, but not defined == Unused Reference: 'RFC2104' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC7296' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'RFC6023' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'SPDP' is defined on line 326, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 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: May 1, 2017 Cisco Systems 6 October 28, 2016 8 Postquantum Preshared Keys for IKEv2 9 draft-fluhrer-qr-ikev2-03 11 Abstract 13 This document describes an extension of IKEv2 to allow it to be 14 resistant to a Quantum Computer, by using preshared keys 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 1, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Creating Child SA Keying Material . . . . . . . . . . . . . . 5 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 59 6.2. Informational References . . . . . . . . . . . . . . . . 7 60 Appendix A. Discussion and Rationale . . . . . . . . . . . . . . 7 61 Appendix B. Acknowledgement . . . . . . . . . . . . . . . . . . 9 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 64 1. Introduction 66 It is an open question whether or not it is feasible to build a 67 quantum computer, but if it is, many of the cryptographic algorithms 68 and protocols currently in use would be insecure. A quantum computer 69 would be able to solve DH and ECDH problems, and this would imply 70 that the security of existing IKEv2 systems would be compromised. 71 IKEv1 when used with preshared keys does not share this 72 vulnerability, because those keys are one of the inputs to the key 73 derivation function. If the preshared key have sufficient entropy 74 and the PRF and encryption and authentication transforms are 75 postquantum secure, then the resulting system is believed to be 76 quantum resistant, that is, believed to be invulnerable to an 77 attacker with a Quantum Computer. 79 This document describes a way to extend IKEv2 to have a similar 80 property; assuming that the two end systems share a long secret key, 81 then the resulting exchange is quantum resistant. By bringing 82 postquantum security to IKEv2, this note removes the need to use an 83 obsolete version of the Internet Key Exchange in order to achieve 84 that security goal. 86 The general idea is that we add an additional secret that is shared 87 between the initiator and the responder; this secret is in addition 88 to the authentication method that is already provided within IKEv2. 89 We stir in this secret when generating the key material (KEYMAT) keys 90 for the child SAs (along with the parameters that IKEv2 normally 91 uses); this secret provides quantum resistance to the IPsec SAs. 93 It was considered important to minimize the changes to IKEv2. The 94 existing mechanisms to do authentication and key exchange remain in 95 place (that is, we continue to do (EC)DH, and potentially a PKI 96 authentication if configured). This does not replace the 97 authentication checks that the protocol does; instead, it is done as 98 a parallel check. 100 1.1. Changes 102 Changes in this draft from the previous versions 104 draft-02 106 - Simplified the protocol by stirring in the preshared key into the 107 child SAs; this avoids the problem of having the responder decide 108 which preshared key to use (as it knows the initiator identity at 109 that point); it does mean that someone with a Quantum Computer can 110 recover the initial IKE negotation. 112 - Removed positive endorsements of various algorithms. Retained 113 warnings about algorithms known to be weak against a Quantum Computer 115 draft-01 117 - Added explicit guidance as to what IKE and IPsec algorithms are 118 Quantum Resistant 120 draft-00 122 - We switched from using vendor ID's to transmit the additional data 123 to notifications 125 - We added a mandatory cookie exchange to allow the server to 126 communicate to the client before the initial exchange 128 - We added algorithm agility by having the server tell the client 129 what algorithm to use in the cookie exchange 131 - We have the server specify the PPK Indicator Input, which allows 132 the server to make a trade-off between the efficiency for the search 133 of the clients PPK, and the anonymity of the client. 135 - We now use the negotiated PRF (rather than a fixed HMAC-SHA256) to 136 transform the nonces during the KDF 138 1.2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 2. Assumptions 146 We assume that each IKE peer (both the initiator and the responder) 147 has an optional Postquantum Preshared Key (PPK) (potentially on a 148 per-peer basis, selected by peer identity), and also has a 149 configurable flag that determines whether this postquantum preshared 150 key is mandatory. This preshared key is independent of the preshared 151 key (if any that the IKEv2 protocol uses to perform authentication. 153 3. Exchanges 155 If the initiator has a configured postquantum preshared key (whether 156 or not it is optional), then it will include a notify payload in its 157 initial encrypted exchange as follows: 159 Initiator Responder 160 ------------------------------------------------------------------ 161 HDR, SK {IDi, [CERT,] [CERTREQ,] 162 [IDr,] AUTH, SAi2, 163 TS, TSr, N(PPK_NOTIFY)} ---> 165 N(PPK_NOTIFY) is a status notification payload with the type [TBA]; 166 it has a protocol ID of 0, and no SPI and no notification data 167 associated with it. 169 When the responder receives the initial encrypted exchange, it checks 170 to see if it received a notify within that exchange, is configured to 171 support PPK with the initiator's identity, and whether that use is 172 mandatory. If the notify was received, and the responder does have a 173 PPK for that identity, then it responds with the standard IKE 174 response with the PPK_NOTIFY notify message included, namely: 176 Initiator Responder 177 ------------------------------------------------------------------ 178 <--- HDR, SK {IDr, [CERT,] AUTH, 179 SAr2, TSi, TSr, N(PPK_NOTIFY)} 181 If the responder is not configured to support PPK with that identity, 182 it continues with the standard IKE protocol, not including the 183 notification. 185 If the responder is configured to support PPK with that identity, and 186 it does not receive the notification, then if the PPK usage is 187 configured as mandatory, it MUST abort the exchange. If the PPK 188 usage is configured as optional, it continues with the standard IKE 189 protocol, not including the notification. 191 This table summarizes the above logic by the responder 193 Received Nonce Have PPK PPK Mandatory Action 194 ------------------------------------------------------------------ 195 No No * Standard IKE protocol 196 No Yes No Standard IKE protocol 197 No Yes Yes Abort negotiation 198 Yes No * Standard IKE protocol 199 Yes Yes * Include PPK_NOTIFY Nonce 201 When the initiator receives the response, then (if it is configured 202 to use a PPK with the responder), then it checks for the presense of 203 the notification. If it receives one, it marks the SA as using the 204 configured PPK; if it does not receive one, it MUST either abort the 205 exchange (if the PPK was configured as mandatory), or it MUST 206 continue without using the PPK (if the PPK was configured as 207 optional). 209 The protocol continues as standard until it comes time to compute the 210 child SA keying material. 212 4. Creating Child SA Keying Material 214 When it comes time to generate the keying material for a child SA, 215 the implementation (both the initiator and the responder) checks to 216 see if they agreed to use a PPK. If they did, then they look up 217 (based on the peer's identity) the configured PPK, and then both 218 sides use one of these alternative formula (based on whether an 219 optional Diffie-Hellman was included): 221 Ni' = prf(PPK, Ni) 222 Nr' = prf(PPK, Nr) 223 KEYMAT = prf+(SK_d, Ni' | Nr') 225 or 227 Ni' = prf(PPK, Ni) 228 Nr' = prf(PPK, Nr) 229 KEYMAT = prf+(SK_d, g^ir (new) | Ni' | Nr') 231 where PPK is the configured postquantum preshared key, Ni, Nr are the 232 nonces from the IKE_SA_INIT exchange if this require is the first 233 Child SA created or the fresh Ni and Nr from the CREATE_CHILD_SA 234 exchange if this is a subsequent creation, and prf is the 235 pseudorandom function that was negotiated for this SA. 237 This is the standard IKE KEYMAT generation, except that the nonces 238 are transformed (via the negotiated PRF function) using the preshared 239 PPK value 240 We use this negotiated PRF, rather than negotiating a separate one, 241 because this PRF is agreed by both sides to have sufficient security 242 properties (otherwise, they would have negotiated something else), 243 and so that we don't need to specify a separate negotiation 244 procedure. 246 When you rekey an IKE SA (generating a fresh SKEYSEED), the initiator 247 and the responder will transform the nonces using the same PPK as 248 they used during the original IKE SA negotiation. That is, they will 249 use the alternate derivation: 251 Ni' = prf(PPK, Ni) 252 Nr' = prf(PPK, Nr) 253 SKEYSEED = prf( SK_d (old), g^ir (new) | Ni' | Nr' ) 254 (SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) = 255 prf+(SKEYSEED, Ni' | Nr' | SPIi | SPIr) 257 An implementation MAY rekey the initial IKE SA immediately after 258 negotiating it; this would reduce the amount of data available to an 259 attacker with a Quantum Computer 261 5. Security Considerations 263 Quantum computers are able to perform Grover's algorithm; that 264 effectively halves the size of a symmetric key. Because of this, the 265 user SHOULD ensure that the postquantum preshared key used has at 266 least 256 bits of entropy, in order to provide a 128 bit security 267 level. 269 Although this protocol preserves all the security properties of IKE 270 against adversaries with conventional computers, this protocol allows 271 an adversary with a Quantum Computer to decrypt all traffic encrypted 272 with the initial IKE SA. In particular, it allows the adversary to 273 recover the identities of both sides. If there is IKE traffic other 274 than the identities that need to be protected against such an 275 adversary, one suggestion would be to form an initial IKE SA (which 276 is used to exchange identities), perhaps by using the protocol 277 documented in RFC6023. Then, you would immediately create a child 278 IKE SA (which is used to exchange everything else). Because the 279 child IKE SA keys are a function of the PPK (among other things), 280 traffic protected by that SA is secure against Quantum capable 281 adversaries. 283 In addition, the policy SHOULD be set to negotiate only quantum- 284 resistant symmetric algorithms; while this RFC doesn't claim to give 285 advise as to what algorithms are secure (as that may change based on 286 future cryptographical results), here is a list of defined IKEv2 and 287 IPsec algorithms that should NOT be used, as they are known not to be 288 Quantum Resistant 290 Any IKE Encryption algorithm, PRF or Integrity algorithm with key 291 size <256 bits 293 Any ESP Transform with key size <256 bits 295 PRF_AES128_XCBC and PRF_AES128_CBC; even though they are defined to 296 be able to use an arbitrary key size, they convert it into a 128 bit 297 key internally 299 6. References 301 6.1. Normative References 303 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 304 Hashing for Message Authentication", RFC 2104, 305 DOI 10.17487/RFC2104, February 1997, 306 . 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, 310 DOI 10.17487/RFC2119, March 1997, 311 . 313 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 314 Kivinen, "Internet Key Exchange Protocol Version 2 315 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 316 2014, . 318 6.2. Informational References 320 [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A 321 Childless Initiation of the Internet Key Exchange Version 322 2 (IKEv2) Security Association (SA)", RFC 6023, 323 DOI 10.17487/RFC6023, October 2010, 324 . 326 [SPDP] McGrew, D., "A Secure Peer Discovery Protocol (SPDP)", 327 2001, . 329 Appendix A. Discussion and Rationale 331 The idea behind this is that while a Quantum Computer can easily 332 reconstruct the shared secret of an (EC)DH exchange, they cannot as 333 easily recover a secret from a symmetric exchange this makes the 334 IPsec KEYMAT and any child SA's SKEYSEED depend on both the symmetric 335 PPK, and also the Diffie-Hellman exchange. If we assume that the 336 attacker knows everything except the PPK during the key exchange, and 337 there are 2**n plausible PPK's, then a Quantum Computer (using 338 Grover's algorithm) would take O(2**(n/2)) time to recover the PPK. 339 So, even if the (EC)DH can be trivially solved, the attacker still 340 can't recover any key material (except for the SK values for the 341 initial IKE exchange) unless they can find the PPK, and that's too 342 difficult if the PPK has enough entropy (say, 256 bits). Note that 343 we do allow an attacker with a Quantum Computer to rederive the 344 keying material for the initial IKE SA; this was a compromise to 345 allow the responder to select the correct PPK quickly. 347 Another goal of this protocol is to minimize the number of changes 348 within the IKEv2 protocol, and in particular, within the cryptography 349 of IKEv2. By limiting our changes to notifications, and translating 350 the nonces, it is hoped that this would be implementable, even on 351 systems that perform much of the IKEv2 processing is in hardware. 353 A third goal was to be friendly to incremental deployment in 354 operational networks, for which we might not want to have a global 355 shared key, and also if we're rolling this out incrementally. This 356 is why we specifically try to allow the PPK to be dependent on the 357 peer, and why we allow the PPK to be configured as optional. 359 A fourth goal was to avoid violating any of the security goals of 360 IKEv2. 362 The third and fourth goals are in partial conflict. In order to 363 achieve postquantum security, we need to stir in the PPK when the 364 keys are computed, however the keys are computed before we know who 365 we're talking to (and so which PPK we should use). And, we can't 366 just tell the other side which PPK to use, as we might use different 367 PPK's for different peers, and so that would violate the anonymity 368 goal. If we just (for example) included a hash of the PPK, someone 369 listening in could easily tell when we're using the same PPK for 370 different exchanges, and thus deduce that the systems are related. 371 The compromise we selected was to stir in the PPK in all the derived 372 keys except the initial IKE SA keys, While this allows an attacker 373 with a Quantum Computer to recover the identities, a poll on the 374 IPsecME mailing list indicated that the majority of the people on the 375 list did not think anonymity was an important property within IKE. 376 We stir in the shared secret within the Child SA keying material; 377 this allows an implementation that wants to protect the other IKE- 378 based traffic to create an initial IKE SA to exchange identities, and 379 then immediately create a Child SA, and use that Child SA to exchange 380 the rest of the negotiation. 382 In addition, when we stir in the PPK, we always use it to modify a 383 nonce (using the negotiated PRF). We modify the nonce (rather than, 384 say, including the PPK in with the prf or prf+ computation directly) 385 so that this would be easier to implement on an hardware-based IKE 386 implementation; the prf computations might be built-in, but the 387 nonces would be external inputs, and so modifying those would 388 minimize the changes. 390 Appendix B. Acknowledgement 392 The idea of stirring in the PPK into the IPsec key generation process 393 was originally suggested on the list by Tero Kivinen. 395 Authors' Addresses 397 Scott Fluhrer 398 Cisco Systems 400 Email: sfluhrer@cisco.com 402 David McGrew 403 Cisco Systems 405 Email: mcgrew@cisco.com 407 Panos Kampanakis 408 Cisco Systems 410 Email: pkampana@cisco.com