Subject: #516 note about WWW-A parsing potentially misleading

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 15:10:24 +0100

Hi there,

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-24.html#rfc.section.4.4>:

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

This is text that we copied from RFC 2616 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.47>). 
However, isn't the

"...if more than one WWW-Authenticate header field is provided..."

incorrect?

What's contained in a challenge does not depend on the number of header 
field instances, after all.

Best regards, Julian

---

From: Michael Sweet <[email-masked]>
Date: Wed, 30 Oct 2013 10:39:44 -0400

Julian,

This might be a case of what-is-defined vs. what-is-used, but in my experience user agents/clients don't support multiple WWW-Authenticate headers and often do not look past the first challenge in the value.

Given that the current p1-messaging draft says that senders MUST NOT repeat headers (section 3.2.2) and that WWW-Authenticate is not listed as an exception like Set-Cookie, I think it would be appropriate/safe to drop the "or if more than one WWW-Authenticate header field is provided" part in p7-auth.

On Oct 30, 2013, at 10:10 AM, Julian Reschke <[email-masked]> wrote:

> "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."
> 
> This is text that we copied from RFC 2616 (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.47>). However, isn't the
> 
> What's contained in a challenge does not depend on the number of header field instances, after all.
> 
> Best regards, Julian
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 30 Oct 2013 15:40:51 +0100

>field instances, after all.

The intent may have been to emphasise that having only one challenge per
WWW-Authenticate header does not mean no special care has to be taken. I
agree that it can be confusing; replacing the sub clause by "and" should
be fine.

(User agents should also take special care handling multiple headers; it
can make a difference whether you parse them individually or merge them
first and then parse the whole value; e.g. two individually malformed
values might turn into a well-formed value. But WWW-Authenticate is not
special in that regard.)
-- 
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/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 15:50:21 +0100

> This might be a case of what-is-defined vs. what-is-used, but in my experience user agents/clients don't support multiple WWW-Authenticate headers and often do not look past the first challenge in…

Multiple challenges in one header field: 
<http://greenbytes.de/tech/tc/httpauth/#multibasicunknown2> (fail for 
everyone except Safari and Konqueror)

Multiple header field instances: 
<http://greenbytes.de/tech/tc/httpauth/#multibasicunknown2mf> (seems to 
work interoperably)

> Given that the current p1-messaging draft says that senders MUST NOT repeat headers (section 3.2.2) and that WWW-Authenticate is not listed as an exception like Set-Cookie, I think it would be appr…

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-24.html#rfc.section.3.2.2.p.2>:

"A sender MUST NOT generate multiple header fields with the same field 
name in a message unless either the entire field value for that header 
field is defined as a comma-separated list [i.e., #(values)] or the 
header field is a well-known exception (as noted below)."

So WWW-Authenticate does not need to be listed as exception because it 
*does* use the list syntax.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 15:58:49 +0100

> agree that it can be confusing; replacing the sub clause by "and" should

Not sure what your proposal is.

How about:

"User agents are advised to take special care in parsing the
WWW-Authenticate header field, as each field value can contain more than 
one challenge, and the header field itself can occur multiple times. 
Furthermore, the contents of a single challenge can contain a
comma-separated list of authentication parameters."

> values might turn into a well-formed value. But WWW-Authenticate is not

That is true, but as you say not specific to this one. The way to 
address this would to require validation of the header field instances 
before re-combining them, but then *that* requires knowledge of the 
field values' syntax.

Best regards, Julian

---

From: Michael Sweet <[email-masked]>
Date: Wed, 30 Oct 2013 11:00:32 -0400

Julian,

On Oct 30, 2013, at 10:50 AM, Julian Reschke <[email-masked]> wrote:
> Multiple challenges in one header field: <http://greenbytes.de/tech/tc/httpauth/#multibasicunknown2> (fail for everyone except Safari and Konqueror)
> 
> Multiple header field instances: <http://greenbytes.de/tech/tc/httpauth/#multibasicunknown2mf> (seems to work interoperably)

I'm glad to see the multiple header situation has improved; my last experiments with this 3-4 years ago (trying to support simultaneous Basic and Negotiate auth for CUPS) were not successful at all...

> "A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below)."
> 
> So WWW-Authenticate does not need to be listed as exception because it *does* use the list syntax.
> 
> Best regards, Julian
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 30 Oct 2013 16:13:41 +0100

>Not sure what your proposal is.

s/if more than one WWW-Authenticate header field is provided/and/ would
be a minimal solution that addresses the problem.

>comma-separated list of authentication parameters."

That would also work, but editorially it would be better to keep the two
comma cases together (comma separates challenges; comma separates para-
meters in challenges; then mention multiple headers).
-- 
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/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 16:31:11 +0100

> meters in challenges; then mention multiple headers).

Yup.

"User agents are advised to take special care in parsing the
WWW-Authenticate header field, as each field value can contain more than
one challenge, and each challenge can contain a comma-separated list of 
authentication parameters. Furthermore, the header field itself can 
occur multiple times."

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 Oct 2013 14:30:04 +1100

On 31/10/2013, at 2:31 AM, Julian Reschke <[email-masked]> wrote:
> one challenge, and each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur multiple times."

+1

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 Oct 2013 14:01:32 +0100

>> one challenge, and each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur multiple times."

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2455>

(Note that I also removed a similar sentence that appeared under the 
"challenge" definition).

Best regards, Julian