Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)
From: Dan Winship <[email-masked]>
To: Julian Reschke <[email-masked]>
Cc: [email-masked]
Date: Mon, 12 Jan 2009 11:32:16 -0500
List-Id: <ietf-http-auth.osafoundation.org>

Julian Reschke wrote:
>> Yeah, basically no one handles this correctly. I pointed this out on the
>> httpbis list, and the consensus seemed to be "then they should fix their
>> code".
> 
> Please elaborate: is *-Authenticate broken in the same way as Cookie in
> that combining multiple instances into the same header makes it
> *impossible* to parse the value, or is parsing just harder?

It's just harder. Provided that all the WWW-Authenticate headers obey
the 2617 syntax for "challenge", then I'm pretty sure the rule I gave is
correct:

>> "a comma followed by a token
>> which is not followed by an equals sign indicates the start of a new
>> challenge"

That rule also still works with NTLM and Negotiate. Of course, it would
be possible for someone to violate the 2617 grammar in other ways that
would make that rule fail, but AFAIK no one has *yet*, and so if someone
did in the future, we could all gang up on them and beat them until they
stopped.

I looked around at one point and found four other uses of
WWW-Authenticate: draft-nystrom-http-sasl, OAuth, the proposed
OpenID-over-WWW-Authenticate, and the WSSE auth that was proposed for
AtomPub but later dropped. All four used the correct RFC2617 syntax.

-- Dan

Date: Mon, 12 Jan 2009 14:41:16 +0100
From: "Thomas Broyer" <[email-masked]>
To: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

On Sun, Jan 11, 2009 at 11:50 PM, Thomas Broyer wrote:
> On Sun, Jan 11, 2009 at 10:17 PM, Yngve N. Pettersen (Developer Opera
> Software ASA) wrote:
>>
>> WWW-Authenticate: Cookie realm="Cookie", Basic realm="Basic"
>
> My *.asis file contained two distinct headers, so it must be an
> artifact of apache mod_asis...
> I've put the tests under version control so you can get the source and
> run them with some other server:
> http://hg.ltgt.net/http-cookie-auth/file/tip/tests

I've just added a small python script to serve an *.asis file for all
incoming requests:
http://hg.ltgt.net/http-cookie-auth/raw-file/tip/tests/asis.py
(call the script with the asis file as the first argument, the server
will listen on port 8000; it also dumps the request headers on stdout)

Results for cookie-and-basic:
All tested browsers prompt for "Basic" (i.e. ignore the unknown
"cookie" scheme): IE (6, 7 and 8b2), Firefox (2.0.0.20, 3.0.5 and
3.1b2), Opera (9.63 and 10), Safari 3.2.1/Windows, and Chrome
2.0.156.1.

Results for basic-and-cookie:
I've only tested Opera (9.63 and 10) and Chrome Dev (2.0.156.1) on
this one, and the results are the same as above; i.e. order of the
WWW-Authenticate headers doesn't matter.

These are the expected results, per RFC2616 (AFAICT).

@Julian: this means that if you want to mix Cookie and Basic at the
same URL, you'll have Basic unless the user has already authenticated
with Cookie at another (non-mixed) URL.

-- 
Thomas Broyer

Date: Mon, 12 Jan 2009 12:58:41 +0000
From: Joe Orton <[email-masked]>
To: Julian Reschke <[email-masked]>
Mail-Followup-To: Julian Reschke <[email-masked]>, Bjoern Hoehrmann <[email-masked]>, [email-masked]
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA)
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP	Authentication (draft-broyer-http-cookie-auth-00)

On Mon, Jan 12, 2009 at 01:44:54PM +0100, Julian Reschke wrote:
> So it seems RFC 4559 is incompatible with RFC 2617. Does anybody 
> volunteer to raise an erratum?

Incompatibilities include:

- the auth-param grammar issue mentioned here
- connection-auth not request-auth
- use of WWW-Auth in a 2xx response rather than Auth-Info

the correct thing to do with 4559 is to deprecate it and replace it with 
something which isn't completely broken, which draft-johansson-http-gss 
looks to be doing though I haven't reviewed that in detail.

joe

Date: Mon, 12 Jan 2009 13:44:54 +0100
From: Julian Reschke <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>> But auth-param is defined to be a token, thus can not contain a space 
>> character...:
>>
>>    auth-scheme    = token
>>    auth-param     = token "=" ( token | quoted-string )
>>    challenge   = auth-scheme 1*SP 1#auth-param
> 
> As I understand it, at the moment all NTLM and Negotiate headers are not
> properly formed, either you get only the scheme name without a mandatory
> parameter, or you get a scheme name followed by a base64 string, which
> usually does not follow the token=token syntax. The point was that even
> if you wish to support them, you'd need some other scheme with a special
> kind of invalid syntax for there to be a problem.

Oh, I see. Thanks for the clarification.

So it seems RFC 4559 is incompatible with RFC 2617. Does anybody 
volunteer to raise an erratum?

BR, Julian

From: Bjoern Hoehrmann <[email-masked]>
To: Julian Reschke <[email-masked]>
Date: Mon, 12 Jan 2009 13:38:07 +0100
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

* Julian Reschke wrote:
>But auth-param is defined to be a token, thus can not contain a space 
>character...:
>
>    auth-scheme    = token
>    auth-param     = token "=" ( token | quoted-string )
>    challenge   = auth-scheme 1*SP 1#auth-param

As I understand it, at the moment all NTLM and Negotiate headers are not
properly formed, either you get only the scheme name without a mandatory
parameter, or you get a scheme name followed by a base64 string, which
usually does not follow the token=token syntax. The point was that even
if you wish to support them, you'd need some other scheme with a special
kind of invalid syntax for there to be a problem.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Mon, 12 Jan 2009 13:37:54 +0100
From: Julian Reschke <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

Julian Reschke wrote:
> But auth-param is defined to be a token, thus can not contain a space 
> character...:

s/auth-param/the name in auth-param/

> ...

BR, Julian

