<pre>Independent Submission                                       F. Hao, Ed.
Request for Comments: 8236                     Newcastle University (UK)
Category: Informational                                   September 2017
ISSN: 2070-1721


        <span class="h1">J-PAKE: Password-Authenticated Key Exchange by Juggling</span>

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 <a href="./rfc7841#section-2">Section&nbsp;2 of RFC 7841</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc8236">http://www.rfc-editor.org/info/rfc8236</a>.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.







<span class="grey">Hao                           Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-2">2</a>
     <a href="#section-1.1">1.1</a>.  Requirements Language . . . . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
     <a href="#section-1.2">1.2</a>.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
   <a href="#section-2">2</a>.  J-PAKE over Finite Field  . . . . . . . . . . . . . . . . . .   <a href="#page-4">4</a>
     <a href="#section-2.1">2.1</a>.  Protocol Setup  . . . . . . . . . . . . . . . . . . . . .   <a href="#page-4">4</a>
     <a href="#section-2.2">2.2</a>.  Two-Round Key Exchange  . . . . . . . . . . . . . . . . .   <a href="#page-5">5</a>
     <a href="#section-2.3">2.3</a>.  Computational Cost  . . . . . . . . . . . . . . . . . . .   <a href="#page-6">6</a>
   <a href="#section-3">3</a>.  J-PAKE over Elliptic Curve  . . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
     <a href="#section-3.1">3.1</a>.  Protocol Setup  . . . . . . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
     <a href="#section-3.2">3.2</a>.  Two-Round Key Exchange  . . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
     <a href="#section-3.3">3.3</a>.  Computational Cost  . . . . . . . . . . . . . . . . . . .   <a href="#page-8">8</a>
   <a href="#section-4">4</a>.  Three-Pass Variant  . . . . . . . . . . . . . . . . . . . . .   <a href="#page-8">8</a>
   <a href="#section-5">5</a>.  Key Confirmation  . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-9">9</a>
   <a href="#section-6">6</a>.  Security Considerations . . . . . . . . . . . . . . . . . . .  <a href="#page-11">11</a>
   <a href="#section-7">7</a>.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
   <a href="#section-8">8</a>.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
     <a href="#section-8.1">8.1</a>.  Normative References  . . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
     <a href="#section-8.2">8.2</a>.  Informative References  . . . . . . . . . . . . . . . . .  <a href="#page-14">14</a>
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-15">15</a>
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-15">15</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   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 [<a href="#ref-BM92" title="&quot;Encrypted Key Exchange: Password-based Protocols Secure against Dictionary Attacks&quot;">BM92</a>].  The first PAKE
   protocol, called Encrypted Key Exchange (EKE), was proposed by Steven
   Bellovin and Michael Merrit in 1992 [<a href="#ref-BM92" title="&quot;Encrypted Key Exchange: Password-based Protocols Secure against Dictionary Attacks&quot;">BM92</a>].  Other well-known PAKE
   protocols include Simple Password Exponential Key Exchange (SPEKE) by
   David Jablon in 1996 [<a href="#ref-Jab96" title="&quot;Strong Password-Only Authenticated Key Exchange&quot;">Jab96</a>] and Secure Remote Password (SRP) by Tom
   Wu in 1998 [<a href="#ref-Wu98" title="&quot;The Secure Remote Password Protocol&quot;">Wu98</a>].  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 [<a href="./rfc5054" title="&quot;Using the Secure Remote Password (SRP) Protocol for TLS Authentication&quot;">RFC5054</a>].

   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 [<a href="#ref-HR08" title="&quot;Password Authenticated Key Exchange by Juggling&quot;">HR08</a>].  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 [<a href="./rfc8235" title="&quot;Schnorr Non-interactive Zero Knowledge Proof&quot;">RFC8235</a>].  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



<span class="grey">Hao                           Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


   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 [<a href="#ref-AP05" title="&quot;Simple Password-Based Encrypted Key Exchange Protocols&quot;">AP05</a>] and SESPAKE [<a href="#ref-SOAA15" title="&quot;On the Security of One Password Authenticated Key Exchange Protocol&quot;">SOAA15</a>], 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 [<a href="#ref-MOZILLA" title="&quot;Services/KeyExchange&quot;">MOZILLA</a>], Pale moon sync [<a href="#ref-PALEMOON" title="&quot;Pale Moon Sync&quot;">PALEMOON</a>], and
   Google Nest products [<a href="#ref-ABM15" title="&quot;Security of the J-PAKE Password-Authenticated Key Exchange Protocol&quot;">ABM15</a>].  It has been included into widely
   distributed open source libraries such as OpenSSL [<a href="#ref-BOINC" title="&quot;Index of /android-boinc/libssl/crypto/jpake&quot;">BOINC</a>], Network
   Security Services (NSS) [<a href="#ref-MOZILLA_NSS">MOZILLA_NSS</a>], and the Bouncy Castle
   [<a href="#ref-BOUNCY" title="&quot;org.bouncycastle.crypto.agreement.jpake (Bouncy Castle Library 1.57 API Specification)&quot;">BOUNCY</a>].  Since 2015, J-PAKE has been included in Thread [<a href="#ref-THREAD" title="&quot;Thread Commissioning&quot;">THREAD</a>] as
   a standard key agreement mechanism for IoT (Internet of Things)
   applications, and also included in ISO/IEC 11770-4:2017
   [<a href="#ref-ISO.11770-4">ISO.11770-4</a>].

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Requirements Language</span>

   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
   <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>] [<a href="./rfc8174" title="&quot;Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words&quot;">RFC8174</a>] when, and only when, they appear in all
   capitals, as shown here.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Notation</span>

   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




