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

[Simon Josefsson <[e-mail]>]

Hello.

I had a look at the update, and it needs more work.  First the basics.
Scrypt and PBKDF2 are two different algorithms.  Scrypt is described in
RFC 7914 and PBKDF2 in RFC 2898.  The updated draft refers to these as
the same algorithm "Scrypt/PBKDF2".  They are not the same thing.

I still believe it is a bad idea to describe non-iterative password
protection schemes at all.  We have had 15+ years of bad incidents with
salted password databases that suggest it is time to stop doing that.
If this is included, care should be made to bring this point up early
in the introduction section.  Right now it leaps from salted password
databases to memory-hard functions.  The right balance should be to
focus on iterative constructs like PBKDF2 which is the traditional
state-of-the-art standard, and mention memory-hard functions as a
recommended improvement.

There seems to be an impedance mismatch in describing
PRECIS/OpaqueString prepared password in the context of legacy
databases.  My perception is that we have little deployment of
PRECIS/OpaqueString prepared password databases out there, questioning
the need for "legacy" compatibility for these databases, especially
combined with SHA1.

/Simon

> Simon,
> 
> Have you had a chance to look at this yet?  I'd like to make sure a
> new version is posted by Dan before I put this for IESG review.  I'm
> looking at Dan's suggestions now as well.  The draft is supposed to
> be on next week's telechat, but I'll delay if needed.
> 
> Thank you,
> Kathleen
> 
> On Thu, Sep 29, 2016 at 4:10 PM, Dan Harkins <[e-mail]>
> wrote:
> 
> >
> >   Hi Simon,
> >
> >   Please take a look at the attached and let me know whether it
> > addresses your concerns. I decided against adding support for HTTP
> > Digest-style MD5 because it requires a client contribution and
> > EAP-pwd doesn't have a way to provide that.
> >
> >   regards,
> >
> >   Dan.
> >
> >
> >
> > On 9/24/16 2:16 AM, Simon Josefsson wrote:
> >
> >> 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
> >>
> >
> >
> 
>