idnits 2.17.1 draft-hao-jpake-05.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 (November 14, 2016) is 2719 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 631 -- Looks like a reference, but probably isn't: '2' on line 633 -- Looks like a reference, but probably isn't: '3' on line 635 -- Looks like a reference, but probably isn't: '4' on line 637 -- Looks like a reference, but probably isn't: '5' on line 640 -- Looks like a reference, but probably isn't: '6' on line 643 -- Looks like a reference, but probably isn't: '7' on line 646 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 November 14, 2016 5 Expires: May 18, 2017 7 J-PAKE: Password Authenticated Key Exchange by Juggling 8 draft-hao-jpake-05 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 May 18, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . 10 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 9.2. Informative References . . . . . . . . . . . . . . . . . 13 72 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 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 [I-D-Schnorr]. Third, J-PAKE is efficient. It adopts 98 novel engineering techniques to optimize the use of ZKP so that 99 overall the protocol is sufficiently efficient for practical use. 100 Fourth, J-PAKE is designed to work generically in both the finite 101 field and elliptic curve settings (i.e., DSA and ECDSA-like groups 102 respectively). Unlike SPEKE, it does not require any extra primitive 103 to hash passwords onto a designated elliptic curve. Unlike SPAKE2 104 [AP05], 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 currently J-PAKE is being standardized by ISO/IEC 114 11770-4 [7]. 116 1.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 1.2. Notations 124 The following notations are used in this document: 126 o Alice: the assumed identity of the prover in the protocol 128 o Bob: the assumed identity of the verifier in the protocol 130 o s: a low-entropy secret shared between Alice and Bob 132 o a || b: concatenation of a and b 134 o H: a secure cryptographic hash function 136 o p: a large prime 138 o q: a large prime divisor of p-1, i.e., q | p-1 140 o Zp*: a multiplicative group of integers modulo p 142 o Gq: a subgroup of Zp* with prime order q 143 o g: a generator of Gq 145 o g^x: g raised to the power of x 147 o a mod b: a modulo b 149 o Fq: a finite field of q elements where q is a prime 151 o E(Fq): an elliptic curve defined over Fq 153 o G: a generator of the subgroup over E(Fq) with prime order n 155 o n: the order of G 157 o h: the cofactor of the subgroup generated by G, as defined by h 158 = |E(Fq)|/n 160 o P x [b]: multiplication of a point P with a scalar b over E(Fq) 162 o P.x: the x coordinate of a point P over E(Fq) 164 o KDF(a): Key Derivation Function with input a 166 o HMAC(MacKey, MacData): HMAC function with MacKey as the key and 167 MacData as the input data 169 2. J-PAKE over Finite Field 171 2.1. Protocol Setup 173 When implemented over a finite field, J-PAKE may use the same group 174 parameters as DSA. Let p and q be two large primes such that q | 175 p-1. Let Gq denote a subgroup of Zp* with prime order q, in which 176 the Decisional Diffie-Hellman problem (DDH) is intractable. Let g be 177 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. Here DSA 180 group parameters are used only as an example. Other multiplicative 181 groups where the discrete logarithm problem (DLP) is intractable are 182 also suitable for the implementation. 184 Let s be a secret value derived from a low-entropy password shared 185 between Alice and Bob. The value of s is required to fall within the 186 range of [1, q-1]. (Note that s must not be 0 for any non-empty 187 secret.) This range is defined as a necessary condition in [HR08] 188 for proving the "on-line dictionary attack resistance", since s, s+q, 189 s+2q, ..., are all considered equivalent values as far as the 190 protocol specification is concerned. In a practical implementation, 191 one may obtain s by taking a cryptographic hash of the password and 192 wrapping the result with respect to modulo q. Alternatively, one may 193 simply treat the password as an octet string and convert the string 194 to an integer modulo q by following the method defined in section 195 2.3.8 of [SEC1]. In either case, one must ensure s is not 0. 197 2.2. Two-Round Key Exchange 199 Round 1: Alice selects x1 uniformly at random from [0, q-1] and x2 200 from [1, q-1]. Similarly, Bob selects x3 uniformly at random from 201 [0, q-1] and x4 from [1, q-1]. 203 o Alice -> Bob: g1 = g^x1 mod p, g2 = g^x2 mod p and knowledge 204 proofs for x1 and x2 206 o Bob -> Alice: g3 = g^x3 mod p, g4 = g^x4 mod p and knowledge 207 proofs for x3 and x4 209 In this round, the sender must demonstrate the knowledge of the 210 ephemeral private keys. A suitable technique is to use the Schnorr 211 NIZK proof [I-D-Schnorr]. [[Q1:: The reference is an accompanying 212 internet draft submission to IETF and it needs to be updated once it 213 is accepted by IETF. --Hao]] As an example, suppose one wishes to 214 prove the knowledge of the exponent for X = g^x mod p. The generated 215 Schnorr NIZK proof will contain: {UserID, V = g^v mod p, r = v - x * 216 c mod q} where UserID is the unique identifier for the prover, v is a 217 number chosen uniformly at random from [0, q-1] and c = H(g || V || 218 X || UserID). The "uniqueness" of UserID is defined from the user's 219 perspective -- for example, if Alice communicates with several 220 parties, she shall associate a unique identity with each party. Upon 221 receiving a Schnorr NIZK proof, Alice shall check the prover's UserID 222 is a valid identity and is different from her own identity. During 223 the key exchange process using J-PAKE, each party shall ensure that 224 the other party has been consistently using the same identity 225 throughout the protocol execution. Details about the Schnorr NIZK 226 proof, including the generation and the verification procedures, can 227 be found in [I-D-Schnorr]. 229 When this round finishes, Alice verifies the received knowledge 230 proofs as specified in [I-D-Schnorr] and also checks that g4 != 1 mod 231 p. Similarly, Bob verifies the received knowledge proofs and also 232 checks that g2 != 1 mod p. 234 Round 2: 236 o Alice -> Bob: A = (g1*g3*g4)^(x2*s) mod p and a knowledge proof 237 for x2*s 239 o Bob -> Alice: B = (g1*g2*g3)^(x4*s) mod p and a knowledge proof 240 for x4*s 242 In this round, the Schnorr NIZK proof is computed in the same way as 243 in the previous round except that the generator is different. For 244 Alice, the generator used is (g1*g3*g4) instead of g; for Bob, the 245 generator is (g1*g2*g3) instead of g. Since any non-identity element 246 in Gq can be used as a generator, Alice and Bob just need to ensure 247 g1*g3*g4 != 1 mod p and g1*g2*g3 != 1 mod p. With overwhelming 248 probability, these inequalities are statistically guaranteed even 249 when the user is communicating with an adversary (i.e., in an active 250 attack). Nonetheless, for absolute guarantee, the receiving party 251 should explicitly check if these inequalities hold, and the cost of 252 doing that is negligible. 254 When the second round finishes, Alice and Bob verify the received 255 knowledge proofs and then compute the key material as follows: 257 o Alice computes Ka = (B/g4^(x2*s))^x2 mod p 259 o Bob computes Kb = (A/g2^(x4*s))^x4 mod p 261 Here Ka = Kb = g^((x1+x3)*x2*x4*s) mod p. Let K denote the same key 262 material held by both parties. Using K as input, Alice and Bob then 263 apply a Key Derivation Function (KDF) to derive a common session key 264 k. If the subsequent secure communication uses a symmetric cipher in 265 an authenticated mode (say AES-GCM), then one key is sufficient, 266 i.e., k = KDF(K). Otherwise, the session key should comprise an 267 encryption key (for confidentiality) and a MAC key (for integrity), 268 i.e., k = k_enc || k_mac, where k_enc = KDF(K || "JPAKE_ENC") and 269 k_mac = KDF(K || "JPAKE_MAC"). The exact choice of the KDF is left 270 to specific applications to define. (In many cases, the KDF may 271 simply be a cryptographic hash function, e.g., SHA-256.) 273 2.3. Computational Cost 275 The computational cost is estimated based on counting the number of 276 modular exponentiations since they are the predominant cost factors. 277 Note that it takes one exponentiation to generate a Schnorr NIZK 278 proof and two to verify it [I-D-Schnorr]. For Alice, she has to 279 perform 8 exponentiations in the first round, 4 in the second round, 280 and 2 in the final computation of the session key. Hence, that is 14 281 modular exponentiations in total. Based on the symmetry, the 282 computational cost for Bob is exactly the same. 284 3. J-PAKE over Elliptic Curve 286 3.1. Protocol Setup 288 The J-PAKE protocol works basically the same in the elliptic curve 289 (EC) setting, except that the underlying multiplicative group over a 290 finite field is replaced by an additive group over an elliptic curve. 291 Nonetheless, the EC version of J-PAKE is specified here for 292 completeness. 294 When implemented over an elliptic curve, J-PAKE may use the same EC 295 parameters as ECDSA, e.g., NIST P-256, P-384, and P-521 [NISTCurve]. 296 Let E(Fq) be an elliptic curve defined over a finite field Fq where q 297 is a large prime. Let G be a generator for the subgroup over E(Fq) 298 of prime order n. Here the NIST curves are used only as an example. 299 Other secure curves such as Curve25519 are also suitable for the 300 implementation as long as the elliptic curve discrete logarithm 301 problem (ECDLP) remains intractable. 303 As before, let s denote the shared secret between Alice and Bob. The 304 value of s is required to fall within [1, n-1]. 306 3.2. Two-Round Key Exchange 308 Round 1: Alice selects x1 and x2 uniformly at random from [1, n-1]. 309 Similarly, Bob selects x3 and x4 uniformly at random from [1, n-1]. 311 o Alice -> Bob: G1 = G x [x1], G2 = G x [x2] and knowledge proofs 312 for x1 and x2 314 o Bob -> Alice: G3 = G x [x3], G4 = G x [x4] and knowledge proofs 315 for x3 and x4 317 When this round finishes, Alice and Bob verify the received knowledge 318 proofs as specified in [I-D-Schnorr]. 320 Round 2: 322 o Alice -> Bob: A = (G1 + G3 + G4) x [x2*s] and a knowledge proof 323 for x2*s 325 o Bob -> Alice: B = (G1 + G2 + G3) x [x4*s] and a knowledge proof 326 for x4*s 328 When the second round finishes, Alice and Bob verify the received 329 knowledge proofs and then compute the key material as follows: 331 o Alice computes Ka = (B - (G4 x [x2*s])) x [x2] 332 o Bob computes Kb = (A - (G2 x [x4*s])) x [x4] 334 Here Ka = Kb = G x [(x1+x3)*(x2*x4*s)]. Let K denote the same key 335 material held by both parties. Using K as input, Alice and Bob then 336 apply a Key Derivation Function (KDF) to derive a common session key 337 k. Note that K is a point on E(Fq), consisting of the x and y 338 coordinates. In practice, it is sufficient to use only the x 339 coordinate as the input to KDF to derive the session key. The x 340 coordinate, which is a field element in Fq, can be converted to an 341 octet string, by following the method defined in section 2.3.3 in 342 [SEC1]. 344 3.3. Computational Cost 346 In the EC setting, the computational cost of J-PAKE is estimated 347 based on counting the number of scalar multiplications over the 348 elliptic curve. Note that it takes one multiplication to generate a 349 Schnorr NIZK proof and one to verify it [I-D-Schnorr]. For Alice, 350 she has to perform 6 multiplications in the first round, 3 in the 351 second round, and 2 in the final computation of the session key. 352 Hence, that is 11 multiplications in total. Based on the symmetry, 353 the computational cost for Bob is exactly the same. 355 4. Three-Pass Variant 357 The two-round J-PAKE protocol is completely symmetric, which 358 significantly simplifies the security analysis. In practice, one 359 party normally initiates the communication and the other party 360 responds. In that case, the protocol will be completed in three 361 passes instead of two rounds. The two-round J-PAKE protocol can be 362 trivially changed to three passes without losing security. Take the 363 finite field setting as an example and assume Alice initiates the key 364 exchange. The three-pass variant works as follows: 366 1. Alice -> Bob: g1 = g^x1 mod p, g2 = g^x2 mod p, knowledge proofs 367 for x1 and x2. 369 2. Bob -> Alice: g3 = g^x3 mod p, g4 = g^x4 mod p, B = 370 (g1*g2*g3)^(x4*s) mod p, knowledge proofs for x3, x4, and x4*s. 372 3. Alice -> Bob: A = (g1*g3*g4)^(x2*s) mod p and a knowledge proof 373 for x2*s. 375 Both parties compute the session keys in exactly the same way as 376 before. 378 5. Key Confirmation 380 The two-round J-PAKE protocol (or the three-pass variant) provides 381 cryptographic guarantee that only the authenticated party who used 382 the same password at the other end is able to compute the same 383 session key. So far the authentication is only implicit. The key 384 confirmation is also implicit [Stinson06]. The two parties may use 385 the derived key straight-away to start secure communication by 386 encrypting messages in an authenticated mode. Only the party with 387 the same derived session key will be able to decrypt and read those 388 messages. 390 For achieving explicit authentication, an additional key confirmation 391 procedure should be performed. This provides explicit assurance that 392 the other party has actually derived the same key. In this case, the 393 key confirmation is explicit [Stinson06]. 395 In J-PAKE, explicit key confirmation is recommended whenever the 396 network bandwidth allows it. It has the benefit of providing 397 explicit and immediate confirmation if the two parties have derived 398 the same key and hence are authenticated to each other. This allows 399 a practical implementation of J-PAKE to effectively detect online 400 dictionary attacks (if any), and stop them accordingly by setting a 401 threshold for the consecutively failed connection attempts. 403 To achieve explicit key confirmation, there are several methods 404 available. They are generically applicable to all key exchange 405 protocols, not just J-PAKE. In general, it is recommended to use a 406 different key from the session key for key confirmation, say using k' 407 = KDF(K || "JPAKE_KC"). The advantage of using a different key for 408 key confirmation is that the session key remains indistinguishable 409 from random after the key confirmation process (although this 410 perceived advantage is actually subtle and only theoretical). Two 411 explicit key confirmation methods are presented here. 413 The first method is based on the one used in the SPEKE protocol 414 [Jab96]. Suppose Alice initiates the key confirmation. Alice sends 415 to Bob H(H(k')), which Bob will verify. If the verification is 416 successful, Bob sends back to Alice H(k'), which Alice will verify. 417 This key confirmation procedure needs to be completed in two rounds, 418 as shown below. 420 1. Alice -> Bob: H(H(k')) 422 2. Bob -> Alice: H(k') 424 The second method is based on the unilateral key confirmation scheme 425 specified in NIST SP 800-56A Revision 1 [BJS07]. Alice and Bob send 426 to each other a MAC tag, which they will verify accordingly. This 427 key confirmation procedure can be completed in one round. 429 In the finite field setting it works as follows. 431 o Alice -> Bob: MacTagAlice = HMAC(k', "KC_1_U" || Alice || Bob || 432 g1 || g2 || g3 || g4) 434 o Bob -> Alice: MacTagBob = HMAC(k', "KC_1_U" || Bob || Alice || 435 g3 || g4 || g1 || g2) 437 In the EC setting it works basically the same. Let G1.x, G2.x, G3.x 438 and G4.x be the x coordinates of G1, G2, G3 and G4 respectively. It 439 is sufficient (and simpler) to include only the x coordinates in the 440 HMAC function. Hence, the key confirmation works as follows. 442 o Alice -> Bob: MacTagAlice = HMAC(k', "KC_1_U" || Alice || Bob || 443 G1.x || G2.x || G3.x || G4.x) 445 o Bob -> Alice: MacTagBob = HMAC(k', "KC_1_U" || Bob || Alice || 446 G3.x || G4.x || G1.x || G2.x) 448 The second method assumes an additional secure MAC function (HMAC) 449 and is slightly more complex than the first method. However, it can 450 be completed within one round and it preserves the overall symmetry 451 of the protocol implementation. For this reason, the second method 452 is recommended. 454 6. Security Considerations 456 A PAKE protocol is designed to provide two functions in one protocol 457 execution. The first one is to provide zero-knowledge authentication 458 of a password. It is called "zero knowledge" because at the end of 459 the protocol, the two communicating parties will learn nothing more 460 than one bit information: whether the passwords supplied at two ends 461 are equal. Therefore, a PAKE protocol is naturally resistant against 462 phishing attacks. The second function is to provide session key 463 establishment if the two passwords are equal. The session key will 464 be used to protect the confidentiality and integrity of the 465 subsequent communication. 467 More concretely, a secure PAKE protocol shall satisfy the following 468 security requirements [HR10]. 470 1. Off-line dictionary attack resistance: It does not leak any 471 information that allows a passive/active attacker to perform off- 472 line exhaustive search of the password. 474 2. Forward secrecy: It produces session keys that remain secure even 475 when the password is later disclosed. 477 3. Known-key security: It prevents a disclosed session key from 478 affecting the security of other sessions. 480 4. On-line dictionary attack resistance: It limits an active 481 attacker to test only one password per protocol execution. 483 First, a PAKE protocol must resist off-line dictionary attacks. A 484 password is inherently weak. Typically, it has only about 20-30 bits 485 entropy. This level of security is subject to exhaustive search. 486 Therefore, in the PAKE protocol, the communication must not reveal 487 any data that allows an attacker to learn the password through off- 488 line exhaustive search. 490 Second, a PAKE protocol must provide forward secrecy. The key 491 exchange is authenticated based on a shared password. However, there 492 is no guarantee on the long-term secrecy of the password. A secure 493 PAKE scheme shall protect past session keys even when the password is 494 later disclosed. This property also implies that if an attacker 495 knows the password but only passively observes the key exchange, he 496 cannot learn the session key. 498 Third, a PAKE protocol must provide known key security. A session 499 key lasts throughout the session. An exposed session key must not 500 cause any global impact on the system, affecting the security of 501 other sessions. 503 Finally, a PAKE protocol must resist on-line dictionary attacks. If 504 the attacker is directly engaging in the key exchange, there is no 505 way to prevent such an attacker trying a random guess of the 506 password. However, a secure PAKE scheme should mitigate the effect 507 of the on-line attack to the minimum. In the best case, the attacker 508 can only guess exactly one password per impersonation attempt. 509 Consecutively failed attempts can be easily detected and the 510 subsequent attempts shall be thwarted accordingly. 512 It has been proven in [HR10] that J-PAKE satisfies all of the four 513 requirements based on the assumptions that the Decisional Diffie- 514 Hellman problem is intractable and the underlying Schnorr NIZK proof 515 is secure. An independent study that proves security of J-PAKE in a 516 model with algebraic adversaries and random oracles can be found in 517 [ABM15]. By comparison, it has been known that EKE has the problem 518 of leaking partial information about the password to a passive 519 attacker, hence not satisfying the first requirement [Jas96]. For 520 SPEKE and SRP-6, an attacker may be able to test more than one 521 password in one on-line dictionary attack (see [Zha04] and [Hao10]), 522 hence they do not satisfy the fourth requirement in the strict 523 theoretical sense. Furthermore, SPEKE is found vulnerable to an 524 impersonation attack and a key-malleability attack [HS14]. These two 525 attacks affect the SPEKE protocol specified in Jablon's original 1996 526 paper [Jab96] as well in the latest IEEE P1363.2 standard draft D26 527 and the latest published ISO/IEC 11770-4:2006 standard. As a result, 528 the specification of SPEKE in ISO/IEC 11770-4 is being revised to 529 address the identified problems. 531 7. IANA Considerations 533 This document has no actions for IANA. 535 8. Acknowledgements 537 The editor would like to thank Dylan Clarke, Siamak Shahandashti, 538 Robert Cragie and Stanislav Smyshlyaev for useful comments. This 539 work is supported by EPSRC First Grant (EP/J011541/1) and ERC 540 Starting Grant (No. 306994). 542 9. References 544 9.1. Normative References 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, 548 DOI 10.17487/RFC2119, March 1997, 549 . 551 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 552 "Using the Secure Remote Password (SRP) Protocol for TLS 553 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 554 2007, . 556 [SEC1] "Standards for Efficient Cryptography. SEC 1: Elliptic 557 Curve Cryptography", SECG SEC1-v2, May 2004, 558 . 560 [ABM15] Abdalla, M., Benhamouda, F., and P. MacKenzie, "Security 561 of the J-PAKE Password-Authenticated Key Exchange 562 Protocol", IEEE Symposium on Security and Privacy, May 563 2015. 565 [BM92] Bellovin, S. and M. Merrit, "Encrypted Key Exchange: 566 Password-based Protocols Secure against Dictionary 567 Attacks", IEEE Symposium on Security and Privacy, May 568 1992. 570 [HR08] Hao, F. and P. Ryan, "Password Authenticated Key Exchange 571 by Juggling", 16th Workshop on Security Protocols 572 (SPW'08), May 2008. 574 [HR10] Hao, F. and P. Ryan, "J-PAKE: Authenticated Key Exchange 575 Without PKI", Springer Transactions on Computational 576 Science XI, 2010. 578 [HS14] Hao, F. and S. Shahandashti, "The SPEKE Protocol 579 Revisited", Security Standardisation Research, December 580 2014. 582 [Jab96] Jablon, D., "Strong Password-Only Authenticated Key 583 Exchange", ACM Computer Communications Review, October 584 1996. 586 [Stinson06] 587 Stinson, D., "Cryptography: Theory and Practice (3rd 588 Edition)", CRC, 2006. 590 [Wu98] Wu, T., "The Secure Remote Password protocol", Symposimum 591 on Network and Distributed System Security, March 1998. 593 [I-D-Schnorr] 594 Hao, F., "Schnorr NIZK proof: Non-interactive Zero 595 Knowledge Proof for Discrete Logarithm", Internet Draft 596 submitted to IETF, 2013. 598 9.2. Informative References 600 [BJS07] Barker, E., Johnson, D., and M. Smid, "Recommendation for 601 Pair-Wise Key Establishment Schemes Using Discrete 602 Logarithm Cryptography (Revised)", NIST Special 603 Publication 800-56A, March 2007, 604 . 607 [Jas96] Jaspan, B., "Dual-Workfactor Encrypted Key Exchange: 608 Efficiently Preventing Password Chaining and Dictionary 609 Attacks", USENIX Symphosium on Security, July 1996. 611 [Zha04] Zhang, M., "Analysis of The SPEKE Password-Authenticated 612 Key Exchange Protocol", IEEE Communications Letters, 613 January 2004. 615 [Hao10] Hao, F., "On Small Subgroup Non-Confinement Attacks", 616 IEEE conference on Computer and Information Technology, 617 2010. 619 [AP05] Abdalla, M. and D. Poincheval, "Simple Password-Based 620 Encrypted Key Exchange Protocols", Topics in Cryptology - 621 CT-RSA, 2005. 623 [NISTCurve] 624 "Recommended Elliptic Curves for Federal Government use", 625 July 1999, 626 . 629 9.3. URIs 631 [1] https://wiki.mozilla.org/Services/Sync/SyncKey/J-PAKE 633 [2] https://www.palemoon.org/sync/ 635 [3] http://boinc.berkeley.edu/android-boinc/libssl/crypto/jpake/ 637 [4] https://dxr.mozilla.org/mozilla- 638 central/source/security/nss/lib/freebl/jpake.c 640 [5] https://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/cryp 641 to/agreement/jpake/package-summary.html 643 [6] http://threadgroup.org/Portals/0/documents/whitepapers/ 644 Thread%20Commissioning%20white%20paper_v2_public.pdf 646 [7] http://www.iso.org/iso/home/store/catalogue_tc/ 647 catalogue_detail.htm?csnumber=67933 649 Author's Address 651 Feng Hao (editor) 652 Newcastle University (UK) 653 Claremont Tower, School of Computing Science, Newcastle University 654 Newcastle Upon Tyne 655 United Kingdom 657 Phone: +44 (0)191-208-6384 658 EMail: feng.hao@ncl.ac.uk