From: Stefan Eissing <[email-masked]>
Date: Mon, 12 Jan 2009 13:31:24 +0100
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

The algorithm I have implemented and working for some years now:

- Concatenate all "WWW-Authenticate:" as comma-separated single header
- Parse "WWW-Authenticate:" by splitting along ",":
     - if " " is there and has no '"' before it, remember the string =20
before " " as scheme name
     - else if it is a known scheme name, remember that
     - else if we remember a scheme name, this is a parameter(-part) =20
to that scheme
     - else we have an invalid case, insert error handling here

All parameters of a scheme are just concatenated to a single string. =20
So parameters
with "," in their value will be glued together again.

- Then we have collected a map of scheme names and all parameters to =20
it (as single string)
- This is handed to the Scheme handler the client knows and prefers =20
and has not
   already tried.

Other strategies are of course possible.

Cheers, Stefan

Am 12.01.2009 um 13:20 schrieb Bjoern Hoehrmann:

> * Julian Reschke wrote:
>> Please elaborate: is *-Authenticate broken in the same way as =20
>> Cookie in
>> that combining multiple instances into the same header makes it
>> *impossible* to parse the value, or is parsing just harder?
>
> You would essentially need a scheme with key=3Dvalue pairs as =
parameters
> where the key can include spaces like in
>
>   WWW-Authenticate: Hypothetical realm=3D"hypo", Security Level=3D"3", =
...
>
> Parsing this would require conflict resolution as it can be parsed as
> one challenge for Hypothetical or two challenges for Hypothetical and
> Security. As I recall, this is not the case for Negotiate or NTLM.
>
> If you do have a case as above, you should still be able to process it
> with knowledge about the scheme, you would also have to have =20
> overlap in
> the parameter names and scheme names to get values that =20
> implementations
> who care would have trouble processing. So I don't think this =20
> counts as
> impossible.
> --=20
> Bj=F6rn H=F6hrmann =B7 mailto:[email-masked] =B7 http://=20
> bjoern.hoehrmann.de
> Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://=20
> www.bjoernsworld.de
> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://=20
> www.websitedev.de/
> _______________________________________________
> ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

--
<green/>bytes GmbH, Hafenweg 16, D-48155 M=FCnster, Germany
Amtsgericht M=FCnster: HRB5782

Date: Mon, 12 Jan 2009 13:25:12 +0100
From: Julian Reschke <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>> Please elaborate: is *-Authenticate broken in the same way as Cookie in 
>> that combining multiple instances into the same header makes it 
>> *impossible* to parse the value, or is parsing just harder?
> 
> You would essentially need a scheme with key=value pairs as parameters
> where the key can include spaces like in
> 
>   WWW-Authenticate: Hypothetical realm="hypo", Security Level="3", ...
> 
> Parsing this would require conflict resolution as it can be parsed as
> one challenge for Hypothetical or two challenges for Hypothetical and
> Security. As I recall, this is not the case for Negotiate or NTLM.
> ...

But auth-param is defined to be a token, thus can not contain a space 
character...:

    auth-scheme    = token
    auth-param     = token "=" ( token | quoted-string )
    challenge   = auth-scheme 1*SP 1#auth-param

(<http://greenbytes.de/tech/webdav/rfc2617.html#rfc.section.1.2>)

BR, Julian

From: Bjoern Hoehrmann <[email-masked]>
To: Julian Reschke <[email-masked]>
Date: Mon, 12 Jan 2009 13:20:49 +0100
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

* Julian Reschke wrote:
>Please elaborate: is *-Authenticate broken in the same way as Cookie in 
>that combining multiple instances into the same header makes it 
>*impossible* to parse the value, or is parsing just harder?

You would essentially need a scheme with key=value pairs as parameters
where the key can include spaces like in

  WWW-Authenticate: Hypothetical realm="hypo", Security Level="3", ...

Parsing this would require conflict resolution as it can be parsed as
one challenge for Hypothetical or two challenges for Hypothetical and
Security. As I recall, this is not the case for Negotiate or NTLM.

If you do have a case as above, you should still be able to process it
with knowledge about the scheme, you would also have to have overlap in
the parameter names and scheme names to get values that implementations
who care would have trouble processing. So I don't think this counts as
impossible.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Mon, 12 Jan 2009 08:58:24 +0100
From: Julian Reschke <[email-masked]>
To: Dan Winship <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

Dan Winship wrote:
> Yngve N. Pettersen (Developer Opera Software ASA) wrote:
>>> At least as defined in RFC 2616 it makes no difference whether you have
>>> two headers, or a single header with the two values separated by a comma
>>> and RFC 2616, which defines the syntax of the header, notes:
>>
>> Well, you are right, and I had missed that one, primarily because I  
>> considered 2617 the entire (selfcontained, except for general syntax)  
>> specification for authentication, including the headers.

(commenting Yngwe...)

The definition of the WWW-Authenticate header is in RFC 2616, which says:

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

(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.47>)

And yes, that requires the reader to know the "#" rule (list 
production). And yes again, it would be good if in HTTPbis, we can have 
syntax and general semantics of HTTP auth in a single document. My 
proposal is to insert the contents RFC 2617, Section 1, into Part 7 of 
HTTPbis.

>> This is possibly a problem that can occur frequently when  splitting a  
>> specification across multiple documents
> 
> 2617 actually explicitly warns about this:
> 
>    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.

Indeed.

>> It would not surprise me if this have bitten more than one  
>> authentication implementor
> 
> Yeah, basically no one handles this correctly. I pointed this out on the
> httpbis list, and the consensus seemed to be "then they should fix their
> code".

Please elaborate: is *-Authenticate broken in the same way as Cookie in 
that combining multiple instances into the same header makes it 
*impossible* to parse the value, or is parsing just harder?

I wouldn't want to add another special case to Part 1, Section 4.2 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-05.html#rfc.section.4.2>) 
if it isn't absolutely required.

>> However, I am aware of two methods (there may be more) that does not use  
>> the parameter parts in the initial step and cannot be used with the syntax  
>> in 2616: NTLM and Negotiate. One might say that they are not conformant,  
>> but they are in wide use on intranets.
> 
> They don't use commas internally though, right? So you can still split
> multiple challenges apart by using the rule "a comma followed by a token
> which is not followed by an equals sign indicates the start of a new
> challenge". Easy! :-/

Let's try to nail down a way to properly parse those. If we can't, we'll 
need to think about another special case in HTTPbis.

BR, Julian

Date: Sun, 11 Jan 2009 20:27:19 -0500
From: Dan Winship <[email-masked]>
To: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

Yngve N. Pettersen (Developer Opera Software ASA) wrote:
>> At least as defined in RFC 2616 it makes no difference whether you have
>> two headers, or a single header with the two values separated by a comma
>> and RFC 2616, which defines the syntax of the header, notes:
> 
> 
> Well, you are right, and I had missed that one, primarily because I  
> considered 2617 the entire (selfcontained, except for general syntax)  
> specification for authentication, including the headers.
> 
> This is possibly a problem that can occur frequently when  splitting a  
> specification across multiple documents

2617 actually explicitly warns about this:

   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.

> It would not surprise me if this have bitten more than one  
> authentication implementor

Yeah, basically no one handles this correctly. I pointed this out on the
httpbis list, and the consensus seemed to be "then they should fix their
code".

> However, I am aware of two methods (there may be more) that does not use  
> the parameter parts in the initial step and cannot be used with the syntax  
> in 2616: NTLM and Negotiate. One might say that they are not conformant,  
> but they are in wide use on intranets.

They don't use commas internally though, right? So you can still split
multiple challenges apart by using the rule "a comma followed by a token
which is not followed by an equals sign indicates the start of a new
challenge". Easy! :-/

-- Dan

Date: Mon, 12 Jan 2009 00:13:21 +0100
To: "Bjoern Hoehrmann" <[email-masked]>
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Organization: Opera Software AS
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

On Sun, 11 Jan 2009 22:39:53 +0100, Bjoern Hoehrmann <[email-masked]>  
wrote:

> * Yngve N. Pettersen (Developer Opera Software ASA) wrote:
>> This test sends an (IMO) invalid header
>>
>> WWW-Authenticate: Cookie realm="Cookie", Basic realm="Basic"
>>
>> All parameters in WWW-Authenticate, except the first, are comma  
>> separated,
>> combining two WWW_Authenticate headers by comma separating them  
>> therefore
>> IMO changes the meaning of the meaning. This becomed very clear if you  
>> add
>> a Digest authentication challenge as well.
>
> At least as defined in RFC 2616 it makes no difference whether you have
> two headers, or a single header with the two values separated by a comma
> and RFC 2616, which defines the syntax of the header, notes:

Well, you are right, and I had missed that one, primarily because I  
considered 2617 the entire (selfcontained, except for general syntax)  
specification for authentication, including the headers.

This is possibly a problem that can occur frequently when  splitting a  
specification across multiple documents: Part of the fundamentals is in  
one document, but the most of the defintition is in another document which  
leaves out recollecting/repeating the fundamentals detailed in the other  
document. IMO 2617 should have duplicated the header definitions from  
2616. It would not surprise me if this have bitten more than one  
authentication implementor, as 2617 is the primary reference for the  
methods and where the implementor would turn for all information relevant  
to implementing support for those methods and the headers.

However, I am aware of two methods (there may be more) that does not use  
the parameter parts in the initial step and cannot be used with the syntax  
in 2616: NTLM and Negotiate. One might say that they are not conformant,  
but they are in wide use on intranets.

One might perhaps note that if a syntax element with multiple (low level)  
elements can be used repeatedly within the same header, then the lower  
level elements within the syntax should use a different separator than the  
separator used for the higher level elements. (in RFC2965 the use of  
commas in the port element require the entire value to be qouted in order  
to separate them from the commas that can be used in the high level  
syntax.)

-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Date: Sun, 11 Jan 2009 23:50:45 +0100
From: "Thomas Broyer" <[email-masked]>
To: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

On Sun, Jan 11, 2009 at 10:17 PM, Yngve N. Pettersen (Developer Opera
Software ASA) wrote:
> On Sun, 11 Jan 2009 21:00:36 +0100, Thomas Broyer wrote:
>
>>> - 401 with WWW-Authenticate / Cookie *and* Basic (for instance).
>>
>> http://ltgt.net/tests/http-cookie-auth/cookie-and-basic.asis
>
> This test sends an (IMO) invalid header
>
> WWW-Authenticate: Cookie realm="Cookie", Basic realm="Basic"

My *.asis file contained two distinct headers, so it must be an
artifact of apache mod_asis...
I've put the tests under version control so you can get the source and
run them with some other server:
http://hg.ltgt.net/http-cookie-auth/file/tip/tests

(and as Bjoern pointed out, the combined header is nonetheless valid)

-- 
Thomas Broyer

From: Bjoern Hoehrmann <[email-masked]>
To: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sun, 11 Jan 2009 22:39:53 +0100
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

* Yngve N. Pettersen (Developer Opera Software ASA) wrote:
>This test sends an (IMO) invalid header
>
>WWW-Authenticate: Cookie realm="Cookie", Basic realm="Basic"
>
>All parameters in WWW-Authenticate, except the first, are comma separated,  
>combining two WWW_Authenticate headers by comma separating them therefore  
>IMO changes the meaning of the meaning. This becomed very clear if you add  
>a Digest authentication challenge as well.

At least as defined in RFC 2616 it makes no difference whether you have
two headers, or a single header with the two values separated by a comma
and RFC 2616, which defines the syntax of the header, notes:

   The WWW-Authenticate response-header field MUST be included in 401
   (Unauthorized) response messages. The field value consists of at
   least one challenge that indicates the authentication scheme(s) and
   parameters applicable to the Request-URI.

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

   The HTTP access authentication process is described in "HTTP
   Authentication: Basic and Digest Access Authentication" [43]. User
   agents are advised to take special care in parsing the WWW-
   Authenticate field value as it might contain more than one challenge,
   or if more than one WWW-Authenticate header field is provided, the
   contents of a challenge itself can contain a comma-separated list of
   authentication parameters.

There have been discussions about changing how multiple headers are
joined, I am not sure what the status of that is.

>I suspect this needs some clearing up in HTTPbis. My recommendation is to  
>require only a single challenge in each WWW-Authenticate header, and to  
>forbid joining of multiple authentication headers.

(Don't forget to raise that then as issue :-)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Sun, 11 Jan 2009 22:17:27 +0100
To: "Thomas Broyer" <[email-masked]>, [email-masked]
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Organization: Opera Software AS
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

On Sun, 11 Jan 2009 21:00:36 +0100, Thomas Broyer <[email-masked]>  
wrote:

>> - 401 with WWW-Authenticate / Cookie *and* Basic (for instance).
>
> http://ltgt.net/tests/http-cookie-auth/cookie-and-basic.asis

This test sends an (IMO) invalid header

WWW-Authenticate: Cookie realm="Cookie", Basic realm="Basic"

All parameters in WWW-Authenticate, except the first, are comma separated,  
combining two WWW_Authenticate headers by comma separating them therefore  
IMO changes the meaning of the meaning. This becomed very clear if you add  
a Digest authentication challenge as well.

Each method offered must be in a separate header.

> http://ltgt.net/tests/http-cookie-auth/basic-and-cookie.asis

The same applies for this one.

I do notice, though, upon a *very* close reading (resembling what happened  
with ccTLD cookies in Netscape's spec), that RFC 2617 says in a single  
sentence (with similar for Proxy) that

    This response MUST
    include a WWW-Authenticate header field containing at least one
    challenge applicable to the requested resource.

There is no syntax definition in RFC2617 of what the form of  
WWW-Authenticate is, only the form of the challenge.

The above quote may be taken to mean that the definition of  
WWW-Authenticate is

    WWW-Authenticate ":" 1#challenge
    challenge   = auth-scheme 1*SP 1#auth-param

while Opera is assuming, due to the syntax of "challenge"

    WWW-Authenticate ":" challenge
    challenge   = auth-scheme 1*SP 1#auth-param

a defintion which IMO makes much more sense considering the combined use  
of space and comma as separators (the 1#challenge variant would require  
clients to scan each parameter for an internal space, and would make  
parsing more difficult).

I suspect this needs some clearing up in HTTPbis. My recommendation is to  
require only a single challenge in each WWW-Authenticate header, and to  
forbid joining of multiple authentication headers.

AFAIK all servers send each method offered as an individual header, not  
combined. This is also a method that makes sense when authentication  
methods can be plugged into the server in the form of modules.

For reference: Cookies (RFC2965) got around the multiple cookie problem  
only by requiring all non-cookie parameters on the header to start with  
"$".

-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Date: Sun, 11 Jan 2009 21:23:35 +0100
From: Julian Reschke <[email-masked]>
To: Thomas Broyer <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

Thomas Broyer wrote:
> ...
>> So it seems that there are at least three scenarios to be tested:
> 
> Note that the "results" above are only for WWW-Authenticateion /
> Cookie (test00).
> ...

Yep -- I was hoping you add the tests, which you did. (Thanks!)

> ...
> http://ltgt.net/tests/http-cookie-auth/cookie-and-basic.asis
> http://ltgt.net/tests/http-cookie-auth/basic-and-cookie.asis
> 
> You'd have to sniff your connection (I generally use Fiddler on
> Windows) to know what your browser actually do.

(another good one is Microsoft Network Monitor 3.2)

> Chrome "stable" pops up the authentication dialog with "Cookie" in the
> first test and "Basic" in the second, so I guess (I have no Fiddler at
> hand) in the first case it won't send any Authorization header to the
> server (as in the simple WWW-Authenticate / Cookie test).

I just tried with 2.0.156.1, and for 
<http://ltgt.net/tests/http-cookie-auth/cookie-and-basic.asis> the 
response body is displayed immediately.

> Opera 9.63 shows the blocking error page for cookie-and-basic, and
> pops up the authentication dialog for basic-and-cookie; so order
> matters.

Right. But it shouldn't, methinks. Otherwise deploying new auth schemes 
gets even harder as it is right now. This should be reported as a bug to 
Opera...

> IE7 and Firefox 3 (3.0.4) both show the 401 response body in the
> cookie-and-basic case, and pops up the authentication dialog in the
> basic-and-cookie case.

Which happens to be what we want (but really isn't what they should be 
doing...).

> Safari 3.2.1 on Windows shows the "Basic" prompt in both cases. When
> you dismiss the prompt, you're *not* given the 401 response body.

Picking the only known scheme regardless of ordering seems to me the 
right thing to do, although it will make it harder to deploy "Cookie".

Best regards, Julian

Date: Sun, 11 Jan 2009 21:00:36 +0100
From: "Thomas Broyer" <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

On Sun, Jan 11, 2009 at 6:40 PM, Julian Reschke wrote:
> Thomas Broyer wrote:
>>
>> ...
>> Tests at: http://ltgt.net/tests/http-cookie-auth/
>> Results at:
>> http://hg.ltgt.net/http-cookie-auth/raw-file/tip/ua-compat.html
>> ...
>
> So it seems that there are at least three scenarios to be tested:

Note that the "results" above are only for WWW-Authenticateion /
Cookie (test00).

> - 401 with no WWW-Authenticate header (illegal according to RFC2617, but
> interesting to see how the various UAs behave),

http://ltgt.net/tests/http-cookie-auth/no-www-authenticate.asis
HTML content displayed as is in all the browsers I've tested (same
list as ua-compat.html)

> - 401 with WWW-Authenticate / Cookie, and

http://ltgt.net/tests/http-cookie-auth/test00/
Results in ua-compat.html linked above.
Summary: will work in Chrome (works in "dev" version), doesn't work in
Opera (blocking error page) but I've filed a bug so I hope it'll be
fixed in Opera 10.

> - 401 with WWW-Authenticate / Cookie *and* Basic (for instance).

http://ltgt.net/tests/http-cookie-auth/cookie-and-basic.asis
http://ltgt.net/tests/http-cookie-auth/basic-and-cookie.asis

You'd have to sniff your connection (I generally use Fiddler on
Windows) to know what your browser actually do.

