"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. > - 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf