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

[Nico Williams <[e-mail]>]

On Wed, Jun 15, 2011 at 6:01 PM, Stephen Farrell
<[e-mail]> wrote:
> On 15/06/11 20:53, Nico Williams wrote:
>> [...]
>
> 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

I'm guessing concentrators already provide this.  But yeah.

Also, I suspect that there are subtle changes that are required in
order to get credential selection right on the client side with one's
chosen TLS implementation, and possibly on the server side to deal
with arbitrary credential validation methods (there was a bit of
discussion of this latter at the W3C workshop during Q&A for the WebID
presentation, brought on by questions/comments by Brad Hill, but Henry
Story wasn't present, so there were no detailed answers).

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

Perhaps we can ask the WebID folks about their experience here, since
they've gone further down this road than anyone else, near as I can
tell.


> (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.)

I don't think we need to publish a requirements RFC before we do
anything else, or even at all.  But we need to have some clue as to
what the requirements are :)

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

A lot of authentication methods can and do protect client credentials
from theft.  ZKPPs are all the rage right now, and for good reason.
And no, the fact that the server's verifiers can be stolen doesn't
bother me if people minimize that infrastructure and protect it.  This
isn't like credit card information (where there's no need to structure
the data, thus it ends up all over the place), nor as sensitive as
Kerberos KDBs, say.  Plus between KDFs like scruypt and decent
password quality we can do a very good job of slowing the offline
dictionary attacks enough that theft of asymmetric password verifiers
is not that big a deal.

There's also ABFAB WG's mechanism.  There's OAuth (which, I hear, is
getting mutual auth soon too).  There's Kerberos (always in demand in
the enterprise).  Etcetera.

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

I suspect that the TLS user cert approach could get traction very
quickly if it's true that no changes are needed to TLS stacks.  I'll
hope, in that case, that we still get to deploy app-layer
authentication in some use cases, because if you don't care for user
certs (because that's not the authentication infrastructure that you
have), there's really no better choice.

Nico
--