W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: #195, was: ABNF for Authorization header not quite right

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 28 Jul 2011 17:06:29 +0200
Message-ID: <4E317AF5.3090601@gmx.de>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 2011-07-28 02:45, Manger, James H wrote:
>>> I suggest changing the ABNF to the following:
>>>     credentials = auth-scheme SP ( b64 / #auth-param )
>>>     b64 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="
>>>     <b64>   includes the 66 unreserved URI characters plus a few others.
>>>     It can hold a base64, base64url (URL and filename safe alphabet),
>>>     base32, or base16 (hex) encoding, with or without padding, but
>>>     excluding whitespace [RFC4648].
>>> This accepts authentication schemes that transmit a base64 blob instead of name=value pairs (such as BASIC, NTLM, NEGOTIATE). It also accepts dot-separated base64url blobs, as proposed in new specs such as JSON Web Tokens.
>>> I dropped<quoted-string>   as I don't know where that came from. Perhaps it was added with<token>   as they are often a pair. If there are no existing uses (and I don't know of any) it adds no value.
>> Indeed.
>> Maybe we need
>>    credentials = auth-scheme SP #( b64 / auth-param )
> I doubt we need that. I have never seen a NTLM or Negotiate scheme header with more than 1 base64 blob.


>> though? As far as I can tell, RFC 4559 uses that.
>> Also: RFC 4559 seems to need this for the challenge as well...
> RFC 4559 "SPEGNO/NTLM/Negotiate" might specify that, but I don't think it can work as it makes parsing ambiguous. For instance, does the following response header include 1 scheme with 4 parameters, or 2 or 3 schemes? Is "tuv" another authentication scheme supported by this server, or a parameter of the "ABC" scheme?
>    WWW-Authenticate: ABC xyz, a=1, qrs, tuv

The ABNF says:

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

so there needs to be at least one auth-param, separated by one or more SPs.

That being said, we may have to rethink the use of the list production here.

Keep in mind that 1#auth-param allosws

	scheme auth-param

but also

	scheme ,auth-param

because of the specific rules for empty list elements.

*That* would be impossible to parse, and thus we may want not to use the 
# notation over here.

Best regards, Julian

> The ambiguity that occurs for<challenge>  might not occur for<credentials>  if only 1 Authorization header is allowed, but it does show that we cannot match what the ABNF in RFC 4559 theoretically needs. We should match what is actually in use -- which seems to be a single base64 blob.
> I prefer
>    ( b64 / #auth-param )
> instead of
>    #( b64 / auth-param )
> That is, I think a<b64>  blob should only be allowed when it is the first (and only) parameter.
> --
> James Manger
Received on Thursday, 28 July 2011 15:07:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC