Subject: WGLC p7: Parsing auth challenges

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 29 Apr 2013 19:55:38 +0100

Hi,

In sections 2.1 & 4.4 (and by reference 4.2) of p7 User Agents are guided to take "special care" when parsing WWW-Authenticate and/or Proxy-Authenticate header field values, but it is never plainly stated what that means.

From the grammar, it looks as if the critical distinction is that (ignoring any allowed whitespace for brevity):

A sequence "," token "=" means we are now receiving a parameter to an existing challenge. This is guaranteed because the "=" and value are non-optional components of auth-param. (The grammar would be unresolvably ambiguous otherwise.)

A sequence "," token and anything other than "=" means we are now receiving the start of a new challenge. This is guaranteed because token68 may not contain "," and token (for a following auth-param) may not be empty. (The grammar would be unresolvably ambiguous otherwise.)

(And if we don't get something, after whitespace elimination, which is either the end of the header field value or a token after the ",", then the value is invalid and should be rejected.)

If that interpretation is correct, it would be helpful to state this clearly, rather than merely infer it. (And if that interpretation is not correct, clearly relying on inference alone is unreliable!)

There is perhaps still the question of whether in the face of multiple WWW/Proxy-Authenticate headers, the implied "," separating their values according to #rule is still allowed to operate at both levels of the grammar, or only at the outermost (#challenge) level.

Thanks
Ben

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 30 Apr 2013 12:40:01 +1000

Hi Ben,

I think you have it right, so have created an editorial ticket:
 http://trac.tools.ietf.org/wg/httpbis/trac/ticket/474

If the editors have a problem with it, they can come back and talk to us.

Cheers,

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Apr 2013 13:43:16 +0200

> A sequence "," token and anything other than "=" means we are now receiving the start of a new challenge. This is guaranteed because token68 may not contain "," and token (for a following auth-para…

Right (or something invalid).

> (And if we don't get something, after whitespace elimination, which is either the end of the header field value or a token after the ",", then the value is invalid and should be rejected.)

You could have an empty list entry, such as in

  WWW-Authenticate: Basic realm="foo", , Basic realm="bar"

> If that interpretation is correct, it would be helpful to state this clearly, rather than merely infer it. (And if that interpretation is not correct, clearly relying on inference alone is unreliab…

The interpretation is correct. Can you make a more concrete proposal?

> There is perhaps still the question of whether in the face of multiple WWW/Proxy-Authenticate headers, the implied "," separating their values according to #rule is still allowed to operate at both…

Not sure about what you're asking. Can you provide an example?

Best regards, Julian

---

From: John Sullivan <[email-masked]>
Date: Tue, 30 Apr 2013 14:45:09 +0100

>   WWW-Authenticate: Basic realm="foo", , Basic realm="bar"

Ah yes, of course. I always assume that basic #rule processing,
including eliminating empty entries, has been done at a lower
layer so at this level the comma "doesn't exist" - but if we're
talking about sequences including the "," here, that is an
inconsistent way of describing it.

(And if we get a non-empty string, after whitespace elimination,
between the "," but before the earlier of either the end of the
header field value or the next ",", which is not a token then the
value is invalid and should be rejected.)

> Not sure about what you're asking. Can you provide an example?

WWW-Authenticate: chal1 param1p1=val , param1p2=val, chal2 param2p1=val

Should clearly be equivalent to:

WWW-Authenticate: chal1 param1p1=val , param1p2=val
WWW-Authenticate: chal2 param2p1=val

It also should (according to the above rules) be equivalent to:

WWW-Authenticate: chal1 , param1p1=val , param1p2=val, chal2 param2p1=val

And of course:

WWW-Authenticate: , chal1 , param1p1=val , param1p2=val, chal2 param2p1=val

WWW-Authenticate: chal1 , param1p1=val , , param1p2=val, chal2 param2p1=val

WWW-Authenticate: chal1 , param1p1=val , param1p2=val, chal2 param2p1=val,

But what about:

WWW-Authenticate: chal1 param1p1=val
WWW-Authenticate: param1p2=val, chal2 param2p1=val

This *could* be unambiguously parsed as equivalent to the above,
but feels a bit shakier to allow. OTOH dumb processors assuming
#rule might transform in or out of that form (by breaking on an
arbitrary unencoded comma or squashing any #rule headers into a
single instance).

On that matter I just also noticed:

WWW-Authenticate: chal2
WWW-Authenticate: param2p1=val

Which looks similar but is probably disallowed by the grammar as
it stands: the param list is optional, but if present must be
separated by 1*SP (and any such you attempted to put in wouldn't
form part of field-value.)

Going back up a bit, compare:

Apparently allowed:
WWW-Authenticate: chal1 , param1p1=val , param1p2=val, chal2 param2p1=val

Apparently invalid:
WWW-Authenticate: chal1, param1p1=val , param1p2=val, chal2 param2p1=val

John
--

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Apr 2013 16:06:10 +0200

> inconsistent way of describing it.

#rule processing can not happen at a lower layer because if requires 
knowledge of the ABNF for "rule".

> WWW-Authenticate: chal2 param2p1=val

Yes.

> WWW-Authenticate: chal1 , param1p1=val , param1p2=val, chal2 param2p1=val,

Yes.

> arbitrary unencoded comma or squashing any #rule headers into a

Yes. It's invalid (each header field instance needs to conform to 
#challenge), but folding it into a single string may make it valid-

> form part of field-value.)

It's as invalid as the previous example.

> ...

Yes.

The syntax for WWW-A is a big mess. Not sure what we can do here in the 
spec though.

Best regards, Julian