Document: draft-harkins-salted-eap-pwd-06 Reviewer: Dale R. Worley Review Date: 2016-09-05 IESG Telechat date: 2016-10-27 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Summary: This draft is basically ready for publication, but has possible nits that should be considered for fixing before publication. Minor issues: 2.5. Payload Modifications The construction of the EAP-pwd-Commit/Request message limits the salt to 255 octets, or 2040 bits. This probably ought to be mentioned in section 2.1 where the length of the salt is discussed. Is there any reason to be concerned that 2040 bits will be inadequate in the near-to-medium future? Nits/editorial comments: Abstract It included support for raw keys and RFC2751-style double hashing of a password but did not include support for salted passwords. I believe that the reference to RFC 2751 is incorrect. Probably what is meant is RFC 2759 (see the reference thereto in RFC 5931). In any case, the referenced RFC should be listed as a reference. 1.1. Background Databases of stored passwords present an attractive target for attack-- get access to the database, learn the passwords. Normally, the spacing before and after "--" is the same. There are also examples of this in sections 2.1 and 5. Perhaps discuss this with the RFC Editor concerning the meaning the authors want to associate with this punctuation. 2.1. Password Pre-Processing o TBD8: OpaqueString and a UNIX crypt() ([CRY]) Probably change "a UNIX crypt" to "UNIX crypt". o TBD5: OpaqueString and a random salt with SHA-1 ([SHS]) For TBD5-TBD8, it might be clearer to say "OpaqueString and then ...", as all of them have a two-phase structure. 5. Security Considerations there is no dictionary attack needed to recover the plaintext password. This is correct but doesn't emphasize the important point. Perhaps since the plaintext password need not be recovered, no dictionary attack is needed -- While the immediate effect of such a compromise would be the compromised server, I think changing "would be the compromised server" to "would be the compromise of the server" would make this clearer. Dale