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

[Dan Harkins <[e-mail]>]

   Hello,

   Please see the attached and comments below.

On 10/11/16 1:47 AM, Simon Josefsson wrote:
> mån 2016-10-10 klockan 08:58 -0700 skrev Dan Harkins:
>>     Hello,
>>
>> On 10/10/16 12:18 AM, Simon Josefsson wrote:
>>> mån 2016-10-10 klockan 09:03 +0200 skrev Stefan Winter:
>>>> Hello,
>>>>
>>>>> 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.
>>>> This is not the ocean this draft attempts to boil.
>>>>
>>>> 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.
>>>
>>>> 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.
>>> 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.
>>     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.

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

   Fixed.

>> 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?
> Unless I'm missing something, you need to separate scrypt from PBKDF2.
> They aren't compatible.

   Fixed.

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

   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.

>
>>> 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.
>>     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.
> No, I would be happy with this case:
>
> 1) PRECIS/OpaqueString is specified for PBKDF2 and/or scrypt only.

   Done.

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

   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.
>>   It also supports
>> OpaqueString-prepared passwords with scrypt/PBKDF2 with SHA-256 and SHA-512
>> so we should have all bases covered.
> 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.

   Fixed.

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

   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.