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

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 7 Oct 2016 13:57:59 -0400

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 <[email-masked]> 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
>>
>
>

-- 

Best regards,
Kathleen

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 10 Oct 2016 08:13:55 +0200

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
> 
> >   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.
> >
> >
> >
> >>>> 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.
> >>>>
> >>>> 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.
> >>
> >>>> 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.
> >>
> >>>> 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%.
> >>
> >>>> introduce these methods as new ideas.  Then let me suggest that
> >>>> you only describe OpaqueString+SHA256 and skip OpaqueString+SHA1,
> >>>     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.
> >>
> >> 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.
> >>
> >> SHA1(salt|password) for legacy but recommend use of PBKDF2/scrypt
> >> going forward.
> >>
> >> 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
> >>
> >
> >
> 
>

---

From: Stefan Winter <[email-masked]>
Date: Mon, 10 Oct 2016 09:03:22 +0200

Hello,

> salted password databases that suggest it is time to stop doing that.

This is not the ocean this draft attempts to boil.

The draft does not make any recommendations about how to store passwords.

It attempts to make password databases usable with a new EAP type.

I don't think you are actually stating that salt-hash databases don't
exist in massive amounts in deployed reality? Because saying so would be
quite silly; they do exist.

If we were to ignore that deployed reality and spec the draft merely
around PBKDF2 and some, we'd have an EAP type supporting only a tiny
fraction of password databases out there. All the rest of deployed
reality is left without a good zero-knowledge EAP type and is remains
stranded with "traditional" PKIX-style server validations with either a
cleartext password or a lousy NT-Hash inside the TLS tunnel - which, as
our experience in a world-scale EAP-based roaming consortium shows,
means: no protection at all for many because end users ignore all
certificate warnings given half a chance to.

It is actually quite easy to improve security for virtually everybody
using EAP: it's these few paragraphs in the draft which describe how to
use salted databases.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 10 Oct 2016 09:18:24 +0200

> The draft does not make any recommendations about how to store passwords.

Hello Stefan.

Recommendations ought to be part of the security considerations.  It
already is part of the document, to some extent.

> quite silly; they do exist.

Of course.  I did not say that, and if you got that impression, I must
have been terribly unclear in what I wrote.

I question whether deployed PRECIS/OpaqueString databases prepared
passwords salted+hashed with SHA1 exists.  PRECIS/OpaqueString is fairly
new.  My perception is that people who are knowledgeable enough to use
PRECIS/OpaqueString to prepare passwords in general also know that
salting passwords is not sufficient.

> using EAP: it's these few paragraphs in the draft which describe how to

I'm with you on the high-level discussion.  So let's discuss details.
My assertions are:

1) Drafts dealing with password hashing should not ignore security
practices around password hashing.  Supporting PBKDF2 is a hygiene
factor, scrypt gives bonus points.

2) Complexity leads to reduced security.  Is there legacy justification
for all variants of hashes specified in the document?  Is there legacy
justification for both SASLprep and PRECIS/OpaqueString?

3) I challenge that PRECIS/OpaqueString-prepared passwords are deployed
in a salted+hashed way but without iterative constructs.  If you have
pointers to the opposite, for each of the specified hashes, I'm happy to
learn something new.

What do you think?

I'm aware of password databases that use raw salt+hash on (unprepared)
UTF-8 encoded password strings.  In my experience, that is more common
than salt+hash of SASLprep or PRECIS/OpaqueString passwords.  The draft
does not discuss how the password is encoded for TBD1-TBD10, which seems
like another missing piece.

/Simon

---

From: Dan Harkins <[email-masked]>
Date: Mon, 10 Oct 2016 08:58:04 -0700

Hello,

> salting passwords is not sufficient.

   But the draft doesn't specify OpaqueString with SHA1.

> factor, scrypt gives bonus points.

It does support PBKDF2 now. Yes, it does so under the guise of scrypt
because the scrypt RFC indicates that as an option. Adding support for
the other scrypt options would open up this draft to ugly negotiation.
I can get away with crypt() doing a myriad of stuff under the covers
because it embeds the specific algorithm in the salt and all I need
to do is say do crypt().

   So does this draft not already pass the hygiene test and also get
a single bonus point?

> justification for both SASLprep and PRECIS/OpaqueString?

   I believe the answer to the first question is yes. That is the motivation
for this draft. Regarding the second question, there is no legacy
justification for OpaqueString but there is one for SASLprep, that's
whey there's an option for SASLprep with SHA-1 but none for OpaqueString
with SHA-1.
> pointers to the opposite, for each of the specified hashes, I'm happy to

   I have no pointers but if that is your challenge that you should be
