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

From: Julian Reschke <[email-masked]>
Date: Sun, 07 Aug 2011 20:28:03 +0200

On 2011-07-29 01:45, Manger, James H wrote:
>>> 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.
>
> NTLM doesn't include any params initially.
> A recent HTTPbis change made the 1 and only previously-required parameter 'realm' optional.
> So the syntax should be adjusted not to require any params. At which point a base64 blob that isn't the first param would be ambiguous.
> ...

James,

again sorry for the slow feedback.

I spent some time on

   <http://greenbytes.de/tech/tc/httpauth/>

making sure that what RFC 2616/7 specify is actually parseable (it seems 
to, I've done with with XSLT 2 and regexps). (Feedback on more tests 
welcome...).

Summarizing where we are:

- we introduce a b64 grammar production

- we remove the at-least one auth-param requirement from the ABNF 
(actually, that should be done as part of issue 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/177>

- we allow b64 both in challenges and credentials *instead* of a list of 
auth-params (we believe a single b64 is sufficient for Negotiate & friends)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 08 Aug 2011 15:38:13 +0200

> auth-params (we believe a single b64 is sufficient for Negotiate & friends)

OK, here's a proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/195/195.diff>; 
it introduces a new grammar construct as suggested by James, and allows 
it *instead* of auth-param lists. Also, it suggests that it's for 
backwards compatibility and that it should not be used for new schemes.

In particular:

2.1.  Challenge and Response

    HTTP provides a simple challenge-response authentication mechanism
    that can be used by a server to challenge a client request and by a
    client to provide authentication information.  It uses an extensible,
    case-insensitive token to identify the authentication scheme,
    followed by a comma-separated list of attribute-value pairs which
    carry the parameters necessary for achieving authentication via that
    scheme.

      auth-scheme    = token
      auth-param     = token BWS "=" BWS ( token / quoted-string )

    As an alternative to a list of auth parameters, a single string can
    be used:

      b64token       = 1*( ALPHA / DIGIT /
                           "-" / "." / "_" / "~" / "+" / "/" ) *"="

    This includes the 66 unreserved URI characters ([RFC3986]), plus a
    few others, so that it can hold a base64, base64url (URL and filename
    safe alphabet), base32, or base16 (hex) encoding, with or without
    padding, but excluding whitespace ([RFC4648]).

    ...

      challenge   = auth-scheme [ 1*SP ( b64token / #auth-param ) ]

    ...

      credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ]

--> Note that I made 1*SP optional when nothing follows.

2.3.1.  Considerations for New Authentication Schemes

    ...

    o  The "b64token" notation was introduced for compatibility with
       existing authentication schemes, it MUST NOT be used in new
       schemes.

Appendix A.  Changes from RFCs 2616 and 2617

    ...

    The "b64token" alternative to auth-param lists has been added for
    consistency with legacy authentication schemes such as "Basic".
    (Section 2)

...feedback appreciated. Once the change is applied I'll update 
<http://greenbytes.de/tech/tc/httpauth/> accordingly.

Best regards, Julian

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 9 Aug 2011 09:50:19 +1000

> backwards compatibility and that it should not be used for new schemes.

Julian,

I like the new text, except for disallowing <b64token> for new schemes.
I don't think that extra restriction is necessary, or useful.

Other authentication schemes could well copy how BASIC/NTLM/NEGOTIATE
do it, for the same reasons (a single blob is a good match for their
information model).
draft-ietf-oauth-v2-bearer (currently in Working Group Last Call)
defines the BEARER HTTP authentication scheme to uses a single
string (it currently allows any ASCII chars other than controls and space,
but should be able to adopt <b64token>).

So suggested text (with a few <ins>erts and <del>etes):

    HTTP provides a simple challenge-response authentication mechanism
    that can be used by a server to challenge a client request and by a
    client to provide authentication information.  It uses an extensible,
    case-insensitive token to identify the authentication scheme,
    followed by <ins>a single string or</ins>
    a comma-separated list of attribute-value pairs which
    carry the parameters necessary for achieving authentication via that
    scheme.

      auth-scheme    = token

    <del>As an alternative to a list of auth parameters, a single string can
    be used:</del>

    <ins>The single sting alternative <b64token></ins>
    includes the 66 unreserved URI characters ([RFC3986]), plus a
    few others, so that it can hold a base64, base64url (URL and filename
    safe alphabet), base32, or base16 (hex) encoding, with or without
    padding, but excluding whitespace ([RFC4648]).

    ...

    ...

    ...

    o  The "b64token" notation was introduced for compatibility with
       existing authentication schemes<del>, it MUST NOT be used in new
       schemes</del>.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 09 Aug 2011 11:12:55 +0200

On 2011-08-09 01:50, Manger, James H wrote:
>>> auth-params (we believe a single b64 is sufficient for Negotiate&  friends)
>
> I like the new text, except for disallowing<b64token>  for new schemes.

Most of it is yours :-)

> but should be able to adopt<b64token>).

My concern is that b64token is constrained to a single value; if you 
pick it, there are no extension points left. I think this is sufficient 
reason to discourage it. Will come up with new proposed text later on.

Could you please point out to the draft-ietf-oauth-v2-bearer people that 
they are painting themselves into a corner with this, and should just 
use auth-params instead?

>
> So suggested text (with a few<ins>erts and<del>etes):
>
>      followed by<ins>a single string or</ins>

Ack.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 09 Aug 2011 13:24:34 +0200

Hi,

so I went ahead and applied the following change: 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1394>

> reason to discourage it. Will come up with new proposed text later on.

New text:

    o  The "b64token" notation was introduced for compatibility with
       existing authentication schemes and can only be used once per
       challenge/credentials.  New schemes thus ought to use the "auth-
       param" syntax instead, because otherwise future extensions will be
       impossible.

>> <del>As an alternative to a list of auth parameters, a single string can

Now...:

    HTTP provides a simple challenge-response authentication mechanism
    that can be used by a server to challenge a client request and by a
    client to provide authentication information.  It uses an extensible,
    case-insensitive token to identify the authentication scheme,
    followed by additional information necessary for achieving
    authentication via that scheme.  The latter can either be a comma-
    separated list of attribute-value pairs or a single sequence of
    characters capable of holding base64-encoded information.

      auth-scheme    = token

    The "b64token" syntax allows the 66 unreserved URI characters
    ([RFC3986]), plus a few others, so that it can hold a base64,
    base64url (URL and filename safe alphabet), base32, or base16 (hex)
    encoding, with or without padding, but excluding whitespace
    ([RFC4648]).

(reminder: this is only our development version, so we can still tune 
it...).

Best regards, Julian