ietf
[Top] [All Lists]

Re: review of draft-sheffer-emu-eap-eke-06

2010-05-04 01:14:47
"Dan Harkins" <dharkins(_at_)lounge(_dot_)org> writes:

  Hi Simon,

On Mon, May 3, 2010 3:32 pm, Simon Josefsson wrote:
"Dan Harkins" <dharkins(_at_)lounge(_dot_)org> writes:

  Issues with prf and prf+

  - In sections 5.1 and 5.2 the password is passed directly into prf+
    (which is the same as the one from RFC 2409 and uses HMAC-SHA1 or
    HMAC-SHA256). This is a key derivation type function and assumes it
    has been passed a key having properties, like a uniformly random
    distribution, that a low-entropy password does not have.

    I recommend deriving a key for Encr() in a 2-step process using and
    "extractor and expander" KDF. It might also be good to mention that
    the first, leftmost, length-of-cipher-key bits are used as the
cipher
    key.

I agree with your comments.  However would not salting and an iterative
design, as provided by PKCS#5 PBKDF2, be more appropriate than
extract-and-expand?  See section 4 of the extract-and-expand document to
see why it is not always appropriate for passwords.

  I don't believe so. PBKDF2 does 1000 iterations of HMAC-ing to increase
the work factor of brute force guessing the password. This is useful when
the protocol using the password is not based on a zero knowledge proof.
In this case it is, and an active attacker gets only one guess at the
password per attack (a passive attacker gets zero guesses) and that
would be the case even if the password is used directly as a "key" to
an HMAC-based KDF.

  Section 4 of the extract-and-expand document says, "In the case of
password-based KDFs, a main goal is to slow down dictionary attacks using
two ingredients: a salt value and the intentional slowing of the key
derivation computation. HKDF naturally accommodates the use of salt;
however, a slowing down mechanism is not part of this specification."
But in the case of EAP-EKE a dictionary attack is foiled outright by the
protocol. There is no need to use a KDF to slow one down.

Right.  I agree.

  Issues with elliptic curves cryptography

This raises a question.  What is the patent status of the technologies
used by this document?  I recall concerns with some non-HMAC-based
password based authentication protocols.

  I believe it has been submitted:

       https://datatracker.ietf.org/ipr/1071/

Thanks for the pointer.

/Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>