Chrome "stable" pops up the authentication dialog with "Cookie" in the
first test and "Basic" in the second, so I guess (I have no Fiddler at
hand) in the first case it won't send any Authorization header to the
server (as in the simple WWW-Authenticate / Cookie test).

Opera 9.63 shows the blocking error page for cookie-and-basic, and
pops up the authentication dialog for basic-and-cookie; so order
matters.

IE7 and Firefox 3 (3.0.4) both show the 401 response body in the
cookie-and-basic case, and pops up the authentication dialog in the
basic-and-cookie case.

Safari 3.2.1 on Windows shows the "Basic" prompt in both cases. When
you dismiss the prompt, you're *not* given the 401 response body.

-- 
Thomas Broyer

Date: Sun, 11 Jan 2009 18:40:52 +0100
From: Julian Reschke <[email-masked]>
To: Thomas Broyer <[email-masked]>
Cc: [email-masked]
Subject: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

Thomas Broyer wrote:
> ...
> Tests at: http://ltgt.net/tests/http-cookie-auth/
> Results at: http://hg.ltgt.net/http-cookie-auth/raw-file/tip/ua-compat.html
> ...

So it seems that there are at least three scenarios to be tested:

- 401 with no WWW-Authenticate header (illegal according to RFC2617, but 
interesting to see how the various UAs behave),

