Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D16112BD1E; Fri, 23 Sep 2016 10:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 QXgIQNSh_mIe; Fri, 23 Sep 2016 10:37:27 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A530212BCF5; Fri, 23 Sep 2016 10:37:27 -0700 (PDT) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 0A0D31FE01F0; Fri, 23 Sep 2016 10:37:26 -0700 (PDT) To: Simon Josefsson , iesg@ietf.org, secdir@ietf.org, draft-harkins-salted-eap-pwd.all@ietf.org References: <87fuosqtkh.fsf@latte.josefsson.org> From: Dan Harkins Message-ID: <66a779c8-d87b-7c70-c7cf-7eabc48f9880@lounge.org> Date: Fri, 23 Sep 2016 10:37:25 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <87fuosqtkh.fsf@latte.josefsson.org> Content-Type: multipart/alternative; boundary="------------8DC7B18469FB0F134BA64983" Archived-At: Subject: Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 17:37:30 -0000 This is a multi-part message in MIME format. --------------8DC7B18469FB0F134BA64983 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Simon, On 9/22/16 12:31 AM, Simon Josefsson wrote: > Hello, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. Thank you for your review and comments. > > This document adds support for salted password databases to EAP-pwd > (RFC5931). I believe the document is Not Ready for the following > reasons: > > 1) The introduction and security considerations fails to acknowledge > that password salting is not sufficient to protect against real-world > password recovery attacks. Iterative constructs are needed. This > knowledge is old, PBKDF2/RFC2898 (which is one standard technique to > address the problem) was published in 2000 and has been widely > deployed since then. The document should mention this aspect. There > have been many successful attacks against pure-salted password > databases in the real world, for example: > https://en.wikipedia.org/wiki/2012_LinkedIn_hack The intent is to support existing databases that RFC 5931 could not. I guess it deserves to be mentioned in case someone wants to create a new salted password database. I will add something regarding real-world attacks to recover passwords given a salted/encrypted database. > > 2) Code points for the pre-processing techniques PBKDF2 (RFC 2898) and > scrypt (RFC 7914) should be added, to support use of best security > practices. Great suggestion, I will add these. > > 3) There are interop concerns with crypt() when discussion about which > crypt algorithms (DES, MD5, etc) are to be used is lacking. The page > mentions a couple of > algorithms, but several others exist out there. Consider if the > server tells the client to use an exotic crypt() schema like BSDi or > NTHASH, and the client does not support this algorithm. The document > should discuss the sub-negotiation problem. The document should > mention what happens when the server choses an algorithm the client > doesn't support. The document should recommend that servers use > widely-implemented schemas, like DES, md5, or sha256. Yes, there needs to be something to deal with failure of a client to support a server's crypt algorithm. Since this is not a dynamic sort of thing-- oh, you don't like BSDi, how about sha256?-- so I think the only option is failure, but it should be mentioned. > > 4) Introducing a new pre-processing technique like OpaqueString+SHA1 > or OpaqueString+crypt() add complexity. As far as I understand, there > are no password databases with OpaqueString-processed passwords which > are hashed with SHA-1 or crypt out there today. Thus there is no > interop argument for introducing the methods. Please confirm that the > intention is to introduce these methods as new ideas. Then let me > suggest that you only describe OpaqueString+SHA256 and skip > OpaqueString+SHA1, OpaqueString+SHA512, OpaqueString+crypt. This > reduces complexity and does not cause a reduction of security. Actually no, these aren't for new databases. There has to be some canonical way to deal with "international" character sets. RFC 5931 used to refer to SASLprep but that's been obsoleted. So I MUST now refer to OpaqueString. I went to the OpaqueString tutorial a couple of IETFs ago and asked whether passwords treated with SASLprep would map 1:1 to passwords treated with OpaqueString and the answer I got was something like, "uhm, well, I'm not sure. I think so." So the expectation is that a passphrase of "Eu amo São Paulo" (with the problematic diacritical) in an existing database created by SASLprep could be used with salted EAP-pwd and the corresponding OpaqueString pre-processing technique. And that means that every non-internationalized salting technique needs an OpaqueString version, including SHA1 and crypt. > Further, password databases with HTTP Digest MD5 passwords are widely > used. For added legacy compatibility, consider support it too. This is > not a show stopper, but failure to mentioning it in the context of > deployed password databases appears to me like an elephant in the room. > Where there conscious reasons for not including it? It may be worth > stating those reasons in the document, if that is the case. Good suggestion. I'll add MD5 too. regards, Dan. > > Cheers, > /Simon > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --------------8DC7B18469FB0F134BA64983 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
  Hi Simon,

