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

[Stephen Farrell <[e-mail]>]

Hi Nico.

Skipping over stuff where I'd agree or maybe quibble a bit to
the meaty part:

On 15/06/11 20:53, Nico Williams wrote:
> 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.

I don't think a TLS change is needed for this approach, other than
maybe in terms of the interface between a server's TLS accelerator
and the backend, however, there is a fair point that higher layer
authentication is different and can be as good. I suspect that
the TLS mutual approach might be easier to do, but that's just
me arm-waving at this point really.

I think that's ok though - I reckon we're at the point of trying
to identify options that can meet our security requirements.
After that we'll have to see which, if any, of those might get
real deployment and then figure out the relevant details. At
least that where I think we're at.

(And before anyone says it: I do not think we should go off and
write up those requirements in an RFC. This is not our first
attempt at this and the minutiae of the requirements matter
far less than adoption of something that's really better than
current password schemes.)

> 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!

Better server auth is also a fair point - however that might be
somewhat less pressing were client credentials not immediately
stealable from backend databases. Could be that DANE might
provide an approach to help in that respect were we to take
this TLS mutual approach.

I totally agree that *if* this activity results in something new
actually being deployed then we better do a good job because we
won't get another chance if we do a bad job.

However, I also think that we had better not scare off the
punters by demanding more security perfection than is possible.
Put another way - actual deployment here trumps most things
so long as whatever gets deployed is a real improvement.

S.