idnits 2.17.1 draft-fluhrer-qr-ikev2-00.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 (September 10, 2015) is 3145 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 157, but not defined == Unused Reference: 'AES' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'RFC7296' is defined on line 267, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 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: March 13, 2016 Cisco Systems 6 September 10, 2015 8 An Extension for Postquantum Security using Preshared Keys for IKEv2 9 draft-fluhrer-qr-ikev2-00 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 March 13, 2016. 33 Copyright Notice 35 Copyright (c) 2015 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. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Computing SKEYSEED . . . . . . . . . . . . . . . . . . . 4 55 3.2. Verifying preshared key . . . . . . . . . . . . . . . . . 5 56 3.3. Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 5. Normative References . . . . . . . . . . . . . . . . . . . . 6 59 Appendix A. Discussion and Rationale . . . . . . . . . . . . . . 6 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 62 1. Introduction 64 It is an open question whether or not it is feasible to build a 65 quantum computer, but if it is, many of the cryptographic algorithms 66 and protocols currently in use would be insecure. A quantum computer 67 would be able to solve DH and ECDH problems, and this would imply 68 that the security of existing IKEv2 systems would be compromised. 69 IKEv1 when used with preshared keys does not share this 70 vulnerability, because those keys are one of the inputs to the key 71 derivation function. If the preshared key have sufficient entropy, 72 then the resulting system is believed to be quantum resistant. 74 This document describes a way to extend IKEv2 to have a similar 75 property; assuming that the two end systems share a long secret key, 76 then the resulting exchange is quantum resistant, that is, believed 77 to be invulnerable to an attacker with a Quantum Computer. By 78 bringing postquantum security to IKEv2, this note removes the need to 79 use an obsolete version of the Internet Key Exchange in order to 80 achieve that security goal. 82 The general idea is that we add an additional secret that is shared 83 between the initiator and the responder; this secret is in addition 84 to the authentication method that is already provided within IKEv2. 85 We stir in this secret when generating the IKE keys (along with the 86 parameters that IKEv2 normally uses); this secret adds quantum 87 resistance to the exchange. 89 It is important to minimize the changes to IKEv2. The existing 90 mechanisms to do authentication and key exchange remain in place 91 (that is, we continue to do (EC)DH, and potentially a PKI 92 authentication if configured). This does not replace the 93 authentication checks that the protocol does; instead, it is done as 94 a parallel check. 96 1.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. Assumptions 104 We assume that each IKE peer (both the initiator and the responder) 105 has an optional Postquantum Preshared Key (PPK) (potentially on a 106 per-peer basis), and also has a configurable flag that determines 107 whether this postquantum preshared key is mandatory. This preshared 108 key is independent of the preshared key (if any) that the IKEv2 109 protocol uses to perform authentication. 111 In addition, we assume that the initiator knows which PPK to use with 112 the peer it is initiating to (for instance, if it knows the peer, 113 then it can determine which PPK will be used). 115 3. Exchanges 117 If the initiator has a configured postquantum preshared key (whether 118 or not it is optional), then it will include a vendor ID payload in 119 its initial exchange as follows: 121 Initiator Responder 122 ------------------------------------------------------------------ 123 HDR, SAi1, KEi, Ni, VID ---> 125 The contents of this vendor ID payload MUST consist of: 127 o 16 byte fixed vendor id 129 o 16 random bytes 131 o 16 bytes of AES256(HMAC_SHA256(ppk, "A"), random_bytes) 133 The 16 byte fixed vendor id consists of: 135 0x26, 0x9c, 0x82, 0x00, 0x36, 0x8a, 0xf5, 0x3b, 136 0x85, 0xd9, 0xde, 0x63, 0x6b, 0x3b, 0x29, 0xa4 138 this is the MD5 of "Quantum Resistant Secret Hash". 140 That is, we use HMAC_SHA256(ppk, "A") as the 256 bit AES key to 141 encrypt the 16 random bytes (in ECB mode), where "A" is a string 142 consisting of a single 0x41 octet. 144 When the responder receives this vendor ID, it scans through its list 145 of configured postquantum preshared keys, and determines which one it 146 is (by computing AES256(HMAC(ppk, "A"), Nonce) and comparing that 147 value to the 16 bytes within the payload. 149 If the responder finds a value that matches the payload for a 150 particular PPK, that indicates that the intiator and responder share 151 a PPK and can make use of this extension. Upon finding such a 152 preshared key, the responder includes a vendor ID payload with the 153 response: 155 Initiator Responder 156 ------------------------------------------------------------------ 157 <--- HDR, SAr1, Ker, Nr, [CERTREQ], VID 159 The contents of this vendor ID payload MUST consist of: 161 o 16 byte fixed vendor id 163 The 16 byte fixed vendor id consists of: 165 0x26, 0x9c, 0x82, 0x00, 0x36, 0x8a, 0xf5, 0x3b, 166 0x85, 0xd9, 0xde, 0x63, 0x6b, 0x3b, 0x29, 0xa4 168 this is the MD5 of "Quantum Resistant Secret Hash". 170 The random value and its encryption are not included in the VID this 171 time. This VID serves as a postquantum preshared key confirmation. 173 If the responder does not find such a preshared key, then it MAY 174 continue with the protocol without including a vendor ID (if it is 175 configured to not have mandatory preshared keys), or it MAY abort the 176 exchange (if it configured to make preshared keys mandatory). 178 When the initiator receives the response, it KUST check for the 179 presence of the vendor ID. If it receives one, it marks the SA as 180 using the configured preshared key; if it does not receive one, it 181 MAY either abort the exchange (if the preshared key was configured as 182 mandatory), or it MAY continue without using the preshared key (if 183 the preshared key was configured as optional). 185 3.1. Computing SKEYSEED 187 When it comes time to generate the keying material during the initial 188 Exchange, the implementation (both the initiator and the responder) 189 checks to see if there was an agreed-upon preshared key. If there 190 was, then both sides use this alternative formula: 192 SKEYSEED = prf(HMAC_SHA256(ppk, Ni) | HMAC_SHA256(ppk, Nr), g^ir) 193 (SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) = 194 prf+(SKEYSEED, HMAC_SHA256(ppk, Ni) | HMAC_SHA256(ppk, Nr) | 195 SPIi | SPIr) 197 where ppk is the postquantum preshared key, Ni, Nr are the nonces 198 exchanged in the IKEv2 exchange (and not the nonces used in the 199 vendor id;apos;s), HMAC_SHA256(a, b) uses 'a' as the key, and 'b' as 200 the text, and g^ir is the Diffie-Hellman shared secret. 202 3.2. Verifying preshared key 204 Once both the initiator and the responder have exchanged identities, 205 they both double-check with their policy database to verify that they 206 were configured to use those preshared keys when negotiating with the 207 peer. If they are not, they MUST abort the exchange. 209 3.3. Child SAs 211 When you create a child SA, the initiator and the responder will 212 transform the nonces using the same ppk as they used during the 213 original IKE SA negotiation. That is, they will use one of the 214 alternative derivations (depending on whether an optional Diffie- 215 Hellman was included): 217 KEYMAT = prf+(SK_d, HMAC_SHA256(ppk, Ni) | HMAC_SHA256(ppk, Nr)) 219 or 221 KEYMAT = prf+(SK_d, g^ir (new) | 222 HMAC_SHA256(ppk, Ni) | HMAC_SHA256(ppk, Nr)) 224 When you rekey an IKE SA (generating a fresh SKEYSEED), the initiator 225 and the responder will transform the nonces using the same ppk as 226 they used during the original IKE SA negotiation. That is, they will 227 use the alternate derivation: 229 SKEYSEED = prf( SK_d (old), g^ir (new) | 230 HMAC_SHA256(ppk, Ni) | HMAC_SHA256(ppk, Nr)) 231 (SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) = 232 prf+(SKEYSEED, HMAC_SHA256(ppk, Ni) | HMAC_SHA256(ppk, Nr) | 233 SPIi | SPIr) 235 4. Security Considerations 237 Quantum computers are able to perform Grover's algorithm; that 238 effectively halves the size of a symmetric key. Because of this, the 239 user SHOULD ensure that the postquantum preshared key used has at 240 least 256 bits of entropy, in order to provide a 128 bit security 241 level. 243 In addition, the policy SHOULD be set to negotiate only quantum- 244 resistant symmetric algorithms (AES-256, SHA-256 or better). 246 The random values within the vendor ID are there to prevent anyone 247 from deducing whether two different exchanges use the same ppk 248 values. To prevent such a leakage, every exchange SHOULD use a fresh 249 16 byte random value. Violating this places the anonymity at risk; 250 however it has no other security implication. 252 5. Normative References 254 [AES] National Institute of Technology, "Specification for the 255 Advanced Encryption Standard (AES)", 2001, . 257 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 258 Hashing for Message Authentication", RFC 2104, 259 DOI 10.17487/RFC2104, February 1997, 260 . 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, 264 DOI 10.17487/RFC2119, March 1997, 265 . 267 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 268 Kivinen, "Internet Key Exchange Protocol Version 2 269 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 270 2014, . 272 Appendix A. Discussion and Rationale 274 The idea behind this is that while a Quantum Computer can easily 275 reconstruct the shared secret of an (EC)DH exchange, they cannot as 276 easily recover a secret from a symmetric exchange this makes the 277 SKEYSEED depend on both the symmetric ppk, and also the Diffie- 278 Hellman exchange. If we assume that the attacker knows everything 279 except the ppk during the key exchange, and there are 2**n plausible 280 ppk's, then a Quantum Computer (using Grover's algorithm) would take 281 O(2**(n/2)) time to recover the ppk. So, even if the (EC)DH can be 282 trivially solved, the attacker still can't recover any key material 283 unless they can find the ppk, and that's too difficult if the ppk has 284 enough entropy (say, 256 bits). 286 Another goal of this protocol is to minimize the number of changes 287 within the IKEv2 protocol, and in particular, within the cryptography 288 of IKEv2. By limiting our changes to vendor id's, and translating 289 the nonces, it is hoped that this would be implementable, even on 290 systems that perform much of the IKEv2 processing is in hardware. 292 A third goal was to be friendly to incremental deployment in 293 operational networks, for which we might not want to have a global 294 shared key, and also if we're rolling this out incrementally. This 295 is why we specifically try to allow the ppk to be dependent on the 296 peer, and why we allow the ppk to be configured as optional. 298 A fourth goal was to avoid violating any of the security goals of 299 IKEv2. One such goal is anonymity; that someone listening into the 300 exchanges cannot easily determine who is negotiating with whom. 302 The third and fourth goals are in partial conflict. In order to 303 achieve postquantum security, we need to stir in the ppk when the 304 keys are computed, however the keys are computed before we know who 305 we're talking to (and so which ppk we should use). And, we can't 306 just tell the other side which ppk to use, as we might use different 307 ppk's for different peers, and so that would violate the anonymity 308 goal. If we just (for example) included a hash of the ppk, someone 309 listening in could easily tell when we're using the same ppk for 310 different exchanges, and thus deduce that the systems are related. 311 The compromise we selected was to include enough information that 312 someone who knows the ppk can recognize it, however someone who 313 doesn't know the ppk learns nothing. However, one issue with this is 314 that the responder needs to do a linear scan over all ppk's it has 315 been configured with; this is not ideal, but it's the best compromise 316 we can come up with. And, the current protocol (of having the 317 initiator send an R, Enc(R) pair in the vendor id) doesn't allow 318 anyone who doesn't know the vendor id have no information whether two 319 exchanges use the same ppk or not. 321 An alternative approach to solve this problem without a linear scan 322 would be to do a normal (non-QR) IKEv2 exchange, and when the two 323 sides obtain identities, see if they need to be QR, and if so, create 324 an immediate IKEv2 child SA (using the ppk). One issue with this is 325 that someone with a quantum computer could deduce the identities 326 used. 328 A slightly different approach to try to make this even more friendly 329 to IKEv2-based cryptographic hardware might be to use invertible 330 cryptography when we present the nonces to the kdf. The idea here is 331 in case we have IKEv2 hardware that insists on selecting its own 332 nonces (and so we won't be able to give a difference nonce to the 333 KDF); instead, we encrypt the nonce that we send (and decrypt the 334 nonce that we get). Of course, this means that the responder will 335 need to figure out which ppk we're using up front (based on the 336 vendor id); we're not sure if this idea would be a net improvement 337 (especially since the transform we're proposing now is 338 cryptographically secure and simple). 340 The reasoning behind the cryptography used: the values we use in the 341 vendor id's are cryptographically independent of the values used 342 during the SKEYSEED generation (because HMAC_SHA256(ppk, A) is 343 independent of HMAC_SHA256(ppk, B) if A and B are different strings 344 (and as any real nonce must be longer than a single byte, there is 345 never a collision between that and \quot;A\quot;. This independent 346 stems from the assumption that SHA-256 is a secure MAC. This was 347 chosen over more ad hoc designs where the two uses of the ppk would 348 appear to be independent (but that doesn't follow from any standard 349 cryptographical assumption. The method of encoding the ppk within 350 the vendor id (using AES-256) was chosen as it met two goals: 352 o Anonymity; given A, AES256_K1(A), B, AES256_K2(B), it's fairly 353 obvious that gives someone (even if they have a quantum computer) 354 no clue about whether K1==K2 (unless either A==B or AES256_K1(A)== 355 AES256_K2(B); both highly unlikely events if A and B are chosen 356 randomly). 358 o Performance during the linear search; a server could preexpand the 359 AES keys, and so comparing a potential ppk against an vendor id 360 from the initiator would amount to performing a single AES block 361 encryption and then doing a 16 byte comparison. 363 The first goal is considered important; one of the goals of IKEv2 is 364 to provide anonymity. The second is considered important because the 365 linear scan directly affects scalability. While this draft requires 366 a linear scan over all ppk's known by the responder (it is unknown 367 how to avoid this without leaking when the same ppk is being 368 negotiated by two different exchanges), this use of AES makes this 369 linear scan as cheap as possible. We don't know how to avoid the 370 linear scan, so making the scan cheap (while not compromising on 371 security) was considered important. 373 One thing that this draft does not address is algorithm agility; it 374 specifies that we'll use HMAC-SHA256 and AES256, and does not allow 375 any alternatives. This might change in a latter version of this 376 draft. 378 Authors' Addresses 380 Scott Fluhrer 381 Cisco Systems 383 Email: sfluhrer@cisco.com 384 David McGrew 385 Cisco Systems 387 Email: mcgrew@cisco.com 389 Panos Kampanakis 390 Cisco Systems 392 Email: pkampana@cisco.com