Re: [TLS] draft on new TLS key exchange

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

  Hello,

On Wed, October 5, 2011 11:58 pm, Marsh Ray wrote:
> On 10/05/2011 01:12 AM, Dan Harkins wrote:
>>
>>    Hi,
>>
>>    I just uploaded a -00 draft that defines a new key exchange
>> for TLS that does not require certificates-- authentication using
>> a simple password only. It can be found at:
>>
>>           http://tools.ietf.org/html/draft-harkins-tls-pwd-00
>>
>>    Please take a look. The authors solicit comments.
>
> http://tools.ietf.org/html/draft-harkins-tls-pwd-00 :
>> 4.  Specification of the TLS-PWD Handshake
>>
>>    The authenticated key exchange is accomplished by each side deriving
>>    a password-based element, PE, in the chosen group, making a
>>    "committment" to a single guess of the password using PE, and
>>    generating the Premaster Secret.  The ability of each side to produce
>>    a valid finished message authenticates itself to the other side.
>
> Here are my comments. Some of them probably apply to other TLS
> password-only schemes too.
>
> Comment 1:
>
> Are you familiar with the studies showing that the great majority of
> users re-use passwords across sites and a large percentage have same
> password everywhere?
>
> http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html
> http://nakedsecurity.sophos.com/2009/03/10/password-website/
>
> This one finds that the average password is used at 6 different sites:
> http://research.microsoft.com/apps/pubs/?id=74164
>
> I don't see anything in this protocol that allows the client endpoint to
> actually authenticate the server. Can the client know if he's
> authenticating with the legitimate server?
>
> If not, perhaps it's OK as long as either the handshake fails or the bad
> guy is reduced to the role of a dumb router between the legit client and
> server.

  The client definitely authenticates the server. They both perform the
same calculations to arrive at the same premaster secret. If either side
has the wrong password, the secret group element will be different and
they'll be doing their calculations with a different generator and
that won't work.

> Comment 2:
>
> But the server DNS name and port do not appear to be bound into the
> authentication. Couldn't the bad guy take a connection destined for one
> web site/service and feed it to another?

  Only if that other website had provisioned the same username/password.

> Comment 3:
>
> The standard of practice for actual "secure" web sites (e.g. PCI
> compliance if you want to handle credit cards) forbids storing plaintext
> passwords on the server side. Any web app developer who was not using at
> least salted hashes today would be ridiculed as incompetent (e.g.,
> Sony). The industry seems to be recognizing the importance of imposing a
> work factor (PBKDF2, bcrypt, scrypt) to resist dictionary attacks when
> the authentication database gets compromised, say, by a typical SQL
> injection.
>
> Is there any way to impose a work factor onto the attacker's guesses?

  As I mentioned in a previous email it's possible to salt the password
at provisioning time and have the server send the salt to the client in
the ServerKeyExchange. I will do that in -01.

> Who do you envision will deploy a protocol that requires the storage of
> plaintext passwords?

  That sounds like a general, non-TLS-specific, question so I'll answer
it generally: when either side can initiate to the other, or in a true
peer-to-peer situation where both sides could theoretically initiate
simultaneously. But that's not the case for TLS where there are strict
client and server roles. And, as I mentioned, I'll add some salt to the
stored password.

> Conceivably there could be special-purpose systems that could generate
> handle these passwords securely, but couldn't they just as easily manage
> a private cert infrastructure?
>
> Comment 4:
>
> The hunting and pecking loops for both the ECC and FFC password elements
> look like a timing oracle to me. They seem to require a large
> exponentiation or sqrt on every iteration and the number of iterations
> is data-dependent. If I'm not mistaken, every input to the loop except
> the password itself is transmitted in cleartext during the handshake.
>
> Couldn't an attacker observe the timings of a sufficient number of
> failed handshakes to enable an offline brute force attack on the
> low-entropy password?

  This is a very good point. I think the attacker would have to observe
successful handshakes though. It's the number of times through the loop
until the PE is determined that the attacker wants to know and a failed
guess will not provide any useful information.

  And I don't think this attack enables an offline dictionary attack.
I think that it will allow the attacker to exclude large chunks of the
password pool with each observed successful exchange until what's left
is manageable (or until there's just 1 entry left in the pool).

  But I'm not sure how concerned I am about this. After finding PE
there will be a modular exponentiation or point multiply using this
random element as the generator. That's a random generator and a random
scalar and the timing variablities on that will make it hard to isolate
the timing dependencies of the hunting-and-pecking loop. Especially
since it's a random PE used for each run of the protocol. Combine that
with the system knowledge and control required to glean timing information
out of an observed run of the protocol and I'm not sure how practical
this would be.

  Thanks for your comments. Regards,

  Dan.