[Gen-art] IETF LC Gen-ART review of draft-harkins-salted-eap-pwd-06
worley@ariadne.com (Dale R. Worley) Tue, 06 September 2016 01:30 UTC
Return-Path: <worley@alum.mit.edu>
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 1E8E812B0BC for <gen-art@ietfa.amsl.com>; Mon, 5 Sep 2016 18:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 v7rAwh-eVbgX for <gen-art@ietfa.amsl.com>; Mon, 5 Sep 2016 18:30:54 -0700 (PDT)
Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A23D12B0CA for <gen-art@ietf.org>; Mon, 5 Sep 2016 18:30:54 -0700 (PDT)
Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-06v.sys.comcast.net with SMTP id h5DTbtAZK2Nhqh5DxbjMCa; Tue, 06 Sep 2016 01:30:53 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-12v.sys.comcast.net with SMTP id h5Dwb0k1F6fC3h5Dxbtgis; Tue, 06 Sep 2016 01:30:53 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u861UpB6002141; Mon, 5 Sep 2016 21:30:51 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u861UoES002138; Mon, 5 Sep 2016 21:30:51 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: gen-art@ietf.org, ietf@ietf.org, draft-harkins-salted-eap-pwd.all@ietf.org
Sender: worley@ariadne.com
Date: Mon, 05 Sep 2016 21:30:50 -0400
Message-ID: <87eg4x3jcl.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfCPNinDj72UcgmmzccXqUCkRGmN+pOidJxWPom8f2Si451jd+XUYkEKiaNS8lKKR5pTVbcSY04gJppuZbMwsEkss5iAdG7nQvPxc7Cv7MYE3EVOtcyjZ EBBk0s1yfY2f1e0hfmCafP5Q90SrLM7Kp6CE8Ru72UXd3ne/KYBE25xpFHALXLEy78SX843c8Pjz9yxX1ZGAimi6o4FghKW/De2Wl4dKkYwXSYpd1+QZx0pk X6/GteOC/Z7If01sDDftrw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/BvJ1Dv_aFPESJAEjyqDXkyFgzXQ>
Subject: [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: Tue, 06 Sep 2016 01:30:56 -0000
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
- [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