Re: [TLS] Should TLS 1.3 use an augmented PAKE by default?

[Andy Lutomirski <[e-mail]>]

On 03/18/2014 02:13 PM, Daniel Kahn Gillmor wrote:
> 
> Hi Andy--
> 
> Thanks for raising this question.
> 
> On 03/18/2014 02:11 PM, Andy Lutomirski wrote:
>> 1. When clients authenticate with a password, if they send their
>> password to the wrong server, that server learns their password.
> 
> I think you're talking about HTTP basic auth here, or IMAP AUTH=PLAIN,
> right?  Other authentication mechanisms that are layered on top of TLS
> don't necessarily have the same concern.

As far as I know, pretty much all authentication methods that layer on
top of TLS either have this problem or are, at the very least,
vulnerable to dictionary attack by a rogue server.  Getting secure
augmented password-based authentication right is tricky, and I think
that TLS should offer this service.

> 
>>  This
>> is the basis of most phishing attacks.  (I'm ignoring TLS-SRP, which is
>> basically unused.)
> 
> TLS SRP's lack of use suggests that there is not a high pressure for
> deployment here.
> 
> It's probably worth thinking some about why SRP adoption has been so
> slow (i don't know the global answer here, but i only know a few folks
> who are using it)

I'd guess it's a chicken-and-egg problem.

> 
>> 2. If a client uses a client certificate, the client has to store the
>> private key *and* certificate associated with the certificate.  That
>> means that any encrypted form of that certificate is subject to a
>> dictionary attack.
> 
> i'm not sure i understand.  the certificate is public, right?  i think
> you mean that the stored public key (presumably encrypted locally) is
> subject to an offline dictionary attack.  This is no better or worse
> than a client with an encrypted password store, of course.

There are several ways to make this work.  For example, suppose that a
server or organization wants to accept client certificates.  It issues
to each client c some identifier I_c that identifies that client and a
randomly generated augmented PAKE "password" P_c.  The issuer remembers
V_c (the verifier corresponding to P_c) for each client.  The issuer and
all of the servers need to be able to look up (or decrypt) V_c given
I_c, but, critically, the client must store a copy of V_c or anything
that can be used to generate V_c.

The client chooses a password and stores (I_c, E_password(P_c)).  E
should be a pseudorandom permutation keyed by the password.

Now, if the client's encrypted key is stolen, an attacker cannot mount
an offline dictionary attack to recover the low-entropy password.

With TLS client authentication as it currently stands, I think it's
basically impossible to achieve this type of security.

The goal is to achieve "Type III" security in [1].

> 
> A client which caches credentials for the user over the long term should
> be locking those credentials (whether public-key-based or
> password-based) with a heavily-stretched password, to make offline
> dictionary attacks expensive.
> 
>> Both of these problems can be solved if the default mode of client
>> authentication in TLS 1.3 were an augmented PAKE or a non-key-exchanging
>> equivalent.  #1 is addressed directly, and it would even be safe to
>> share passwords between different servers.
> 
> how does PAKE allow sharing of passwords between servers?  can't a
> server willing to do a bunch of offline computation figure out the
> client's password from its stored verifier?  this moves the offline
> dictionary attack from the client to the server, but it would still
> allow the server to recover the client's password, which would then
> enable its reuse on different sites if the user thought it was ok to
> share a password between services.

Yes, this is true, of course.  It's still an improvement over the status
quo, where a dictionary attack isn't even needed.

> 
>> It might make sense to use similar techniques to authenticate servers to
>> clients.  First, symmetry is nice.  Second, I think that several of the
>> protocols for doing this kind of authentication are actually *faster*
>> than using digital signatures.
> 
> how strong is a PAKE for a generic network-based adversary?  how strong
> is it when the server itself is the adversary?
> 
> At the CFRG meeting at IETF-89 earlier this month, there was very little
> enthusiasm in the room for further discussion about PAKE.  this may just
> be fatigue from the dragonfly discussion, though.
> 
>> Should TLS do something like this?  This may fit in with Watson Ladd's
>> suggestions about using something other than conventional DH for key
>> exchange.
> 
> What about this proposal is different from SRP, which we already have?
> Why not encourage more adoption of SRP and learn what the sticking
> points are for that authentication mechanism?

SRP is a complicated and rather slow thing that bolts on to TLS pre-1.3.
 Since the whole key exchange concept is being rethought for TLS 1.3 (or
is at least apparently up for discussion), it may be possible to have
TLS 1.3's standard key exchange be directly usable as an augmented PAKE
without any significant drawbacks.

I'll leave the details to the more serious cryptographers, but I suspect
that triple DH could actually be made to work: rather than having Alice
send (g^a, g^x), she sends ("Alice", g^x) and lets Bob look up / decrypt
g^a on his own.

If TLS 1.3 naturally supported augmented PAKE-style authentication, then
using it as as simple as setting the credentials.  This is a far cry
from the current state of affairs, which involves using arcane and
barely supported APIs in the various awful TLS implementations to try to
get SRP to work and hoping it doesn't kill performance.

> 
> My basic sense is that PAKE models are generally useful for one-shot or
> limited-time use, as a bootstrapping step to something stronger, but not
> as a regular, per-connection authentication mechanism.  I'd be happy to
> be convinced that they're more generally useful, though :)

I think that there's no real downside to using PAKE for all or almost
all authentication, not just passwords.

After all, authenticating with a traditional keypair just means that you
prove to your peer that you know a private key that corresponds to a
public key known by the peer.  Authenticating with an augmented PAKE is
exactly the same thing, with the added properties that offline
dictionary attacks are impossible (at least against low-entropy
passwords) and that the private key can be an arbitrary string.


[1] http://eprint.iacr.org/2012/120.pdf