Last Call Review of draft-harkins-salted-eap-pwd-06
review-harkins-salted-eap-pwd-06-secdir-lc-josefsson-2016-09-22-00

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.

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



  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.

  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.

  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.

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.

Cheers,
/Simon


Attachment:


signature.asc




Description:

 PGP signature