Hi Simon,
On Mon, May 3, 2010 3:32 pm, Simon Josefsson wrote:
> "Dan Harkins" <dharkins@xxxxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf