ietf
[Top] [All Lists]

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

2010-05-03 19:51:55

  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.

  My recommendation was simply to use an HMAC-based KEF with the
assumptions that it was built on. This allows the protocol to be analyzed
without placing strong assumptions on the underlying hash function
(basically, you get the security of HMAC when you use it correctly,
whether you get it when you use it incorrectly is an open question that
I am not qualified to answer). PBKDF2 is also much more computationally
intensive and there doesn't seem to be a "bang" for that "buck" :-)

  - Section 5.1 says "If the password is non-ASCII, it SHOULD be
normalized
    by the sender before the EAP-EKE message is constructed. The
    normalization method is SASLprep, [RFC4013]. Note that the password
    is not null-terminated."

    I don't think this will work. The SHOULD should be a MUST and the
    mention of SASLprep should use normative language-- i.e. it "MUST
    be SASLprep". Is there a mandatory-to-implement format? Is support
    for ASCII a MUST? Also, there's no mention of unassigned code
points?
    What happens if one of these is hit during normalization? I don't
    believe the text as written will assure interoperability and it will
    also be a DISCUSS target, said using the voice of experience :-)

I agree strongly with this comment as well.

  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/

  regards,

  Dan.


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

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