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

Daniel Harkins <> Thu, 08 September 2016 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1970112B100 for <>; Thu, 8 Sep 2016 10:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.409
X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mJDHCHRQmxGH for <>; Thu, 8 Sep 2016 10:56:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 215A012B20C for <>; Thu, 8 Sep 2016 10:56:49 -0700 (PDT)
X-ASG-Debug-ID: 1473357408-03d1340928cc660001-h9jmKw
Received: from ([]) by with ESMTP id D2LVl9XDPV8oO23m (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 08 Sep 2016 10:56:48 -0700 (PDT)
Received: from ([fe80::6c58:60ca:c422:ac39]) by ([fe80::88ce:11e3:e0a3:1489%16]) with mapi id 14.03.0158.001; Thu, 8 Sep 2016 10:56:47 -0700
From: Daniel Harkins <>
To: "Dale R. Worley" <>, "" <>, "" <>, "" <>
Subject: Re: IETF LC Gen-ART review of draft-harkins-salted-eap-pwd-06
Thread-Topic: IETF LC Gen-ART review of draft-harkins-salted-eap-pwd-06
X-ASG-Orig-Subj: Re: IETF LC Gen-ART review of draft-harkins-salted-eap-pwd-06
Thread-Index: AQHSB95SCkeRWbQ8Ok+PSq01zxO3BqBv5P4A
Date: Thu, 8 Sep 2016 17:56:47 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.16.0.160506
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Barracuda-Connect: UNKNOWN[]
X-Barracuda-Start-Time: 1473357408
X-Barracuda-Encrypted: AES128-SHA
X-Virus-Scanned: by bsmtpd at
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version Rule breakdown below pts rule name description ---- ---------------------- --------------------------------------------------
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Sep 2016 18:02:32 -0000

  Hi Dale,

On 9/5/16, 6:30 PM, "Dale R. Worley" <> wrote:

>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.

  Thank you for the review!

>For more information, please see the FAQ at
>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?

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

>Nits/editorial comments:
>   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.

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

>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.

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

>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.

  Yes, that reads better.

>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.

  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.

>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

  Yes that is better. Thanks.

>   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.

  That does make it clearer, thanks.

>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.

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

>(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.)


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

  best regards,