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

From: Simon Josefsson <[email-masked]>
Date: Thu, 22 Sep 2016 09:31:26 +0200

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

---

From: Dan Harkins <[email-masked]>
Date: Fri, 23 Sep 2016 10:37:25 -0700

Hi Simon,

> comments just like any other last call comments.

   Thank you for your review and comments.

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

>    scrypt (RFC 7914) should be added, to support use of best security

   Great suggestion, I will add these.
>    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.

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

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

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 24 Sep 2016 11:16:22 +0200

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

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

Hi Dan.  Thanks for quick response.

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

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

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