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

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

From: Nico Williams <nico@cryptonector.com>
Date: Tue, 14 Jun 2011 18:47:13 -0500
Message-ID: <BANLkTimT0rRQt1XkqXR8iS=QfZiddXs2XQ@mail.gmail.com>
To: Yutaka OIWA <y.oiwa@aist.go.jp>
Cc: public-identity@w3.org, http-auth@ietf.org
On Tue, Jun 14, 2011 at 5:46 PM, Yutaka OIWA <y.oiwa@aist.go.jp> wrote:
> 2011/6/15 Nico Williams <nico@cryptonector.com>:
>> On Mon, Jun 13, 2011 at 11:59 PM, Peter Gutmann
>> <pgut001@cs.auckland.ac.nz> wrote:
>>> Phillip Hallam-Baker <hallam@gmail.com> writes:
>>>>what would we want HTTP authentication to look like?
>>> I have a suggestion for what it shouldn't look like: Any method that hands
>>> over the password (or a password-equivalent like a password in hashed form) as
>>> current browsers do should be banned outright, and anyone who implements
>>> hand-over-the-password should killed and eaten to prevent them from passing on
>>> the genes.
>> +1.
> +1, although the original statement is a bit too strong in wording for me :-)


>>  - 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.
> IMO, I agree that TLS is too low.
> However, although the application layer use-case exists,
> I believe that for general use cases HTTP-auth layer is more appropriate,
> because the trust relationship becomes much simpler.

Can you explain what you mean by "the trust relationship becomes much simpler"?

> Backward-compatibility is important, and all intermediates *should* and
> *in most cases will* work well with new http authentication
> that completely complies with existing HTTP auth framework design.

Compatibility with existing installed base of HTTP stacks is a huge
plus.  Application-layer authentication can be implemented using CGI
on the server-side, if you want the lowest common denominator, and
practically every HTTP server has CGI support (even IIS!).  This is a
critical feature.

> All they've needed is just forward auth-related headers to the origin server.

Application-layer authentication also works whether there's proxies in
the path or not.  It is end-to-end because it is implemented by the
application-layer end-points.  This is also a critical feature.

> Required code modification is almost the same magnitude in both cases,
> because we need to change the client, and to add some server-side thing.

With application-layer authentication one could make a CGI reference
implementation that can be trivially installed and used on the vast
majority of existing servers.  With HTTP-layer authentication one must
modify the HTTP servers that one uses.  That's a huge difference in
favor of application-layer authentication.  Sure, CGI isn't great, but
fast CGI is quite decent, and the important thing is to get deployment
momentum -- optimization for each HTTP server can come later.

> we can keep all other intermediates as it is.
> Some client-side change is necessary in both cases to make mutual
> authentication trustful and unforgeable.
> In server-side, http-layer authentication can be implemented in either
> in the server or in the application.

The same is true for application-layer authentication, oddly enough.
There is a bit of a dualism between HTTP- and application-layer
authentication as long as the HTTP stacks expose enough
request/response header interfaces to the application.

On the client-side this duality is more complete than on the
server-side.  There's no reason that the HTTP stack couldn't implement
application-layer authentication, and there's no reason that the
application couldn't implement HTTP-layer authentication.  However,
there's no way to implement HTTP-layer authentication with CGI, and
that's a big issue.

There are other reasons to want application-layer authentication.  For
example, the application-layer authentication process need not reveal
any information about what resources the client wishes to access
unless the client tries to access a protected resource before
authenticating, whereas with HTTP-layer authentication the client must
access a harmless resource to get the same effect.  This is another
case where the duality of HTTP- and application-layer authentication
is not complete.

But let's say that the semantics and implementation and deployment
considerations authentication at either layer are fully equivalent to
those of authentication at the other layer...  Then why shouldn't we
just flip a coin to pick which layer to add authentication to?  It is
precisely because the duality mentioned above is not complete that we
have good reasons to pick one layer or the other.

Received on Tuesday, 14 June 2011 23:47:37 UTC

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