W3C home > Mailing lists > Public > public-web-security@w3.org > January 2010

Re: [ietf-http-auth] HTTP Mutual-auth proposal status / HTTP AUTH meet-up in Anaheim?

From: Thomas Broyer <t.broyer@gmail.com>
Date: Wed, 6 Jan 2010 01:57:06 +0100
Message-ID: <a9699fd21001051657h67ee88b2ubbf6fb3436ef75a7@mail.gmail.com>
To: Yutaka OIWA <y.oiwa@aist.go.jp>
Cc: public-web-security@w3.org
On Tue, Jan 5, 2010 at 10:39 AM, Yutaka OIWA wrote:
> Dear Thomas,
>
> Thank you very much for detailed comments.
>
> Some of our design principles in the current draft regarding
> compatibility are as follows:
>
>  (A) It is a mid- to long-term solution:  to use our scheme,
>     we assume that software supporting our scheme can fully
>     parse new headers and follow other requirements.
>
>  (B) However, it must not confuse existing implementations which do
>     not support this protocol.  At least, older implementations must
>     be able to access 401 pages or unauthenticated pages (for
>     optionally-authenticated contents) without confusion.
>
>     To this purpose, we will not changed any existing meaning of
>     headers.
>
>  (C) Up to these, we will choose the methods which is the easiest
>     to be implemented.
>
> Then,
>
> Thomas Broyer <t.broyer@gmail.com> writes:
>
>> Why introduce the Optional-WWW-Authenticate? why not just use a
>> WWW-Authenticate header in non-401 responses?
>> See http://trac.tools.ietf.org/wg/httpbis/trac/ticket/78#comment:4
>
> My concern is that it will confuse existing implementations (principle B).
> By introducing a new header, the applications which do not support
> the extension will always ignore it.  It will be safer.
>
> The proposal in the provided resource is reasonable, but I can not
> depend on it in this time, at least.

Try it here:
http://www.ltgt.net/tests/http-cookie-auth/www-authenticate-in-200.asis

