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: Yutaka OIWA <y.oiwa@aist.go.jp>
Date: Tue, 05 Jan 2010 18:39:24 +0900
To: Thomas Broyer <t.broyer@gmail.com>
Cc: public-web-security@w3.org
Message-ID: <878wcc99gz.fsf@bluewind.rcis.aist.go.jp>
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.

> Figure 2 talks about a 200-opt-B0 response which isn't defined
> anywhere (200-Optional-B0 is defined in section 12, why not define it
> in section 4, even if it just points to the "full definition" in
> section 12, but it would make the spec much more easy to follow)

Thank you, I will improve the text.

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

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

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

 (7) Finally, we have been hesitated from defining a new status code 
     only for ourself :-)

To replace it I need more detailed and careful comparisons on pros and
cons, but basically I am not sticking on every detail of our idea; If
the same functionality and usability are provided, I understand that
our protocol is to be improved during the standardization.

# At least, if 308 will be a part of HTTP standard before ours, we
# will be happy to use it (either by replacing or adding as an
# alternative).

> My main concern is that it needs
> browsers to explicitly implement it, which makes it unusable in the
> short term (I don't know if it's possible to plug new auth-schemes
> into Internet Explorer, but if it's not, then it'll be unusable in the
> *long* term too, at least on the Web)

I can understand your concern and I am not a optimist, but I am
thinking easier on this issue for two reasons: We already have had a
preliminary IE component-based implementation (unfortunately it was
closed-source by an external company and we do not know internal
details), and we think if its concept is accepted by other browsers IE
will be likely to implement it (if MS continues to maintain it until
then :-))

> what you're saying ;-) ), and others would fallback to the alternate
> auth-scheme. You'd however have to do extensive testing to determine
> the recommended order of the WWW-Authenticate headers (IIRC some
> browsers only look at the first WWW-Authenticate header, so some of
> them could use the alternate auth-scheme instead of Mutual and others
> fail to authenticate altogether)

This is true, and for a possible fall-back to cookie-based
authentication (using conventional Cookie), it will work well.

For HTTP-auth fallback, if the current browsers use either best or
first appeared scheme in the WWW-Authenticate header, we have a
workaround (by putting Mutual in the second, and enforcing only NEWER
implementations to support priority-based choosing of auth-schemes
(Principle A).)



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?

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]
Received on Tuesday, 5 January 2010 09:40:00 GMT

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