Hi Dale, I have posted an -07 of the draft that addresses all of your comments except the spacing after --. I'll leave that to the taste of the RFC editor. Sorry for the delay but I was waiting on another reviewer's agreement on resolution of his comments. Thanks for your patience.
regards, Dan. On 10/14/16, 6:45 PM, "Dale R. Worley" <wor...@ariadne.com> wrote: >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 _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
