ISE write-up for: draft-smyshlyaev-sespake-16
Abstract:
"This document specifies the Security Evaluated Standardized Password
Authenticated Key Exchange (SESPAKE) protocol. The SESPAKE protocol
provides password authenticated key exchange for usage in the systems
for protection of sensitive information. The security proofs of the
protocol were made for the case of an active adversary in the
channel, including MitM attacks and attacks based on the
impersonation of one of the subjects."
This draft has no IANA Considerations.
The -09 version was reviewed for me by Mike Hamburg, Paul Lambert and
Jörn-Marc Schmidt (volunteers from the CFRG list). Their reviews are
appended below; its authors have made the changes discussed between
them, reaching agreement with the version 16 on 24 December 2016.
- - - - -
Mike Hamburg's review:
read over the document briefly, especially the diffs.
The protocol hasn’t changed much, and it’s still basically fine but I think it
could be better.
I’m not sure what was gained by replacing INT with an abstract function phi.
Since phi = INT in the example, it seems to just give wiggle room that will not
be used.
The new diagram is helpful.
The “Byte representation of a point X,Y” is a little unclear. Perhaps the
authors should declare a function intEncode_n :: [0,n) -> B_{ceil log_{256} n},
and say that (X,Y) encodes to intEncode_p(X) || intEncode_p(Y). Also, the
lower-case p there is correct, but it’s the characteristic and not the subgroup
generator. The subgroup generator is called capital P. But you do want the
lower-case p.
Also, the authors might want to consider point compression. Or not.
I’m skeptical as to whether the innovative small subgroup handling gains
anything. Why does one need to test whether Q_B is in the small subgroup?
Does the protocol need to be contributory even if the adversary knows the
password? It looks to me like the small subgroup handling is a convoluted way
to abort the protocol without aborting it. Perhaps there is a reason involving
the failure counters.
I’m still not a fan of the multiple Q points. Either there is an attack on one
Q or there is not. If there is an attack, reducing its likelihood of success
to 1/3 seems like a waste of time. Just generating Q using a hash of P is
enough to prevent a backdoor attack.
- - - - -
Paul Lambert's review:
Postive aspects:
- the specification is well written and complete for the defined scope
- the inclusion of counters for limiting password guessing is an
important addition (as compared to SPAKE2)
- the inclusion of salt values is an important addition (as compared to
SPAKE2)
- having a matching published ³proof² is important for this type of
protocol
(disclaimer - the referenced proof maps closely to the specification,
but I¹ve not reviewed the correctness of the proof)
- the base PAKE functionality of SESPAKE is efficient and one of the best
technical options for implementing this type of PAKE functionality
Minor Comments:
- The ability to parameterize the functionality is nice, but there is no
guidance on how many Q¹s are required or when the Q value should be
changed.
Could an implementation just use N=1? Other algorithms do not provide
this flexibility.
If N>=1 what are the benefits and when is one index selected over
another?
- the extensive test vectors are very nice, but the specification and
vectors are based on GOST algorithms that are not widely adopted in
Internet applications. The GOST algorithms have a complete set of
definitions and usage recommendations that makes for a relatively tightly
defined set of protocols. The specification is well written in a manner
that it is relatively easy to substitute alternative choices for the
elliptic curve parameters and hash algorithms. The elliptic curves are
readily able to be changed by the use of the ³ID_ALG² field.
"The ID_ALG identifier of the elliptic curve used in the protocol"
The PBKDF and HMAC are hard-wired to specific algorithms. For my
application of this algorithm I plan to replace the usage of the ³ID_ALG²
with a Cipher Suite Identifier (csi). This effectively bundles the
elliptic curve parameters with selections for other algorithms (like the
hashes).
- the protocol is documented as 6 protocol steps. It seems viable to
combine steps (3 and 4, 4 and 5):
A_ID --->
<--- ID_ALG, B_ID (optional), ind, salt
u_1, (DATA_A || MAC_A) --->
<--- u_2, (DATA_B || MAC_B)
- some applications may not need to send A_ID which would then reduce to:
<--- ID_ALG, B_ID (optional), ind, salt
u_1, (DATA_A || MAC_A) --->
<--- u_2, (DATA_B || MAC_B)
Editorial:
- the use of Œ||¹ for concatenation versus a coma (Œ,¹) may be inconstant
The second message uses comas to show multiple fields in a message
<--- ID_ALG, B_ID (optional), ind, salt
The last two messages use concatenation:
<--- (DATA_B || MAC_B)
Given that DATA_A and DATA_B should be processed as unique fields it
may be more appropriate to document this as:
<--- DATA_B, MAC_B
Major Issues:
- None
The draft-smyshlyaev-sespake-09 specification is written as specification
for a PAKE protocol. It is not a complete communication protocol and does
not include message formats suitable for an implementation. This is not an
issue and the specification provides good documentation of the
cryptographic protocol in a manner suitable for incorporation/translation
of the mechanism into an implementation.
I would recommend that the specification should progress forward as
written or with minor modifications per these comments if the author finds
any of them to be improvements.
- - - - -
Jörn-Marc Schmidt's review
I had a look at Stanislav's draft. I think it's in a good shape. The protocol
description is very comprehensive and contains detailed instructions for all
its parameter. I also like the fact that it comes with a security proof (in a
dedicated paper). Maybe it's worth mentioning in the draft that the SEPAKE can
be implemented as a balance or a an augmented PAKE: Balanced if both parties
use PW, salt and Q_ind, augmented in case one party stores Q_PW = f(PW, salt,
2000)*Q_ind. I also think that the function f (PBKDF2) is in particularly
helpful in the augmented scenario.
Minor comments on p4:
isn't --> is not
masked by element --> masked by an element
- - - - -