ISE write-up for: draft-hao-jpake-06
"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
This draft has no IANA Considerations.
The draft has not been discussed in any IETF WG.
It was reviewed for me by Stanislav Smyshlyaev and Russ Housley.
The authors have made the changes suggested by the reviewers.
- - - - -
Stanislav Smyshlyaev's Review
Overall opinion: Minor changes needed
The -05 version addresses most of my concerns described in my brief review
for -04 version (in October 2016), but I’d still prefer some changes to be
The PAKE topic is important for such areas as IoT, Bluetooth tokens and key
servers – for the cases when the user-remembered secret is preferred to be
used. J-PAKE is a scheme that is completely different from most other
proposals: SPAKE, SPEKE, PAK, AugPAKE SESPAKE etc. It has its problems
though: it is notably slower than any other protocols considered in IETF
and CFRG. The construction is truly original and has to be considered when
certain PAKE is chosen for some application. Hence I support publication of
an RFC on J-PAKE – but a revised version of it.
Section 1: the phrase “Third, J-PAKE is efficient” seems to be misleading
and I’d prefer that it would be removed. It’s less efficient than most of
other PAKEs considered in IETF and CFRG.
When talking about disadvantages of other schemes, it must be mentioned
that not only SPAKE2, but also SESPAKE (though, with only one point with
unknown discrete logarithm) requires trusted setup.
The “HMAC” notation is used in the paper, though SHA-3 (not requiring HMAC
construction, in contrast to SHA-2) is mentioned. In my opinion, a “MAC” or
even a “PRF” notation would be more convenient. Also later you say “an
additional secure MAC function (HMAC)”, which is also a little misleading –
HMAC is not the only one secure MAC.
In 2.1 the DDH problem intractability is required, but a few statements
later the [supposed to be a weaker property] DLP intractability is
required. I’d prefer that only the more restrictive DDH intractability
requirement would be mentioned.
Section 2.2: it should be explicitly stated (here and in other
corresponding parts of the document), which actions must be done if the
required verifications are unsuccessful. Some practical attacks occur
because of incorrect error handling in protocols, so we should be very
The implicit recommendation in 3.2 to derive keys only from the
x-coordinate should be removed, in my opinion. The modern hashes have at
least 64-byte block, hence there’s no reason to leave y-coordinate (with
only 1 bit of information, though) behind for 256-bit curves, for example.
In the Security considerations section you recommend to add countermeasures
against on-line dictionary attacks. I’d prefer to see more explicit
recommendations here: for example, that the false authentication counters
should be handled in such a way that any error (including ones before the
key confirmation stage) would lead to incrementing false authentication
Also in 9.2 the following change must be made: [AP05]: “Poincheval” ->
It seems to me that the document is useful and should become an RFC in a
slightly revised form.
- - - - -
Russ Housley's Review
The Independent Stream Editor (ISE) asked the Crypto Review Panel to
review this document. Here is my review.
Summary: Almost Ready
Once the comments below are resolved, I think that the ISE should
publish the document.
Section 2.2: Please remove [[Q1:: ... --Hao]]
In Section 2.2, Round 2, the document says:
... Alice and Bob just need to ensure g1*g3*g4 != 1 mod p and
g1*g2*g3 != 1 mod p. ...
I realize that the probability is extremely small that either of
these values will be 1, but the specification needs to say what the
implementer should do if it happens. My guess is go back to Round 1,
and pick new ephemeral private keys.
Please explain why UserID is included in Section 2, but not Section 3.
How does this difference impact the security offered by the two J-PAKE
In Section 2.1, the document says:
... The two communicating parties, Alice and Bob, both agree
on (p, q, g), which can be hard-wired in the software code. Here DSA
group parameters are used only as an example. Other multiplicative
groups where the discrete logarithm problem (DLP) is intractable are
also suitable for the implementation.
It might be useful to point to NIST FIPS 186-4, Appendix A as a way to
generate p, q, and g. The, you can go on to say that other ways work
too. This gives implementers algorithms to use.
In Section 2.2, the first sentence of Round 1 should explain that x1,
x2, x3, and x4 are ephemeral private keys.
In Section 3.1, you point to [NISTCurve]. That document includes
pseudorandom curves over GF(p), pseudorandom curves over GF(2^m), and
Koblitz curves. You only name one of them. Are all of them acceptable
here? Also, that document includes some curves that offer only 80-bit
security, which is considered too weak today. It is desirable for you
to include some guidance to pick a secure curve.
In Section 3.2, the first sentence of Round 1 should explain that x1,
x2, x3, and x4 are ephemeral private keys.
In Section 3.2, it says:
... In practice, it is sufficient to use only the x
coordinate as the input to KDF to derive the session key. ...
I understand the security claim; however, Alice and Bob need to do the
same thing to produce the same key. Therefore, I suggest:
... Since it is sufficient to use only the x
coordinate as the input to KDF to derive the session key,
the y coordinate is not provided as an input to the KDF. ...
Section 1.2 does nit define | or |a|, but it uses them:
o q: a large prime divisor of p-1, i.e., q | p-1
o h: the cofactor of the subgroup generated by G, as defined by h
In addition, [a, b] should be explained in Section 1.2.
Section 5 says:
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')
This looks like two messages, but one round.
Also, since both mechanisms are two messages (one round), the reason
for preferring the second mechanism is incorrect.
Section 6: s/latest IEEE P1363.2 standard draft D26
/the D26 draft of IEEE P1363.2/
In Section 9.1, [I-D-Schnorr] should point to draft-hao-schnorr-05 as a
- - - - -