Re: [Gen-art] IETF LC Gen-ART review of draft-harkins-salted-eap-pwd-06
Daniel Harkins <dharkins@arubanetworks.com> Thu, 08 September 2016 17:56 UTC
Return-Path: <btv1==059339490fe==dharkins@arubanetworks.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610B012B220 for <gen-art@ietfa.amsl.com>; Thu, 8 Sep 2016 10:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.409
X-Spam-Level:
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=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGRijTqRB0Nn for <gen-art@ietfa.amsl.com>; Thu, 8 Sep 2016 10:56:49 -0700 (PDT)
Received: from mx02.arubanetworks.com (sjcbarracuda02.arubanetworks.com [104.36.248.60]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2141B12B100 for <gen-art@ietf.org>; Thu, 8 Sep 2016 10:56:49 -0700 (PDT)
X-ASG-Debug-ID: 1473357408-03d1340928cc660001-nPVVhF
Received: from sjc-exch10hc-02.arubanetworks.com ([10.1.8.46]) by mx02.arubanetworks.com with ESMTP id D2LVl9XDPV8oO23m (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 08 Sep 2016 10:56:48 -0700 (PDT)
X-Barracuda-Envelope-From: dharkins@arubanetworks.com
Received: from PWSN02.arubanetworks.com ([fe80::6c58:60ca:c422:ac39]) by sjc-exch10hc-02.arubanetworks.com ([fe80::88ce:11e3:e0a3:1489%16]) with mapi id 14.03.0158.001; Thu, 8 Sep 2016 10:56:47 -0700
From: Daniel Harkins <dharkins@arubanetworks.com>
To: "Dale R. Worley" <worley@ariadne.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-harkins-salted-eap-pwd.all@ietf.org" <draft-harkins-salted-eap-pwd.all@ietf.org>
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, 08 Sep 2016 17:56:47 +0000
Message-ID: <74089959-67DF-4382-BEFF-8B6DFF3E8E25@arubanetworks.com>
References: <87eg4x3jcl.fsf@hobgoblin.ariadne.com>
In-Reply-To: <87eg4x3jcl.fsf@hobgoblin.ariadne.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.16.0.160506
x-originating-ip: [69.12.173.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: <69F10BADF14C20488397F582939027F3@arubanetworks.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Barracuda-Connect: UNKNOWN[10.1.8.46]
X-Barracuda-Start-Time: 1473357408
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: https://mx01.arubanetworks.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at arubanetworks.com
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 3.2.3.30104 Rule breakdown below pts rule name description ---- ---------------------- --------------------------------------------------
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/m4UDDGUiw8cVShjUe5VYgQanfYc>
Subject: Re: [Gen-art] IETF LC Gen-ART review of draft-harkins-salted-eap-pwd-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2016 18:02:04 -0000
Hi Dale, On 9/5/16, 6:30 PM, "Dale R. Worley" <worley@ariadne.com> 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 ><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? 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: > >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. 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". Yes. > 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 hash. >(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.) Indeed. Thanks for your helpful review. I will be incorporating the agreed-to resolutions in the next version of the draft. best regards, Dan.
- [Gen-art] IETF LC Gen-ART review of draft-harkins… Dale R. Worley
- Re: [Gen-art] IETF LC Gen-ART review of draft-har… Daniel Harkins
- Re: [Gen-art] IETF LC Gen-ART review of draft-har… Dale R. Worley
- Re: [Gen-art] IETF LC Gen-ART review of draft-har… Dale R. Worley