Tested in (all browsers running in WinXP SP3):
 - IE6
 - IE7
 - IE8
 - Firefox 3.0.16
 - Firefox 3.5.6
 - Firefox 3.6b5
 - Chrome 3.0.195.38 (current "stable" version)
 - Chrome 4.0.249.43 (current "beta" version)
 - Chrome 4.0.266.0 (current "dev" version)
 - Safari 4.0.4 (531.21.10)
 - Opera 9.64
 - Opera 10.10
 - Opera 10.50 pre-alpha (build: 3186)
 - Links 0.83 (from
http://www.jikos.cz/~mikulas/links//download/binaries/win32/ )
and (running in a Sony-Ericsson K750i):
 - phone's built-in browser
 - Opera Mini 4.2
and (running in a Samsung Player Style (SGH F480)):
 - phone's built-in browser
 - Opera Mini 5 beta 2
and (on a linux box; my web host via SSH actually):
 - Lynx Version 2.8.7dev.4 (14 Nov 2006)


*All* of them display the response body without prompting for credentials.


>> In the next version of draft-broyer-http-cookie-auth (and as already
>> briefly discussed in ietf-http-wg and ieth-http-auth), I'm going to
>> propose the addition of a new status code (308, Unauthorized, See
>> Other), which seems to be equivalent to your proposed
>> "Authentication-Control: Mutual location-when-unauthenticated=xxxx"
>> (you'd use a 308 with a WWW-Authenticate response header, just like a
>> 401 but with a Location header).
>> Why did you chose this approach instead of introducing a new status code?
>> The main difference seems to be that if a client doesn't support
>> Authentication-Control (or the auth-scheme it contains) it'll present
>> the 401 response body to the user (or whichever equivalent behavior
>> for non-browser UAs), whereas if the client doesn't support the 308
>> status code (whichever the auth-scheme), it should per HTTP follow the
>> redirect (in practice unfortunately browsers don't do that and just
>> present the response body, so you'd have to include a <meta refresh>
>> and/or some script to make sure the user is redirected to the login
>> form).
>
> It seems to be a good alternative;  I have a few things to be mentioned,
> and it will be worth discussing in detail.
> I will describe the reasons I chose this approach:
>
>  (1) First, we have several information to be put on
>     Authentication-Control header, not only location-when-unauthenticated.
>
>  (2) The redirection target may be "authentication-protocol"
>     dependent: For example, clients which do not support Mutual
>     authentications may be redirected to a separate login page using
>     Meta tags, which will be useful in a transition phase.  Thus I
>     included "Mutual" in the syntax.

Is there a real use case or is it merely "speculation"? I mean,
couldn't you redirect to a single auth-independent page and return a
401 with several auth-schemes there? (instead of several
WWW-Authenticate + Authentication-Control pairs on the "initial" 401,
the one I would replace with a 308)
I can however see the need for the 401+Authentication-Control in a
transition phase from Basic or Digest (where a 308 wouldn't be
recognized by UAs as an "Unauthorized" status code).

Well, I actually don't really understand the need for
location-when-authenticated in Mutual-auth; why isn't the page
returned in the 401 response body? (to save bytes in a transition
phase from Basic/Digest? not really a compelling argument...)

>  (3) The additional header is easier to be modified from an
>     application layer (CGIs).  To use 308 code, we must ensure that
>     status codes can be changed inside "ErrorDocument" CGI pages, and
>     that doing it will preserve WWW-Authenticate header, which is not
>     very useful in the current HTTP spec (principles B and C).

IIUC, you wouldn't use location-when-unauthenticated with
server-controlled auth (e.g. mod_auth/mod_auth_digest in Apache; as
those are currently only Basic or Digest, and with those you'd just
return the page in the 401 response body, see above), so I don't think
the "changing the status code inside ErrorDocument" is a compelling
argument either.

As for the "easier to be modified from an application layer (CGIs)",
I've played with WWW-Authenticate in CGIs (PHP and Python, for Digest,
HMACDigest, Basic against a database, X-WSSE and mixing them), not
using the server modules (mod_auth in Apache for instance) at all
(except for mod_rewrite to pass the Authorization request header value
into a HTTP_AUTHORIZATION env var, but that's what we're talking about
here).

>     This is also a reason we introduced an additional
>     "Authentication-Control" header, instead of merging it with
>     "WWW-Authenticate" and "Authentication-Info" headers.  Our first
>     design had these information merged, but during our trial
>     implementation effort we found it better to be separated (it has
>     made server-side implementation much complicated.)
>
>  (5) In our design, for a simple application we can just conveniently
>     set a fixed- value Authentication-Control header containing both
>     location-when-unauthenticated and location-when-logout
>     (because the spec explicitly require to ignore these fields
>      in non-useful cases.)
>
>  (6) New status code will always have a possibility of concerns with
>     existing implementations, as you have mentioned; New headers are
>     much simple to be handled in real uses (Principle B).

Well, UAs should treat an unknown 3xx as a 300, which means they "MAY
use the Location field value for automatic redirection" or they should
just "render" the response body (which is exactly what browsers do, in
my tests).
I understand "principle B" but it doesn't seem to apply here (I
haven't found any browser that chokes; I haven't checked non-browser
UAs though, apart from wget, which neither chokes nor follows the
redirect).

> Thank you again for your very helpful comment.
> I personally think that my proposal and yours share many interesting
> properties (e.g. non-modal authentication (i.e. 401-status contents
> will be displayed in a normal case), possibility for optional
> authentications, etc.)  I will be very happy if we can discuss it
> further.
> # Do you plan to go Anaheim?

Oh no; I'm doing all of this on my spare time (as a hobby if you
prefer), so nobody would fund the transport and hotel for me ;-)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/
Received on Wednesday, 6 January 2010 00:57:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 19 December 2010 00:16:01 GMT