Subject: IETF LC Gen-ART review of draft-harkins-salted-eap-pwd-06

From: [email-masked] (Dale R. Worley)
Date: Mon, 05 Sep 2016 21:30:50 -0400

Document: draft-harkins-salted-eap-pwd-06
Reviewer: Dale R. Worley
Review Date: 2016-09-05
IETF LC End Date: 2016-09-22

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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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.

2.3.  Using UNIX crypt

   Different algorithms are supported with the UNIX crypt() function.
   The particular algorithm used is indicated by prepending an encoding
   of "setting" to the passed salt.  The specific algorithm used is
   opaque to EAP-pwd as the entire salt, including the encoded
   "setting", is passed as an opaque string for interpretation by
   crypt().

This seems to be an awkward way to phrase this.  From the outside,
there appears to be one crypt() function with two arguments.  The
"particular algorithm used" is just crypt() specialized with a fixed
value of one argument.  But any two-argument function can be
specialized with a fixed argument, and usually one does not describe
all the resulting functions as a "particular algorithm".

This text did deceive me upon the first reading.  I thought that
different versions of Unix provided different crypt functions and the
salt included a selector value to select the correct version.  But
looking at the referenced cypt manual page corrected me.

Perhaps this section could be left out entirely, as the details aren't
needed in this specification, and the referenced crypt manual page
gives the needed information.

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.

It might be worth noting that any salted password remote authorization
protocol has the same limitation as this draft's method, viz., that
disclosure of the hash of the salted password allows an attacker to
impersonate a client.  That is, that this method is not somehow
deficient because it also has that property.

(What makes the Unix salted-password database immune to disclosure is
that the OS controls the preparation of the user-given password; it's
not a remote authorization system and so an attacker must enter the
unsalted password.)

Dale

---

From: Daniel Harkins <[email-masked]>
Date: Thu, 8 Sep 2016 17:56:47 +0000

Hi Dale,

>like any other last call comments.

  Thank you for the review!

>in the near-to-medium future?

  Good point. I will mention salt length limits in 2.1. I do not believe this will
provide any issues in the future.

>case, the referenced RFC should be listed as a reference.

  Yes, it's RFC 2759. Will fix and add to references.

>associate with this punctuation.

  I'll get rid of the space and if the RFC Editor wants to add it back I won't complain.

>Probably change "a UNIX crypt" to "UNIX crypt".

  Yes.

>as all of them have a two-phase structure.

  Yes, that reads better.

>gives the needed information.

  I agree this sounds weird at first blush but I think I’m going to keep the text.
I want to ensure that implementations pass the salt en masse to crypt() and
the encoded setting is not removed.

>   since the plaintext password need not be recovered, no dictionary

  Yes that is better. Thanks.

  That does make it clearer, thanks.

>deficient because it also has that property.

  I don't think that is true. The client needs to know the password, not the salted
hash.

>not a remote authorization system and so an attacker must enter the

  Indeed.

  Thanks for your helpful review. I will be incorporating the agreed-to resolutions
in the next version of the draft.

  best regards,

  Dan.

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 09 Sep 2016 15:38:16 -0400

>   I don't think that is true. The client needs to know the password,

Maybe I'm misunderstanding you, but I think you're incorrect.  Indeed,
your draft says 

   the salted password from a compromised database can be used directly
   to impersonate the EAP-pwd client

The reason that this impersonation can be done is that this is a
*remote* authorization protocol, and there is no way for the server to
compel the attacker to hash what the attacker knows with the salt and
then transmit the result.  Whereas in a *local* authorization protocol,
the server compels the user to present the supposed password, and then
the server hashes it with the salt.

Dale