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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Simon,

to answer your last point: EKE is patented, see https://datatracker.ietf.org/ipr/1071/. The patent is due to expire on October of next year. This is (obviously) unrelated to any elliptic curve patents.

Thanks,
	Yaron

Thanks,
	Yaron

On 05/04/2010 01:32 AM, 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.

   - 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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]