JPAKE: PasswordAuthenticated Key Exchange by Juggling
drafthaojpake06
The information below is for an old version of the document that is already published as an RFC.
Document  Type 
This is an older version of an InternetDraft that was ultimately published as RFC 8236.



Author  Feng Hao  
Last updated  20170905 (Latest revision 20170428)  
RFC stream  Independent Submission  
Intended RFC status  Informational  
Formats  
IETF conflict review  conflictreviewhaojpake  
Stream  ISE state  Published RFC  
Consensus boilerplate  Unknown  
Document shepherd  Eliot Lear  
Shepherd writeup  Show Last changed 20170510  
IESG  IESG state  Became RFC 8236 (Informational)  
Telechat date  (None)  
Responsible AD  (None)  
Send notices to  Nevil Brownlee <rfcise@rfceditor.org>  
IANA  IANA review state  IANA OK  No Actions Needed  
IANA action state  No IANA Actions 
drafthaojpake06
Network Working Group F. Hao, Ed. InternetDraft Newcastle University (UK) Intended status: Informational April 26, 2017 Expires: October 28, 2017 JPAKE: Password Authenticated Key Exchange by Juggling drafthaojpake06 Abstract This document specifies a Password Authenticated Key Exchange by Juggling (JPAKE) protocol. This protocol allows the establishment of a secure endtoend communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party. Status of This Memo This InternetDraft is submitted in full conformance with the provisions of BCP 78 and BCP 79. InternetDrafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as InternetDrafts. The list of current Internet Drafts is at http://datatracker.ietf.org/drafts/current/. InternetDrafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use InternetDrafts as reference material or to cite them other than as "work in progress." This InternetDraft will expire on October 28, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/licenseinfo) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Hao Expires October 28, 2017 [Page 1] InternetDraft JPAKE April 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3 2. JPAKE over Finite Field . . . . . . . . . . . . . . . . . . 4 2.1. Protocol Setup . . . . . . . . . . . . . . . . . . . . . 4 2.2. TwoRound Key Exchange . . . . . . . . . . . . . . . . . 5 2.3. Computational Cost . . . . . . . . . . . . . . . . . . . 6 3. JPAKE over Elliptic Curve . . . . . . . . . . . . . . . . . 7 3.1. Protocol Setup . . . . . . . . . . . . . . . . . . . . . 7 3.2. TwoRound Key Exchange . . . . . . . . . . . . . . . . . 7 3.3. Computational Cost . . . . . . . . . . . . . . . . . . . 8 4. ThreePass Variant . . . . . . . . . . . . . . . . . . . . . 8 5. Key Confirmation . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction PasswordAuthenticated Key Exchange (PAKE) is a technique that aims to establish secure communication between two remote parties solely based on their shared password, without relying on a Public Key Infrastructure or any trusted third party [BM92]. The first PAKE protocol, called EKE, was proposed by Steven Bellovin and Michael Merrit in 1992 [BM92]. Other wellknown PAKE protocols include SPEKE (by David Jablon in 1996) [Jab96] and SRP (by Tom Wu in 1998) [Wu98]. SRP has been revised several times to address reported security and efficiency issues. In particular, the version 6 of SRP, commonly known as SRP6, is specified in [RFC5054]. This document specifies a PAKE protocol called Password Authenticated Key Exchange by Juggling (JPAKE), which was designed by Feng Hao and Peter Ryan in 2008 [HR08]. There are a few factors that may be considered in favor of JPAKE. First, JPAKE has security proofs, while equivalent proofs are lacking in EKE, SPEKE and SRP6. Second, JPAKE follows a completely different design approach from all other PAKE protocols, and is built Hao Expires October 28, 2017 [Page 2] InternetDraft JPAKE April 2017 upon a wellestablished Zero Knowledge Proof (ZKP) primitive: Schnorr NIZK proof [SchnorrNIZK]. Third, JPAKE adopts novel engineering techniques to optimize the use of ZKP so that overall the protocol is sufficiently efficient for practical use. Fourth, JPAKE is designed to work generically in both the finite field and elliptic curve settings (i.e., DSA and ECDSAlike groups respectively). Unlike SPEKE, it does not require any extra primitive to hash passwords onto a designated elliptic curve. Unlike SPAKE2 [AP05] and SESPAKE [SOAA15], it does not require a trusted setup (i.e., the socalled common reference model) to define a pair of generators whose discrete logarithm must be unknown. Finally, JPAKE has been used in real world applications at a relatively large scale, e.g., Firefox sync [1], Pale moon sync [2] and Google Nest products [ABM15]; it has been included into widely distributed open source libraries such as OpenSSL [3], Network Security Services (NSS) [4] and the Bouncy Castle [5]; since 2015, it has been included into Thread [6] as a standard key agreement mechanism for IoT (Internet of Things) applications, and also included into ISO/IEC 117704 [7]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Notations The following notations are used in this document: o Alice: the assumed identity of the prover in the protocol o Bob: the assumed identity of the verifier in the protocol o s: a lowentropy secret shared between Alice and Bob o a  b: a divides b o a  b: concatenation of a and b o [a, b]: the interval of integers between and including a and b o H: a secure cryptographic hash function o p: a large prime o q: a large prime divisor of p1, i.e., q  p1 o Zp*: a multiplicative group of integers modulo p Hao Expires October 28, 2017 [Page 3] InternetDraft JPAKE April 2017 o Gq: a subgroup of Zp* with prime order q o g: a generator of Gq o g^x: g raised to the power of x o a mod b: a modulo b o Fp: a finite field of p elements where p is a prime o E(Fp): an elliptic curve defined over Fp o G: a generator of the subgroup over E(Fp) with prime order n o n: the order of G o h: the cofactor of the subgroup generated by G, which is equal to the order of the elliptic curve divided by n o P x [b]: multiplication of a point P with a scalar b over E(Fp) o KDF(a): Key Derivation Function with input a o MAC(MacKey, MacData): MAC function with MacKey as the key and MacData as the input data 2. JPAKE over Finite Field 2.1. Protocol Setup When implemented over a finite field, JPAKE may use the same group parameters as DSA [FIPS1864]. Let p and q be two large primes such that q  p1. Let Gq denote a subgroup of Zp* with prime order q. Let g be a generator for Gq. Any nonidentity element in Gq can be a generator. The two communicating parties, Alice and Bob, both agree on (p, q, g), which can be hardwired in the software code. They can also use the method in NIST FIPS 1864, Appendix A [FIPS1864] to generate (p, q, g). Here DSA group parameters are used only as an example. Other multiplicative groups suitable for cryptography can also be used for the implementation, e.g., groups defined in [RFC4419]. A group setting that provides 128bit security or above is recommended. The security proof of JPAKE depends on the Decisional DiffieHellman (DDH) problem being intractable in the considered group. Let s be a secret value derived from a lowentropy password shared between Alice and Bob. The value of s is required to fall within the range of [1, q1]. (Note that s must not be 0 for any nonempty Hao Expires October 28, 2017 [Page 4] InternetDraft JPAKE April 2017 secret.) This range is defined as a necessary condition in [HR08] for proving the "online dictionary attack resistance", since s, s+q, s+2q, ..., are all considered equivalent values as far as the protocol specification is concerned. In a practical implementation, one may obtain s by taking a cryptographic hash of the password and wrapping the result with respect to modulo q. Alternatively, one may simply treat the password as an octet string and convert the string to an integer modulo q by following the method defined in Section 2.3.8 of [SEC1]. In either case, one must ensure s is not equal to 0 modulo q. 2.2. TwoRound Key Exchange Round 1: Alice selects an ephemeral private key x1 uniformly at random from [0, q1] and another ephemeral private key x2 uniformly at random from [1, q1]. Similarly, Bob selects an ephemeral private key x3 uniformly at random from [0, q1] and another ephemeral private key x4 uniformly at random from [1, q1]. o Alice > Bob: g1 = g^x1 mod p, g2 = g^x2 mod p and ZKPs for x1 and x2 o Bob > Alice: g3 = g^x3 mod p, g4 = g^x4 mod p and ZKPs for x3 and x4 In this round, the sender must send zero knowledge proofs to demonstrate the knowledge of the ephemeral private keys. A suitable technique is to use the Schnorr NIZK proof [SchnorrNIZK]. As an example, suppose one wishes to prove the knowledge of the exponent for X = g^x mod p. The generated Schnorr NIZK proof will contain: {UserID, V = g^v mod p, r = v  x * c mod q} where UserID is the unique identifier for the prover, v is a number chosen uniformly at random from [0, q1] and c = H(g  V  X  UserID). The "uniqueness" of UserID is defined from the user's perspective  for example, if Alice communicates with several parties, she shall associate a unique identity with each party. Upon receiving a Schnorr NIZK proof, Alice shall check the prover's UserID is a valid identity and is different from her own identity. During the key exchange process using JPAKE, each party shall ensure that the other party has been consistently using the same identity throughout the protocol execution. Details about the Schnorr NIZK proof, including the generation and the verification procedures, can be found in [SchnorrNIZK]. When this round finishes, Alice verifies the received ZKPs as specified in [SchnorrNIZK] and also checks that g4 != 1 mod p. Similarly, Bob verifies the received ZKPs and also checks that g2 != Hao Expires October 28, 2017 [Page 5] InternetDraft JPAKE April 2017 1 mod p. If any of these checks fails, this session should be aborted. Round 2: o Alice > Bob: A = (g1*g3*g4)^(x2*s) mod p and a ZKP for x2*s o Bob > Alice: B = (g1*g2*g3)^(x4*s) mod p and a ZKP for x4*s In this round, the Schnorr NIZK proof is computed in the same way as in the previous round except that the generator is different. For Alice, the generator used is (g1*g3*g4) instead of g; for Bob, the generator is (g1*g2*g3) instead of g. Since any nonidentity element in Gq can be used as a generator, Alice and Bob just need to ensure g1*g3*g4 != 1 mod p and g1*g2*g3 != 1 mod p. With overwhelming probability, these inequalities are statistically guaranteed even when the user is communicating with an adversary (i.e., in an active attack). Nonetheless, for absolute guarantee, the receiving party shall explicitly check if these inequalities hold, and abort the session in case such a check fails. When the second round finishes, Alice and Bob verify the received ZKPs. If the verification fails, the session is aborted. Otherwise, the two parties compute the common key material as follows: o Alice computes Ka = (B/g4^(x2*s))^x2 mod p o Bob computes Kb = (A/g2^(x4*s))^x4 mod p Here Ka = Kb = g^((x1+x3)*x2*x4*s) mod p. Let K denote the same key material held by both parties. Using K as input, Alice and Bob then apply a Key Derivation Function (KDF) to derive a common session key k. If the subsequent secure communication uses a symmetric cipher in an authenticated mode (say AESGCM), then one key is sufficient, i.e., k = KDF(K). Otherwise, the session key should comprise an encryption key (for confidentiality) and a MAC key (for integrity), i.e., k = k_enc  k_mac, where k_enc = KDF(K  "JPAKE_ENC") and k_mac = KDF(K  "JPAKE_MAC"). The exact choice of the KDF is left to specific applications to define. 2.3. Computational Cost The computational cost is estimated based on counting the number of modular exponentiations since they are the predominant cost factors. Note that it takes one exponentiation to generate a Schnorr NIZK proof and two to verify it [SchnorrNIZK]. For Alice, she needs to perform 8 exponentiations in the first round, 4 in the second round, and 2 in the final computation of the session key. Hence, that is 14 Hao Expires October 28, 2017 [Page 6] InternetDraft JPAKE April 2017 modular exponentiations in total. Based on the symmetry, the computational cost for Bob is exactly the same. 3. JPAKE over Elliptic Curve 3.1. Protocol Setup The JPAKE protocol works basically the same in the elliptic curve (EC) setting, except that the underlying multiplicative group over a finite field is replaced by an additive group over an elliptic curve. Nonetheless, the EC version of JPAKE is specified here for completeness. When implemented over an elliptic curve, JPAKE may use the same EC parameters as ECDSA [FIPS1864]. The FIPS 1864 standard [FIPS1864] defines three types of curves suitable for ECDSA: pseudorandom curves over prime fields, pseudorandom curves over binary fields and special curves over binary fields called Koblitz curves or anomalous binary curves. All these curves that are suitable for ECDSAA can also be used to implement JPAKE. However, for the illustration purpose, only curves over prime fields are described in this document. Typically, such curves include NIST P256, P384 and P521. When choosing a curve, a level of 128bit security or above is recommended. Let E(Fp) be an elliptic curve defined over a finite field Fp where p is a large prime. Let G be a generator for the subgroup over E(Fp) of prime order n. Here the NIST curves are used only as an example. Other secure curves such as Curve25519 are also suitable for the implementation. The security proof of JPAKE relies on the assumption that the DDH problem is intractable in the considered group. As before, let s denote the shared secret between Alice and Bob. The value of s falls within [1, n1]. In particular, note that s must not be equal to 0 mod n. 3.2. TwoRound Key Exchange Round 1: Alice selects ephemeral private keys x1 and x2 uniformly at random from [1, n1]. Similarly, Bob selects ephemeral private keys x3 and x4 uniformly at random from [1, n1]. o Alice > Bob: G1 = G x [x1], G2 = G x [x2] and ZKPs for x1 and x2 o Bob > Alice: G3 = G x [x3], G4 = G x [x4] and ZKPs for x3 and x4 When this round finishes, Alice and Bob verify the received ZKPs as specified in [SchnorrNIZK]. As an example, to prove the knowledge of the discrete logarithm of X = G x [x] with respect to the base point Hao Expires October 28, 2017 [Page 7] InternetDraft JPAKE April 2017 G, the ZKP contains: {UserID, V = G x [v], r = v  x * c mod n} where UserID is the unique identifier for the prover, v is a number chosen uniformly at random from [1, n1] and c = H(G  V  X  UserID). The verifier shall check the prover's UserID is a valid identity and is different from its own identity. If the verification of the ZKP fails, the session is aborted. Round 2: o Alice > Bob: A = (G1 + G3 + G4) x [x2*s] and a ZKP for x2*s o Bob > Alice: B = (G1 + G2 + G3) x [x4*s] and a ZKP for x4*s When the second round finishes, Alice and Bob verify the received ZKPs. The ZKPs are computed in the same way as in the previous round except that the generator is different. For Alice, the new generator is G1 + G3 + G4; for Bob, it is G1 + G2 + G3. Alice and Bob shall check that these new generators are not points at infinity. If any of these checks fails, the session is aborted. Otherwise, the two parties compute the common key material as follows: o Alice computes Ka = (B  (G4 x [x2*s])) x [x2] o Bob computes Kb = (A  (G2 x [x4*s])) x [x4] Here Ka = Kb = G x [(x1+x3)*(x2*x4*s)]. Let K denote the same key material held by both parties. Using K as input, Alice and Bob then apply a Key Derivation Function (KDF) to derive a common session key k. 3.3. Computational Cost In the EC setting, the computational cost of JPAKE is estimated based on counting the number of scalar multiplications over the elliptic curve. Note that it takes one multiplication to generate a Schnorr NIZK proof and one to verify it [SchnorrNIZK]. For Alice, she has to perform 6 multiplications in the first round, 3 in the second round, and 2 in the final computation of the session key. Hence, that is 11 multiplications in total. Based on the symmetry, the computational cost for Bob is exactly the same. 4. ThreePass Variant The tworound JPAKE protocol is completely symmetric, which significantly simplifies the security analysis. In practice, one party normally initiates the communication and the other party responds. In that case, the protocol will be completed in three passes instead of two rounds. The tworound JPAKE protocol can be Hao Expires October 28, 2017 [Page 8] InternetDraft JPAKE April 2017 trivially changed to three passes without losing security. Take the finite field setting as an example and assume Alice initiates the key exchange. The threepass variant works as follows: 1. Alice > Bob: g1 = g^x1 mod p, g2 = g^x2 mod p, ZKPs for x1 and x2. 2. Bob > Alice: g3 = g^x3 mod p, g4 = g^x4 mod p, B = (g1*g2*g3)^(x4*s) mod p, ZKPs for x3, x4, and x4*s. 3. Alice > Bob: A = (g1*g3*g4)^(x2*s) mod p and a ZKP for x2*s. Both parties compute the session keys in exactly the same way as before. 5. Key Confirmation The tworound JPAKE protocol (or the threepass variant) provides cryptographic guarantee that only the authenticated party who used the same password at the other end is able to compute the same session key. So far the authentication is only implicit. The key confirmation is also implicit [Stinson06]. The two parties may use the derived key straightaway to start secure communication by encrypting messages in an authenticated mode. Only the party with the same derived session key will be able to decrypt and read those messages. For achieving explicit authentication, an additional key confirmation procedure should be performed. This provides explicit assurance that the other party has actually derived the same key. In this case, the key confirmation is explicit [Stinson06]. In JPAKE, explicit key confirmation is recommended whenever the network bandwidth allows it. It has the benefit of providing explicit and immediate confirmation if the two parties have derived the same key and hence are authenticated to each other. This allows a practical implementation of JPAKE to effectively detect online dictionary attacks (if any), and stop them accordingly by setting a threshold for the consecutively failed connection attempts. To achieve explicit key confirmation, there are several methods available. They are generically applicable to all key exchange protocols, not just JPAKE. In general, it is recommended to use a different key from the session key for key confirmation, say using k' = KDF(K  "JPAKE_KC"). The advantage of using a different key for key confirmation is that the session key remains indistinguishable from random after the key confirmation process (although this Hao Expires October 28, 2017 [Page 9] InternetDraft JPAKE April 2017 perceived advantage is actually subtle and only theoretical). Two explicit key confirmation methods are presented here. The first method is based on the one used in the SPEKE protocol [Jab96]. Suppose Alice initiates the key confirmation. Alice sends to Bob H(H(k')), which Bob will verify. If the verification is successful, Bob sends back to Alice H(k'), which Alice will verify. This key confirmation procedure needs to be completed in two rounds, as shown below. 1. Alice > Bob: H(H(k')) 2. Bob > Alice: H(k') The above procedure requires two rounds instead of one, because the second message depends on the first. If both parties attempt to send the first message at the same time without an agreed order, they cannot tell if the message that they receive is a genuine challenge or a replayed message, and consequently may enter a deadlock. The second method is based on the unilateral key confirmation scheme specified in NIST SP 80056A Revision 1 [BJS07]. Alice and Bob send to each other a MAC tag, which they will verify accordingly. This key confirmation procedure can be completed in one round. In the finite field setting it works as follows. o Alice > Bob: MacTagAlice = MAC(k', "KC_1_U"  Alice  Bob  g1  g2  g3  g4) o Bob > Alice: MacTagBob = MAC(k', "KC_1_U"  Bob  Alice  g3  g4  g1  g2) In the EC setting, the key confirmation works basically the same. o Alice > Bob: MacTagAlice = MAC(k', "KC_1_U"  Alice  Bob  G1  G2  G3  G4) o Bob > Alice: MacTagBob = MAC(k', "KC_1_U"  Bob  Alice  G3  G4  G1  G2) The second method assumes an additional secure MAC function (e.g., one may use HMAC) and is slightly more complex than the first method. However, it can be completed within one round and it preserves the overall symmetry of the protocol implementation. For this reason, the second method is recommended. Hao Expires October 28, 2017 [Page 10] InternetDraft JPAKE April 2017 6. Security Considerations A PAKE protocol is designed to provide two functions in one protocol execution. The first one is to provide zeroknowledge authentication of a password. It is called "zero knowledge" because at the end of the protocol, the two communicating parties will learn nothing more than one bit information: whether the passwords supplied at two ends are equal. Therefore, a PAKE protocol is naturally resistant against phishing attacks. The second function is to provide session key establishment if the two passwords are equal. The session key will be used to protect the confidentiality and integrity of the subsequent communication. More concretely, a secure PAKE protocol shall satisfy the following security requirements [HR10]. 1. Offline dictionary attack resistance: It does not leak any information that allows a passive/active attacker to perform off line exhaustive search of the password. 2. Forward secrecy: It produces session keys that remain secure even when the password is later disclosed. 3. Knownkey security: It prevents a disclosed session key from affecting the security of other sessions. 4. Online dictionary attack resistance: It limits an active attacker to test only one password per protocol execution. First, a PAKE protocol must resist offline dictionary attacks. A password is inherently weak. Typically, it has only about 2030 bits entropy. This level of security is subject to exhaustive search. Therefore, in the PAKE protocol, the communication must not reveal any data that allows an attacker to learn the password through off line exhaustive search. Second, a PAKE protocol must provide forward secrecy. The key exchange is authenticated based on a shared password. However, there is no guarantee on the longterm secrecy of the password. A secure PAKE scheme shall protect past session keys even when the password is later disclosed. This property also implies that if an attacker knows the password but only passively observes the key exchange, he cannot learn the session key. Third, a PAKE protocol must provide known key security. A session key lasts throughout the session. An exposed session key must not cause any global impact on the system, affecting the security of other sessions. Hao Expires October 28, 2017 [Page 11] InternetDraft JPAKE April 2017 Finally, a PAKE protocol must resist online dictionary attacks. If the attacker is directly engaging in the key exchange, there is no way to prevent such an attacker trying a random guess of the password. However, a secure PAKE scheme should mitigate the effect of the online attack to the minimum. In the best case, the attacker can only guess exactly one password per impersonation attempt. Consecutively failed attempts can be easily detected and the subsequent attempts shall be thwarted accordingly. It is recommended that the false authentication counter should be handled in such a way that any error (which causes the session to fail during the key exchange or key confirmation) would lead to incrementing the false authentication counter. It has been proven in [HR10] that JPAKE satisfies all of the four requirements based on the assumptions that the Decisional Diffie Hellman problem is intractable and the underlying Schnorr NIZK proof is secure. An independent study that proves security of JPAKE in a model with algebraic adversaries and random oracles can be found in [ABM15]. By comparison, it has been known that EKE has the problem of leaking partial information about the password to a passive attacker, hence not satisfying the first requirement [Jas96]. For SPEKE and SRP6, an attacker may be able to test more than one password in one online dictionary attack (see [Zha04] and [Hao10]), hence they do not satisfy the fourth requirement in the strict theoretical sense. Furthermore, SPEKE is found vulnerable to an impersonation attack and a keymalleability attack [HS14]. These two attacks affect the SPEKE protocol specified in Jablon's original 1996 paper [Jab96] as well in the D26 draft of IEEE P1363.2 and the latest published ISO/IEC 117704:2006 standard. As a result, the specification of SPEKE in ISO/IEC 117704:2006 has been revised to address the identified problems. 7. IANA Considerations This document has no actions for IANA. 8. Acknowledgements The editor would like to thank Dylan Clarke, Siamak Shahandashti, Robert Cragie, Stanislav Smyshlyaev and Russ Housley for many useful comments. This work is supported by EPSRC First Grant (EP/J011541/1) and ERC Starting Grant (No. 306994). 9. References Hao Expires October 28, 2017 [Page 12] InternetDraft JPAKE April 2017 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfceditor.org/info/rfc2119>. [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, DOI 10.17487/RFC5054, November 2007, <http://www.rfceditor.org/info/rfc5054>. [SEC1] "Standards for Efficient Cryptography. SEC 1: Elliptic Curve Cryptography", SECG SEC1v2, May 2004, <http://www.secg.org/sec1v2.pdf>. [ABM15] Abdalla, M., Benhamouda, F., and P. MacKenzie, "Security of the JPAKE PasswordAuthenticated Key Exchange Protocol", IEEE Symposium on Security and Privacy, May 2015. [BM92] Bellovin, S. and M. Merrit, "Encrypted Key Exchange: Passwordbased Protocols Secure against Dictionary Attacks", IEEE Symposium on Security and Privacy, May 1992. [HR08] Hao, F. and P. Ryan, "Password Authenticated Key Exchange by Juggling", 16th Workshop on Security Protocols (SPW'08), May 2008. [HR10] Hao, F. and P. Ryan, "JPAKE: Authenticated Key Exchange Without PKI", Springer Transactions on Computational Science XI, 2010. [HS14] Hao, F. and S. Shahandashti, "The SPEKE Protocol Revisited", Security Standardisation Research, December 2014. [Jab96] Jablon, D., "Strong PasswordOnly Authenticated Key Exchange", ACM Computer Communications Review, October 1996. [Stinson06] Stinson, D., "Cryptography: Theory and Practice (3rd Edition)", CRC, 2006. [Wu98] Wu, T., "The Secure Remote Password protocol", Symposimum on Network and Distributed System Security, March 1998. Hao Expires October 28, 2017 [Page 13] InternetDraft JPAKE April 2017 [SchnorrNIZK] Hao, F., "Schnorr NIZK proof: Noninteractive Zero Knowledge Proof for Discrete Logarithm", IETF Internet Draft06 (work in progress), 2017, <https://datatracker.ietf.org/doc/drafthaoschnorr/>. 9.2. Informative References [RFC4419] Friedl, M., Provos, N., and W. Simpson, "DiffieHellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, <http://www.rfceditor.org/info/rfc4419>. [BJS07] Barker, E., Johnson, D., and M. Smid, "Recommendation for PairWise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST Special Publication 80056A, March 2007, <http://csrc.nist.gov/publications/nistpubs/80056A/ SP80056A_Revision1_Mar082007.pdf>. [Jas96] Jaspan, B., "DualWorkfactor Encrypted Key Exchange: Efficiently Preventing Password Chaining and Dictionary Attacks", USENIX Symphosium on Security, July 1996. [Zha04] Zhang, M., "Analysis of The SPEKE PasswordAuthenticated Key Exchange Protocol", IEEE Communications Letters, January 2004. [Hao10] Hao, F., "On Small Subgroup NonConfinement Attacks", IEEE conference on Computer and Information Technology, 2010. [AP05] Abdalla, M. and D. Pointcheval, "Simple PasswordBased Encrypted Key Exchange Protocols", Topics in Cryptology  CTRSA, 2005. [FIPS1864] "Federal Information Processing Standards Publication 1864: Specifications for the Digital Signature Standard (DSS)", July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.1864.pdf>. [SOAA15] Smyshlyaev, S., Oshkin, I., Alekseev, E., and L. Ahmetzyanova, "On the Security of One Password Authenticated Key Exchange Protocol", 2015, <http://eprint.iacr.org/2015/1237.pdf>. Hao Expires October 28, 2017 [Page 14] InternetDraft JPAKE April 2017 9.3. URIs [1] https://wiki.mozilla.org/Services/Sync/SyncKey/JPAKE [2] https://www.palemoon.org/sync/ [3] http://boinc.berkeley.edu/androidboinc/libssl/crypto/jpake/ [4] https://dxr.mozilla.org/mozilla central/source/security/nss/lib/freebl/jpake.c [5] https://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/cryp to/agreement/jpake/packagesummary.html [6] http://threadgroup.org/Portals/0/documents/whitepapers/ Thread%20Commissioning%20white%20paper_v2_public.pdf [7] https://www.iso.org/standard/67933.html Author's Address Feng Hao (editor) Newcastle University (UK) Claremont Tower, School of Computing Science, Newcastle University Newcastle Upon Tyne United Kingdom Phone: +44 (0)1912086384 EMail: feng.hao@ncl.ac.uk Hao Expires October 28, 2017 [Page 15]