- 401 with WWW-Authenticate / Cookie, and

- 401 with WWW-Authenticate / Cookie *and* Basic (for instance).

The latter case would be used for sites that want to support a hybrid 
approach: form based login for browsers, programmatic login for other 
clients (such as WebDAV, AtomPub...). Currently these sites need to do 
user agent sniffing or just hope for those 'other' clients not to start 
their conversation with GET.

Best regards, Julian

Date: Sun, 11 Jan 2009 15:42:55 +0100
From: Julian Reschke <[email-masked]>
To: Thomas Broyer <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-http-auth] Cookie-based HTTP Authentication	(draft-broyer-http-cookie-auth-00)

Thomas Broyer wrote:
> Summary of this long reply:
> The I-D is absolutely unclear about it but the goal is that the
> migration path from current implementations to sending a 401 is as
> easy as possible (in many cases, it'd be nothing more than either
> adding two lines of code for sending the 401 status and the
> WWW-Authenticate header; or replacing a redirect with an internal
> forward; then come the SSO systems which are a bit harder to deal
> with, but not that much actually, even when crossing domain
> boundaries).
> The (almost) only motivation for a specific auth scheme is that a 401
> response requires a WWW-Authenticate. (I've found however that not
> sending a WWW-Authenticate at all is even better supported by
> browsers.)
> Moving away from cookies (while supporting them for backwards
> compatibility) is not part of the plan; at least for "version" 1" of
> the Cookie auth scheme.
> 
> Tests at: http://ltgt.net/tests/http-cookie-auth/
> Results at: http://hg.ltgt.net/http-cookie-auth/raw-file/tip/ua-compat.html
> ...

Good stuff.

I agree that it would be helpful if the next draft would elaborate a bit 
on goals and non-goals, such as:

1) have a HTTP auth scheme that can be returned with a 401

2) whether, for instance for text/html, the additional information 
should be sufficient for non-interactive clients to log in

I think there's sufficient support for part 1), even though currently it 
breaks with Opera. However I'm optimistic that this could be fixed in 
future Opera versions, and that their upgrade rate is good enough not to 
worry about 9.6 too much in time this is done. (Yngwe, are you on this 
list?)

Solving 2) is much harder, at least in the general case where there's 
more than username and password. Maybe there's a middle ground though; 
what about trying just to solve the special case where the form indeed 
only needs a name and a password? That may be sufficiently common to be 
useful.

Related to this; if this moves forward, are there changes for HTML 5 
that would help? Such as pointing UA implementers to this spec? 
(Anything else?)

Best regards, Julian

- remiding

Date: Sun, 11 Jan 2009 03:40:16 +0100
From: "Thomas Broyer" <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-http-auth] Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

To: [email-masked]
From: Bruno Harbulot <[email-masked]>
Date: Fri, 09 Jan 2009 19:32:18 +0000
Lines: 324
Sender: news <[email-masked]>
Subject: Re: [ietf-http-auth] Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

Hello,

