Re: [TLS] about the PWD Proposal

[SeongHan Shin <[e-mail]>]

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 <[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<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
> [e-mail]
> 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 : [phone]
Fax : [phone]
E-mail : [e-mail]
------------------------------------------------------------------