idnits 2.17.1 draft-hao-jpake-06.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 26, 2017) is 2556 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 668 -- Looks like a reference, but probably isn't: '2' on line 670 -- Looks like a reference, but probably isn't: '3' on line 672 -- Looks like a reference, but probably isn't: '4' on line 674 -- Looks like a reference, but probably isn't: '5' on line 677 -- Looks like a reference, but probably isn't: '6' on line 680 -- Looks like a reference, but probably isn't: '7' on line 683 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Hao, Ed. 3 Internet-Draft Newcastle University (UK) 4 Intended status: Informational April 26, 2017 5 Expires: October 28, 2017 7 J-PAKE: Password Authenticated Key Exchange by Juggling 8 draft-hao-jpake-06 10 Abstract 12 This document specifies a Password Authenticated Key Exchange by 13 Juggling (J-PAKE) protocol. This protocol allows the establishment 14 of a secure end-to-end communication channel between two remote 15 parties over an insecure network solely based on a shared password, 16 without requiring a Public Key Infrastructure (PKI) or any trusted 17 third party. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 28, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. J-PAKE over Finite Field . . . . . . . . . . . . . . . . . . 4 57 2.1. Protocol Setup . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Two-Round Key Exchange . . . . . . . . . . . . . . . . . 5 59 2.3. Computational Cost . . . . . . . . . . . . . . . . . . . 6 60 3. J-PAKE over Elliptic Curve . . . . . . . . . . . . . . . . . 7 61 3.1. Protocol Setup . . . . . . . . . . . . . . . . . . . . . 7 62 3.2. Two-Round Key Exchange . . . . . . . . . . . . . . . . . 7 63 3.3. Computational Cost . . . . . . . . . . . . . . . . . . . 8 64 4. Three-Pass Variant . . . . . . . . . . . . . . . . . . . . . 8 65 5. Key Confirmation . . . . . . . . . . . . . . . . . . . . . . 9 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 71 9.2. Informative References . . . . . . . . . . . . . . . . . 14 72 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 Password-Authenticated Key Exchange (PAKE) is a technique that aims 78 to establish secure communication between two remote parties solely 79 based on their shared password, without relying on a Public Key 80 Infrastructure or any trusted third party [BM92]. The first PAKE 81 protocol, called EKE, was proposed by Steven Bellovin and Michael 82 Merrit in 1992 [BM92]. Other well-known PAKE protocols include SPEKE 83 (by David Jablon in 1996) [Jab96] and SRP (by Tom Wu in 1998) [Wu98]. 84 SRP has been revised several times to address reported security and 85 efficiency issues. In particular, the version 6 of SRP, commonly 86 known as SRP-6, is specified in [RFC5054]. 88 This document specifies a PAKE protocol called Password Authenticated 89 Key Exchange by Juggling (J-PAKE), which was designed by Feng Hao and 90 Peter Ryan in 2008 [HR08]. 92 There are a few factors that may be considered in favor of J-PAKE. 93 First, J-PAKE has security proofs, while equivalent proofs are 94 lacking in EKE, SPEKE and SRP-6. Second, J-PAKE follows a completely 95 different design approach from all other PAKE protocols, and is built 96 upon a well-established Zero Knowledge Proof (ZKP) primitive: Schnorr 97 NIZK proof [SchnorrNIZK]. Third, J-PAKE adopts novel engineering 98 techniques to optimize the use of ZKP so that overall the protocol is 99 sufficiently efficient for practical use. Fourth, J-PAKE is designed 100 to work generically in both the finite field and elliptic curve 101 settings (i.e., DSA and ECDSA-like groups respectively). Unlike 102 SPEKE, it does not require any extra primitive to hash passwords onto 103 a designated elliptic curve. Unlike SPAKE2 [AP05] and SESPAKE 104 [SOAA15], it does not require a trusted setup (i.e., the so-called 105 common reference model) to define a pair of generators whose discrete 106 logarithm must be unknown. Finally, J-PAKE has been used in real- 107 world applications at a relatively large scale, e.g., Firefox sync 108 [1], Pale moon sync [2] and Google Nest products [ABM15]; it has been 109 included into widely distributed open source libraries such as 110 OpenSSL [3], Network Security Services (NSS) [4] and the Bouncy 111 Castle [5]; since 2015, it has been included into Thread [6] as a 112 standard key agreement mechanism for IoT (Internet of Things) 113 applications, and also included into ISO/IEC 11770-4 [7]. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 1.2. Notations 123 The following notations are used in this document: 125 o Alice: the assumed identity of the prover in the protocol 127 o Bob: the assumed identity of the verifier in the protocol 129 o s: a low-entropy secret shared between Alice and Bob 131 o a | b: a divides b 133 o a || b: concatenation of a and b 135 o [a, b]: the interval of integers between and including a and b 137 o H: a secure cryptographic hash function 139 o p: a large prime 141 o q: a large prime divisor of p-1, i.e., q | p-1 143 o Zp*: a multiplicative group of integers modulo p 144 o Gq: a subgroup of Zp* with prime order q 146 o g: a generator of Gq 148 o g^x: g raised to the power of x 150 o a mod b: a modulo b 152 o Fp: a finite field of p elements where p is a prime 154 o E(Fp): an elliptic curve defined over Fp 156 o G: a generator of the subgroup over E(Fp) with prime order n 158 o n: the order of G 160 o h: the cofactor of the subgroup generated by G, which is equal to 161 the order of the elliptic curve divided by n 163 o P x [b]: multiplication of a point P with a scalar b over E(Fp) 165 o KDF(a): Key Derivation Function with input a 167 o MAC(MacKey, MacData): MAC function with MacKey as the key and 168 MacData as the input data 170 2. J-PAKE over Finite Field 172 2.1. Protocol Setup 174 When implemented over a finite field, J-PAKE may use the same group 175 parameters as DSA [FIPS186-4]. Let p and q be two large primes such 176 that q | p-1. Let Gq denote a subgroup of Zp* with prime order q. 177 Let g be a generator for Gq. Any non-identity element in Gq can be a 178 generator. The two communicating parties, Alice and Bob, both agree 179 on (p, q, g), which can be hard-wired in the software code. They can 180 also use the method in NIST FIPS 186-4, Appendix A [FIPS186-4] to 181 generate (p, q, g). Here DSA group parameters are used only as an 182 example. Other multiplicative groups suitable for cryptography can 183 also be used for the implementation, e.g., groups defined in 184 [RFC4419]. A group setting that provides 128-bit security or above 185 is recommended. The security proof of J-PAKE depends on the 186 Decisional Diffie-Hellman (DDH) problem being intractable in the 187 considered group. 189 Let s be a secret value derived from a low-entropy password shared 190 between Alice and Bob. The value of s is required to fall within the 191 range of [1, q-1]. (Note that s must not be 0 for any non-empty 192 secret.) This range is defined as a necessary condition in [HR08] 193 for proving the "on-line dictionary attack resistance", since s, s+q, 194 s+2q, ..., are all considered equivalent values as far as the 195 protocol specification is concerned. In a practical implementation, 196 one may obtain s by taking a cryptographic hash of the password and 197 wrapping the result with respect to modulo q. Alternatively, one may 198 simply treat the password as an octet string and convert the string 199 to an integer modulo q by following the method defined in 200 Section 2.3.8 of [SEC1]. In either case, one must ensure s is not 201 equal to 0 modulo q. 203 2.2. Two-Round Key Exchange 205 Round 1: Alice selects an ephemeral private key x1 uniformly at 206 random from [0, q-1] and another ephemeral private key x2 uniformly 207 at random from [1, q-1]. Similarly, Bob selects an ephemeral private 208 key x3 uniformly at random from [0, q-1] and another ephemeral 209 private key x4 uniformly at random from [1, q-1]. 211 o Alice -> Bob: g1 = g^x1 mod p, g2 = g^x2 mod p and ZKPs for x1 and 212 x2 214 o Bob -> Alice: g3 = g^x3 mod p, g4 = g^x4 mod p and ZKPs for x3 and 215 x4 217 In this round, the sender must send zero knowledge proofs to 218 demonstrate the knowledge of the ephemeral private keys. A suitable 219 technique is to use the Schnorr NIZK proof [SchnorrNIZK]. As an 220 example, suppose one wishes to prove the knowledge of the exponent 221 for X = g^x mod p. The generated Schnorr NIZK proof will contain: 222 {UserID, V = g^v mod p, r = v - x * c mod q} where UserID is the 223 unique identifier for the prover, v is a number chosen uniformly at 224 random from [0, q-1] and c = H(g || V || X || UserID). The 225 "uniqueness" of UserID is defined from the user's perspective -- for 226 example, if Alice communicates with several parties, she shall 227 associate a unique identity with each party. Upon receiving a 228 Schnorr NIZK proof, Alice shall check the prover's UserID is a valid 229 identity and is different from her own identity. During the key 230 exchange process using J-PAKE, each party shall ensure that the other 231 party has been consistently using the same identity throughout the 232 protocol execution. Details about the Schnorr NIZK proof, including 233 the generation and the verification procedures, can be found in 234 [SchnorrNIZK]. 236 When this round finishes, Alice verifies the received ZKPs as 237 specified in [SchnorrNIZK] and also checks that g4 != 1 mod p. 238 Similarly, Bob verifies the received ZKPs and also checks that g2 != 239 1 mod p. If any of these checks fails, this session should be 240 aborted. 242 Round 2: 244 o Alice -> Bob: A = (g1*g3*g4)^(x2*s) mod p and a ZKP for x2*s 246 o Bob -> Alice: B = (g1*g2*g3)^(x4*s) mod p and a ZKP for x4*s 248 In this round, the Schnorr NIZK proof is computed in the same way as 249 in the previous round except that the generator is different. For 250 Alice, the generator used is (g1*g3*g4) instead of g; for Bob, the 251 generator is (g1*g2*g3) instead of g. Since any non-identity element 252 in Gq can be used as a generator, Alice and Bob just need to ensure 253 g1*g3*g4 != 1 mod p and g1*g2*g3 != 1 mod p. With overwhelming 254 probability, these inequalities are statistically guaranteed even 255 when the user is communicating with an adversary (i.e., in an active 256 attack). Nonetheless, for absolute guarantee, the receiving party 257 shall explicitly check if these inequalities hold, and abort the 258 session in case such a check fails. 260 When the second round finishes, Alice and Bob verify the received 261 ZKPs. If the verification fails, the session is aborted. Otherwise, 262 the two parties compute the common key material as follows: 264 o Alice computes Ka = (B/g4^(x2*s))^x2 mod p 266 o Bob computes Kb = (A/g2^(x4*s))^x4 mod p 268 Here Ka = Kb = g^((x1+x3)*x2*x4*s) mod p. Let K denote the same key 269 material held by both parties. Using K as input, Alice and Bob then 270 apply a Key Derivation Function (KDF) to derive a common session key 271 k. If the subsequent secure communication uses a symmetric cipher in 272 an authenticated mode (say AES-GCM), then one key is sufficient, 273 i.e., k = KDF(K). Otherwise, the session key should comprise an 274 encryption key (for confidentiality) and a MAC key (for integrity), 275 i.e., k = k_enc || k_mac, where k_enc = KDF(K || "JPAKE_ENC") and 276 k_mac = KDF(K || "JPAKE_MAC"). The exact choice of the KDF is left 277 to specific applications to define. 279 2.3. Computational Cost 281 The computational cost is estimated based on counting the number of 282 modular exponentiations since they are the predominant cost factors. 283 Note that it takes one exponentiation to generate a Schnorr NIZK 284 proof and two to verify it [SchnorrNIZK]. For Alice, she needs to 285 perform 8 exponentiations in the first round, 4 in the second round, 286 and 2 in the final computation of the session key. Hence, that is 14 287 modular exponentiations in total. Based on the symmetry, the 288 computational cost for Bob is exactly the same. 290 3. J-PAKE over Elliptic Curve 292 3.1. Protocol Setup 294 The J-PAKE protocol works basically the same in the elliptic curve 295 (EC) setting, except that the underlying multiplicative group over a 296 finite field is replaced by an additive group over an elliptic curve. 297 Nonetheless, the EC version of J-PAKE is specified here for 298 completeness. 300 When implemented over an elliptic curve, J-PAKE may use the same EC 301 parameters as ECDSA [FIPS186-4]. The FIPS 186-4 standard [FIPS186-4] 302 defines three types of curves suitable for ECDSA: pseudo-random 303 curves over prime fields, pseudo-random curves over binary fields and 304 special curves over binary fields called Koblitz curves or anomalous 305 binary curves. All these curves that are suitable for ECDSAA can 306 also be used to implement J-PAKE. However, for the illustration 307 purpose, only curves over prime fields are described in this 308 document. Typically, such curves include NIST P-256, P-384 and 309 P-521. When choosing a curve, a level of 128-bit security or above 310 is recommended. Let E(Fp) be an elliptic curve defined over a finite 311 field Fp where p is a large prime. Let G be a generator for the 312 subgroup over E(Fp) of prime order n. Here the NIST curves are used 313 only as an example. Other secure curves such as Curve25519 are also 314 suitable for the implementation. The security proof of J-PAKE relies 315 on the assumption that the DDH problem is intractable in the 316 considered group. 318 As before, let s denote the shared secret between Alice and Bob. The 319 value of s falls within [1, n-1]. In particular, note that s must 320 not be equal to 0 mod n. 322 3.2. Two-Round Key Exchange 324 Round 1: Alice selects ephemeral private keys x1 and x2 uniformly at 325 random from [1, n-1]. Similarly, Bob selects ephemeral private keys 326 x3 and x4 uniformly at random from [1, n-1]. 328 o Alice -> Bob: G1 = G x [x1], G2 = G x [x2] and ZKPs for x1 and x2 330 o Bob -> Alice: G3 = G x [x3], G4 = G x [x4] and ZKPs for x3 and x4 332 When this round finishes, Alice and Bob verify the received ZKPs as 333 specified in [SchnorrNIZK]. As an example, to prove the knowledge of 334 the discrete logarithm of X = G x [x] with respect to the base point 335 G, the ZKP contains: {UserID, V = G x [v], r = v - x * c mod n} where 336 UserID is the unique identifier for the prover, v is a number chosen 337 uniformly at random from [1, n-1] and c = H(G || V || X || UserID). 338 The verifier shall check the prover's UserID is a valid identity and 339 is different from its own identity. If the verification of the ZKP 340 fails, the session is aborted. 342 Round 2: 344 o Alice -> Bob: A = (G1 + G3 + G4) x [x2*s] and a ZKP for x2*s 346 o Bob -> Alice: B = (G1 + G2 + G3) x [x4*s] and a ZKP for x4*s 348 When the second round finishes, Alice and Bob verify the received 349 ZKPs. The ZKPs are computed in the same way as in the previous round 350 except that the generator is different. For Alice, the new generator 351 is G1 + G3 + G4; for Bob, it is G1 + G2 + G3. Alice and Bob shall 352 check that these new generators are not points at infinity. If any 353 of these checks fails, the session is aborted. Otherwise, the two 354 parties compute the common key material as follows: 356 o Alice computes Ka = (B - (G4 x [x2*s])) x [x2] 358 o Bob computes Kb = (A - (G2 x [x4*s])) x [x4] 360 Here Ka = Kb = G x [(x1+x3)*(x2*x4*s)]. Let K denote the same key 361 material held by both parties. Using K as input, Alice and Bob then 362 apply a Key Derivation Function (KDF) to derive a common session key 363 k. 365 3.3. Computational Cost 367 In the EC setting, the computational cost of J-PAKE is estimated 368 based on counting the number of scalar multiplications over the 369 elliptic curve. Note that it takes one multiplication to generate a 370 Schnorr NIZK proof and one to verify it [SchnorrNIZK]. For Alice, 371 she has to perform 6 multiplications in the first round, 3 in the 372 second round, and 2 in the final computation of the session key. 373 Hence, that is 11 multiplications in total. Based on the symmetry, 374 the computational cost for Bob is exactly the same. 376 4. Three-Pass Variant 378 The two-round J-PAKE protocol is completely symmetric, which 379 significantly simplifies the security analysis. In practice, one 380 party normally initiates the communication and the other party 381 responds. In that case, the protocol will be completed in three 382 passes instead of two rounds. The two-round J-PAKE protocol can be 383 trivially changed to three passes without losing security. Take the 384 finite field setting as an example and assume Alice initiates the key 385 exchange. The three-pass variant works as follows: 387 1. Alice -> Bob: g1 = g^x1 mod p, g2 = g^x2 mod p, ZKPs for x1 and 388 x2. 390 2. Bob -> Alice: g3 = g^x3 mod p, g4 = g^x4 mod p, B = 391 (g1*g2*g3)^(x4*s) mod p, ZKPs for x3, x4, and x4*s. 393 3. Alice -> Bob: A = (g1*g3*g4)^(x2*s) mod p and a ZKP for x2*s. 395 Both parties compute the session keys in exactly the same way as 396 before. 398 5. Key Confirmation 400 The two-round J-PAKE protocol (or the three-pass variant) provides 401 cryptographic guarantee that only the authenticated party who used 402 the same password at the other end is able to compute the same 403 session key. So far the authentication is only implicit. The key 404 confirmation is also implicit [Stinson06]. The two parties may use 405 the derived key straight-away to start secure communication by 406 encrypting messages in an authenticated mode. Only the party with 407 the same derived session key will be able to decrypt and read those 408 messages. 410 For achieving explicit authentication, an additional key confirmation 411 procedure should be performed. This provides explicit assurance that 412 the other party has actually derived the same key. In this case, the 413 key confirmation is explicit [Stinson06]. 415 In J-PAKE, explicit key confirmation is recommended whenever the 416 network bandwidth allows it. It has the benefit of providing 417 explicit and immediate confirmation if the two parties have derived 418 the same key and hence are authenticated to each other. This allows 419 a practical implementation of J-PAKE to effectively detect online 420 dictionary attacks (if any), and stop them accordingly by setting a 421 threshold for the consecutively failed connection attempts. 423 To achieve explicit key confirmation, there are several methods 424 available. They are generically applicable to all key exchange 425 protocols, not just J-PAKE. In general, it is recommended to use a 426 different key from the session key for key confirmation, say using k' 427 = KDF(K || "JPAKE_KC"). The advantage of using a different key for 428 key confirmation is that the session key remains indistinguishable 429 from random after the key confirmation process (although this 430 perceived advantage is actually subtle and only theoretical). Two 431 explicit key confirmation methods are presented here. 433 The first method is based on the one used in the SPEKE protocol 434 [Jab96]. Suppose Alice initiates the key confirmation. Alice sends 435 to Bob H(H(k')), which Bob will verify. If the verification is 436 successful, Bob sends back to Alice H(k'), which Alice will verify. 437 This key confirmation procedure needs to be completed in two rounds, 438 as shown below. 440 1. Alice -> Bob: H(H(k')) 442 2. Bob -> Alice: H(k') 444 The above procedure requires two rounds instead of one, because the 445 second message depends on the first. If both parties attempt to send 446 the first message at the same time without an agreed order, they 447 cannot tell if the message that they receive is a genuine challenge 448 or a replayed message, and consequently may enter a deadlock. 450 The second method is based on the unilateral key confirmation scheme 451 specified in NIST SP 800-56A Revision 1 [BJS07]. Alice and Bob send 452 to each other a MAC tag, which they will verify accordingly. This 453 key confirmation procedure can be completed in one round. 455 In the finite field setting it works as follows. 457 o Alice -> Bob: MacTagAlice = MAC(k', "KC_1_U" || Alice || Bob || 458 g1 || g2 || g3 || g4) 460 o Bob -> Alice: MacTagBob = MAC(k', "KC_1_U" || Bob || Alice || 461 g3 || g4 || g1 || g2) 463 In the EC setting, the key confirmation works basically the same. 465 o Alice -> Bob: MacTagAlice = MAC(k', "KC_1_U" || Alice || Bob || 466 G1 || G2 || G3 || G4) 468 o Bob -> Alice: MacTagBob = MAC(k', "KC_1_U" || Bob || Alice || 469 G3 || G4 || G1 || G2) 471 The second method assumes an additional secure MAC function (e.g., 472 one may use HMAC) and is slightly more complex than the first method. 473 However, it can be completed within one round and it preserves the 474 overall symmetry of the protocol implementation. For this reason, 475 the second method is recommended. 477 6. Security Considerations 479 A PAKE protocol is designed to provide two functions in one protocol 480 execution. The first one is to provide zero-knowledge authentication 481 of a password. It is called "zero knowledge" because at the end of 482 the protocol, the two communicating parties will learn nothing more 483 than one bit information: whether the passwords supplied at two ends 484 are equal. Therefore, a PAKE protocol is naturally resistant against 485 phishing attacks. The second function is to provide session key 486 establishment if the two passwords are equal. The session key will 487 be used to protect the confidentiality and integrity of the 488 subsequent communication. 490 More concretely, a secure PAKE protocol shall satisfy the following 491 security requirements [HR10]. 493 1. Off-line dictionary attack resistance: It does not leak any 494 information that allows a passive/active attacker to perform off- 495 line exhaustive search of the password. 497 2. Forward secrecy: It produces session keys that remain secure even 498 when the password is later disclosed. 500 3. Known-key security: It prevents a disclosed session key from 501 affecting the security of other sessions. 503 4. On-line dictionary attack resistance: It limits an active 504 attacker to test only one password per protocol execution. 506 First, a PAKE protocol must resist off-line dictionary attacks. A 507 password is inherently weak. Typically, it has only about 20-30 bits 508 entropy. This level of security is subject to exhaustive search. 509 Therefore, in the PAKE protocol, the communication must not reveal 510 any data that allows an attacker to learn the password through off- 511 line exhaustive search. 513 Second, a PAKE protocol must provide forward secrecy. The key 514 exchange is authenticated based on a shared password. However, there 515 is no guarantee on the long-term secrecy of the password. A secure 516 PAKE scheme shall protect past session keys even when the password is 517 later disclosed. This property also implies that if an attacker 518 knows the password but only passively observes the key exchange, he 519 cannot learn the session key. 521 Third, a PAKE protocol must provide known key security. A session 522 key lasts throughout the session. An exposed session key must not 523 cause any global impact on the system, affecting the security of 524 other sessions. 526 Finally, a PAKE protocol must resist on-line dictionary attacks. If 527 the attacker is directly engaging in the key exchange, there is no 528 way to prevent such an attacker trying a random guess of the 529 password. However, a secure PAKE scheme should mitigate the effect 530 of the on-line attack to the minimum. In the best case, the attacker 531 can only guess exactly one password per impersonation attempt. 532 Consecutively failed attempts can be easily detected and the 533 subsequent attempts shall be thwarted accordingly. It is recommended 534 that the false authentication counter should be handled in such a way 535 that any error (which causes the session to fail during the key 536 exchange or key confirmation) would lead to incrementing the false 537 authentication counter. 539 It has been proven in [HR10] that J-PAKE satisfies all of the four 540 requirements based on the assumptions that the Decisional Diffie- 541 Hellman problem is intractable and the underlying Schnorr NIZK proof 542 is secure. An independent study that proves security of J-PAKE in a 543 model with algebraic adversaries and random oracles can be found in 544 [ABM15]. By comparison, it has been known that EKE has the problem 545 of leaking partial information about the password to a passive 546 attacker, hence not satisfying the first requirement [Jas96]. For 547 SPEKE and SRP-6, an attacker may be able to test more than one 548 password in one on-line dictionary attack (see [Zha04] and [Hao10]), 549 hence they do not satisfy the fourth requirement in the strict 550 theoretical sense. Furthermore, SPEKE is found vulnerable to an 551 impersonation attack and a key-malleability attack [HS14]. These two 552 attacks affect the SPEKE protocol specified in Jablon's original 1996 553 paper [Jab96] as well in the D26 draft of IEEE P1363.2 and the latest 554 published ISO/IEC 11770-4:2006 standard. As a result, the 555 specification of SPEKE in ISO/IEC 11770-4:2006 has been revised to 556 address the identified problems. 558 7. IANA Considerations 560 This document has no actions for IANA. 562 8. Acknowledgements 564 The editor would like to thank Dylan Clarke, Siamak Shahandashti, 565 Robert Cragie, Stanislav Smyshlyaev and Russ Housley for many useful 566 comments. This work is supported by EPSRC First Grant (EP/J011541/1) 567 and ERC Starting Grant (No. 306994). 569 9. References 570 9.1. Normative References 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, 574 DOI 10.17487/RFC2119, March 1997, 575 . 577 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 578 "Using the Secure Remote Password (SRP) Protocol for TLS 579 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 580 2007, . 582 [SEC1] "Standards for Efficient Cryptography. SEC 1: Elliptic 583 Curve Cryptography", SECG SEC1-v2, May 2004, 584 . 586 [ABM15] Abdalla, M., Benhamouda, F., and P. MacKenzie, "Security 587 of the J-PAKE Password-Authenticated Key Exchange 588 Protocol", IEEE Symposium on Security and Privacy, May 589 2015. 591 [BM92] Bellovin, S. and M. Merrit, "Encrypted Key Exchange: 592 Password-based Protocols Secure against Dictionary 593 Attacks", IEEE Symposium on Security and Privacy, May 594 1992. 596 [HR08] Hao, F. and P. Ryan, "Password Authenticated Key Exchange 597 by Juggling", 16th Workshop on Security Protocols 598 (SPW'08), May 2008. 600 [HR10] Hao, F. and P. Ryan, "J-PAKE: Authenticated Key Exchange 601 Without PKI", Springer Transactions on Computational 602 Science XI, 2010. 604 [HS14] Hao, F. and S. Shahandashti, "The SPEKE Protocol 605 Revisited", Security Standardisation Research, December 606 2014. 608 [Jab96] Jablon, D., "Strong Password-Only Authenticated Key 609 Exchange", ACM Computer Communications Review, October 610 1996. 612 [Stinson06] 613 Stinson, D., "Cryptography: Theory and Practice (3rd 614 Edition)", CRC, 2006. 616 [Wu98] Wu, T., "The Secure Remote Password protocol", Symposimum 617 on Network and Distributed System Security, March 1998. 619 [SchnorrNIZK] 620 Hao, F., "Schnorr NIZK proof: Non-interactive Zero 621 Knowledge Proof for Discrete Logarithm", IETF Internet 622 Draft-06 (work in progress), 2017, 623 . 625 9.2. Informative References 627 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 628 Group Exchange for the Secure Shell (SSH) Transport Layer 629 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 630 . 632 [BJS07] Barker, E., Johnson, D., and M. Smid, "Recommendation for 633 Pair-Wise Key Establishment Schemes Using Discrete 634 Logarithm Cryptography (Revised)", NIST Special 635 Publication 800-56A, March 2007, 636 . 639 [Jas96] Jaspan, B., "Dual-Workfactor Encrypted Key Exchange: 640 Efficiently Preventing Password Chaining and Dictionary 641 Attacks", USENIX Symphosium on Security, July 1996. 643 [Zha04] Zhang, M., "Analysis of The SPEKE Password-Authenticated 644 Key Exchange Protocol", IEEE Communications Letters, 645 January 2004. 647 [Hao10] Hao, F., "On Small Subgroup Non-Confinement Attacks", 648 IEEE conference on Computer and Information Technology, 649 2010. 651 [AP05] Abdalla, M. and D. Pointcheval, "Simple Password-Based 652 Encrypted Key Exchange Protocols", Topics in Cryptology - 653 CT-RSA, 2005. 655 [FIPS186-4] 656 "Federal Information Processing Standards Publication 657 186-4: Specifications for the Digital Signature Standard 658 (DSS)", July 2013, . 661 [SOAA15] Smyshlyaev, S., Oshkin, I., Alekseev, E., and L. 662 Ahmetzyanova, "On the Security of One Password 663 Authenticated Key Exchange Protocol", 2015, 664 . 666 9.3. URIs 668 [1] https://wiki.mozilla.org/Services/Sync/SyncKey/J-PAKE 670 [2] https://www.palemoon.org/sync/ 672 [3] http://boinc.berkeley.edu/android-boinc/libssl/crypto/jpake/ 674 [4] https://dxr.mozilla.org/mozilla- 675 central/source/security/nss/lib/freebl/jpake.c 677 [5] https://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/cryp 678 to/agreement/jpake/package-summary.html 680 [6] http://threadgroup.org/Portals/0/documents/whitepapers/ 681 Thread%20Commissioning%20white%20paper_v2_public.pdf 683 [7] https://www.iso.org/standard/67933.html 685 Author's Address 687 Feng Hao (editor) 688 Newcastle University (UK) 689 Claremont Tower, School of Computing Science, Newcastle University 690 Newcastle Upon Tyne 691 United Kingdom 693 Phone: +44 (0)191-208-6384 694 EMail: feng.hao@ncl.ac.uk