Re: [TLS] about the PWD Proposal

["Dan Harkins" <[e-mail]>]

  This thread seems to be diverging a bit. Can we return to the
technique used in (version 01 of) the PWD proposal? Is that adequate?

  IKE has a completely different usage model where, as Yaron mentions,
both sides need access to the password. TLS has stricter role assignment.
Wifi-Protected Access is insecure since it's not based on a zero
knowledge proof. Its use of PBKDF2 is just supposed to slow down an
offline dictionary attack.

  Below it's noted that if one has access to database of 10,000 salted
passwords and a dictionary of 100,000 of the most popular passwords
(assume that quite a few of them will be in the 10,000) that it's
possible to do a dictionary attack quite easily. Adding PBKDF2 would
slow that down but not much:

   http://www.theregister.co.uk/2011/01/11/amazon_cloud_wifi_cracking/

  It's futile to throw more iterations at this problem. The solution is
using a protocol based on a zero knowledge proof-- like the protocol in
question-- an get away from broken things like Wifi-Protected Access,
or any of the TLS-PSK ciphersuites, using passwords. If an adversary gets
access to a database of passwords then the contents of that database
should be assumed to be compromised even if they're salted and even if
they've been PBKDF2'd with 10,000 iterations.

  Dan.

On Mon, December 12, 2011 10:52 am, Matt DeMoss wrote:
> Does it make sense to suggest that the server could store long term
> only a salt and the result of PBKDF2?
>
> I believe that could be done without altering the proposal, but would
> be too much work for the server. If the protocol was altered, client
> and server could negotiate the number of iterations and the work of
> performing PBKDF2 could be moved to the client.
>
> Wifi-Protected Access includes a "pass-phrase–to–PSK mapping" using
> PBKDF2, but possibly with different goals.
>
> On Mon, Nov 21, 2011 at 5:16 PM, Yaron Sheffer <[e-mail]>
> wrote:
>> In a somewhat related protocol (IKEv2 with PACE for authentication), we
>> added an appendix on password salting:
>> http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2-08#appendix-B.
>> The setting there is a little different from tls-pwd, because IKE is
>> normally symmetric (peer to peer vs. client to server). But some of our
>> analysis does apply. In particular, dynamically replacing the short
>> credentials by a long shared secret (
>> http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2-08#appendix-B.3)
>> would mitigate much of the risk.
>>
>> Thanks,
>>    Yaron
>>
>> -----
>>  Hi,
>>  I am interested in the PWD proposal at the meeting, and run through
>> it(http://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4),
>>
>>  and have the following concerns:
>>
>> 1. In the document, it  says both Client and Server should be able to
>> compute PE, which is derived from username, password, salt,etc.
>>   That means Client or the user should also remember the salt value, in
>> that
>> case, salt is meaningless and can be replaced by a longer password.
>>   This is quite different from the widely known usage of salt, e.g. in
>> UNIX
>> operating system, salt is not required to remember by the user, but by
>> server to fetch locally by reference to the username.
>>  And as far as I know, I am sure the authors also know that, other
>> password
>> based key exchanges protocols don't involve salt, but store a hash value
>> of
>> password among other things locally.
>>
>>> I realize that this is very different from the usage in UNIX operating
>>> systems, but it is necessary, as the UNIX (or other) operating system
>>> running the web server has to store the password. Storing the password
>>> in
>>> the clear on as an unsalted hash is worse than storing a salted hash
>>> (or
>>> "base" in the draft's terminology), so that is what the TLS server
>>> does. The
>>> use of base instead of password is not to protect the password during
>>> handshake, but to protect it during storage on the server.
>>>
>>> Having said that, I think it is now very practical to take a list of
>>> the
>>> 100,000 most popular passwords on the web, a database of 10,000 salted
>>> hashes (the file described in section 3.4), and find all the matches.
>>> That's
>>> 1,000,000,000 operations, which would take 15 minutes on a MacBook Air
>>> (1.4
>>> GHz). I think the days of saying that a database of salted hashes makes
>>> theft of the password file irrelevant should be over. Yes, I know that
>>> with
>>> unsalted hash it would be practical to test the 100,000,000 most
>>> popular
>>> passwords.
>>>
>>> session cookies somehow (e.g., via the BEAST attack): but if you don't
>>> have my OBCs' private keys then you can't actually make use of my
>>> cookies.
>>>
>>> With OBC cookie theft is not enough.  With OBC the attacker must get
>>> at the private keys for the OBCs.
>>>
>>> Also, with OBC you get closer to true logout: destroy ("forget") your
>>> OBC private keys and your sessions are as good as dead.  Moreover, the
>>> user-agent, not the server, is in control of maximum session lifetime,
>>> since there's no point in the server setting cookies that will outlive
>>> the OBCs.
>>> I we can find no other use case, we might want to rename it to "Origin
>>> Bound Cookie".
>>>
>>> But that would require some interesting interaction between layers.
>>>
>>> Are all cookies received while using OBC considered (by the client!)
>>> bound
>>> to the OBC? If not, the client might use an old cookie after a logout
>>> event,
>>> leading to the server falsely detecting an attempt to forge a cookie.
>>> Maybe
>>> we need a new keyword on the cookie header.
>>>
>>> Where is the "logout" button?  If it's part of the website (in the
>>> "canvas") how does the HTML/HTTP tell the browser to log out? Probably
>>> best
>>> to have it in the Chrome for sites where OBC are supported.
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>