Subject: Multiple challenges in a single WWW-Authenticate header field

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 21:08:43 -0700

draft-ietf-httpbis-p7-auth defines the WWW-Authenticate as:

     WWW-Authenticate   = "WWW-Authenticate" ":" OWS WWW-Authenticate-v
     WWW-Authenticate-v = 1#challenge

Importing challenge from RFC 2617:

      challenge   = auth-scheme 1*SP 1#auth-param

Which means a single header can contain multiple comma-separated challenges:

WWW-Autenticate: Basic realm="X1", Digest realm="X1", domain="http://example.com", Basic realm="X2"

Is this right? It seems odd to rely parsing multiple challenges on the presence of a space between the auth-scheme and list of auth-param. I am not sure why multiple challenges are even allowed, but either way, they should be separated using something other than a comma.

EHL

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 4 Dec 2009 08:38:18 +0100 (CET)

On Thu, 3 Dec 2009, Eran Hammer-Lahav wrote:

> WWW-Autenticate: Basic realm="X1", Digest realm="X1", 
> domain="http://example.com", Basic realm="X2"

I'm hijacking this thread slightly, but I'm still talking a related matter:

Reading this line it made me think. Is there actually any common servers or 
proxies "out there" that merge WWW-Autenticate: or Proxy-Autenticate: headers 
to even provide more than one authenticate method in the same header line? (I 
mean, yes it is allowed and all but does it actually happen in real life?) Or 
of course, like the above example showing *the same* auth method with 
different realms!

I just now checked the libcurl code and that doesn't support "merged" 
Autenticate: headers at all and yet I've never seen anyone report a problem 
with this!

-- 

  / daniel.haxx.se

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 4 Dec 2009 08:47:43 +0100

[re-sent to list, sorry for the dupe Eran]

On Fri, Dec 4, 2009 at 5:08 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> Is this right?

Yes

> It seems odd to rely parsing multiple challenges on the presence of a space between the auth-scheme and list of auth-param.

Hence the following note in RFC 2617:
  Note: User agents will need to take special care in parsing the WWW-
  Authenticate or Proxy-Authenticate header field value if it contains
  more than one challenge, or if more than one WWW-Authenticate header
  field is provided, since the contents of a challenge may itself
  contain a comma-separated list of authentication parameters.

> I am not sure why multiple challenges are even allowed,

WWW-Authenticate: Basic realm="sent in the clear"
WWW-Authenticate: Digest realm="more secure", <other auth-params>
WWW-Authenticate: HMACDigest realm="even more secure", <other auth-params>
WWW-Authenticate: WSSE realm="some other scheme"
(where HMACDigest is
http://tools.ietf.org/html/draft-sayre-http-hmac-digest and WSSE is
described at http://www.xml.com/pub/a/2003/12/17/dive.html )

or
WWW-Authenticate: GoogleLogin realm="use your Google Account", <other
auth-params>
WWW-Authenticate: Cookie realm="or a local HTML form", <other auth-params>
WWW-Authenticate: OpenID realm="or your OpenID", <other auth-params>
(where Cookie is
http://tools.ietf.org/html/draft-broyer-http-cookie-auth and OpenID is
something like http://www.ietf.org/mail-archive/web/dix/current/msg00581.html
or http://wiki2008.openid.net/OpenID_HTTP_Authentication )

The goal is that the client uses the most secure scheme it supports
(in the first example, browsers would use Digest or Basic, while
HttpLib2 would use HmacDigest)

> but either way, they should be separated using something other than a comma.

Using commas is the way to go in HTTP so that you can have multiple
WWW-Authenticate headers (the exception being "Set-Cookie
in-the-wild").

But parsing WWW-Authenticate is really not that hard:
http://code.google.com/p/httplib2/source/browse/httplib2/__init__.py#228

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 4 Dec 2009 08:55:10 +0100

On Fri, Dec 4, 2009 at 8:38 AM, Daniel Stenberg <[email-masked]> wrote:
> proxies "out there" that merge WWW-Autenticate: or Proxy-Autenticate:
> headers to even provide more than one authenticate method in the same header
> line? (I mean, yes it is allowed and all but does it actually happen in real
> life?)

Apache's mod_asis does merge WWW-Authenticate headers:
Source: http://hg.ltgt.net/http-cookie-auth/file/tip/tests/basic-and-cookie.asis
Live: http://ltgt.net/tests/http-cookie-auth/basic-and-cookie.asis

Opera at least is know to get it wrong (even in 10.10):
basic-and-cookie [1] will trigger the auth dialog while
cookie-and-basic [2] won't (only when combined as a single header
though! when sent as two headers, using e.g. [3] it uses Basic in both
cases)
[1] http://ltgt.net/tests/http-cookie-auth/basic-and-cookie.asis
[2] http://ltgt.net/tests/http-cookie-auth/cookie-and-basic.asis
[3] http://hg.ltgt.net/http-cookie-auth/file/tip/tests/asis.py

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 01:01:51 -0700

I wasn't questioning the need to provide multiple challenges in a single response. I was only questioning the wisdom in allowing multiple challenges in a single header field, given the odd combination of separators it creates. It would be nice to try and deprecate this practice, while still requiring clients to deal with it for backwards compatibility.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Thomas Broyer
> Sent: Thursday, December 03, 2009 11:48 PM
> To: HTTP Working Group ([email-masked])
> Subject: Re: Multiple challenges in a single WWW-Authenticate header field
> 
> > It seems odd to rely parsing multiple challenges on the presence of a space
> between the auth-scheme and list of auth-param.
> 
> (where Cookie is http://tools.ietf.org/html/draft-broyer-http-cookie-auth
> and OpenID is something like http://www.ietf.org/mail-
> archive/web/dix/current/msg00581.html
> The goal is that the client uses the most secure scheme it supports (in the
> first example, browsers would use Digest or Basic, while
> Using commas is the way to go in HTTP so that you can have multiple WWW-
> Authenticate headers (the exception being "Set-Cookie in-the-wild").
>

---

From: Dan Winship <[email-masked]>
Date: Fri, 04 Dec 2009 09:26:40 -0500

On 12/04/2009 03:01 AM, Eran Hammer-Lahav wrote:
> I wasn't questioning the need to provide multiple challenges in a
> single response. I was only questioning the wisdom in allowing
> multiple challenges in a single header field, given the odd
> combination of separators it creates. It would be nice to try and
> deprecate this practice, while still requiring clients to deal
> with it for backwards compatibility.

This possibility was discussed before and basically rejected; see the
thread starting at
http://lists.w3.org/Archives/Public/ietf-http-wg/2008JulSep/0300.html.

If you think OAuth is likely to be used in combination with other
WWW-Authenticate methods, you should start filing bugs against browsers
now :-}

-- Dan

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 09:34:39 -0700

Thanks for the reference. I guess adding a auth scheme specific restriction won't work either.

EHL

> From: Dan Winship [mailto:[email-masked]]
> Sent: Friday, December 04, 2009 6:27 AM
> To: Eran Hammer-Lahav
> Cc: Thomas Broyer; HTTP Working Group ([email-masked])
> > deprecate this practice, while still requiring clients to deal with it
> > for backwards compatibility.
> 
> This possibility was discussed before and basically rejected; see the thread
> starting at http://lists.w3.org/Archives/Public/ietf-http-
> wg/2008JulSep/0300.html.
> 
> If you think OAuth is likely to be used in combination with other WWW-
> Authenticate methods, you should start filing bugs against browsers now :-}
> 
> -- Dan