<span class="grey">Hao                           Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


   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

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  J-PAKE over Finite Field</span>

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Protocol Setup</span>

   When implemented over a finite field, J-PAKE may use the same group
   parameters as DSA [<a href="#ref-FIPS186-4">FIPS186-4</a>].  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, <a href="#appendix-A">Appendix A</a> [<a href="#ref-FIPS186-4">FIPS186-4</a>] 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
   [<a href="./rfc4419" title="&quot;Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol&quot;">RFC4419</a>].  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



<span class="grey">Hao                           Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


   secret.)  This range is defined as a necessary condition in [<a href="#ref-HR08" title="&quot;Password Authenticated Key Exchange by Juggling&quot;">HR08</a>]
   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 [<a href="#ref-SEC1" title="&quot;Standards for Efficient Cryptography. SEC 1: Elliptic Curve Cryptography&quot;">SEC1</a>].  In either case, one MUST ensure s is not
   equal to 0 modulo q.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Two-Round Key Exchange</span>

   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 -&gt; Bob: g1 = g^x1 mod p, g2 = g^x2 mod p and ZKPs for x1 and
      x2

   o  Bob -&gt; 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 [<a href="./rfc8235" title="&quot;Schnorr Non-interactive Zero Knowledge Proof&quot;">RFC8235</a>].  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 [<a href="./rfc8235" title="&quot;Schnorr Non-interactive Zero Knowledge Proof&quot;">RFC8235</a>].

   When this round finishes, Alice verifies the received ZKPs as
   specified in [<a href="./rfc8235" title="&quot;Schnorr Non-interactive Zero Knowledge Proof&quot;">RFC8235</a>] 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.



<span class="grey">Hao                           Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


   Round 2:

   o  Alice -&gt; Bob: A = (g1*g3*g4)^(x2*s) mod p and a ZKP for x2*s

   o  Bob -&gt; 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.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Computational Cost</span>

   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 [<a href="./rfc8235" title="&quot;Schnorr Non-interactive Zero Knowledge Proof&quot;">RFC8235</a>].  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.




<span class="grey">Hao                           Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  J-PAKE over Elliptic Curve</span>

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Protocol Setup</span>

   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 [<a href="#ref-FIPS186-4">FIPS186-4</a>].  The FIPS 186-4 standard [<a href="#ref-FIPS186-4">FIPS186-4</a>]
   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.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Two-Round Key Exchange</span>

   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 -&gt; Bob: G1 = G x [x1], G2 = G x [x2] and ZKPs for x1 and x2

   o  Bob -&gt; 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 [<a href="./rfc8235" title="&quot;Schnorr Non-interactive Zero Knowledge Proof&quot;">RFC8235</a>].  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).



<span class="grey">Hao                           Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


   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 -&gt; Bob: A = (G1 + G3 + G4) x [x2*s] and a ZKP for x2*s

   o  Bob -&gt; 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.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Computational Cost</span>

   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 [<a href="./rfc8235" title="&quot;Schnorr Non-interactive Zero Knowledge Proof&quot;">RFC8235</a>].  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.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Three-Pass Variant</span>

   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:



<span class="grey">Hao                           Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


   1.  Alice -&gt; Bob: g1 = g^x1 mod p, g2 = g^x2 mod p, ZKPs for x1 and
       x2.

   2.  Bob -&gt; 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 -&gt; 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.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Key Confirmation</span>

   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 [<a href="#ref-Stinson06">Stinson06</a>].  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 [<a href="#ref-Stinson06">Stinson06</a>].

   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.