happy that the draft supports OpaqueString-prepared passwords with
SHA-256 and SHA-512-- i.e. no iterative constructs. It also supports
OpaqueString-prepared passwords with scrypt/PBKDF2 with SHA-256 and SHA-512
so we should have all bases covered.
> like another missing piece.

It says:
   When using SASLprep a password SHALL be considered a "stored string" per
   [RFC3454] and unassigned code points are therefore prohibited. The
   output of SASLprep SHALL be the binary representation of the
   processed UTF-8 character string.  Prohibted output and unassigned
   codepoints encountered in SASLprep pre-processing SHALL cause a
   failure of pre-processing, and the output SHALL NOT be used with EAP-pwd.

For the non-internationalized EAP-pwd already says:
   The input password string SHALL be treated as an ASCII
   string or a hexadecimal string with no treatment or normalization
   performed.  The output SHALL be the binary representation of the
   input string.

   I'm really not sure what changes are still needed in this draft. If
there are, please tell me again.

   regards,

   Dan.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 11 Oct 2016 10:47:10 +0200

>    But the draft doesn't specify OpaqueString with SHA1.

It used to, I see now that you removed it.  Thank you!  There is still
salt+SHA256 and salt+SHA512 though.  Are they there for legacy reasons?
I think the draft ought to be clear on which algorithms are for legacy
reasons and which ones are recommended for security.  OpaqueString
+PBKDF2 and OpaqueString+scrypt reflect two reasonable choices these
days.  The others are for legacy reasons.

> the other scrypt options would open up this draft to ugly negotiation.

I don't understand.  PBKDF2 and scrypt or two completely different
algorithms.  Yes, scrypt uses PBKDF2 internally, but that does not imply
that scrypt offer a PBKDF2 fallback variant.

>    So does this draft not already pass the hygiene test and also get

Unless I'm missing something, you need to separate scrypt from PBKDF2.
They aren't compatible.

> whey there's an option for SASLprep with SHA-1 but none for OpaqueString

Okay thanks for clarifying!  Are there deployed databases that uses
SASLprep and salt+SHA256 and salt+SHA512 respectively?

My point here is that by having them in the draft, there is a risk that
people will chose it even in new deployments "just because it works".
If there is no deployed base, let's not give people rope to hang
themselves.

> SHA-256 and SHA-512-- i.e. no iterative constructs.

No, I would be happy with this case:

1) PRECIS/OpaqueString is specified for PBKDF2 and/or scrypt only.

I would be okay with:

2) A pointer to some existing deployed legacy database that uses
OpaqueString+salt+SHA256/512.

A situation where the draft specify OpaqueString+salt+SHA256/512 without
any proven legacy need for it is not okay in my mind.

>  It also supports

Right now the scrypt/PBKDF2 variant looks confused to me.  They are two
different algorithms.  Scrypt does not allow you to chose the hash.
PBKDF2 allows the choice, but then you should cite RFC 2898.

> there are, please tell me again.

Exactly.  So if you re-read what I wrote, my point is that my perception
is that salt+hash'ed UTF8 passwords is not uncommon, and the draft does
not describe that variant.

/Simon

---

From: Dan Harkins <[email-masked]>
Date: Wed, 12 Oct 2016 00:22:39 -0700

Hello,

   Please see the attached and comments below.

> days.  The others are for legacy reasons.

   There is a note in the Security Considerations regarding the 
forward-looking
nature of scrypt and PBKDF2 and the rest are to support deployed databases.
> that scrypt offer a PBKDF2 fallback variant.

   Fixed.

> Unless I'm missing something, you need to separate scrypt from PBKDF2.

   Fixed.

> If there is no deployed base, let's not give people rope to hang

   I am a firm disbeliever in the ability of RFCs to influence behavior.
Otherwise we would have had a global PKI back in the late 90s and this
whole password stuff would be a sad joke today. The more we measure the
rope we want to sell the less useful our product is.

> 1) PRECIS/OpaqueString is specified for PBKDF2 and/or scrypt only.

   Done.

> any proven legacy need for it is not okay in my mind.

   I'm sorry but I'm not going to go back and query operators again for
what they want. This draft was written to deal with existing, deployed
salted databases. And it has to support internationalization.
> PBKDF2 allows the choice, but then you should cite RFC 2898.

   Fixed.

> not describe that variant.

   Tell me exactly what you want with suggested text please. The draft,
and the RFC it updates does, indeed, say how the password is encoded
for TBD1-10. Perhaps you could also provide a proven legacy need for
whatever it is that you feel is missing.

   regards,

   Dan.