"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.
- 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.
/Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf