idnits 2.17.1 draft-shin-augmented-pake-15.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 (March 23, 2012) is 4409 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Shin 3 Internet-Draft K. Kobara 4 Intended status: Experimental AIST 5 Expires: September 24, 2012 March 23, 2012 7 Efficient Augmented Password-Only Authentication and Key Exchange for 8 IKEv2 9 draft-shin-augmented-pake-15 11 Abstract 13 This document describes an efficient augmented password-only 14 authentication and key exchange (AugPAKE) protocol where a user 15 remembers a low-entropy password and its verifier is registered in 16 the intended server. In general, the user password is chosen from a 17 small set of dictionary whose space is within the off-line dictionary 18 attacks. The AugPAKE protocol described here is secure against 19 passive attacks, active attacks and off-line dictionary attacks (on 20 the obtained messages with passive/active attacks), and also provides 21 resistance to server compromise (in the context of augmented PAKE 22 security). In addition, this document describes how the AugPAKE 23 protocol is integrated into IKEv2. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 24, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. AugPAKE Specification . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Underlying Group . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2.1. Password Processing . . . . . . . . . . . . . . . . . 6 65 2.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.3.1. Initialization . . . . . . . . . . . . . . . . . . . . 7 67 2.3.2. Actual Protocol Execution . . . . . . . . . . . . . . 7 68 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 3.1. General Assumptions . . . . . . . . . . . . . . . . . . . 9 70 3.2. Security against Passive Attacks . . . . . . . . . . . . . 9 71 3.3. Security against Active Attacks . . . . . . . . . . . . . 10 72 3.3.1. Impersonation Attacks on User U . . . . . . . . . . . 10 73 3.3.2. Impersonation Attacks on Server S . . . . . . . . . . 11 74 3.3.3. Man-in-the-Middle Attacks . . . . . . . . . . . . . . 11 75 3.4. Security against Off-line Dictionary Attacks . . . . . . . 11 76 3.5. Resistance to Server Compromise . . . . . . . . . . . . . 12 77 4. Implementation Consideration . . . . . . . . . . . . . . . . . 13 78 5. AugPAKE for IKEv2 . . . . . . . . . . . . . . . . . . . . . . 13 79 5.1. Integration into IKEv2 . . . . . . . . . . . . . . . . . . 13 80 5.2. Payload Formats . . . . . . . . . . . . . . . . . . . . . 14 81 5.2.1. Notify Payload . . . . . . . . . . . . . . . . . . . . 14 82 5.2.2. Generic Secure Password Method Payload . . . . . . . . 15 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 87 Appendix A. Evaluation by PAKE Selection Criteria . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 92 In the real world, many applications such as web mail, Internet 93 banking/shopping/trade require secure channels between participating 94 parties. Such secure channels can be established by using an 95 authentication and key exchange (AKE) protocol, which allows the 96 involving parties to authenticate each other and to generate a 97 temporary session key. The temporary session key is used to protect 98 the subsequent communications between the parties. 100 Until now, password-only AKE (called, PAKE) protocols have attracted 101 much attention because password-only authentication is very 102 convenient to the users. However, it is not trivial to design a 103 secure PAKE protocol due to the existence of off-line dictionary 104 attacks on passwords. These attacks are possible since passwords are 105 chosen from a relatively-small dictionary that allows for an attacker 106 to perform the exhaustive searches. This problem was brought forth 107 by Bellovin and Merritt [BM92], and many following works have been 108 conducted in the literature (see some examples in [IEEEP1363.2]). A 109 PAKE protocol is said to be secure if the best attack an active 110 attacker can take is restricted to the on-line dictionary attacks, 111 which allow to check a guessed password only by interacting with the 112 honest party. 114 An augmented PAKE protocol (e.g., [BM93], [RFC2945], [ISO]) provides 115 extra protection for server compromise in the sense that an attacker, 116 who obtained a password verifier from a server, cannot impersonate 117 the corresponding user without performing off-line dictionary attacks 118 on the password verifier. This additional security is known as 119 "resistance to server compromise". The AugPAKE protocol described in 120 this document is an augmented PAKE which also achieves measurable 121 efficiency over some previous works (SRP [RFC2945] and AMP [ISO]). 122 We believe the following (see [SKI10] for the formal security proof): 123 1) The AugPAKE protocol is secure against passive attacks, active 124 attacks and off-line dictionary attacks (on the obtained messages 125 with passive/active attacks), and 2) It provides resistance to server 126 compromise. At the same time, the AugPAKE protocol has similar 127 computational efficiency to the plain Diffie-Hellman key exchange 128 [DH76] that does not provide authentication by itself. Specifically, 129 the user and the server need to compute 2 and 2.17 modular 130 exponentiations, respectively, in the AugPAKE protocol. After 131 excluding pre-computable costs, the user and the server are required 132 to compute only 1 and 1.17 modular exponentiations, respectively. 133 Compared with SRP [RFC2945] and AMP [ISO], the AugPAKE protocol is 134 more efficient 1) than SRP in terms of the user's computational costs 135 and 2) than AMP in terms of the server's computational costs. 137 This document also describes how the AugPAKE protocol is integrated 138 into IKEv2 [RFC5996]. 140 1.1. Keywords 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 2. AugPAKE Specification 148 2.1. Underlying Group 150 The AugPAKE protocol can be implemented over the following group. 152 o Let p and q be sufficiently large primes such that q is a divisor 153 of ((p - 1) / 2) and every factors of ((p - 1) / 2) are also 154 primes comparable to q in size. This p is called a "secure" 155 prime. We denote by G a multiplicative subgroup of prime order q 156 over the field GF(p), the integers modulo p. Let g be a generator 157 for the subgroup G so that all the subgroup elements are generated 158 by g. The group operation is denoted multiplicatively (in modulo 159 p). 161 By using a secure prime p, the AugPAKE protocol has computational 162 efficiency gains. Specifically, it does not require the order check 163 of elements, received from the counterpart party. Note that the 164 groups, defined in Discrete Logarithm Cryptography [SP800-56A] and 165 RFC 5114 [RFC5114], are not necessarily the above secure prime 166 groups. 168 Alternatively, one can implement the AugPAKE protocol over the 169 following groups. 171 o Let p and q be sufficiently large primes such that p = (2 * q) + 172 1. This p is called a "safe" prime. We denote by G a 173 multiplicative subgroup of prime order q over the field GF(p), the 174 integers modulo p. Let g be any element of G other than 1. For 175 example, g = h^2 mod p where h is a primitive element. The group 176 operation is denoted multiplicatively (in modulo p). 178 o Let p and q be sufficiently large primes such that q is a divisor 179 of ((p - 1) / 2). We denote by G a multiplicative subgroup of 180 prime order q over the field GF(p), the integers modulo p. Let g 181 be a generator for the subgroup G so that all the subgroup 182 elements are generated by g. The group operation is denoted 183 multiplicatively (in modulo p). If p is not a "secure" prime, the 184 AugPAKE protocol MUST perform the order check of received 185 elements. 187 2.2. Notation 189 The AugPAKE protocol is a two-party protocol where a user and a 190 server authenticate each other and generate a session key. The 191 following notation is used in this document: 193 U 194 The user's identity (e.g., defined in [RFC4282]). It is a string 195 in {0,1}^* where {0,1}^* indicates a set of finite binary 196 strings. 198 S 199 The server's identity (e.g., defined in [RFC4282]). It is a 200 string in {0,1}^*. 202 b = H(a) 203 A binary string a is given as input to a secure one-way hash 204 function H (e.g., SHA-2 family [FIPS180-3]) which produces a 205 fixed-length output b. The hash function H maps {0,1}^* to 206 {0,1}^k where {0,1}^k indicates a set of binary strings of length 207 k and k is a security parameter. 209 b = H'(a) 210 A binary string a is given as input to a secure one-way hash 211 function H' which maps the input a in {0,1}^* to the output b in 212 Z_q^* where Z_q^* is a set of positive integers modulo prime q. 214 a | b 215 It denotes a concatenation of binary strings a and b in {0,1}^*. 217 0x 218 A hexadecimal value is shown preceded by "0x". 220 X * Y mod p 221 It indicates a multiplication of X and Y modulo prime p. 223 X = g^x mod p 224 The g^x indicates a multiplication computation of g by x times. 225 The resultant value modulo prime p is assigned to X. The discrete 226 logarithm problem says that it is computationally hard to compute 227 the discrete logarithm x from X, g and p. 229 w 230 The password remembered by the user. This password may be used 231 as an effective password (instead of itself) in the form of 232 H'(0x00 | U | S | w). 234 W 235 The password verifier registered in the server. This password 236 verifier is computed as follows: W = g^w mod p where the user's 237 password w is used itself, or W = g^w' mod p where the effective 238 password w' = H'(0x00 | U | S | w) is used. 240 bn2bin(X) 241 It indicates a conversion of a multiple precision integer X to 242 the corresponding binary string. If X is an element over GF(p), 243 its binary representation MUST have the same bit length as the 244 binary representation of prime p. 246 U -> S: msg 247 It indicates a message transmission that the user U sends a 248 message msg to the server S. 250 U: 251 It indicates a local computation of user U (without any out-going 252 messages). 254 2.2.1. Password Processing 256 The input password MUST be processed according to the rules of the 257 [RFC4013] profile of [RFC3454]. The password SHALL be considered a 258 "stored string" per [RFC3454] and unassigned code points are 259 therefore prohibited. The output SHALL be the binary representation 260 of the processed UTF-8 character string. Prohibited output and 261 unassigned code points encountered in SASLprep pre-processing SHALL 262 cause a failure of pre-processing and the output SHALL NOT be used 263 with the AugPAKE protocol. 265 The following table shows examples of how various character data is 266 transformed by the rules of the [RFC4013] profile. 268 # Input Output Comments 269 - ----- ------ -------- 270 1 IX IX SOFT HYPHEN mapped to nothing 271 2 user user no transformation 272 3 USER USER case preserved, will not match #2 273 4 a output is NFKC, input in ISO 8859-1 274 5 IX output is NFKC, will match #1 275 6 Error - prohibited character 276 7 Error - bidirectional check 278 2.3. Protocol 280 The AugPAKE protocol consists of two phases: initialization and 281 actual protocol execution. The initialization phase SHOULD be 282 finished in a secure manner between the user and the server, and it 283 is performed all at once. Whenever the user and the server need to 284 establish a secure channel, they can run the actual protocol 285 execution through an open network (i.e., the Internet) in which an 286 active attacker exists. 288 2.3.1. Initialization 290 U -> S: (U, W) 291 The user U computes W = g^w' mod p, where w' is the effective 292 password, and transmits W to the server S. The W is 293 registered in the server as the password verifier of user U. 294 Of course, user U just remembers the password w only. 296 If resistance to server compromise is not necessary and a node needs 297 to act as both initiator and responder, e.g., as a gateway, then the 298 node can store w' instead of W even when it acts as server S. In 299 either case, server S SHOULD NOT store any plaintext passwords. 301 As noted above, this phase SHOULD be performed securely and all at 302 once. 304 2.3.2. Actual Protocol Execution 306 The actual protocol execution of the AugPAKE protocol allows the user 307 and the server to share an authenticated session key through an open 308 network (see Figure 1). 310 +-----------------+ +------------------+ 311 | User U | | Server S (U,W) | 312 | | (U, X) | | 313 | |----------------------------->| | 314 | | | | 315 | | (S, Y) | | 316 | |<-----------------------------| | 317 | | | | 318 | | V_U | | 319 | |----------------------------->| | 320 | | | | 321 | | V_S | | 322 | |<-----------------------------| | 323 | | | | 324 +-----------------+ +------------------+ 326 Figure 1: Actual Protocol Execution 328 U -> S: (U, X) 329 The user U chooses a random element x from Z_q^* and computes 330 its Diffie-Hellman public value X = g^x mod p. The user 331 sends the first message (U, X) to the server S. 333 S -> U: (S, Y) 334 If the received X from user U is 0, 1 or -1 (mod p), server S 335 MUST terminate the protocol execution. Otherwise, the server 336 chooses a random element y from Z_q^* and computes Y = (X * 337 (W^r))^y mod p where r = H'(0x01 | U | S | bn2bin(X)). Note 338 that X^y * g^(w * r * y) mod p can be computed from y and (w 339 * r * y) efficiently using Shamir's trick [MOV97]. Then, 340 server S sends the second message (S, Y) to the user U. 342 U -> S: V_U 343 If the received Y from server S is 0, 1 or -1 (mod p), user U 344 MUST terminate the protocol execution. Otherwise, the user 345 computes K = Y^z mod p where z = 1 / (x + (w * r)) mod q and 346 r = H'(0x01 | U | S | bn2bin(X)). Also, user U generates an 347 authenticator V_U = H(0x02 | U | S | bn2bin(X) | bn2bin(Y) | 348 bn2bin(K)). Then, the user sends the third message V_U to 349 the server S. 351 S -> U: V_S 352 If the received V_U from user U is not equal to H(0x02 | U | 353 S | bn2bin(X) | bn2bin(Y) | bn2bin(K)) where K = g^y mod p, 354 server S MUST terminate the protocol execution. Otherwise, 355 the server generates an authenticator V_S = H(0x03 | U | S | 356 bn2bin(X) | bn2bin(Y) | bn2bin(K)) and a session key SK = 357 H(0x04 | U | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)). Then, 358 server S sends the fourth message V_S to the user U. 360 U: 361 If the received V_S from server S is not equal to H(0x03 | U 362 | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)), user U MUST 363 terminate the protocol execution. Otherwise, the user 364 generates a session key SK = H(0x04 | U | S | bn2bin(X) | 365 bn2bin(Y) | bn2bin(K)). 367 In the actual protocol execution, the sequential order of message 368 exchanges is very important in order to avoid any possible attacks. 369 For example, if the server S sends the second message (S, Y) and the 370 fourth message V_S together, any attacker can easily derive the 371 correct password w with off-line dictionary attacks. 373 The session key SK, shared only if the user and the server 374 authenticate each other successfully, MAY be generated by using a key 375 derivation function (KDF) [SP800-108]. After generating SK, the user 376 and the server MUST delete all the internal states (e.g., Diffie- 377 Hellman exponents x and y) from memory. 379 For the formal proof [SKI10] of the AugPAKE protocol, we need to 380 change slightly the computation of Y (in the above S -> U: (S, Y)) 381 and K (in the above S -> U: V_S) as follows: Y = (X * (W^r))^y' and K 382 = g^y' where y' = H'(0x05 | bn2bin(y)). 384 3. Security Considerations 386 This section shows why the AugPAKE protocol (i.e., the actual 387 protocol execution) is secure against passive attacks, active attacks 388 and off-line dictionary attacks, and also provides resistance to 389 server compromise. 391 3.1. General Assumptions 393 o An attacker is computationally-bounded. 395 o Any hash functions, used in the AugPAKE protocol, are secure in 396 terms of pre-image resistance (one-wayness), second pre-image 397 resistance and collision resistance. 399 3.2. Security against Passive Attacks 401 An augmented PAKE protocol is said to be secure against passive 402 attacks in the sense that an attacker, who eavesdrops the exchanged 403 messages, cannot compute an authenticated session key (shared between 404 the honest parties in the protocol). 406 In the AugPAKE protocol, an attacker can get the messages (U, X), (S, 407 Y), V_U, V_S by eavesdropping, and then wants to compute the session 408 key SK. That is, the attacker's goal is to derive the correct K from 409 the obtained messages X and Y because the hash functions are secure 410 and the only secret in the computation of SK is K = g^y mod p. Note 411 that 413 X = g^x mod p and 415 Y = (X * (W^r))^y = X^y * W^(r * y) = X^y * (g^y)^t = X^y * K^t 417 hold where t = w' * r mod q. Though t is determined from possible 418 password candidates and X, the only way for the attacker to extract K 419 from X and Y is to compute X^y. However, the probability for the 420 attacker to compute X^y is negligible in the security parameter for 421 the underlying groups since both x and y are random elements chosen 422 from Z_q^*. Therefore, the AugPAKE protocol is secure against 423 passive attacks. 425 3.3. Security against Active Attacks 427 An augmented PAKE protocol is said to be secure against active 428 attacks in the sense that an attacker, who completely controls the 429 exchanged messages, cannot compute an authenticated session key 430 (shared with the honest party in the protocol) with the probability 431 better than that of on-line dictionary attacks. In other words, the 432 probability for an active attacker to compute the session key is 433 restricted by the on-line dictioinary attacks where it grows linearly 434 to the number of interactions with the honest party. 436 In the AugPAKE protocol, the user (resp., the server) computes the 437 session key SK only if the received authenticator V_S (resp., V_U) is 438 valid. There are three cases to be considered in the active attacks. 440 3.3.1. Impersonation Attacks on User U 442 When an attacker impersonates the user U, the attacker can compute 443 the same SK (to be shared with the server S) only if the 444 authenticator V_U is valid. For a valid authenticator V_U, the 445 attacker has to compute the correct K from X and Y because the hash 446 functions are secure. In this impersonation attack, the attacker of 447 course knows the discrete logarithm x of X and guesses a password w'' 448 from the password dictionary. So, the probability for the attacker 449 to compute the correct K is bounded by the probability of w = w''. 450 That is, this impersonation attack is restricted by the on-line 451 dictionary attacks where the attacker can try a guessed password 452 communicating with the honest server S. Therefore, the AugPAKE 453 protocol is secure against impersonation attacks on user U. 455 3.3.2. Impersonation Attacks on Server S 457 When an attacker impersonates the server S, the attacker can compute 458 the same SK (to be shared with the user U) only if the authenticator 459 V_S is valid. For a valid authenticator V_S, the attacker has to 460 compute the correct K from X and Y because the hash functions are 461 secure. In this impersonation attack, the attacker chooses a random 462 element y and guesses a password w'' from the password dictionary so 463 that 465 Y = (X * (W'^r))^y = X^y * W'^(r * y) = X^y * (g^y)^t' 467 where t' = w'' * r mod q. The probability for the attacker to 468 compute the correct K is bounded by the probability of w = w''. 469 Also, the attacker knows whether the guessed password is equal to w 470 or not by seeing the received authenticator V_U. However, when w is 471 not equal to w'', the probability for the attacker to compute the 472 correct K is negligible in the security parameter for the underlying 473 groups since the attacker has to guess the discrete logarithm x 474 (chosen by user U) as well. That is, this impersonation attack is 475 restricted by the on-line dictionary attacks where the attacker can 476 try a guessed password communicating with the honest user U. 477 Therefore, the AugPAKE protocol is secure against impersonation 478 attacks on server S. 480 3.3.3. Man-in-the-Middle Attacks 482 When an attacker performs the man-in-the-middle attack, the attacker 483 can compute the same SK (to be shared with the user U or the server 484 S) only if one of the authenticators V_U, V_S is valid. Note that if 485 the attacker relays the exchanged messages honestly, it corresponds 486 to the passive attacks. In order to generate a valid authenticator 487 V_U or V_S, the attacker has to compute the correct K from X and Y 488 because the hash functions are secure. So, the attacker is in the 489 same situation as discussed above. Though the attacker can test two 490 passwords (one with user U and the other with server S), it does not 491 change the fact that this attack is restricted by the on-line 492 dictionary attacks where the attacker can try a guessed password 493 communicating with the honest party. Therefore, the AugPAKE protocol 494 is also secure against man-in-the-middle attacks. 496 3.4. Security against Off-line Dictionary Attacks 498 An augmented PAKE protocol is said to be secure against off-line 499 dictionary attacks in the sense that an attacker, who completely 500 controls the exchanged messages, cannot reduce the possible password 501 candidates better than on-line dictionary attacks. Note that, in the 502 on-line dictionary attacks, an attacker can test one guessed password 503 by running the protocol execution (i.e., communicating with the 504 honest party). 506 As discussed in Section 3.2, an attacker in the passive attacks does 507 not compute X^y (and the correct K = g^y mod p) from the obtained 508 messages X, Y. This security analysis also indicates that, even if 509 the attacker can guess a password, the K is derived independently 510 from the guessed password. Next, we consider an active attacker 511 whose main goal is to perform the off-line dictionary attacks in the 512 AugPAKE protocol. As in Section 3.3, the attacker can 1) test one 513 guessed password by impersonating the user U or the server S, or 2) 514 test two guessed passwords by impersonating the server S (to the 515 honest user U) and impersonating the user U (to the honest server S) 516 in the man-in-the-middle attacks. Whenever the honest party receives 517 an invalid authenticator, the party terminates the actual protocol 518 execution without sending any message. In fact, this is important to 519 prevent an attacker from testing more than one password in the active 520 attacks. Since passive attacks and active attacks cannot remove the 521 possible password candidates efficiently than on-line dictionary 522 attacks, the AugPAKE protocol is secure against off-line dictionary 523 attacks. 525 3.5. Resistance to Server Compromise 527 We consider an attacker who has obtained a (user's) password verifier 528 from a server. In the (augmented) PAKE protocols, there are two 529 limitations [BJKMRSW00]: 1) the attacker can find out the correct 530 password from the password verifier with the off-line dictionary 531 attacks because the verifier has the same entropy as the password; 532 and 2) if the attacker impersonates the server with the password 533 verifier, this attack is always possible because the attacker has 534 enough information to simulate the server. An augmented PAKE 535 protocol is said to provide resistance to server compromise in the 536 sense that the attacker cannot impersonate the user without 537 performing off-line dictionary attacks on the password verifier. 539 In order to show resistance to server compromise in the AugPAKE 540 protocol, we consider an attacker who has obtained the password 541 verifier W and then tries to impersonate the user U without off-line 542 dictionary attacks on W. As a general attack, the attacker chooses 543 two random elements c and d from Z_q^*, and computes 545 X = (g^c) * (W^d) mod p 547 and sends the first message (U, X) to the server S. In order to 548 impersonate user U successfully, the attacker has to compute the 549 correct K = g^y mod p where y is randomly chosen by server S. After 550 receiving Y from the server, the attacker's goal is to find out a 551 value e satisfying Y^e = K mod p. That is, 553 log_g (Y^e) = log_g K mod q 555 (c + (w' * d) + (w' * r)) * y * e = y mod q 557 (c + w' * (d + r)) * e = 1 mod q 559 where log_g K indicates the logarithm of K to the base g. Since 560 there is no off-line dictionary attacks on W, the above solution is 561 that e = 1 / c mod q and d = -r mod q. However, the latter is not 562 possible since r is determined by X (i.e., r = H'(0x01 | U | S | 563 bn2bin(X))) and H' is a secure hash function. Therefore, the AugPAKE 564 protocol provides resistance to server compromise. 566 4. Implementation Consideration 568 As discussed in Section 3, the AugPAKE protocol is secure against 569 passive attacks, active attacks and off-line dictionary attacks, and 570 provides resistance to server compromise. However, an attacker in 571 the on-line dictionary attacks can check whether one password 572 (guessed from the password dictionary) is correct or not by 573 interacting with the honest party. Let N be a dictionary size of 574 passwords. Certainly, the attacker's success probability grows with 575 the probability of (I / N) where I is the number of interactions with 576 the honest party. In order to provide a reasonable security margin, 577 implementation SHOULD take a countermeasure to the on-line dictionary 578 attacks. For example, it would take about 90 years to test 2^(25.5) 579 passwords with one minute lock-out for 3 failed password guesses (see 580 Appendix A in [SP800-63]). 582 5. AugPAKE for IKEv2 584 5.1. Integration into IKEv2 586 IKE is a primary component of IPsec in order to provide mutual 587 authentication and establish security associations between two peers. 588 The AugPAKE protocol, described in Section 2, can be easily 589 integrated into IKEv2 [RFC5996] as a "weak" pre-shared key 590 authentication method (see Figure 2). This integrated protocol 591 preserves the IKEv2 structure and security guarantees (e.g., identity 592 protection). Note that the AugPAKE protocol can be used in three 593 usage scenarios for IKEv2: "Security Gateway to Security Gateway 594 Tunnel", "Endpoint-to-Endpoint Transport" and "Endpoint to Security 595 Gateway Tunnel". 597 Initiator Responder 598 ----------- ----------- 600 IKE_SA_INIT: 602 HDR, SAi1, KEi, Ni, 603 N(SECURE_PASSWORD_METHODS) --> 604 <-- HDR, SAr1, KEr, Nr, 605 N(SECURE_PASSWORD_METHODS) 607 IKE_AUTH: 609 HDR, SK {IDi, GSPM(PVi), [IDr,] 610 SAi2, TSi, TSr} --> 611 <-- HDR, SK {IDr, GSPM(PVr)} 612 HDR, SK {AUTHi} --> 613 <-- HDR, SK {AUTHr, SAr2, TSi, TSr} 615 Figure 2: AugPAKE into IKEv2 617 The changes from IKEv2 are summarized as follows: 619 o In addition to IKEv2, one round trip is added. 621 o The initiator (resp., the responder) sends an 622 N(SECURE_PASSWORD_METHODS) notification to indicate its 623 willingness to use AugPAKE in the IKE_SA_INIT exchange. 625 o The added values GSPM(PVi) and GSPM(PVr) in the IKE_AUTH exchange 626 correspond to X and Y of the AugPAKE protocol in Section 2, 627 respectively. 629 o From K (represented as an octet string) derived in Section 2, the 630 AUTH values in the IKE_AUTH exchange are computed as 632 AUTHi = prf( prf(K, "AugPAKE for IKEv2"), 633 | GSPM(PVi) | GSPM(PVr) | IDi | IDr) 635 AUTHr = prf( prf(K, "AugPAKE for IKEv2"), 636 | GSPM(PVr) | GSPM(PVi) | IDr | IDi) 638 5.2. Payload Formats 640 5.2.1. Notify Payload 642 The Notify Payload N(SECURE_PASSWORD_METHODS) [RFC6467], indicating 643 an willingness to use AugPAKE in the IKE_SA_INIT exchange, defined as 644 follows: 646 1 2 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 ! Next Payload !C! RESERVED ! Payload Length ! 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 ! Protocol ID ! SPI Size ! Notify Message Type ! 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 ! ! 654 ~ Security Parameter Index (SPI) ~ 655 ! ! 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 ! ! 658 ~ Notification Data ~ 659 ! ! 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 As in [RFC5996], the Protocol ID and SPI Size SHALL be set to zero 663 and, therefore, the SPI field SHALL be empty. The Notify Message 664 Type will be 16424 [RFC6467]. 666 The Notification Data contains the list of the 16-bit secure password 667 method numbers: 669 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 ! Secure Password Method #1 ! Secure Password Method #2 ! 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 ! Secure Password Method #3 ! ... ! 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 The response Notify Payload contains exactly one 16-bit secure 678 password method number (i.e., for AugPAKE here) inside the 679 Notification Data field. 681 5.2.2. Generic Secure Password Method Payload 683 The Generic Secure Password Method (GSPM) Payload, denoted GSPM(PV) 684 in Section 5.1, is defined as follows: 686 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 ! Next Payload !C! RESERVED ! Payload Length ! 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 ! ! 692 ~ ~ 693 ! Data Specific to the Secure Password Method ! 694 ~ ~ 695 ! ! 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 The GSPM Payload Type will be 49 [RFC6467]. 700 Since the GSPM(PV) value is a group element, the encoded octet string 701 is actually used in the "Data Specific to the Secure Password Method" 702 field. 704 6. IANA Considerations 706 This document requests IANA to assign a value. 708 IANA SHALL assign a value for "AugPAKE" from the IKEv2 Secure 709 Password Methods registry in [IKEV2-IANA] with the method name of 710 "AugPAKE". 712 7. References 714 7.1. Normative References 716 [FIPS180-3] 717 Information Technology Laboratory, "Secure Hash Standard 718 (SHS)", NIST FIPS Publication 180-3, October 2008, . 722 [IKEV2-IANA] 723 "Internet Key Exchange Version 2 (IKEv2) Parameters", 724 . 726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, March 1997. 729 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 730 Internationalized Strings ("stringprep")", RFC 3454, 731 December 2002. 733 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 734 and Passwords", RFC 4013, February 2005. 736 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 737 Network Access Identifier", RFC 4282, December 2005. 739 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 740 "Internet Key Exchange Protocol Version 2 (IKEv2)", 741 RFC 5996, September 2010. 743 [SP800-108] 744 Chen, L., "Recommendation for Key Derivation Using 745 Pseudorandom Functions (Revised)", NIST Special 746 Publication 800-108, October 2009, . 749 7.2. Informative References 751 [BJKMRSW00] 752 Bellare, M., Jablon, D., Krawczyk, H., MacKenzie, P., 753 Rogaway, P., Swaminathan, R., and T. Wu, "Proposal for 754 P1363 Study Group on Password-Based Authenticated-Key- 755 Exchange Methods", IEEE P1363.2: Password-Based Public-Key 756 Cryptography , Submissions to IEEE P1363.2 , 757 February 2000, . 760 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 761 Password-based Protocols Secure against Dictionary 762 Attacks", Proceedings of the IEEE Symposium on Security 763 and Privacy , IEEE Computer Society , 1992. 765 [BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key 766 Exchange: A Password-based Protocol Secure against 767 Dictionary Attacks and Password File Compromise", 768 Proceedings of the 1st ACM Conference on Computer and 769 Communication Security , ACM Press , 1993. 771 [DH76] Diffie, W. and M. Hellman, "New Directions in 772 Cryptography", IEEE Transactions on Information Theory 773 Volume IT-22, Number 6, 1976. 775 [H10] Harkins, D., "Password-Based Authentication in IKEv2: 776 Selection Criteria and Considerations", Internet-Draft , 777 October 2010, . 780 [IEEEP1363.2] 781 IEEE P1363.2, "Password-Based Public-Key Cryptography", 782 Submissions to IEEE P1363.2 , . 785 [ISO] ISO/IEC JTC 1/SC 27 11770-4, "Information technology -- 786 Security techniques -- Key management -- Part 4: 787 Mechanisms based on weak secrets", May 2006, . 791 [MOV97] Menezes, A., Oorschot, P., and S. Vanstone, "Simultaneous 792 Multiple Exponentiation", in Handbook of Applied 793 Cryptography , CRC Press , 1997. 795 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 796 RFC 2945, September 2000. 798 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 799 Groups for Use with IETF Standards", RFC 5114, 800 January 2008. 802 [RFC6467] Kivinen, T., "Secure Password Framework for Internet Key 803 Exchange Version 2 (IKEv2)", RFC 6467, December 2011. 805 [SKI10] Shin, S., Kobara, K., and H. Imai, "Security Proof of 806 AugPAKE", Cryptology ePrint Archive: Report 2010/334, 807 June 2010, . 809 [SP800-56A] 810 Barker, E., Johnson, D., and M. Smid, "Recommendation for 811 Pair-Wise Key Establishment Schemes Using Discrete 812 Logarithm Cryptography (Revised)", NIST Special 813 Publication 800-56A, March 2007, . 817 [SP800-63] 818 Burr, W., Dodson, D., and W. Polk, "Electronic 819 Authentication Guideline", NIST Special Publication 800-63 820 Version 1.0.2, April 2006, . 823 Appendix A. Evaluation by PAKE Selection Criteria 825 Below are self-evaluation of the AugPAKE protocol by following PAKE 826 selection criteria [H10]. 828 SEC1: AugPAKE is zero knowledge (password) proof. It is secure 829 against passive/active/off-line dictionary attacks. It is also 830 resistant to server-compromise impersonation attacks. 832 SEC2: AugPAKE provides PFS and secure against Denning-Sacco 833 attack. 835 SEC3: IKEv2 identity protection is preserved. 837 SEC4: Any cryptographically secure Diffie-Hellman groups can be 838 used. 840 SEC5: The formal security proof of AugPAKE can be found at 841 [SKI10]. 843 SEC6: AugPAKE can be easily used with strong credential. 845 SEC7: In the case of server compromise, an attacker has to perform 846 off-line dictionary attacks while computing mod. exp. with a 847 password candidate. 849 SEC8: AugPAKE is secure regardless of the transform negotiated by 850 IKEv2. 852 IPR1: AugPAKE was publicly disclosed on Oct. 2008. 854 IPR2: AIST applied for patent in Japan on July 10, 2008. AIST 855 would provide royal-free license of AugPAKE. 857 IPR3: IPR disclosure (see https://datatracker.ietf.org/ipr/1284/) 859 MISC1: AugPAKE adds one round trip to IKEv2. 861 MISC2: Initiator needs to compute only 2 mod. exp. computations 862 while responder needs to compute 2.17 mod. exp. computations. 863 AugPAKE needs to exchange 2 group elements and 2 hash values. 864 This is almost same computation/communication costs as the plain 865 DH key exchange. If we use a large (e.g., 2048/3072-bits) parent 866 group, hash size would be relatively small. 868 MISC3: AugPAKE has the same performance for any type of secrets. 870 MISC4: Internationalization of character-based passwords can be 871 supported. 873 MISC5: AugPAKE can be implemented over any ECP, EC2N and MODP 874 groups. 876 MISC6: AugPAKE has request/response nature of IKEv2. 878 MISC7: No additional negotiation is needed. 880 MISC8: No TTP and clock synchronization 882 MISC9: No additional primitive (e.g., FDH and/or ideal cipher) is 883 needed. 885 MISC10: As above, AugPAKE can be implemented over any ECP/EC2N 886 groups. 888 MISC11: Easy implementation. We already implemented AugPAKE and 889 have been testing in AIST. 891 Authors' Addresses 893 SeongHan Shin 894 AIST 895 Central 2, 1-1-1, Umezono 896 Tsukuba, Ibaraki 305-8568 897 JP 899 Phone: +81 29-861-2670 900 Email: seonghan.shin@aist.go.jp 902 Kazukuni Kobara 903 AIST 905 Phone: 906 Email: k-kobara@aist.go.jp