Thomas Broyer wrote:
>>
>> A. Form identification.
>>
>> I think it would be useful to identify which of the forms is to be used
>> for authorisation. [...]
> 
> Why not... that was suggested on the WHAT WG too; and you're right
> that form-action was part of the answer.
> As you said, "it wouldn't necessarily be a good design", so let's not
> encourage it (just do not include the form-action attribute â€“and do
> not benefit from automatically submitted formâ€“ or live with the
> ambiguity; it would still be better than the current practice of
> redirecting to the login page or sending the login page with a 200
> status and no-cache controls).
> The use-case for form-action was identifying the form in the response
> body for automatic population and submition, in case credentials have
> been passed up-front (as is the case, for example, with httplib2
> <http://code.google.com/p/httplib2/> ). Initially, I was only thinking
> about use-cases where the cookie is set by the server with a
> Set-Cookie2 header (actually in practice, a non-RFC2109-compliant
> Set-Cookie) in response to a POST request.
> During edition of the draft before -00, I loosened the requirements
> (how about a cookie set by a javascript? what about non-HTML
> entities?), but left the form-action unchanged.
> So yes, maybe a form-id would be better?

Yes, I'd be in favour of a form-id.
I was thinking of a non-browser user-agent, which is probably the same 
as what you mean by the case where the credentials have been passed 
up-front. "form-id" seems clearer as a concept, to identify the form, 
and it might also be easier to program (for example, using DOM's 
getElementById).

>> In addition, this might be used for pointing to a form on a different page:
>>
>>    1.  User Agent -> Server
>>
>>    GET https://www.example.com/acme/ HTTP/1.1
>>
>>    2.  Server -> User Agent
>>
>>    HTTP/1.1 401 Unauthorized
>>    WWW-Authenticate: Cookie realm="Acme"
>>            form-uri="https://www.example.com/acme/login#loginform"
>>            form-action="/acme/login"
>>            cookie-name=ACME_TICKET
>>    Content-Type: text/html
>>
>>    <title>Unauthorized</title>
> 
> It would be totally non-backwards-compatible (with current UAs, with
> mostly browsers in mind); or the form would have to be pulled in from
> the returned entity (e.g. an AJAX request to get  the form, instead of
> including it directly within the response body; or a frame eventually,
> but I don't see the point: the UA have to process the returned entity
> to be able to proceed with signing in, so what would it add to
> form-action?).

> There almost no reason not to allow it (developers just won't use it
> most of the time), but what should an UA do with this? present the
> <title>Unauthorized</title> or redirect to the form-uri? (should it be
> an HTTP URI? should it be accessed with a simple HTTP GET? if so, why
> couldn't it be included as part of the returned entity, or the
> returned entity issue the redirection? â€“see the notes about the
> upcoming 3rd example)

Yes, indeed, having a full URI wouldn't be backward compatible. I'm only 
trying to leave the door open just in case one day browsers implement 
this spec and if it can evolve into another spec.
It seems easier to have form-id="#loginform" and then allow 
form-id="http://example.org/login#loginform" in the not-so-near future; 
at least it doesn't do any harm. If it was just form-id="loginform", it 
would be harder to allow for general URIs later.

What I'd like to see in user-agents supporting this type of 
authentication, is the awareness that a potential redirection to a form 
is just for authentication and that it should go back to the initial 
request upon successful authentication. It doesn't matter than much for 
GET requests, but it's more important for a POST request.

An example of this problem is something that happens on a wiki that I 
use, where the session cookie expires after a rather short period of 
time. Suppose you're editing a page in your browser, that you're about 
to POST the modification, but that your credentials have expired.

   A. If the website uses HTTP Basic (or other WWW-Authenticate header 
auth.), the interaction will be like this:

      (1) C->S:
        POST http://example.org/mypage HTTP/1.1

        the-updated-text

      (2) S->C:
        HTTP/1.1 401
        WWW-Authenticate: Basic xxxxxxxxxx

        <title>Unauthorized</title>

(The browser asks the user for the password.)

      (3) C->S:
        POST http://example.org/mypage HTTP/1.1
        Authorization: Basic xxxxxxxxxxxxxxxx

        the-updated-text

(This rarely happens in practice with Basic auth, because browsers tend 
to keep you logged in for however long they run, unless having 
explicitly told not to, but let's assume the credentials your browser 
has are no longer valid for request (1).)

   B. If the website uses a form

      (1) C->S:
        POST http://example.org/mypage HTTP/1.1

        the-updated-text

      (2) S->C:
        HTTP/1.1 200

        <title>Unauthorized</title>
        <form>...</form>

      (3) C->S:
        POST /login

        username=...&password=...

      (4) S->C:
        HTTP/1.1 200

        <title>Welcome, dear xxxxx.</title>

Unfortunately, the entity of the first request will be lost, unless 
there's a session that has memorised it and can let the server process 
the initial request (that wouldn't be RESTful).
This problem is less obvious with GET requests, because the form 
returned in (2) could include a reference to the original page so that 
(3) and (4) looks like this:

      (3) C->S:
        POST /login?origin=http://example.org/mypage

        username=...&password=...

      (4) S->C:
        HTTP/1.1 302
        Location: http://example.org/mypage

        <title>Welcome, dear xxxxx.</title>

      (5) S->C:
        GET http://example.org/mypage

This last step ought not to happen according to RFC 2616 (Section 
10.3.3) [1], but it's the way Firefox, IE and Safari do it. (In fact, 
these browsers could end up doing a GET in step (5) even in request (1) 
was a POST.)

There is also a worse variant to this:

      (1) C->S:
        POST http://example.org/mypage HTTP/1.1

        the-updated-text

      (2a) S->C:
        HTTP/1.1 302
        Location: /login

        <title>Unauthorized</title>
        <form>...</form>

      (2b) C->S:
        GET /login HTTP/1.1

      (2c) S->C:
        HTTP/1.1 200

        <title>Please identify yourself or register.</title>
        <form>...</form>

(The actual wiki I have in mind has in fact a much longer set of 
interactions for what's ultimately a cookie-based authentication, as 
it's protected using Shibboleth. I've described the interaction in [2], 
in the Shibboleth section towards the end... Sorry, no local anchors.)

For this reason, I hope that, one day, it would be possible for browsers 
to be aware that authentication forms should be treated orthogonally, 
like other WWW-Authenticate mechanisms, where successful authentication 
would make the user-agent continue with the original intended request.
Whether this is done via a separate pop-up, some AJAX or something else 
(perhaps in the same window but coming back to the main action upon 
success) would be a choice of implementation.

I think this specification should aim to provide support for this, even 
though we can't expect current implementations to understand this. I 
don't think this would lead to something non-backward-compatible, it 
would just mean that implementations that are broken in the way they 
currently are and that wouldn't support this would still be broken in 
the same way.
In fact, I'd say I'd barely see the point of a WWW-Authenticate Cookie 
scheme if it doesn't aim to make the authentication properly orthogonal 
(which indeed might not be understood by current user-agents --they'd 
behave like they do now-- but could be by the newer ones, progressively).

>> B. Use of Authorization/AuthenticationInfo.
>>
>> To quote Roy Fielding on Cookie-based authentication: "Cookie
>> authentication is not allowed in REST because it lacks visibility, which
>> causes security problems because the other components don't know it is
>> sensitive information."
>> (http://tech.groups.yahoo.com/group/rest-discuss/message/3729)
>>
>> I think this document is a step forward to address this problem (in
>> particular via "cookie-name" and "secure-cookie-name"), in a way that is
>> compatible with the current browser behaviour.
> 
> Note that it doesn't solve the case where the user signs in from a
> public page, and thus never ever sees a 401 and the cookie-name and
> secure-cookie-name (hence Julian's question in early december about
> including the WWW-Authenticate header within a success response â€“2xx
> or eventually 3xxâ€“; that should IMO be added to httpbis or defined in
> a distinct I-D)

I guess you're referring to this thread [3]. Yes, that's a problem for 
mixed authenticated and non-authenticated access. I guess 
WWW-Authenticate could be present in successful responses indeed, as 
it's already the case for SPNEGO (someone has already mentioned it on 
that thread).

>> However, perhaps this could be viewed in a broader context.
>>
>> In my opinion, form-based authentication differs from the authentication
>> mechanisms that use WWW-Authenticate mainly because the authentication
>> function is performed as part of the application (in the REST
>> "Hypermedia As The Engine Of State" sense), unlike the other schemes,
>> which use a mechanism orthogonal to it (such as a dialog box in the
>> browser for Basic auth). Authentication cookies are then merely an
>> artefact of the intersection between the main application and the
>> authentication concern, where the cookie is a vehicle for the
>> authentication token.
>> I think it would be worth trying to go a step further and aiming at
>> decoupling this authentication token from the concept of cookies (which
>> are also widely used for maintaining sessions).
>>
>> I think this Internet Draft presents a satisfactory solution for dealing
>> both with current cookie mechanisms (to become legacy) and with a new
>> mechanism in line with RFC 2617.
>> However, if this new mechanism was to be implemented and actually
>> supported by browsers in the future, I think moving away from using
>> cookies as authentication tokens should be part of the plan.
> 
> Nothing precludes adding it later. I'd rather have something that just
> does what it's been made for (communicate unauthorized access through
> a 401 status rather than 200 or 3xx) sooner, than something that does
> even more, later.

