Subject: [OAUTH-WG] Challenge/Response complexity

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

The authentication framework defined in 2616 and 2617 allows for very complicated combinations of challenges and responses. For example, servers can provide multiple challenges in separate headers and in a single header, and clients can respond with a multiple credentials in one request.

Do we want to limit this? We are allowed to profile the framework. For example:

* Allow only a single Authorization header when used with the Token scheme.
* Forbid more than one challenge per WWW-Authenticate header.

The main motivation for these limits comes from the error reporting requirement. If the server is to provide error information to possible multiple Authorization headers, it needs to be able to identify which error is for which attempt. Also, if a single header can pose multiple challenges, it gets harder to inline error information with the new challenge (which will require defining a new error header).

This is all easy to spec out, but much more work to implement. How do people feel about adding these restrictions vs. maintaining the full flexibility of the current framework?

EHL

---

From: John Panzer <[email-masked]>
Date: Thu, 3 Dec 2009 23:44:32 -0800

I think it'd be reasonable to allow only a single Authorization: header from
client to server when used with the Token scheme.

What do you mean by multiple challenges per WWW-Authenticate header?
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

On Thu, Dec 3, 2009 at 11:34 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> The authentication framework defined in 2616 and 2617 allows for very
> complicated combinations of challenges and responses. For example, servers
> can provide multiple challenges in separate headers and in a single header,
> and clients can respond with a multiple credentials in one request.
>
> The main motivation for these limits comes from the error reporting
> requirement. If the server is to provide error information to possible
> multiple Authorization headers, it needs to be able to identify which error
> is for which attempt. Also, if a single header can pose multiple challenges,
> it gets harder to inline error information with the new challenge (which
> will require defining a new error header).
>
> This is all easy to spec out, but much more work to implement. How do
> people feel about adding these restrictions vs. maintaining the full
> flexibility of the current framework?
>
> EHL
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

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

I mean this:

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

Which is nasty but fully compliant. See related thread on HTTPbis.

EHL

From: John Panzer [mailto:[email-masked]]
Sent: Thursday, December 03, 2009 11:45 PM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Challenge/Response complexity

I think it'd be reasonable to allow only a single Authorization: header from client to server when used with the Token scheme.

What do you mean by multiple challenges per WWW-Authenticate header?
--
John Panzer / Google
[email-masked]<mailto:[email-masked]> / abstractioneer.org<http://abstractioneer.org> / @jpanzer

On Thu, Dec 3, 2009 at 11:34 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
The authentication framework defined in 2616 and 2617 allows for very complicated combinations of challenges and responses. For example, servers can provide multiple challenges in separate headers and in a single header, and clients can respond with a multiple credentials in one request.

EHL
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

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

On 12/04/2009 02:34 AM, Eran Hammer-Lahav wrote:
> complicated combinations of challenges and responses. For example,
> servers can provide multiple challenges in separate headers and in
> a single header, and clients can respond with a multiple credentials
> in one request.

It's not quite that bad; the server can send multiple challenges, but
the client can only respond to one of them at a time. (The
"Authorization" header is not multi-valued like "WWW-Authenticate" is.)
It's expected that the client will pick the best/strongest
WWW-Authenticate option that it knows how to deal with, and then try to
authenticate using that, ignoring the other WWW-Authenticate headers (or
possibly, if the first attempt fails, it might fall back to using its
second choice, etc).

-- Dan

---

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

For those not following the HTTBbis WG, Dan also pointed this section out:

   Multiple header fields with the same field name MUST NOT be sent in a
   message unless the entire field value for that header field is
   defined as a comma-separated list [i.e., #(values)].  Multiple header
   fields with the same field name can be combined into one "field-name:
   field-value" pair, without changing the semantics of the message, by
   appending each subsequent field value to the combined field value in
   order, separated by a comma.  The order in which header fields with
   the same field name are received is therefore significant to the
   interpretation of the combined field value; a proxy MUST NOT change
   the order of these field values when forwarding a message.

This basically prevents us from profiling the header to only permit a single challenge. We can limit a single challenge for the entire response, but that would defeat the purpose of providing clients with multiple options and will break existing sites.

EHL

> -----Original Message-----
> From: Dan Winship [mailto:[email-masked]]
> Sent: Friday, December 04, 2009 6:40 AM
> To: Eran Hammer-Lahav
> > servers can provide multiple challenges in separate headers and in a
> > single header, and clients can respond with a multiple credentials in
> > one request.
> 
> It's not quite that bad; the server can send multiple challenges, but the client
> can only respond to one of them at a time. (The "Authorization" header is
> not multi-valued like "WWW-Authenticate" is.) It's expected that the client
> will pick the best/strongest WWW-Authenticate option that it knows how to
> deal with, and then try to authenticate using that, ignoring the other WWW-
> Authenticate headers (or possibly, if the first attempt fails, it might fall back
> to using its second choice, etc).
> 
> -- Dan

---

From: Brian Eaton <[email-masked]>
Date: Fri, 4 Dec 2009 09:35:41 -0800

> This basically prevents us from profiling the header to only permit a single challenge. We can limit a single challenge for the entire response, but that would defeat the purpose of providing clien…

Agreed.  It's not uncommon to see things like:

WWW-Authenticate: Negotiate
WWW-Authenticate: Basic

... for example.

Cheers,
Brian