Re: [Gen-art] IESG telechat Gen-ART review of draft-harkins-salted-eap-pwd-06

[Daniel Harkins <[e-mail]>]

  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" <[e-mail]> 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