True, but I think this is mainly a question of actual adoption of this 
I-D, and which one will break less the current behaviour.
In particular, will a "401 + WWW-Authenticate: Cookie" confuse and break 
browsers? Would the addition of Authentication-Info confuse them even 
more? I'm not sure, I haven't tried.

>> Thus, I'd suggest adding support for Authorization/AuthenticationInfo as
>> well (and perhaps making them mandatory for implementations to qualify
>> as compliant with this specification), with headers looking like this:
>>
>> S->UA:
>>    AuthenticationInfo: Cookie xxxxxxxxxxxx
>>    (optionally in conjunction with a Set-Cookie2 header containing the
>> same information, for legacy user-agents)
>>
>> UA->S:
>>    Authorization: Cookie xxxxxxxxxxxx
>>    (optionally in conjunction with a Cookie header containing the same
>> information, for legacy user-agents)
> 
> How do you communicate the "protected space"? duplicating RFC2965 at
> the Authentication-Info level with Domain, Path, Secure, etc.
> attributes? (that wouldn't work because no-one is actually
> implementing either RFC2109 or RFC2965, because "the Web" uses
> something looking more like Netscape's cookies)

Yes, that would be something along those lines. I'm just suggesting 
there should be an Authentication-Info header similar to what sets the 
cookie for future user-agents, those embracing this I-D. Set-Cookie2 (or 
whatever else is currently used) should be present as well for the 
existing implementations. Implementations supporting this I-D would then 
be allowed (and perhaps encouraged) to ignore the corresponding 
session-cookie if they understand the Authentication-Info. Separating 
them is just for clarity of the purpose of the header.

Best wishes,

Bruno.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3
[2] 
http://blog.distributedmatter.net/post/2008/06/09/HTTP-authentication-mechanisms-and-how-they-could-work-in-Restlet
[3] http://lists.w3.org/Archives/Public/ietf-http-wg/2008OctDec/0245.html

Date: Thu, 8 Jan 2009 23:20:01 +0100
From: "Thomas Broyer" <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-http-auth] Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

To: [email-masked]
From: Bruno Harbulot <[email-masked]>
Date: Thu, 08 Jan 2009 15:49:28 +0000
Lines: 140
Sender: news <[email-masked]>
Subject: Re: [ietf-http-auth] Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

Hello,

Thomas Broyer wrote:
> Hi all,
> 
> As I previously said, I spent some holiday time to put my thoughts
> about "RFC2617-compliant cookie-based authentication" into an Internet
> Draft.
> Today is my birthday (and the last day of my holidays) so I thought I
> should do something special. I therefore submitted version 00 of my
> work ("release early, release often" they said).
(Happy birthday.)

This looks good. There are a few points I'd suggest to do a bit 
differently perhaps.

A. Form identification.

I think it would be useful to identify which of the forms is to be used 
for authorisation. I can imagine the case where there would be several 
forms on the same page. For example, a page with a template could have a 
default search form as part of the general layout of the page (quite 
common for a wiki for example), as well as the login form; both could be 
displayed on the page returned with "401 Unauthorized". Although it's 
often easy for a human to pick the right form, it would not be so 
obvious for a non-browser user-agent.
"form-action" partly addresses this problem, but there's in principle 
nothing to prevent two forms on the same page to use the same action (it 
wouldn't necessarily be a good design, but that's possible).
I would  suggest using another directive, perhaps called "form-uri", 
combined with an "id" attribute in the form.

    1.  User Agent -> Server

    GET https://www.example.com/acme/ HTTP/1.1

    2.  Server -> User Agent

    HTTP/1.1 401 Unauthorized
    WWW-Authenticate: Cookie realm="Acme"
            form-uri="#loginform"
            form-action="/acme/login"
            cookie-name=ACME_TICKET
    Content-Type: text/html

    <title>Unauthorized</title>
    <form id="loginform" action="/acme/login" method=POST>
    <input type=hidden name=referer value="/acme/">
    <p><label>Username: <input name=user></label>
    <p><label>Password: <input name=pwd type=password></label>
    <p><button type=submit>Sign in</button>
    <p><a href="/acme/register">Register for an account</a>
    </form>

