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

[Simon Josefsson <[e-mail]>]

Den Fri, 23 Sep 2016 10:37:25 -0700
skrev Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06:

> 
>    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.

Hi Dan.  Thanks for quick response.

> > 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.

Thank you.

I believe the experience and understanding in this field is that it is
not responsible to publish a document suggesting to use only salted
password databases today, or even 10 years ago.  Anything in that
direction should come with serious warnings that you are doing
something that the community believe is a bad idea, combined with
guidelines on how to do it properly (PBKDF2/scrypt).  It seems we are
on the same page here, and the detail is how to get the document to say
that.

> >    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.

Thank you.  Some way to encode the PBKDF2/scrypt parameters in the salt
field is required, which require some additional specification work.  I
am happy to review text here.

> >    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.

Agreed.  Failure appears like the only option, but it should be made
clear.  It should also be made clear that servers ought to pick common
algorithms to avoid this problem, even though the strategy isn't 100%.

> >    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.

I do not understand.

Are you saying that you know of implemented/deployed password databases
that uses PRECIS OpaqueString processed passwords that are salted and
then hashed, the way described by your document?  This would surprise
me greatly, but of course it is not impossible.  In my experience,
people who are aware of PRECIS/OpaqueString for password processing
are aware of iterated password processing algorithms like PBKDF2.
I would say more people are aware of PBKDF2 than PRECIS/OpaqueString.

Or are you saying that your intent is to support existing deployed
SASLprep prepared databases?  Do you know of any that use each of SHA1,
SHA256, SHA512 or crypt()?  Or was the addition of all algorithms for
completness?

SASLprep and OpaqueString are not the same algorithm, and they don't
map 1:1, otherwise there wouldn't be any need to have two algorithms.

If the intent is to support existing salted+hashed password databases
with SASLprep, refering to OpaqueString won't work.

This may be a similar situation as with iterated vs non-iterated
algorithms.  You could include SASLprep for legacy reasons, but
recommend use of OpaqueString going forward.  Same as including
SHA1(salt|password) for legacy but recommend use of PBKDF2/scrypt going
forward.

> > 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.

Refer to RFC 7616 for details, it is not as easy as MD5(salt|password),
and the document covers SHA-256 and SHA-512/256 too.  If you add this,
you will need to discuss what the username and realm should be.  I don't
think you must add this if you have no direct use for it, but
acknowledging this widely deployed salted password database appears
relevant.  It is more important to add PBKDF2/scrypt in my opinion.

Thanks,
/Simon