On 9/22/16 12:31 AM, Simon Josefsson wrote:
Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

  Thank you for your review and comments.

 

This document adds support for salted password databases to EAP-pwd
(RFC5931).  I believe the document is Not Ready for the following
reasons:

  1) The introduction and security considerations fails to acknowledge
  that password salting is not sufficient to protect against real-world
  password recovery attacks.  Iterative constructs are needed.  This
  knowledge is old, PBKDF2/RFC2898 (which is one standard technique to
  address the problem) was published in 2000 and has been widely
  deployed since then.  The document should mention this aspect.  There
  have been many successful attacks against pure-salted password
  databases in the real world, for example:
  https://en.wikipedia.org/wiki/2012_LinkedIn_hack

  The intent is to support existing databases that RFC 5931 could not.
I guess it deserves to be mentioned in case someone wants to create a
new salted password database. I will add something regarding real-world
attacks to recover passwords given a salted/encrypted database.

 

  2) Code points for the pre-processing techniques PBKDF2 (RFC 2898) and
  scrypt (RFC 7914) should be added, to support use of best security
  practices.

  Great suggestion, I will add these.

  3) There are interop concerns with crypt() when discussion about which
  crypt algorithms (DES, MD5, etc) are to be used is lacking.  The page
  <https://en.wikipedia.org/wiki/Crypt_%28C%29> mentions a couple of
  algorithms, but several others exist out there.  Consider if the
  server tells the client to use an exotic crypt() schema like BSDi or
  NTHASH, and the client does not support this algorithm.  The document
  should discuss the sub-negotiation problem.  The document should
  mention what happens when the server choses an algorithm the client
  doesn't support.  The document should recommend that servers use
  widely-implemented schemas, like DES, md5, or sha256.

  Yes, there needs to be something to deal with failure of a client
to support a server's crypt algorithm. Since this is not a dynamic sort
of thing-- oh, you don't like BSDi, how about sha256?-- so I think the
only option is failure, but it should be mentioned.

 

  4) Introducing a new pre-processing technique like OpaqueString+SHA1
  or OpaqueString+crypt() add complexity.  As far as I understand, there
  are no password databases with OpaqueString-processed passwords which
  are hashed with SHA-1 or crypt out there today.  Thus there is no
  interop argument for introducing the methods.  Please confirm that the
  intention is to introduce these methods as new ideas.  Then let me
  suggest that you only describe OpaqueString+SHA256 and skip
  OpaqueString+SHA1, OpaqueString+SHA512, OpaqueString+crypt.  This
  reduces complexity and does not cause a reduction of security.

  Actually no, these aren't for new databases. There has to be some
canonical way to deal with "international" character sets. RFC 5931
used to refer to SASLprep but that's been obsoleted. So I MUST now
refer to OpaqueString.

  I went to the OpaqueString tutorial a couple of IETFs ago and asked
whether passwords treated with SASLprep would map 1:1 to passwords
treated with OpaqueString and the answer I got was something like, "uhm,
well, I'm not sure. I think so." So the expectation is that a passphrase
of "Eu amo São Paulo" (with the problematic diacritical) in an existing
database created by SASLprep could be used with salted EAP-pwd and the
corresponding OpaqueString pre-processing technique. And that means that
every non-internationalized salting technique needs an OpaqueString
version, including SHA1 and crypt.

 
Further, password databases with HTTP Digest MD5 passwords are widely
used.  For added legacy compatibility, consider support it too.  This is
not a show stopper, but failure to mentioning it in the context of
deployed password databases appears to me like an elephant in the room.
Where there conscious reasons for not including it?  It may be worth
stating those reasons in the document, if that is the case.

  Good suggestion. I'll add MD5 too.

  regards,

  Dan.

 

Cheers,
/Simon



_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

--------------8DC7B18469FB0F134BA64983--