W3C home > Mailing lists > Public > public-identity@w3.org > June 2011

Re: [websec] [saag] [http-auth] re-call for IETF http-auth BoF

From: Nico Williams <nico@cryptonector.com>
Date: Sat, 25 Jun 2011 23:42:15 -0500
Message-ID: <BANLkTikBqJYSVwU=Gq4a5ZPJxzRXQuccug@mail.gmail.com>
To: Thomas Fossati <tho@koanlogic.com>
Cc: public-identity@w3.org, http-auth@ietf.org
On Sat, Jun 25, 2011 at 3:59 AM, Thomas Fossati <tho@koanlogic.com> wrote:
> On Jun 14, 2011, at 6:17 PM, Nico Williams wrote:
>> Some aspects of the designs are important.
>> For example:
>> - Is this to be done in TLS?  HTTP?  Or at the application-layer?
>> IMO: TLS is too low a layer to do authentication in, and doing it in
>> HTTP would require retrofitting too many HTTP stacks.  Doing it at the
>> application layer has a number of advantages.
> I've tried to figure out how to get something similar to your REST GSS -- which I like -- at the HTTP level and, yes, you need to hammer HTTP clients a bit to teach them how to do the challange-response on a specially crafted cookie, but then it seems you can switch from stateless to stateful HTTP (and viceversa) quite robustly.

I think the main benefit of doing this at the app-layer is that the
server-side can be portably implemented as FastCGI and instantly be
available on 90+% of servers.  I've started implementing in FCGI,
incidentally, and I believe I can implement all of REST-GSS this way.

Another major benefit of being able to use FastCGI is that you
automatically get privilege separation!  You can run the app, the web
server, and the REST-GSS FastCGI all under different user accounts,
with different access, privileges, ...

The POST/DELETE/GET can be implemented as a FastCGI responder, the MIC
validation as a FastCGI authorizer, and the servers' MICs can be
computed and added by a FastCGI filter.

On the client-side the situation is not as convenient regardless of
whether authentication is *in* HTTP or *above* HTTP: the apps, the
browsers, the XMLHttpRequest API -- all need extending, and all need
deploying.  At best you can save having to extend the HTTP libraries,
but in the browser that's not much of a savings, I bet, and even then,
people will prefer that HTTP libraries to just implement REST-GSS (as
opposed to having to use a separate library in addition).

> Still there's the related bootstrap problem to solve, i.e. the authentication phase and implied key agreement.

That's what the GSS mechanisms do for you!  That's the beauty of this:
you're reusing an existing security framework that has just the right
semantics: you get to authenticate an initiator (client user) to an
acceptor (service) , and preferably also the acceptor to the
initiator, and you get to do per-request/response integrity protection
(MIC tokens) without having to have ordered message delivery.

There's several GSS mechanisms available now, and it's relatively easy
to add new ones (see RFC5802).  A ZKPP mechanism would be great.  A
federated ZKPP mechanism would be even better!

> In this respect I've only been able to sketch a TLS-based mechanism, with a) explicit HTTP redirection, or b) a-priori knowledge of the authentication URI via .well-known or DNS-SD, which then uses RFC 5705 to feed both parties with the needed crypto material.
> Anyway, I still have hazy thoughts about the whole matter, basically from an architectural standpoint, i.e. about where (which layer) the secure state management component must be placed.
> My unanswered (taboo?) question being: would the core HTTP protocol benefit from introducing secure state handling capabilities ?  Or should HTTP remain stateless ?

I like keeping things that are meant to be stateless stateless.
Implementations of HTTP that don't handle DIGEST or HTTP/Negotiate
would have a hard time adjusting, for example.

Also, if we do this *in* HTTP then we have the problem that the HTTP
method and URI are not specific to the authentication facility -- they
are real, and thus they are sent, initially, without having
authenticated the service to the user.  That's a problem, though maybe
it's not a big deal (I'm not sure).

Received on Sunday, 26 June 2011 04:42:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:47 UTC