In addition, this might be used for pointing to a form on a different page:

    1.  User Agent -> Server

    GET https://www.example.com/acme/ HTTP/1.1

    2.  Server -> User Agent

    HTTP/1.1 401 Unauthorized
    WWW-Authenticate: Cookie realm="Acme"
            form-uri="https://www.example.com/acme/login#loginform"
            form-action="/acme/login"
            cookie-name=ACME_TICKET
    Content-Type: text/html

    <title>Unauthorized</title>

"form-action" might become redundant in this case, or be used as a 
safe-guard.

B. Use of Authorization/AuthenticationInfo.

To quote Roy Fielding on Cookie-based authentication: "Cookie 
authentication is not allowed in REST because it lacks visibility, which 
causes security problems because the other components don't know it is 
sensitive information." 
(http://tech.groups.yahoo.com/group/rest-discuss/message/3729)

I think this document is a step forward to address this problem (in 
particular via "cookie-name" and "secure-cookie-name"), in a way that is 
compatible with the current browser behaviour. However, perhaps this 
could be viewed in a broader context.

In my opinion, form-based authentication differs from the authentication 
mechanisms that use WWW-Authenticate mainly because the authentication 
function is performed as part of the application (in the REST 
"Hypermedia As The Engine Of State" sense), unlike the other schemes, 
which use a mechanism orthogonal to it (such as a dialog box in the 
browser for Basic auth). Authentication cookies are then merely an 
artefact of the intersection between the main application and the 
authentication concern, where the cookie is a vehicle for the 
authentication token.
I think it would be worth trying to go a step further and aiming at 
decoupling this authentication token from the concept of cookies (which 
are also widely used for maintaining sessions).

I think this Internet Draft presents a satisfactory solution for dealing 
both with current cookie mechanisms (to become legacy) and with a new 
mechanism in line with RFC 2617.
However, if this new mechanism was to be implemented and actually 
supported by browsers in the future, I think moving away from using 
cookies as authentication tokens should be part of the plan.
Thus, I'd suggest adding support for Authorization/AuthenticationInfo as 
well (and perhaps making them mandatory for implementations to qualify 
as compliant with this specification), with headers looking like this:

S->UA:
    AuthenticationInfo: Cookie xxxxxxxxxxxx
    (optionally in conjunction with a Set-Cookie2 header containing the 
same information, for legacy user-agents)

UA->S:
    Authorization: Cookie xxxxxxxxxxxx
    (optionally in conjunction with a Cookie header containing the same 
information, for legacy user-agents)

In fact, perhaps this scheme should be called something else than "Cookie".

Best wishes,

Bruno.

-- 
http://blog.distributedmatter.net/

Date: Wed, 7 Jan 2009 00:15:44 +0100
From: "Thomas Broyer" <[email-masked]>
Sender: [email-masked]
To: public-html <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [ietf-http-auth] Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

On Mon, Jan 5, 2009 at 1:25 AM, Thomas Broyer wrote:
>
> As I previously said, I spent some holiday time to put my thoughts
> about "RFC2617-compliant cookie-based authentication" into an Internet
> Draft.

A collegue of mine told me I forgot to include a direct link to the draft.
Here it is (for those not used to IETF I-Ds' URLs):
http://www.ietf.org/internet-drafts/draft-broyer-http-cookie-auth-00.txt

I've put an HTML version here:
http://ltgt.net/projects/http-cookie-auth/draft-broyer-http-cookie-auth-00.html

As a side note, I've moved my Mercurial repository from broyer.info to
hg.ltgt.net (you'll be automatically redirected).
And my apologies to Julian and others as the -00 draft doesn't include
acknowledgements (fixed in the repo)

-- 
Thomas Broyer

Date: Mon, 5 Jan 2009 01:25:13 +0100
From: "Thomas Broyer" <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked], public-html <[email-masked]>
Subject: [ietf-http-auth] Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00)

Hi all,

As I previously said, I spent some holiday time to put my thoughts
about "RFC2617-compliant cookie-based authentication" into an Internet
Draft.
Today is my birthday (and the last day of my holidays) so I thought I
should do something special. I therefore submitted version 00 of my
work ("release early, release often" they said).

As written in the draft, discussion should go to the ietf-http-auth
list (if it happened to not be the appropriate list, please tell me so
I can fix it in the next version).

The Security Considerations section is not yet complete but for this
00 draft I though the overall authentication process was the most
important (have a look at the examples too).

Thanks in advance for your feedback.

(My intent is to publish some kind of "reference implementations" and
"proof of concepts" in various languages later in my mercurial
repository http://broyer.info/hg/http-cookie-auth/ but if you'd like
to contribute now, just send me your code!)

---------- Forwarded message ----------
From: IETF I-D Submission Tool <[email-masked]>
Date: Mon, Jan 5, 2009 at 1:15 AM
Subject: New Version Notification for draft-broyer-http-cookie-auth-00
To: [email-masked]

A new version of I-D, draft-broyer-http-cookie-auth-00.txt has been
successfuly submitted by Thomas Broyer and posted to the IETF
repository.

Filename:        draft-broyer-http-cookie-auth
Revision:        00
Title:           Cookie-based HTTP Authentication
Creation_date:   2009-01-04
WG ID:           Independent Submission
Number_of_pages: 11

Abstract:
This document specifies an HTTP authentication scheme for use when
credentials are validated by an out-of-band mechanism (not defined
here) and later communicated to the server through the use of a
cookie.  Which out-of-band mechanism should be used, and how, is
described by the 401 (Unauthorized) response body.  It is common
practice that this mechanism is an HTML form, sending the user's
credentials with the use of an HTTP POST request to a tier URL which
will set a cookie in response; though this document doesn't preclude
the use of other mechanisms.

The IETF Secretariat.

-- 
Thomas Broyer