Re: [http-auth] Doing it the TLS mutual way...

[Nico Williams <[e-mail]>]

On Tue, Jun 14, 2011 at 4:48 PM, Stephen Farrell
<[e-mail]> wrote:
> As it says below, Russ pointed out that this is quite like
> what the enroll WG tried to do a while back, so I'm clearly
> not suggesting something novel here either.

Something not too unlike this was presented at the W3C IDBROWSER
workshop, and several people have suggested something along these
lines at various times (including at that workshop, where even I
mentioned something of the sort as a possible alternative to my
proposal).


> The Problem
> -----------
>
> - TLS mutual authentication is too hard to deploy on the public
> Internet.

PKI doesn't gives us strong mutual authentication.  Or even strong
authentication at all in a PKI with too many root CAs and too many
principals to really validate them all.  Thus you're not actually
proposing a user cert PKI.

In other words, this doesn't get us mutual authentication because the
servers will continue to be authenticated as weakly as they are today.

This could be addressed by having services whose job is to whitelist
other services.  For example, suppose I'm shopping: I could use a user
cert from a shopping federation and my browser could be smart enough
to go ask that federation if any given server I'm visiting has the
right cert.  This would be more than a remote cert validation service.
 It's at least a remote server cert pinning service, but better than
that, it can be a remote whitelist.  This would allow us to get strong
mutual authentication from TLS.

(Yes, the TLS server cert PKI sticks in my craw.)

> - Password based authentication schemes leave server side
> databases vulnerable.

But they could be pass-through schemes such that the RP doesn't have
to have access to it, thus you minimize the attack surface.  This is
the sort of thing that ABFAB WG is working on.  (I'm assuming you
meant things like DIGEST-MD5 here.)

> - EKE/PAKE schemes may help but may require the verifier to store
> a database of values that are dictionary attackable and these
> schemes do require a password to be sent to the server at least at
> account creation and reset time.

The above comment applies to this as well.

> The Approach
> ------------

Options for getting the user certs issued/enrolled would include:

 - a certification protocol for enrollment and/or remote access to
user certs (basically issue a new, short-lived cert when the user
authenticates to the "IdP");
 - a cert registration protocol for registering self-signed certs as
RP-only user certs.

SACRED could be another option for remote access to credentials.

And yet I don't like this approach, nor any of the possible variants.

I much prefer doing authentication at a higher layer, with channel
binding to TLS -- this would require zero changes to TLS (particularly
when using tls-server-end-point as the channel binding type) and HTTP
(at most one might need a new HTTP error code).  Application-layer
authentication could even be implemented, on the server-side, as CGI
programs to get massive adoption to be trivial (no need to upgrade
existing code, just install new code).  Whereas schemes based on TLS
user certs seem to require at least somewhat invasive changes to TLS
and HTTP.

Still, I'd live with this approach IF we also did something to improve
authentication of the service to the user.  So far no one who proposes
TLS user cert approaches proposes any way to strengthen server
authentication, and that has me quite concerned: this may be the only
chance we get for many years to improve authentication of the servers
to the users -- let's not blow it!

Nico
--