<span class="grey">Hao                           Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


   The first method is based on the one used in the SPEKE protocol
   [<a href="#ref-Jab96" title="&quot;Strong Password-Only Authenticated Key Exchange&quot;">Jab96</a>].  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 -&gt; Bob: H(H(k'))

   2.  Bob -&gt; 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 [<a href="#ref-BJS07" title="&quot;Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)&quot;">BJS07</a>].  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 -&gt; Bob: MacTagAlice = MAC(k', "KC_1_U" || Alice || Bob || g1
      || g2 || g3 || g4)

   o  Bob -&gt; 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 -&gt; Bob: MacTagAlice = MAC(k', "KC_1_U" || Alice || Bob || G1
      || G2 || G3 || G4)

   o  Bob -&gt; 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.








<span class="grey">Hao                           Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Security Considerations</span>

   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 [<a href="#ref-HR10" title="&quot;J-PAKE: Authenticated Key Exchange Without PKI&quot;">HR10</a>].

   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.



<span class="grey">Hao                           Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


   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 [<a href="#ref-HR10" title="&quot;J-PAKE: Authenticated Key Exchange Without PKI&quot;">HR10</a>] 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
   [<a href="#ref-ABM15" title="&quot;Security of the J-PAKE Password-Authenticated Key Exchange Protocol&quot;">ABM15</a>].  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 [<a href="#ref-Jas96" title="&quot;Dual-Workfactor Encrypted Key Exchange: Efficiently Preventing Password Chaining and Dictionary Attacks&quot;">Jas96</a>].  For
   SPEKE and SRP-6, an attacker may be able to test more than one
   password in one online dictionary attack (see [<a href="#ref-Zha04" title="&quot;Analysis of the SPEKE Password-Authenticated Key Exchange Protocol&quot;">Zha04</a>] and [<a href="#ref-Hao10" title="&quot;On Small Subgroup Non-Confinement Attacks&quot;">Hao10</a>]),
   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 [<a href="#ref-HS14" title="&quot;The SPEKE Protocol Revisited&quot;">HS14</a>].  These two
   attacks affect the SPEKE protocol specified in Jablon's original 1996
   paper [<a href="#ref-Jab96" title="&quot;Strong Password-Only Authenticated Key Exchange&quot;">Jab96</a>] 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.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  IANA Considerations</span>

   This document does not require any IANA actions.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  References</span>

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Normative References</span>

   [<a id="ref-ABM15">ABM15</a>]    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.

   [<a id="ref-BM92">BM92</a>]     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.



<span class="grey">Hao                           Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


   [<a id="ref-HR08">HR08</a>]     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.

   [<a id="ref-HR10">HR10</a>]     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.

   [<a id="ref-HS14">HS14</a>]     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.

   [<a id="ref-Jab96">Jab96</a>]    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.

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
              DOI 10.17487/RFC2119, March 1997,
              &lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;.

   [<a id="ref-RFC5054">RFC5054</a>]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
              "Using the Secure Remote Password (SRP) Protocol for TLS
              Authentication", <a href="./rfc5054">RFC 5054</a>, DOI 10.17487/RFC5054, November
              2007, &lt;<a href="https://www.rfc-editor.org/info/rfc5054">https://www.rfc-editor.org/info/rfc5054</a>&gt;.

   [<a id="ref-RFC8174">RFC8174</a>]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
              <a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
              May 2017, &lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;.

   [<a id="ref-RFC8235">RFC8235</a>]  Hao, F., Ed., "Schnorr Non-interactive Zero Knowledge
              Proof", <a href="./rfc8235">RFC 8235</a>, DOI 10.17487/RFC8235, September 2017,
              &lt;<a href="https://www.rfc-editor.org/info/rfc8235">https://www.rfc-editor.org/info/rfc8235</a>&gt;.

   [<a id="ref-SEC1">SEC1</a>]     "Standards for Efficient Cryptography. SEC 1: Elliptic
              Curve Cryptography", SECG SEC1-v2, May 2009,
              &lt;<a href="http://www.secg.org/sec1-v2.pdf">http://www.secg.org/sec1-v2.pdf</a>&gt;.

   [<a id="ref-Stinson06">Stinson06</a>]
              Stinson, D., "Cryptography: Theory and Practice", 3rd
              Edition, CRC, 2006.

   [<a id="ref-Wu98">Wu98</a>]     Wu, T., "The Secure Remote Password Protocol", Internet
              Society Symposium on Network and Distributed System
              Security, March 1998.





<span class="grey">Hao                           Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Informative References</span>

   [<a id="ref-AP05">AP05</a>]     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.

   [<a id="ref-BJS07">BJS07</a>]    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,
              &lt;<a href="http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf">http://csrc.nist.gov/publications/nistpubs/800-56A/</a>
              <a href="http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf">SP800-56A_Revision1_Mar08-2007.pdf</a>&gt;.

   [<a id="ref-BOINC">BOINC</a>]    BOINC, "Index of /android-boinc/libssl/crypto/jpake",
              February 2011, &lt;<a href="http://boinc.berkeley.edu/android-boinc/libssl/crypto/jpake/">http://boinc.berkeley.edu/</a>
              <a href="http://boinc.berkeley.edu/android-boinc/libssl/crypto/jpake/">android-boinc/libssl/crypto/jpake/</a>&gt;.

   [<a id="ref-BOUNCY">BOUNCY</a>]   Bouncy Castle Cryptography Library,
              "org.bouncycastle.crypto.agreement.jpake (Bouncy Castle
              Library 1.57 API Specification)", May 2017,
              &lt;<a href="https://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/agreement/jpake/package-summary.html">https://www.bouncycastle.org/docs/docs1.5on/org/</a>
              <a href="https://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/agreement/jpake/package-summary.html">bouncycastle/crypto/agreement/jpake/package-summary.html</a>&gt;.

   [<a id="ref-FIPS186-4">FIPS186-4</a>]
              National Institute of Standards and Technology, "Digital
              Signature Standard (DSS)", FIPS PUB 186-4,
              DOI 10.6028/NIST.FIPS.186-4, July 2013,
              &lt;<a href="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">http://nvlpubs.nist.gov/nistpubs/FIPS/</a>
              <a href="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">NIST.FIPS.186-4.pdf</a>&gt;.

   [<a id="ref-Hao10">Hao10</a>]    Hao, F., "On Small Subgroup Non-Confinement Attacks", IEEE
              Conference on Computer and Information Technology,
              DOI 10.1109/CIT.2010.187, 2010.

   [<a id="ref-ISO.11770-4">ISO.11770-4</a>]
              ISO/IEC, "Information technology -- Security techniques --
              Key management -- Part 4: Mechanisms based on weak
              secrets", (under development), July 2017,
              &lt;<a href="https://www.iso.org/standard/67933.html">https://www.iso.org/standard/67933.html</a>&gt;.

   [<a id="ref-Jas96">Jas96</a>]    Jaspan, B., "Dual-Workfactor Encrypted Key Exchange:
              Efficiently Preventing Password Chaining and Dictionary
              Attacks", USENIX Symposium on Security, July 1996.

   [<a id="ref-MOZILLA">MOZILLA</a>]  Mozilla Wiki, "Services/KeyExchange", August 2011,
              &lt;<a href="https://wiki.mozilla.org/index.php?title=Services/KeyExchange&amp;oldid=343704">https://wiki.mozilla.org/index.php?title=Services/</a>
              <a href="https://wiki.mozilla.org/index.php?title=Services/KeyExchange&amp;oldid=343704">KeyExchange&amp;oldid=343704</a>&gt;.




<span class="grey">Hao                           Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8236">RFC 8236</a>                         J-PAKE                   September 2017</span>


   [<a id="ref-MOZILLA_NSS">MOZILLA_NSS</a>]
              Mozilla Central, "jpake.c - DXR", August 2016,
              &lt;<a href="https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/freebl/jpake.c">https://dxr.mozilla.org/mozilla-central/source/</a>
              <a href="https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/freebl/jpake.c">security/nss/lib/freebl/jpake.c</a>&gt;.

   [<a id="ref-PALEMOON">PALEMOON</a>] Moonchild Productions, "Pale Moon Sync",
              &lt;<a href="https://www.palemoon.org/sync/">https://www.palemoon.org/sync/</a>&gt;.

   [<a id="ref-RFC4419">RFC4419</a>]  Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman
              Group Exchange for the Secure Shell (SSH) Transport Layer
              Protocol", <a href="./rfc4419">RFC 4419</a>, DOI 10.17487/RFC4419, March 2006,
              &lt;<a href="https://www.rfc-editor.org/info/rfc4419">https://www.rfc-editor.org/info/rfc4419</a>&gt;.

   [<a id="ref-SOAA15">SOAA15</a>]   Smyshlyaev, S., Oshkin, I., Alekseev, E., and L.
              Ahmetzyanova, "On the Security of One Password
              Authenticated Key Exchange Protocol", 2015,
              &lt;<a href="http://eprint.iacr.org/2015/1237.pdf">http://eprint.iacr.org/2015/1237.pdf</a>&gt;.

   [<a id="ref-THREAD">THREAD</a>]   Thread, "Thread Commissioning", White Paper, July 2015,
              &lt;<a href="https://portal.threadgroup.org/DesktopModules/Inventures_Document/FileDownload.aspx?ContentID=658">https://portal.threadgroup.org/DesktopModules/</a>
              <a href="https://portal.threadgroup.org/DesktopModules/Inventures_Document/FileDownload.aspx?ContentID=658">Inventures_Document/FileDownload.aspx?ContentID=658</a>&gt;.

   [<a id="ref-Zha04">Zha04</a>]    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]
</pre>