Subject: Re: [TLS] about the PWD Proposal

From: SeongHan Shin <[email-masked]>
Date: Sat, 10 Dec 2011 17:39:25 +0900

Dear TLS WG members,

You can see I-D of "augmented" PAKE protocol below.
https://datatracker.ietf.org/doc/draft-shin-augmented-pake/
In Section 2, several advantages and security features can be found.

Best regards,
Shin

On Tue, Nov 22, 2011 at 7:16 AM, Yaron Sheffer <[email-masked]>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<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<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<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
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/tls<https://www.ietf.org/mailman/listinfo/tls>
>

-- 

------------------------------------------------------------------
SeongHan Shin
Research Center for Information Security (RCIS),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : [email-masked]
------------------------------------------------------------------

---

From: Matt DeMoss <[email-masked]>
Date: Mon, 12 Dec 2011 13:52:43 -0500

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 <[email-masked]> wrote:
> added an appendix on password salting:
> http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2-08#appendix-B.
> credentials by a long shared secret (
> http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2-08#appendix-B.3)
>  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),
>
>   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
>  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.
>
>> "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
>> 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.
>>
>> 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.
>>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 12 Dec 2011 12:52:55 -0800 (PST)

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:
>> that
>> UNIX
>> password
>>> That's
>>> bound

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Dec 2011 15:04:44 -0600

> they've been PBKDF2'd with 10,000 iterations.

PBKDF and salting buys the compromised service and its users time to
change all their passwords.  I think this is critical from an
operations point of view.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 13 Dec 2011 03:01:44 +0100 (MET)

Off-topic:

> they've been PBKDF2'd with 10,000 iterations.

WPA2-PSK is quite different from TLS-PSK in that one should *NOT*
use a memorizable password for WPA2-PSK, but instead a very long and
garbled one that is saved and automatically used.

If you're using WPA2-PSK with an short or memorizable passwort,
then you're not using the technology in the fashion that it is
intended to be used.

What WPA2-PSK does not provide (and where it differs from WPA2-Enterprise)
is confidentiality from other rightful WPA2-PSK clients.  AFAIK, only
for WPA2-Enterprise every communication link will use a seperate
set of keys, while WPA2-PSK clients will all use the same keys
(and therefore can watch each others traffic).

-Martin

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 12 Dec 2011 18:46:15 -0800 (PST)

> Off-topic:

  Indeed! :-)

> garbled one that is saved and automatically used.

  Actually the spec (-2007 version) provides for "an alternative manner
of setting the PSK [which] uses the password-to-key algorithm defined
[by PBKDF2]". It expressly says how to use a password. There isn't any
normative language around it's use-- like "should not"-- but it does,
informally, give a use case which is: "PSK-based authentication, typically
managed by the pass-phrase hash method as described in [PBKDF2]."

> then you're not using the technology in the fashion that it is

  Yes, you should not use a memorizable password but given the fact that
your average human's ability to enter a large pseudo-random character
string repeatedly (or have multiple average humans enter it once) in an
error-free fashion is quite low that is exactly how it is used.

> (and therefore can watch each others traffic).

  There is nothing in the protocol that prevents a single and unique
PSK being assigned to a MAC address, it's just that that's not really
how it's used. Again, that's because it's easier to just have a single
PSK for everyone and make that PSK be easy to enter.

  Protocols that lose security when deployed in the easiest and most
straightforward manner (i.e. the way everyone's gonna deploy it!) are
extremely fragile. To tie it all back to what this thread used to be,
when one uses a password with a protocol based on a zero knowledge proof
there's a certain amount of robustness and misuse resistance. You should
not share a password but if you do it will not give an adversary an
advantage in determining the password because it still takes 1 active
attack to some other protocol participant to check each candidate
password in the dictionary-- do 50 attacks against a single device or
1 attack against 50 devices, it's no different.

  (By the way, the upcoming -2012 version of the 802.11 standard will
have a secure replacement for WPA2-PSK that is based on a zero knowledge
proof...coming soon to an 802.11 implementation near you!)

  regards,

  Dan.