Re: [Cfrg] Fwd: New Version Notification for draft-harkins-pkex-03.txt

Dear Dan,

During the analysis of Wi-Fi DPP proposal, I've had a chance to look closer
at your draft (and many thanks to Liliya Ahmetzyanova for her comments),
draft-harkins-pkex-04 <https://tools.ietf.org/html/draft-harkins-pkex-04>.

The document is in a pretty good state, in my opinion. Also I don't see any
critical problems in the protocol or it's description.

However, there are several recommendations that you may find useful.

1. It would be better to indicate point G explicitly (as it is already done
for P_I and P_R). Also it would be better to generate new G by the same
method as described in your document or in [LMSS].
2. It seems useful to add checks of X' and Y' for not being equal to the
point at infinity.
3. We strongly recommend to describe explicitly possible countermeasures
against online brute force attack. For example, they can consist of using
counters (so it should be stated when to change it, limitations of their
values and what should peers do when this limits are reached, see
([RFC8125] and [RFC8133]).
4. The PKEX protocol translates code into an elliptic curve point in the
following way. The code is hashed within other parameters and the hash
value is used as a scalar which an elliptic curve point is multiplied by.
There exists small but still non-null probability that this hash value
turns to zero modulo q, where q is the order of the used elliptic curve
point group. If that happens, an ephemeral key is not masked and the
overall security of the PKEX protocol is violated. It seems useful to add
checks here and introduce some algorithm that changes zero hash value to a
nonzero value in a deterministic way.
5. Maybe you consider reasonable to think about using an additional value
"salt" to randomize the masking points Q_I and Q_R for different sessions
by adding one more argument for hash function. The salt value may be chosen
by the Initiator and transferred together with the point M.

References:
[LMSS]: Lochter, M., Merkle, J., Schmidt, J-M., Schutze, T.: Requirements
for Standard Elliptic Curves. Cryptology ePrint Archive, Report 2014/832.
[RFC8133]: S. Smyshlyaev (Ed.), E. Alekseev, I. Oshkin, V. Popov, The
Security Evaluated Standardized Password-Authenticated Key Exchange
(SESPAKE) Protocol. RFC 8133.
[RFC8125]: Schmidt, J.-M.: Requirements for Password-Authenticated Key
Agreement (PAKE) Schemes. RFC 8125.

Best regards,
Stanislav Smyshlyaev

2017-01-03 8:07 GMT+03:00 Dan Harkins <dharkins@lounge.org>:

>
>   New version of the PKEX protocol... changes include cleaning up of how
> proof-of-possession is accomplished and some new role-specific (SPAKE2)
> elements for some popular FFC groups from RFC 3256.
>
>   This protocol allows for the establishment of trust in "raw" public keys
> to be used, subsequently, in protocols like IPsec or TLS.
>
>   Comments are solicited!
>
>   regards,
>
>   Dan.
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-harkins-pkex-03.txt
> Date: Mon, 02 Jan 2017 21:00:19 -0800
> From: internet-drafts@ietf.org
> To: Dan Harkins <dharkins@lounge.org> <dharkins@lounge.org>
>
> A new version of I-D, draft-harkins-pkex-03.txt
> has been successfully submitted by Dan Harkins and posted to the
> IETF repository.
>
> Name:		draft-harkins-pkex
> Revision:	03
> Title:		Public Key Exchange
> Document date:	2017-01-02
> Group:		Individual Submission
> Pages:		30
> URL:            https://www.ietf.org/internet-drafts/draft-harkins-pkex-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-harkins-pkex/
> Htmlized:       https://tools.ietf.org/html/draft-harkins-pkex-03
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-harkins-pkex-03
>
> Abstract:
>    This memo describes a password-authenticated protocol to allow two
>    devices to exchange "raw" (uncertified) public keys and establish
>    trust that the keys belong to their respective identities.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
>