Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06

[Dan Harkins <[e-mail]>]

   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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview