idnits 2.17.1 draft-kuegler-ipsecme-pace-ikev2-10.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 date (April 18, 2012) is 4391 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Kuegler 3 Internet-Draft Bundesamt fuer Sicherheit in der 4 Intended status: Experimental Informationstechnik (BSI) 5 Expires: October 20, 2012 Y. Sheffer 6 Porticor 7 April 18, 2012 9 Password Authenticated Connection Establishment with IKEv2 10 draft-kuegler-ipsecme-pace-ikev2-10 12 Abstract 14 IKEv2 does not allow secure peer authentication when using short 15 credential strings, i.e. passwords. Several proposals have been made 16 to integrate password-authentication protocols into IKE. This 17 document provides an adaptation of PACE (Password Authenticated 18 Connection Establishment) to the setting of IKEv2 and demonstrates 19 the advantages of this integration. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 20, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. The IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . 7 60 3.2. The IKE_AUTH Exchange, Round #1 . . . . . . . . . . . . . 7 61 3.3. The IKE_AUTH Exchange, Round #2 . . . . . . . . . . . . . 8 62 3.4. Creating a Long Term Shared Secret . . . . . . . . . . . . 9 63 3.5. Using the Long Term Shared Secret . . . . . . . . . . . . 10 64 4. Encrypting and Mapping the Nonce . . . . . . . . . . . . . . . 11 65 4.1. Encrypting the Nonce . . . . . . . . . . . . . . . . . . . 11 66 4.2. Mapping the Nonce . . . . . . . . . . . . . . . . . . . . 12 67 4.2.1. MODP Diffie-Hellman . . . . . . . . . . . . . . . . . 12 68 4.2.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 13 69 4.2.3. Validation . . . . . . . . . . . . . . . . . . . . . . 13 70 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 13 71 5.1. Password Processing . . . . . . . . . . . . . . . . . . . 13 72 5.2. The SECURE_PASSWORD_METHODS Notification . . . . . . . . . 13 73 5.3. The PSK_PERSIST Notification . . . . . . . . . . . . . . . 14 74 5.4. The PSK_CONFIRM Notification . . . . . . . . . . . . . . . 15 75 5.5. The GSPM(ENONCE) Payload . . . . . . . . . . . . . . . . . 15 76 5.6. The KE (KEi2/KEr2) Payloads in PACE . . . . . . . . . . . 15 77 5.7. PACE and Session Resumption . . . . . . . . . . . . . . . 16 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 6.1. Credential Security Assumptions . . . . . . . . . . . . . 16 80 6.2. Vulnerability to Passive and Active Attacks . . . . . . . 16 81 6.3. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 16 82 6.4. Randomness . . . . . . . . . . . . . . . . . . . . . . . . 17 83 6.5. Identity Protection . . . . . . . . . . . . . . . . . . . 17 84 6.6. Denial of Service . . . . . . . . . . . . . . . . . . . . 17 85 6.7. Choice of Encryption Algorithms . . . . . . . . . . . . . 17 86 6.8. Security Model and Security Proof . . . . . . . . . . . . 17 87 6.9. Long-Term Credential Storage . . . . . . . . . . . . . . . 18 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 93 Appendix A. Protocol Selection Criteria . . . . . . . . . . . . . 20 94 A.1. Security Criteria . . . . . . . . . . . . . . . . . . . . 20 95 A.2. Intellectual Property Criteria . . . . . . . . . . . . . . 20 96 A.3. Miscellaneous Criteria . . . . . . . . . . . . . . . . . . 20 97 Appendix B. Password Salting . . . . . . . . . . . . . . . . . . 21 98 B.1. Solving the Asymmetric Case with Symmetric Cryptography . 22 99 B.2. Solving the Fully Symmetric Case with Asymmetric 100 Cryptography . . . . . . . . . . . . . . . . . . . . . . . 22 101 B.3. Generation of a Long Shared Secret . . . . . . . . . . . . 23 102 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 23 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 105 1. Introduction 107 PACE [TR03110] is a security protocol that establishes a mutually 108 authenticated (and encrypted) channel between two parties based on 109 weak (short) passwords. PACE provides strong session keys that are 110 independent of the strength of the password. PACE belongs to a 111 family of protocols often referred to as Zero-Knowledge Password 112 Proof (ZKPP) protocols, all of which amplify weak passwords into 113 strong session keys. This draft describes the integration of PACE 114 into IKEv2 [RFC5996] as a new authentication mode, analogous to the 115 existing certificate and PSK authentication modes. 117 Some of the advantages of our approach, compared to the existing 118 IKEv2, include: 119 o The current best practice to implement password authentication in 120 IKE involves certificate-based authentication of the server plus 121 some EAP method to authenticate the client. This involves two 122 non-trivial infrastructure components (PKI and EAP/AAA). 123 Moreover, certificate authentication is hard to get right, and 124 often depends for its security on unreliable user behavior. 125 o Alternatively, native IKEv2 shared secret authentication can be 126 used with passwords. This usage however is insecure, specifically 127 it is vulnerable to active attackers. 128 o Some newer EAP methods can be used for mutual authentication, and 129 combined with [RFC5998] can be well integrated into IKEv2. This 130 is certainly an option in some cases, but the current proposal may 131 be simpler to implement. 132 Compared to other protocols aiming at similar goals, PACE has several 133 advantages. PACE was designed to allow for a high level of 134 flexibility with respect to cryptographic algorithms, e.g. it can be 135 implemented based on standard Diffie-Hellman as well as Elliptic 136 Curve Diffie-Hellman without any restrictions on the mathematical 137 group to be used other than the requirement that the group is 138 cryptographically secure. The protocol itself is also proven to be 139 cryptographically secure [PACEsec]. The PACE protocol is currently 140 used in an international standard for digital travel documents 141 [ICAO]. 143 The integration aims at keeping as much as possible of IKEv2 144 unchanged, e.g. the mechanisms used to establish Child SAs as 145 provided by IKEv2 are maintained with no change. 147 The PAKE Framework document [RFC6467] defines a set of payloads for 148 different types of PAKE methods within IKEv2. This document reuses 149 this framework. Note that the current document is self-contained, 150 i.e. all relevant payloads and semantics are redefined here. 152 1.1. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 The following notation is used in this draft: 160 E() Symmetric encryption 161 D() Symmetric decryption 162 KA() Key agreement 163 Map() Mapping function 164 Pwd Shared password 165 SPwd Stored password 166 KPwd Symmetric key derived from a password Pwd 167 G Static group generator 168 GE Ephemeral group generator 169 ENONCE Encrypted nonce 170 PKEi Ephemeral public key of the initiator 171 SKEi Ephemeral secret key of the initiator 172 PKEr Ephemeral public key of the responder 173 SKEr Ephemeral secret key of the responder 174 AUTH Authentication payload 176 Any other notation used here is defined in [RFC5996]. 178 2. Overview 180 At a high level the following steps are performed by the initiator 181 and the responder. They result in a two-round IKE_AUTH exchange, 182 described in Section 3 below. 183 1. The initiator randomly and uniformly chooses a nonce s, encrypts 184 the nonce using the password, and sends the ciphertext 186 ENONCE = E(KPwd, s) 188 to the responder. The responder recovers the plaintext nonce s 189 with the help of the shared password Pwd. 190 2. The nonce s is mapped to an ephemeral generator 192 GE = G^s * SASharedSecret, 194 where G is the generator of the selected MODP group and 195 SASharedSecret is a shared secret that has been generated in the 196 IKE_SA_INIT step. 198 3. Both the initiator and the responder each calculate an ephemeral 199 key pair 201 (SKEi, PKEi = GE^SKEi) and (SKEr, PKEr=GE^SKEr), 203 respectively, based on the ephemeral generator GE and exchange 204 the public keys. 205 4. Finally, they compute the shared secret 207 PACESharedSecret = PKEi^SKEr = PKEr^SKEi 209 and generate, exchange, and verify the IKE authentication token 210 AUTH using the shared secret PACESharedSecret. 212 The encryption function E() must be carefully chosen to prevent 213 dictionary attacks that would otherwise allow an attacker to recover 214 the password. Those restrictions are described in Section 4.1. 215 Details on the mapping function including the elliptic curve variant 216 can be found in Section 4.2. 218 To avoid the risks inherent in storing a short password (e.g. the 219 fact that passwords are often reused for different applications), 220 this protocol allows the peers to jointly convert the password into a 221 cryptographically stronger shared secret. This shared secret can 222 then be stored by both peers, in lieu of the original password or its 223 salted variants. 225 3. Protocol Sequence 227 The protocol consists of three round trips, IKE_SA_INIT, and a 228 2-round IKE_AUTH exchange, as shown in the next figure. An optional 229 Informational exchange may follow (see Section 3.4). 231 Initiator Responder 232 --------- --------- 234 IKE_SA_INIT: 236 HDR, SAi1, KEi, Ni, N(SECURE_PASSWORD_METHODS) -> 238 <- HDR, SAr1, KEr, Nr, N(SECURE_PASSWORD_METHODS) 240 IKE_AUTH round #1: 242 HDR, SK{IDi, [IDr,], SAi2, 243 TSi, TSr, GSPM(ENONCE), KEi2} -> 245 <- HDR, SK{IDr, KEr2} 247 IKE_AUTH round #2: 249 HDR, SK{AUTH [, N(PSK_PERSIST)] } -> 251 <- HDR, SK{AUTH, SAr2, TSi, TSr [, N(PSK_PERSIST)] } 253 Figure 1: IKE SA Setup with PACE 255 3.1. The IKE_SA_INIT Exchange 257 The initiator sends a SECURE_PASSWORD_METHODS notification that 258 indicates its support of this extension, and its wish to authenticate 259 using a password. The following text assumes that the responder sent 260 back a SECURE_PASSWORD_METHODS notification that indicates its 261 preference for PACE. 263 If PACE was chosen, the algorithms negotiated in SAi1 and SAr1 are 264 also used for the execution of PACE, i.e. the key agreement protocol 265 (standard Diffie-Hellman or Elliptic Curve Diffie-Hellman), the group 266 to be used, and the encryption algorithm. 268 3.2. The IKE_AUTH Exchange, Round #1 270 This is the first part of the PACE authentication of the peers. This 271 exchange MUST NOT be used unless both peers indicated support of this 272 protocol. 274 The initiator selects a random nonce s and encrypts it to form ENONCE 275 using the password Pwd, as described in Section 4.1. Then the 276 initiator maps the nonce to an ephemeral generator GE of the group as 277 described in Section 4.2, chooses randomly and uniformly an ephemeral 278 key pair (SKEi,PKEi) based on the ephemeral generator and finally 279 generates the payloads GSPM(ENONCE) containing the encrypted nonce 280 and KEi2 containing the ephemeral public key. 282 The responder decrypts the received encrypted nonce s = D(KPwd, 283 ENONCE), performs the mapping and randomly and uniformly chooses an 284 ephemeral key pair (SKEr,PKEr) based on the ephemeral generator GE. 285 The responder generates the KEr2 payload containing the ephemeral 286 public key. 288 During the Diffie-Hellman key agreement, each party MUST check that 289 the two public keys PKEi and PKEr differ. Otherwise, it MUST abort 290 the protocol. 292 The request is equivalent to the IKE_AUTH request in a normal IKEv2 293 exchange, i.e. any payload which is valid in an IKE_AUTH request is 294 valid (with the same semantics) in this round's request. In 295 particular, certificate-related payloads are allowed, even though 296 their use may not be practical within this mode. 298 3.3. The IKE_AUTH Exchange, Round #2 300 This is the second part of the PACE authentication of the peers. 302 The initiator and the responder calculate the shared secret 303 PACESharedSecret: 305 PACESharedSecret = KA(SKEi, PKEr, GE) = KA(SKEr, PKEi, GE), 307 where KA denotes the Diffie-Hellman key agreement, e.g. (for MODP 308 groups) modular exponentiation. Then they calculate the 309 authentication tokens AUTHi and AUTHr. 311 The initiator calculates: 313 AUTHi = prf(prf+(Ni | Nr, PACESharedSecret), 314 | PKEr) 316 See Sec. 2.15 of [RFC5996] for the definition of signed octets. 318 The responder calculates: 320 AUTHr = prf(prf+(Ni | Nr, PACESharedSecret), 321 | PKEi) 323 Both AUTH payloads MUST indicate as their authentication method the 324 Generic Secure Password Authentication Method [RFC6467], whose value 325 is 12. The authentication tokens are exchanged and each of them MUST 326 be verified by the other party. The behavior when this verification 327 fails is unchanged from [RFC5996]. 329 Each of the peers MAY generate a long term credential at this point, 330 after it has verified the opposite peer's identity. The shared 331 secret is: 333 LongTermSecret = prf(Ni | Nr, "PACE Generated PSK" | 334 PACESharedSecret) 335 where the literal string is ASCII-encoded, with no zero terminator. 336 The generated secret MUST be persisted to stable memory before 337 sending the response. See Section 3.4 for more details about this 338 facility. 340 This round's response is equivalent to the IKE_AUTH response in a 341 normal IKEv2 exchange, i.e. any payload which is valid in an IKE_AUTH 342 response is valid (with the same semantics) in the second round's 343 response. 345 Following authentication, all temporary values MUST be deleted by the 346 peers, including in particular s, the ephemeral generator, the 347 ephemeral key pairs, and PACESharedSecret. 349 3.4. Creating a Long Term Shared Secret 351 To reduce the time that the peers store a hashed password, it is 352 RECOMMENDED to replace the password by a dedicated shared secret, 353 according to the method described in this section. See Appendix B 354 for more discussion of the security threats involved. 356 Both peers generate the value LongTermSecret during round #2 of 357 IKE_AUTH, as shown above. Later on, they exchange a PERSIST_PSK 358 notification. Assume both peers support this mechanism, e.g. the IKE 359 implementation is able to modify its own credential store. Then each 360 of the peers, when receiving the notification, permanently deletes 361 the stored password and replaces it with LongTermSecret. These 362 credentials are stored in the Peer Authorization Database (PAD) 363 [RFC4301] and are associated with the identity of the opposite peer. 365 This solution is designed as a two-phase commitment, so that failure 366 at any time cannot result in the peers not having any shared secret. 368 Initiator Responder 369 --------- --------- 371 IKE_AUTH round #2: 373 HDR, SK{..., N(PSK_PERIST)} ----------> 374 Responder computes and stores PSK 376 <------- HDR, SK{..., N(PSK_PERSIST)} 378 Initiator computes and stores PSK 380 HDR, SK{N(PSK_CONFIRM)} --------------> 382 Responder deletes the short password 384 <-------------- HDR, SK{N(PSK_CONFIRM)} 386 Initiator deletes the short password 388 Figure 2: IKE SA Setup with PACE and PSK Generation 390 In the second round of IKE_AUTH, the initiator MAY send a PSK_PERSIST 391 notification if it wishes to use this mechanism. If the responder 392 agrees, and only after it has authenicated the initiator, it MUST 393 generate a new PSK, store it to stable storage (e.g. to disk), and 394 MUST respond with a PSK_PERSIST notification. Otherwise it simply 395 does not include the notification in its reply. When receiving the 396 reply, and after authenticating the responder, the initiator MUST 397 also generate the PSK and save it in stable storage. 399 If the peers have negotiated this mechanism, the initiator MUST send 400 the PSK_CONFIRM notification in an Informational exchange shortly 401 after the IKE SA has been set up. When the responder receives it, it 402 MUST delete the stored short password from its credential database, 403 and respond with a PSK_CONFIRM notification. Upon receiving this 404 notification, the initiator deletes its copy of the short password. 406 If not saved to persistent storage, the LongTermSecret MUST be 407 deleted when the IKE SA is rekeyed or when it is torn down. It 408 SHOULD be deleted 1 hour after the initial IKE SA has been set up. 410 3.5. Using the Long Term Shared Secret 412 The LongTermSecret MUST be used as a regular IKE PSK, rather than 413 with PACE or any other password-based authentication method. 415 Normally at the completion of this protocol, both peers will have 416 either a shared password or a shared PSK. The protocol is designed 417 so that the peers will have a shared credential, regardless of any 418 protocol failures. However in some failure cases, the initiator may 419 find itself with both a short password and a PSK for a particular 420 peer. In that case, it MUST first try to authenticate with a 421 password, and upon success, MUST attempt to convert it to a PSK. If 422 password authentication fails, it MUST use the PSK and upon 423 successful setup of the IKE SA, MUST permanently delete the password. 425 4. Encrypting and Mapping the Nonce 427 4.1. Encrypting the Nonce 429 The shared password is not used as-is. Instead, it SHOULD be 430 converted into a "stored password" SPwd, so that the plaintext 431 password does not need to be stored for long periods. SPwd is 432 defined as: 434 SPwd = prf("IKE with PACE", Pwd) 436 where the literal string consists of ASCII characters with no zero 437 terminator. If the negotiated prf requires a fixed-size key, the 438 literal string is either truncated or padded with zero octets on the 439 right, as needed. 441 KPwd = prf+(Ni | Nr, SPwd) 443 where Ni and Nr are the regular IKE nonces, stripped of any headers. 444 If the negotiated prf takes a fixed-length key and the lengths of Ni 445 and Nr do not add up to that length, half the bits must come from Ni 446 and half from Nr, taking the first bits of each. "prf+" is defined in 447 Sec. 2.13 of [RFC5996]. The length of KPwd is determined by the key 448 length of the negotiated encryption algorithm. 450 A nonce s is randomly selected by the initiator (see Section 6.4 for 451 additional considerations). The length of s MUST be exactly 32 452 octets. 454 Note: Padding MUST NOT be used when encrypting the nonce. The size 455 of the nonce has been chosen such that it can be encrypted with block 456 ciphers having block sizes of 32, 64, and 128 bit without any 457 padding. 459 If an authenticated encryption cipher [RFC5282] has been negotiated 460 for the IKE SA, it MUST NOT be used as-is because such use would be 461 vulnerable to dictionary attacks. Instead, the corresponding 462 unauthenticated mode MUST be used. All GCM and all CCM encryption 463 algorithms are mapped to the corresponding counter-mode algorithm. 464 For example, if the negotiated encryption algorithm (Transform Type 465 1) is "AES-GCM with a 8 octet ICV", then ENCR_AES_CTR (with the same 466 key length) is used to encrypt the nonce. If such a mapping does not 467 exist for a particular cipher, then it MUST NOT be used within the 468 current protocol. 470 KPwd is now used with the encryption transform to encrypt the nonce: 472 ENONCE = E(KPwd, s) 474 If an Initialization Vector (IV) is required by the cipher, it MUST 475 be included in the GSPM(ENONCE) payload. It is RECOMMENDED to choose 476 the IV randomly and uniformly distributed, even though this condition 477 is not necessary for the cryptographic security of the protocol. 479 4.2. Mapping the Nonce 481 The mapping is based on a second anonymous Diffie-Hellman key 482 agreement protocol to create a shared secret which is used together 483 with the exchanged nonce to calculate a common secret generator of 484 the group. 486 While in [TR03110] the generation of the shared secret is part of the 487 mapping, in the setting of IKEv2 a shared secret SASharedSecret has 488 already been generated as part of the IKE_SA_INIT step. Using the 489 notation of [RFC5996], 491 SASharedSecret = g^ir 493 Let G and GE be the generator of the negotiated DH group, and the 494 calculated ephemeral generator, respectively. The following 495 subsections describe the mapping for different Diffie-Hellman 496 variants. 498 4.2.1. MODP Diffie-Hellman 500 The function Map:G->GE is defined as GE = G^s * SASharedSecret. 502 Note that the protocol will fail if G^s = 1/SASharedSecret. If s is 503 chosen randomly, this event occurs with negligible probability. In 504 implementations that detect such a failure, the initiator SHOULD 505 choose s again. 507 4.2.2. Elliptic Curve Diffie-Hellman 509 The function Map:G->GE is defined as GE = s*G + SASharedSecret. 511 Note that the protocol will fail if s*G = -SharedSecret. If s is 512 chosen randomly, this event occurs with negligible probability. In 513 implementations that detect such a failure, the initiator SHOULD 514 choose s again. 516 4.2.3. Validation 518 Implementations MUST verify that the shared secrets SASharedSecret 519 and PACESharedSecret are elements of the group generated by G to 520 prevent small subgroup attacks. 522 It is RECOMMENDED to use the public key validation method or the 523 compatible cofactor exponentiation described in Section 3.1 and 524 Section 3.4, respectively, of [RFC2785]. The Elliptic Curve 525 equivalents of those methods are described in more detail in 526 [TR03111]. 528 Any failure in the validation MUST be interpreted as an attack, and 529 the protocol SHALL be aborted. 531 5. Protocol Details 533 5.1. Password Processing 535 The input password string SHOULD be processed according to the rules 536 of the [RFC4013] profile of [RFC3454]. A password SHOULD be 537 considered a "stored string" per [RFC3454] and unassigned code points 538 are therefore prohibited. The output is the binary representation of 539 the processed UTF-8 character string. Prohibited output and 540 unassigned codepoints encountered in SASLprep preprocessing SHOULD 541 cause a preprocessing failure and the output SHOULD NOT be used. A 542 compliant implementation MUST NOT apply any other form of processing 543 to the input password, other than as described in this section. 545 See Sec. 3 of [RFC4013] for examples of SASLprep processing. 547 5.2. The SECURE_PASSWORD_METHODS Notification 549 [RFC6467] defines a new type of Notify payload to indicate support 550 for Secure Password Methods (SPM) in the IKE_SA_INIT exchange. The 551 SPM Notify payload is defined as follows: 553 1 2 3 554 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Next Payload |C| RESERVED | Payload Length | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Protocol ID | SPI Size | Notify Message Type | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | | 561 ~ Security Parameter Index (SPI) ~ 562 | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | | 565 ~ Notification Data ~ 566 | | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 3: SECURE_PASSWORD_METHODS Payload Structure 571 The Protocol ID is zero, and the SPI Size is also zero, indicating 572 that the SPI field is empty. The Notify Message Type is 573 SECURE_PASSWORD_METHODS (value 16424). 575 The Notification Data contains the list of the 16-bit secure password 576 method numbers: 578 1 2 3 579 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Secure Password Method #1 | Secure Password Method #2 | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Secure Password Method #3 | ... | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Figure 4: SECURE_PASSWORD_METHODS Payload Data 588 For the current method, the list of proposed methods MUST include the 589 value PACE, which is TBD by IANA. 591 5.3. The PSK_PERSIST Notification 593 This document defines the PSK_PERSIST notification type, whose value 594 is TBD by IANA. This notification MUST be sent with no data. 595 However, for future extensibility, the receiver MUST ignore any 596 notification data if such data is present. 598 5.4. The PSK_CONFIRM Notification 600 This document defines the PSK_CONFIRM notification type, whose value 601 is TBD by IANA. This notification MUST be sent with no data. 602 However, for future extensibility, the receiver MUST ignore any 603 notification data if such data is present. 605 5.5. The GSPM(ENONCE) Payload 607 This protocol defines the ENONCE (encrypted nonce) payload, which 608 reuses the GSPM payload type [RFC6467] (value 49). Its format is as 609 follows: 611 0 1 2 3 612 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Next Payload |C| RESERVED | Payload Length | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | PACE-RESERVED | Initialization Vector | 617 +-+-+-+-+-+-+-+-+ + 618 | (optional, length depends on the encryption algorithm) | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Encrypted Nonce ~ 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 ~ | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Figure 5: ENONCE Payload Structure 627 See Section 4.1 for further details about the encrypted nonce. Note 628 that the protocol, and in particular this payload's format, does not 629 support any padding of the encrypted data. 631 The PACE-RESERVED field must be sent as zero, and must be rejected by 632 the receiver if it is not 0. 634 5.6. The KE (KEi2/KEr2) Payloads in PACE 636 PACE reuses the KE payload for its Diffie-Hellman exchange, with the 637 new payloads being sent within the IKE_AUTH exchange. Since only one 638 Diffie-Hellman group is negotiated, the group denoted by these 639 payloads MUST be identical to the one used in the "regular" KE 640 payloads in IKE_SA_INIT. 642 5.7. PACE and Session Resumption 644 A session resumption [RFC5723] ticket may be requested during the 645 IKE_AUTH exchange. The request MUST be sent in the request of the 646 first round, and any response MUST be sent in the response of the 647 second one. 649 PACE should be considered an "authentication method", in the sense of 650 Sec. 5 of [RFC5723], which means that its use MUST be noted in the 651 protected ticket. The format of the ticket is not standardized, 652 however we RECOMMEND that this indication should distinguish between 653 the different secure password authentication methods defined for IKE. 655 Note that even if the initial authentication used PACE and its 656 extended IKE_AUTH, session resumption will still include the normal 657 IKE_AUTH exchange. 659 6. Security Considerations 661 A major goal of this protocol has been to maintain the level of 662 security provided by IKEv2. What follows is an analysis of this 663 protocol. The reader is referred to [RFC5996] for the generic IKEv2 664 security considerations. 666 6.1. Credential Security Assumptions 668 This protocol makes no assumption on the strength of the shared 669 credential. Best common practices regarding minimal password length, 670 use of multiple character classes etc. SHOULD be followed. 672 6.2. Vulnerability to Passive and Active Attacks 674 The protocol is secure against both passive and active attackers. 675 See Section 6.8 for a security proof. 677 While not attacking the cryptography, an attacker can still perform a 678 standard password guessing attack. To mitigate such attacks, an 679 implementation MUST include standard protections, such as rate 680 limiting the number of allowed password guessing attempts, possibly 681 locking identities out after a certain number of failed attempts etc. 682 Note that the protocol is symmetric and therefore this guidance 683 applies to client-side implementations as well. 685 6.3. Perfect Forward Secrecy 687 The key derivation for the IKE SA and any Child SAs is performed as 688 part of IKEv2 and remains unchanged. It directly follows that 689 perfect forward security is provided independent of the 690 authentication additionally performed by PACE. 692 6.4. Randomness 694 The security of this protocol depends on the quality generation of 695 random quantities, and see Sec. 5 of [RFC5996] for more details. 696 Specifically, any deviation from randomness of the nonce s might 697 compromise the password. Therefore, it is strongly RECOMMENDED that 698 the initiator passes the raw random material through a strong prf to 699 ensure the statistical qualities of the nonce. 701 6.5. Identity Protection 703 This protocol is identical to IKEv2 in the quality of identity 704 protection it provides. Both peers' identities are secure from 705 passive attackers, and both peers' identities are exposed to active, 706 man-in-the-middle attackers. 708 6.6. Denial of Service 710 We are not aware of any new denial-of-service attack vector enabled 711 by this protocol. 713 6.7. Choice of Encryption Algorithms 715 Any transforms negotiated for IKEv2 may be used by this protocol. 716 Please refer to Section 4.1 for the considerations regarding 717 authenticated encryption ("combined mode") algorithms. 719 6.8. Security Model and Security Proof 721 PACE is cryptographically proven secure in [PACEsec] in the model of 722 Bellare, Pointcheval, and Rogaway [BPRmodel]. The setting in which 723 PACE is proven secure is however slightly different from the setting 724 used in IKEv2. The differences are described in the following: 725 o Part of the mapping is already performed within IKEv2 before PACE 726 is started. This rearrangement does not affect the proof as the 727 resulting PACESharedSecret remains close to uniformly distributed 728 in the group generated by G. 729 o The keys for the IKE SA and any Child SAs are already generated 730 within IKEv2 before PACE is started. While those session keys 731 could also be derived in PACE, only the keys for the 732 authentication token are considered in the proof, which explicitly 733 recommends a separate key for this purpose. 734 o IKEv2 allows the negotiation of a stream cipher for PACE while the 735 proven variant always uses a block cipher. The ideal cipher is 736 replaced in the proof by lazy-sampling technique which is 737 similarly applicable to the stream cipher based construction. 738 The differences in the setting therefore have no impact on the 739 validity of the proof. 741 6.9. Long-Term Credential Storage 743 This protocol does not require peers to store the plaintext password. 744 Instead, the value SPwd SHOULD be stored by both peers. 746 In addition, the protocol allows both peers to replace the password 747 by a crypto-strength shared secret. This solution improves the 748 system's security (since passwords are often used for multiple 749 applications), but at the cost of implementation complexity. In 750 particular, if this optional mechanism is to be used, the credential 751 database would need to be writable by the key management subsystem. 753 See Appendix B for alternatives to this approach. 755 7. IANA Considerations 757 IANA is requested to allocate (has allocated) the following values: 758 o A PACE value from the "IKEv2 Secure Password Methods" registry 759 [RFC6467]. 760 o A PSK_PERSIST and a PSK_CONFIRM value from the "IKEv2 Notify 761 Message Types - Status Types" registry. We note that these 762 notification types are generic and other password authentication 763 methods may also choose to use them. 764 This document does not define any new registries. 766 8. Acknowledgments 768 We would like to thank Dan Harkins for pointing out a security issue 769 with our use of combined-mode algorithms, in a previous version of 770 the protocol. We thank Tero Kivinen for his generic framework 771 document, and for a thorough and fruitful review. Hugo Krawczyk 772 proposed to amplify the password into a persistent shared secret. 774 9. References 776 9.1. Normative References 778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 779 Requirement Levels", BCP 14, RFC 2119, March 1997. 781 [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" 782 Attacks on the Diffie-Hellman Key Agreement Method for 783 S/MIME", RFC 2785, March 2000. 785 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 786 Internationalized Strings ("stringprep")", RFC 3454, 787 December 2002. 789 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 790 and Passwords", RFC 4013, February 2005. 792 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 793 Internet Protocol", RFC 4301, December 2005. 795 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 796 "Internet Key Exchange Protocol Version 2 (IKEv2)", 797 RFC 5996, September 2010. 799 9.2. Informative References 801 [BPRmodel] 802 Bellare, M., Pointcheval, D., and P. Rogaway, 803 "Authenticated Key Exchange Secure against Dictionary 804 Attacks, EUROCRYPT 2000, LNCS 1807, pp. 139-155, Springer- 805 Verlag", 2000. 807 [I-D.harkins-ipsecme-pake-criteria] 808 Harkins, D., "Password-Based Authentication in IKEv2: 809 Selection Criteria and Considerations", 810 draft-harkins-ipsecme-pake-criteria-01 (work in progress), 811 October 2010. 813 [ICAO] ISO/IEC JTC1 SC17 WG3/TF5 for ICAO, "Supplemental Access 814 Control for Machine Readable Travel Documents, version 815 1.00", March 2010. 817 [PACEsec] Bender, J., Fischlin, M., and D. Kuegler, "Security 818 Analysis of the PACE Key-Agreement Protocol. The extended 819 abstract appeared in Information Security Conference (ISC) 820 2009, LNCS 5735, pp. 33-48, Springer-Verlag", 2009. 822 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 823 Algorithms with the Encrypted Payload of the Internet Key 824 Exchange version 2 (IKEv2) Protocol", RFC 5282, 825 August 2008. 827 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 828 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 829 January 2010. 831 [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension 832 for EAP-Only Authentication in IKEv2", RFC 5998, 833 September 2010. 835 [RFC6467] Kivinen, T., "Secure Password Framework for Internet Key 836 Exchange Version 2 (IKEv2)", RFC 6467, December 2011. 838 [TR03110] BSI, "TR-03110, Advanced Security Mechanisms for Machine 839 Readable Travel Documents - Extended Access Control (EAC), 840 Password Authenticated Connection Establishment (PACE), 841 and Restricted Identification (RI), Version 2.03", 2010. 843 [TR03111] BSI, "TR-03111, Elliptic Curve Cryptography, Version 844 1.11", 2009. 846 Appendix A. Protocol Selection Criteria 848 To support the selection of a password-based protocol for inclusion 849 in IKEv2, a number of criteria are provided in 850 [I-D.harkins-ipsecme-pake-criteria]. In the following sections, 851 those criteria are applied to the PACE protocol. 853 A.1. Security Criteria 855 SEC1: PACE is a zero knowledge protocol. 856 SEC2: The protocol supports perfect forward secrecy and is resistant 857 to replay attacks. 858 SEC3: The identity protection provided by IKEv2 remains unchanged. 859 SEC4: Any cryptographically secure Diffie-Hellman group can be used. 860 SEC5: The protocol is proven secure in the Bellare-Pointcheval- 861 Rogaway model. 862 SEC6: Strong session keys are generated. 863 SEC7: A transform of the password can be used instead of the 864 password itself. 866 A.2. Intellectual Property Criteria 868 IPR1: The first draft of [TR03110] was published on May 21, 2007. 869 IPR2: BSI has developed PACE aiming to be free of patents. BSI has 870 not applied for a patent on PACE. 871 IPR3: The protocol itself is believed to be free of IPR. 873 A.3. Miscellaneous Criteria 874 MISC1: One additional exchange is required. 875 MISC2: The protocol requires the following operations per entity: 876 * one key derivation from the password, 877 * one symmetric encryption or decryption, 878 * one multi-exponentiation for the mapping, 879 * one exponentiation for the key pair generation, 880 * one exponentiation for the shared secret calculation, and 881 * two symmetric authentications (generation and 882 verification). 883 MISC3: The performance is independent of the type/size of password. 884 MISC4: Internationalization of character-based passwords is 885 supported. 886 MISC5: The protocol uses the same group as negotiated for IKEv2. 887 MISC6: The protocol fits into the request/response nature of IKE. 888 MISC7: The password-based symmetric encryption must be additionally 889 negotiated. 890 MISC8: Neither trusted third parties nor clock synchronization are 891 required. 892 MISC9: Only general cryptographic primitives are required. 893 MISC10: Any secure variant of Diffie-Hellman (e.g. standard or 894 Elliptic Curve) can be used. 895 MISC11: The protocol can be implemented easily based on existing 896 cryptographic primitives. 898 Appendix B. Password Salting 900 This protocol requires that passwords should not be stored in 901 plaintext. Instead, we store a hash of the password with a fixed 902 hash. This value is then used in the ZKPP protocol, replacing the 903 original password and acting as a "password equivalent". The main 904 benefit of this solution is that a system administrator or an 905 undetermined attacker does not get immediate access to the passwords. 906 We believe this is sufficiently secure for the main usage scenario of 907 the protocol. 909 However the common practice of password salting is clearly more 910 powerful, and this appendix presents a few ideas on how password 911 salting can be applied and/or adopted to fit into a symmetric 912 protocol such as IKE. First, let us list the threats that we expect 913 salting to handle, as well as the non-threats: 914 o The plain password should not be visible to a casual onlooker, as 915 noted above. It is assumed that very often the same password is 916 used for multiple applications, and so a password exposed allows 917 an attacker a starting point for further attacks. 918 o An attacker must not be able to construct lookup tables (such as 919 the famous "rainbow tables") that enable her to discover the plain 920 password. 922 o IKE is a symmetric protocol, in the sense that any of the peers 923 might initiate an IKE exchange to another peer. As a result all 924 peers must have stored credentials (passwords or password 925 equivalents) that would enable them to set up an IKE exchange. So 926 an attacker that reaches the credential store would in fact be 927 able to impersonate IKE to another peer. We believe that this 928 reduces, but does not invalidate the importance of salting, 929 because of the other threats that remain. 930 Below we present different scenarios and solutions that support 931 password salting in this setting. 933 We assume that each credential is used to authenticate exactly two 934 peers to one another, i.e. (as per the best practice) group 935 credentials are not allowed. 937 B.1. Solving the Asymmetric Case with Symmetric Cryptography 939 Despite the protocol's symmetry, there are use cases that are 940 somewhat asymmetric. Consider the case of an organization that 941 consists of a headquarters and branches, using a hub-and-spoke 942 architecture. Communication sessions can be initiated by the center 943 or by any of the branches, but only the center holds a large 944 credential database. 946 Here it would be possible to use traditional password salting, 947 stored password = hash(salt, password), 948 where the hash function is a symmetric hash (e.g. HMAC-SHA-256), and 949 the salt is picked at random for each password. The salt would need 950 to be sent in the first exchange of the protocol, regardless of which 951 side initiates the session. Unlike the normal use of salted 952 passwords, here it is the stored password, rather than the original 953 password, that is used by the follow-on ZKPP protocol. 955 B.2. Solving the Fully Symmetric Case with Asymmetric Cryptography 957 For the fully symmetric case, we propose a salting method based on a 958 commutative one-way function. This is essentially a novel variant of 959 the RSA protocol. 961 The implementation proposed here requires a composite number n that 962 is common to all peers. The composite number n can be either 963 generated by a trusted (third) party as n = p * q, where p and q are 964 strong primes (i.e. p = 2 * p' + 1 and q = 2 * q' + 1, where p' and 965 q' are also primes), and the trusted party promises not to retain a 966 copy of the primes. Alternatively, n can be chosen randomly and 967 tested for "small" prime factors. In the latter case it is certainly 968 not guaranteed that n is composed of only two primes. While this has 969 the advantage that no one knows the factorization of n, the 970 disadvantage is that n is likely to be significantly easier to 971 factor. 973 Each peer then chooses a public encryption key e. In a simple 974 implementation the encryption key is generated randomly by each peer, 975 picking a different value for each of the passwords that it stores. 977 Note that although the pair (n,e) is similar to an RSA public key, 978 the usual rules for generating "e" for the RSA protocol do not apply 979 here, and a random "e" is sufficient. The password is hashed by a 980 symmetric hash function H (e.g. SHA-256). Each peer i stores the 981 two values 982 e_i, H(P)^e_i (mod n) 983 where P is the original password. The values e_i are exchanged by 984 the peers before the ZKPP protocol commences (in IKEv2-PACE, this 985 would be in IKE_SA_INIT) and the following value is used in the ZKPP 986 protocol run that follows, in lieu of the original password: 987 H(P) ^ (e_i * e_j) (mod n). 988 This transformation is used as a salting mechanism only and the 989 salted values themselves are never sent on the wire. 991 This scheme can be enhanced by basing the value "e" on each peer's 992 identity (IDi, IDr), e.g. making it a simple hash of the identity. 993 This eliminates the need to send "e" explicitly, and additionally 994 binds the identity of the peer with its secret. 996 B.3. Generation of a Long Shared Secret 998 An alternative to salting is to store the plain passwords, but only 999 for a short while. As soon as the first IKE SA is set up between two 1000 peers, the peers exchange nonces and generate a long shared secret, 1001 based on IKE's SK_d. They now destroy the short password and replace 1002 it with the new secret. 1004 This method has been added to the current protocol, as an optional 1005 mechanism. 1007 Appendix C. Change Log 1009 Note to RFC Editor: please remove this appendix before publication. 1011 C.1. -10 1013 Changed the symbolic name of the PACE authentication method, as 1014 agreed with IANA. Filled in a few values defined by RFC 6467. 1016 C.2. -09 1018 Implemented a number of IESG comments. 1020 C.3. -08 1022 Added the option to replace the password by a stronger shared secret. 1023 Thanks, Sony. 1025 C.4. -07 1027 Adopted the framework proposed in [RFC6467]. However this document 1028 is self-contained. Changed the PKEi/r payloads to reuse the normal 1029 KE payloads; they are disambiguated by the context: which exchange 1030 they are used in. Added an appendix on password salting for 1031 symmetric protocols. 1033 C.5. -06 1035 Defined how authenticated-encryption algorithms can be used. Updated 1036 references. 1038 C.6. -05 1040 Editorial corrections. 1042 C.7. -04 1044 Editorial corrections. 1046 C.8. -03 1048 Completed the security considerations (security proof). Reordered 1049 some sections for clarity. 1051 C.9. -02 1053 Added security considerations. Changed encryption of the nonce. 1054 Simplified the derivation of the AUTH payloads. 1056 C.10. draft-kuegler-ipsecme-pace-ikev2-01 1058 Formalized the protocol: added payload formats, error behavior etc. 1060 Authors' Addresses 1062 Dennis Kuegler 1063 Bundesamt fuer Sicherheit in der Informationstechnik (BSI) 1064 Postfach 200363 1065 Bonn 53133 1066 Germany 1068 Email: dennis.kuegler@bsi.bund.de 1070 Yaron Sheffer 1071 Porticor 1073 Email: yaronf.ietf@gmail.com