diff options
Diffstat (limited to 'doc/rfc/rfc8236.txt')
| -rw-r--r-- | doc/rfc/rfc8236.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc8236.txt b/doc/rfc/rfc8236.txt new file mode 100644 index 0000000..3438726 --- /dev/null +++ b/doc/rfc/rfc8236.txt @@ -0,0 +1,843 @@ + + + + + + +Independent Submission F. Hao, Ed. +Request for Comments: 8236 Newcastle University (UK) +Category: Informational September 2017 +ISSN: 2070-1721 + + + J-PAKE: Password-Authenticated Key Exchange by Juggling + +Abstract + + This document specifies a Password-Authenticated Key Exchange by + Juggling (J-PAKE) protocol. This protocol allows the establishment + of a secure end-to-end 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 document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8236. + +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/license-info) 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. + + + + + + + +Hao Informational [Page 1] + +RFC 8236 J-PAKE September 2017 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. J-PAKE over Finite Field . . . . . . . . . . . . . . . . . . 4 + 2.1. Protocol Setup . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Two-Round Key Exchange . . . . . . . . . . . . . . . . . 5 + 2.3. Computational Cost . . . . . . . . . . . . . . . . . . . 6 + 3. J-PAKE over Elliptic Curve . . . . . . . . . . . . . . . . . 7 + 3.1. Protocol Setup . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. Two-Round Key Exchange . . . . . . . . . . . . . . . . . 7 + 3.3. Computational Cost . . . . . . . . . . . . . . . . . . . 8 + 4. Three-Pass Variant . . . . . . . . . . . . . . . . . . . . . 8 + 5. Key Confirmation . . . . . . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 8.2. Informative References . . . . . . . . . . . . . . . . . 14 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 + +1. Introduction + + Password-Authenticated 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 Encrypted Key Exchange (EKE), was proposed by Steven + Bellovin and Michael Merrit in 1992 [BM92]. Other well-known PAKE + protocols include Simple Password Exponential Key Exchange (SPEKE) by + David Jablon in 1996 [Jab96] and Secure Remote Password (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 SRP-6, is specified in [RFC5054]. + + This document specifies a PAKE protocol called Password-Authenticated + Key Exchange by Juggling (J-PAKE), which was designed by Feng Hao and + Peter Ryan in 2008 [HR08]. There are a few factors that may be + considered in favor of J-PAKE. First, J-PAKE has security proofs, + while equivalent proofs are lacking in EKE, SPEKE and SRP-6. Second, + J-PAKE follows a completely different design approach from all other + PAKE protocols, and is built upon a well-established Zero Knowledge + Proof (ZKP) primitive: Schnorr NIZK proof [RFC8235]. Third, J-PAKE + adopts novel engineering techniques to optimize the use of ZKP so + that overall the protocol is sufficiently efficient for practical + use. Fourth, J-PAKE is designed to work generically in both the + + + +Hao Informational [Page 2] + +RFC 8236 J-PAKE September 2017 + + + finite field and elliptic curve settings (i.e., DSA and ECDSA-like + 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 so-called common reference model) to define a pair + of generators whose discrete logarithm must be unknown. Finally, + J-PAKE has been used in real-world applications at a relatively large + scale, e.g., Firefox sync [MOZILLA], Pale moon sync [PALEMOON], and + Google Nest products [ABM15]. It has been included into widely + distributed open source libraries such as OpenSSL [BOINC], Network + Security Services (NSS) [MOZILLA_NSS], and the Bouncy Castle + [BOUNCY]. Since 2015, J-PAKE has been included in Thread [THREAD] as + a standard key agreement mechanism for IoT (Internet of Things) + applications, and also included in ISO/IEC 11770-4:2017 + [ISO.11770-4]. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +1.2. Notation + + The following notation is 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 low-entropy 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 p-1, i.e., q | p-1 + + o Zp*: a multiplicative group of integers modulo p + + + + +Hao Informational [Page 3] + +RFC 8236 J-PAKE September 2017 + + + o Gq: a subgroup of Zp* with prime order q + + o g: a generator of Gq + + o g^d: g raised to the power of d + + 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. J-PAKE over Finite Field + +2.1. Protocol Setup + + When implemented over a finite field, J-PAKE may use the same group + parameters as DSA [FIPS186-4]. Let p and q be two large primes such + that q | p-1. Let Gq denote a subgroup of Zp* with prime order q. + Let g be a generator for Gq. Any non-identity element in Gq can be a + generator. The two communicating parties, Alice and Bob, both agree + on (p, q, g), which can be hard-wired in the software code. They can + also use the method in NIST FIPS 186-4, Appendix A [FIPS186-4] 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 128-bit security or above + is recommended. The security proof of J-PAKE depends on the + Decisional Diffie-Hellman (DDH) problem being intractable in the + considered group. + + Let s be a secret value derived from a low-entropy password shared + between Alice and Bob. The value of s is REQUIRED to fall within the + range of [1, q-1]. (Note that s must not be 0 for any non-empty + + + +Hao Informational [Page 4] + +RFC 8236 J-PAKE September 2017 + + + secret.) This range is defined as a necessary condition in [HR08] + for proving the "on-line 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. Two-Round Key Exchange + + Round 1: Alice selects an ephemeral private key x1 uniformly at + random from [0, q-1] and another ephemeral private key x2 uniformly + at random from [1, q-1]. Similarly, Bob selects an ephemeral private + key x3 uniformly at random from [0, q-1] and another ephemeral + private key x4 uniformly at random from [1, q-1]. + + 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 [RFC8235]. As an example, + suppose one wishes to prove the knowledge of the exponent for D = g^d + mod p. The generated Schnorr NIZK proof will contain: {UserID, + V = g^v mod p, r = v - d * c mod q}, where UserID is the unique + identifier for the prover, v is a number chosen uniformly at random + from [0, q-1] and c = H(g || V || D || 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 J-PAKE, + 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 [RFC8235]. + + When this round finishes, Alice verifies the received ZKPs as + specified in [RFC8235] and also checks that g4 != 1 mod p. + Similarly, Bob verifies the received ZKPs and also checks that + g2 != 1 mod p. If any of these checks fails, this session should be + aborted. + + + +Hao Informational [Page 5] + +RFC 8236 J-PAKE September 2017 + + + 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 non-identity 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 AES-GCM), 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 [RFC8235]. 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 + modular exponentiations in total. Based on the symmetry, the + computational cost for Bob is exactly the same. + + + + +Hao Informational [Page 6] + +RFC 8236 J-PAKE September 2017 + + +3. J-PAKE over Elliptic Curve + +3.1. Protocol Setup + + The J-PAKE 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 J-PAKE is specified here for + completeness. + + When implemented over an elliptic curve, J-PAKE may use the same EC + parameters as ECDSA [FIPS186-4]. The FIPS 186-4 standard [FIPS186-4] + 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 ECDSA can also + be used to implement J-PAKE. However, for illustration purposes, + only curves over prime fields are described in this document. + Typically, such curves include NIST P-256, P-384, and P-521. When + choosing a curve, a level of 128-bit 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 implementation. The security proof of J-PAKE 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, n-1]. In particular, note that s MUST + not be equal to 0 mod n. + +3.2. Two-Round Key Exchange + + Round 1: Alice selects ephemeral private keys x1 and x2 uniformly at + random from [1, n-1]. Similarly, Bob selects ephemeral private keys + x3 and x4 uniformly at random from [1, n-1]. + + 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 [RFC8235]. As an example, to prove the knowledge of the + discrete logarithm of D = G x [d] with respect to the base point G, + the ZKP contains: {UserID, V = G x [v], r = v - d * c mod n}, where + UserID is the unique identifier for the prover, v is a number chosen + uniformly at random from [1, n-1] and c = H(G || V || D || UserID). + + + +Hao Informational [Page 7] + +RFC 8236 J-PAKE September 2017 + + + 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 J-PAKE 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 [RFC8235]. 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. Three-Pass Variant + + The two-round J-PAKE 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 two-round J-PAKE protocol can be + trivially changed to three passes without losing security. Take the + finite field setting as an example, and assume Alice initiates the + key exchange. The three-pass variant works as follows: + + + +Hao Informational [Page 8] + +RFC 8236 J-PAKE September 2017 + + + 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 two-round J-PAKE protocol (or the three-pass 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 straight away 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 J-PAKE, 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 J-PAKE 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 J-PAKE. In general, it is recommended that a + different key from the session key be used for key confirmation -- + say, 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. + (However, this perceived advantage is actually subtle and only + theoretical.) Two explicit key confirmation methods are presented + here. + + + + + +Hao Informational [Page 9] + +RFC 8236 J-PAKE September 2017 + + + 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 800-56A 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 Informational [Page 10] + +RFC 8236 J-PAKE September 2017 + + +6. Security Considerations + + A PAKE protocol is designed to provide two functions in one protocol + execution. The first one is to provide zero-knowledge 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 + offline exhaustive search of the password. + + 2. Forward secrecy: It produces session keys that remain secure even + when the password is later disclosed. + + 3. Known-key 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 20-30 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 + offline 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 long-term 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 Informational [Page 11] + +RFC 8236 J-PAKE September 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 minimize the effect + of the online attack. 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 be handled in such a way that any error (which + causes the session to fail during the key exchange or key + confirmation) leads to incrementing the false authentication counter. + + It has been proven in [HR10] that J-PAKE 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 J-PAKE 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 SRP-6, 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 key-malleability 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 ISO/ + IEC 11770-4:2006 standard. As a result, the specification of SPEKE + in ISO/IEC 11770-4:2006 has been revised to address the identified + problems. + +7. IANA Considerations + + This document does not require any IANA actions. + +8. References + +8.1. Normative References + + [ABM15] Abdalla, M., Benhamouda, F., and P. MacKenzie, "Security + of the J-PAKE Password-Authenticated Key Exchange + Protocol", 2015 IEEE Symposium on Security and Privacy, + DOI 10.1109/sp.2015.41, May 2015. + + [BM92] Bellovin, S. and M. Merrit, "Encrypted Key Exchange: + Password-based Protocols Secure against Dictionary + Attacks", IEEE Symposium on Security and Privacy, + DOI 10.1109/risp.1992.213269, May 1992. + + + +Hao Informational [Page 12] + +RFC 8236 J-PAKE September 2017 + + + [HR08] Hao, F. and P. Ryan, "Password Authenticated Key Exchange + by Juggling", Lecture Notes in Computer Science, pp. + 159-171, from 16th Security Protocols Workshop (SPW '08), + DOI 10.1007/978-3-642-22137-8_23, 2011. + + [HR10] Hao, F. and P. Ryan, "J-PAKE: Authenticated Key Exchange + Without PKI", Transactions on Computational Science XI, + pp. 192-206, DOI 10.1007/978-3-642-17697-5_10, 2010. + + [HS14] Hao, F. and S. Shahandashti, "The SPEKE Protocol + Revisited", Security Standardisation Research, pp. 26-38, + DOI 10.1007/978-3-319-14054-4_2, December 2014. + + [Jab96] Jablon, D., "Strong Password-Only Authenticated Key + Exchange", ACM SIGCOMM Computer Communication Review, Vol. + 26, pp. 5-26, DOI 10.1145/242896.242897, October 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.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, <https://www.rfc-editor.org/info/rfc5054>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero Knowledge + Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017, + <https://www.rfc-editor.org/info/rfc8235>. + + [SEC1] "Standards for Efficient Cryptography. SEC 1: Elliptic + Curve Cryptography", SECG SEC1-v2, May 2009, + <http://www.secg.org/sec1-v2.pdf>. + + [Stinson06] + Stinson, D., "Cryptography: Theory and Practice", 3rd + Edition, CRC, 2006. + + [Wu98] Wu, T., "The Secure Remote Password Protocol", Internet + Society Symposium on Network and Distributed System + Security, March 1998. + + + + + +Hao Informational [Page 13] + +RFC 8236 J-PAKE September 2017 + + +8.2. Informative References + + [AP05] Abdalla, M. and D. Pointcheval, "Simple Password-Based + Encrypted Key Exchange Protocols", Topics in Cryptology + CT-RSA, DOI 10.1007/978-3-540-30574-3_14, 2005. + + [BJS07] Barker, E., Johnson, D., and M. Smid, "Recommendation for + Pair-Wise Key Establishment Schemes Using Discrete + Logarithm Cryptography (Revised)", NIST Special + Publication 800-56A, March 2007, + <http://csrc.nist.gov/publications/nistpubs/800-56A/ + SP800-56A_Revision1_Mar08-2007.pdf>. + + [BOINC] BOINC, "Index of /android-boinc/libssl/crypto/jpake", + February 2011, <http://boinc.berkeley.edu/ + android-boinc/libssl/crypto/jpake/>. + + [BOUNCY] Bouncy Castle Cryptography Library, + "org.bouncycastle.crypto.agreement.jpake (Bouncy Castle + Library 1.57 API Specification)", May 2017, + <https://www.bouncycastle.org/docs/docs1.5on/org/ + bouncycastle/crypto/agreement/jpake/package-summary.html>. + + [FIPS186-4] + National Institute of Standards and Technology, "Digital + Signature Standard (DSS)", FIPS PUB 186-4, + DOI 10.6028/NIST.FIPS.186-4, July 2013, + <http://nvlpubs.nist.gov/nistpubs/FIPS/ + NIST.FIPS.186-4.pdf>. + + [Hao10] Hao, F., "On Small Subgroup Non-Confinement Attacks", IEEE + Conference on Computer and Information Technology, + DOI 10.1109/CIT.2010.187, 2010. + + [ISO.11770-4] + ISO/IEC, "Information technology -- Security techniques -- + Key management -- Part 4: Mechanisms based on weak + secrets", (under development), July 2017, + <https://www.iso.org/standard/67933.html>. + + [Jas96] Jaspan, B., "Dual-Workfactor Encrypted Key Exchange: + Efficiently Preventing Password Chaining and Dictionary + Attacks", USENIX Symposium on Security, July 1996. + + [MOZILLA] Mozilla Wiki, "Services/KeyExchange", August 2011, + <https://wiki.mozilla.org/index.php?title=Services/ + KeyExchange&oldid=343704>. + + + + +Hao Informational [Page 14] + +RFC 8236 J-PAKE September 2017 + + + [MOZILLA_NSS] + Mozilla Central, "jpake.c - DXR", August 2016, + <https://dxr.mozilla.org/mozilla-central/source/ + security/nss/lib/freebl/jpake.c>. + + [PALEMOON] Moonchild Productions, "Pale Moon Sync", + <https://www.palemoon.org/sync/>. + + [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman + Group Exchange for the Secure Shell (SSH) Transport Layer + Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, + <https://www.rfc-editor.org/info/rfc4419>. + + [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>. + + [THREAD] Thread, "Thread Commissioning", White Paper, July 2015, + <https://portal.threadgroup.org/DesktopModules/ + Inventures_Document/FileDownload.aspx?ContentID=658>. + + [Zha04] Zhang, M., "Analysis of the SPEKE Password-Authenticated + Key Exchange Protocol", IEEE Communications Letters, + Vol. 8, pp. 63-65, DOI 10.1109/lcomm.2003.822506, January + 2004. + +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). + +Author's Address + + Feng Hao (editor) + Newcastle University (UK) + Urban Sciences Building, School of Computing, Newcastle University + Newcastle Upon Tyne + United Kingdom + + Phone: +44 (0)191-208-6384 + Email: feng.hao@ncl.ac.uk + + + + + + + +Hao Informational [Page 15] + |