Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

From: William Mills <[email-masked]>
Date: Tue, 11 Oct 2011 09:20:42 -0700 (PDT)

So where are we on this?  Any progress?

________________________________
From: "Manger, James H" <[email-masked]>
To: William J. Mills <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Tuesday, August 30, 2011 11:39 PM
Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

William J. Mills said:
>Did item #2 below get resolved?  I haven't seen any more traffic about it and it seems pretty significant.

No, I haven’t seen any resolution for #2 (or any of these comments).
The latest HTTPbis draft (http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16) has updated ABNF for <challenge> and <credentials> that supports the base64-blobs used by BASIC and NTLM. It does not allow what BEARER tries to do.
 
--
James Manger

________________________________

From:"Manger, James H" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Thursday, July 28, 2011 8:51 PM
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

My working group last call comments on draft-ietf-oauth-v2-bearer-08.txt:

1. Mentioning that this is an HTTP authentication mechanism in the title and/or abstract would be useful to the wider IETF (& beyond) audience.
Title:
  "The BEARER HTTP authentication mechanism for use with OAuth 2"
Abstract:
  "This specification describes how to use bearer tokens in
  HTTP requests to access OAuth 2 protected resources."

[Personally, I wouldn't bother mentioning OAuth at all here, but others seem to want this context restriction.]

2. The ABNF for <credentials> does not comply with RFC 2617 "HTTP Authentication". And even though RFC 2617 is broken is this aspect, the BEARER spec doesn't comply with the errata (still broken) or the more likely fixes proposed for HTTPbis [draft-ietf-httpbis-p7-auth].
I expect HTTPbis to allow a base64-like-blob consistently in Authorization and WWW-Authenticate headers (to accommodate BASIC and NTLM). Multiple WWW-Authenticate headers can have their values combined, separated by commas. They can also have quoted-string parameters. To be able to parse this, requires disallowing commas and double-quotes from the base64-like-blob (and hence from <access-token>) at a minimum; only allowing equals at the end also helps.
The current approach in the bearer spec disallows all but 94 chars/bytes. I suggest reducing this to 69. Something in between (eg 91 chars, dropping comma, quote, and slash) might work. None of these options are materially easier than the others for a token issuer; and less symbols just means less risk of escaping problems elsewhere (eg allowing "<" in an access token will wreck someone's XML somewhere, for no benefit).

Suggestion: 
  access-token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="

  <access-token> 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].

2b. If 2 is not accepted (and assuming HTTPbis will allow any content after the scheme name in a Authorization header) can we please not misuse the <quoted-char> label when no quoting is going on. The following is a better equivalent:

  access-token = 1*(%x21-7E) ; ASCII, except controls, space, or delete

3. Drop '\' from the allowed chars in a scope value, to avoid clashing with the HTTP quoted-string escaping mechanism (and don't use the <quoted-char> label when no quoting is going on).
  scope-v = 1*(%x21 / %x23-5B / %x5D-7E); excludes space and " and \

4. Section 3.3 "Summary of Recommendations" sensibly says clients "MUST ensure that bearer tokens are not leaked to *unintended parties*" and correctly notes that this is "the primary security consideration" that underlies all the others. So it is a glaring hole that OAuth2 fails to tell the client who the intended parties are when issuing a bearer token.

--
James Manger
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 12 Oct 2011 11:06:57 +1100

>> 2. The ABNF for <credentials> does not comply with RFC 2617 "HTTP Authentication".

> So where are we on this?  Any progress?

Some progress.
draft-ietf-oauth-v2-bearer-09 defines the “Authorization: Bearer ...” request header to match draft-ietf-httpbis-p7-auth. It uses <b64token> for the access token.
The spec is not quite right as it also includes a comma-separated list of name=value pairs <#auth-param> as another option for the header, without any hint about how this works for the Bearer scheme.

Still to do:
Change
credentials = "Bearer" 1*SP ( b64token / #auth-param )
to
credentials = "Bearer" 1*SP b64token
It would also be worth explicitly stating the restrictions on access tokens that the Bearer scheme applies over what OAuth core allows, which is any Unicode string. The Bearer spec requires an access token to match <b64token>. This does not have to be base64 (or base64url), but it can only use 68 ASCII chars (plus “=”’s at the end). Section 4.1.1 “The “Bearer” OAuth Access Token Type” is probably the place to mention the restrictions. Suggested text:

  “When the type is “bearer” the “access_token” value MUST match the <b64token> ABNF [draft-ietf-httpbis-p7-auth], which allows the 66 unreserved URI characters plus a few others so it can hold a base64 or base64url encoding [RFC4648]. Using a base64url encoding without padding (or a few base64url encoded items separated by dots) is RECOMMENDED as it avoids the need for any escaping in most situations.”

Probably need to add RFC 4648 “The Base16, Base32, and Base64 Data Encodings” as an informative reference if including this suggested text.

--
James Manger

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Oct 2011 11:21:05 +0200

On 2011-10-12 02:06, Manger, James H wrote:
> draft-ietf-oauth-v2-bearer-09 defines the “Authorization: Bearer ...”
> request header to match draft-ietf-httpbis-p7-auth. It uses <b64token>
> for the access token.
>
> The spec is not quite right as it also includes a comma-separated list
> of name=value pairs <#auth-param> as another option for the header,
> without any hint about how this works for the Bearer scheme.
>
> Still to do:
>
> Change
>
> ...

I'd like to point out that we added b64token in HTTPbis in order to 
grandfather Basic and Digest; it's really not designed for new schemes.

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

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

So be aware that by choosing b64token, you are closing the door for any 
kind of extensibility here. (Note that this isn't a matter of taste, but 
directly follows from syntax requirements for parsing the header field)

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Wed, 12 Oct 2011 14:32:25 +0000

Draft 09 allows either b64token or auth-params.  Unless there's a working group consensus that this must change, both syntax options will be supported.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Reschke
Sent: Wednesday, October 12, 2011 2:21 AM
To: Manger, James H
Cc: [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

On 2011-10-12 02:06, Manger, James H wrote:
> draft-ietf-oauth-v2-bearer-09 defines the "Authorization: Bearer ..."

I'd like to point out that we added b64token in HTTPbis in order to grandfather Basic and Digest; it's really not designed for new schemes.

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

So be aware that by choosing b64token, you are closing the door for any kind of extensibility here. (Note that this isn't a matter of taste, but directly follows from syntax requirements for parsing the header field)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Oct 2011 16:51:51 +0200

> Draft 09 allows either b64token or auth-params.  Unless there's a working group consensus that this must change, both syntax options will be supported.

Mike,

that doesn't work. The restriction in HTTPbis is there because it's 
necessary so a recipient can parse a header field that contains 
multiple, comma-separated challenges.

If you think that HTTPbis is wrong here please come over to the HTTPbis 
mailing list and argue your point.

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Wed, 12 Oct 2011 18:02:11 +0000

The syntax in HTTPbis is:
    credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ]

The syntax in Bearer 09 is:
   credentials = "Bearer" 1*SP ( b64token / #auth-param )

As this conforms to HTTPbis, I don't see a problem.  I think HTTPbis and Bearer are both fine as-is.

				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Wednesday, October 12, 2011 7:52 AM
To: Mike Jones
Cc: Manger, James H; [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

Mike,

that doesn't work. The restriction in HTTPbis is there because it's necessary so a recipient can parse a header field that contains multiple, comma-separated challenges.

If you think that HTTPbis is wrong here please come over to the HTTPbis mailing list and argue your point.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Oct 2011 20:23:55 +0200

> As this conforms to HTTPbis, I don't see a problem.  I think HTTPbis and Bearer are both fine as-is.

The intent is that a scheme uses one of the two constructs, not both.

Bearer can't use auth-params and b64tokens in the same challenge, so 
it's unclear to me how this is supposed to work.

If you have a notation where you can express the bearer token as 
auth-param then why don't you *always* use it and get rid of the 
b64token construct?

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Wed, 12 Oct 2011 18:26:38 +0000

Because b64token is existing practice

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Wednesday, October 12, 2011 11:24 AM
To: Mike Jones
Cc: Manger, James H; [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

Bearer can't use auth-params and b64tokens in the same challenge, so it's unclear to me how this is supposed to work.

If you have a notation where you can express the bearer token as auth-param then why don't you *always* use it and get rid of the b64token construct?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Oct 2011 20:35:18 +0200

> Because b64token is existing practice

<include-disclaimer-about-maturity-of-internet-drafts/>

Anyway, how do you then send credentials that include the bearer token 
plus additional parameters? Example, please.

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Wed, 12 Oct 2011 18:39:05 +0000

One possible syntax is:

Bearer access_token=xyz_-123,more_info=pdq

Ultimately though, the format of the bearer token is outside of the scope of the spec, and up to the participants to determine, including whether to use b64token syntax or params syntax.

				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Wednesday, October 12, 2011 11:35 AM
To: Mike Jones
Cc: Manger, James H; [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

Anyway, how do you then send credentials that include the bearer token plus additional parameters? Example, please.

Best regards, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 12 Oct 2011 11:48:00 -0700

Not that I will ever use this, but this is really broken way to create a protocol. Now is the time to make hard choices and pick one format.

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mike Jones
> Sent: Wednesday, October 12, 2011 11:39 AM
> To: Julian Reschke
> Cc: [email-masked]
> Ultimately though, the format of the bearer token is outside of the scope of
> the spec, and up to the participants to determine, including whether to use
> b64token syntax or params syntax.
> 
> 				-- Mike
>

---

From: William Mills <[email-masked]>
Date: Wed, 12 Oct 2011 12:56:21 -0700 (PDT)

I have suggested before, and I will reiterate that we should define explicitly how to transport the token in an extensible way if extensions are desired.  I think we shoudl allow both of:

    Bearer b64token

and 

    Bearer token=<quoted string>

The first ensures compatibility with extant implementation, and the second provides definition for the basics where people want to extend it.

-bill

________________________________
From: Mike Jones <[email-masked]>
To: Julian Reschke <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Wednesday, October 12, 2011 11:39 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

One possible syntax is:

                -- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Wednesday, October 12, 2011 11:35 AM
To: Mike Jones
Cc: Manger, James H; [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

Best regards, Julian

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 13 Oct 2011 11:38:17 +1100

> Ultimately though, the format of the bearer token is outside of the scope of the spec, and up to the participants to determine, including whether to use b64token syntax or params syntax.

It is great to see an example explaining the intention of the "b64token / #auth-param" part of the draft. These details need to be in the spec. Draft 9 makes no mention of an "access_token" parameter for the HTTP header -- in sharp contrast to mentioning such a parameter for the URI query string and POST body mechanisms. Can the "access_token" value be a <token> (as in the above example)? Can it be a <quoted-string>? Can it use RFC5987 (eg access_token*=UTF-8''...)?

Can a client choose the b64token or auth-param option, implying servers MUST support both? Or is it the other way around: servers only have to support b64token so existing servers are compliant without requiring any changes?

I thought the consensus was that bearer tokens were so simple that "Bearer <b64token>" was sufficient. In the unlikely event that more parameters were required in future, a new scheme (eg Bearer2) could be defined. If this is no longer the consensus then lets:

1. Define a single syntax that servers MUST support.
  Authorization: Bearer a="<access_token>"

2. Use a short parameter name, such as "a", saving 10-bytes per request over "access_token". The long name is needed in a URI query string or POST body so the parameter is unambiguous amongst any number of other application-specific parameters. In a Bearer HTTP header there is no such possibility of confusion.

3. Don't allow the value to be either a <token> or <quoted-string> -- just pick one (I suggest <quoted-string>). It doesn't help developers or interop to offer a pointless choice.

4. Allow future comma-separated parameters, and state that unrecognized parameters MUST be ignored.

5. Add an informative note that some servers might also accept a header of the form "Bearer <access_token>", but clients using this form are not compliant to this spec.

6. Explicitly state that when the type is "bearer" in an OAuth2 token response, the "access_token" MUST only consist of characters that can be represented in a <quoted-string>, ie %x20-7E (assuming <quoted-string> was picked at #3).

7. Recommend that a base64url encoding without padding (of binary data or of UTF-8 encoded text) is a good choice for an "access_token" value (or a few base64url encoded segments separated by dots) as it avoids the need to escape characters in most situations.

--
James Manger

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 12 Oct 2011 18:37:35 -0700

> I thought the consensus was that bearer tokens were so simple that "Bearer <b64token>" was sufficient. In the unlikely event that more parameters were required in future, a new scheme (eg Bearer2)…

While I much prefer what you suggest below (and it was suggested
before), I think it is too late for that. It will force existing
deployments to implement ambiguous parsing code.

Let's stick with "Bearer <b64token>". If this is the only option, do
we have to limit the token chars to b64?

If more flexibility is needed then we can define a new scheme for that.

Marius

---

From: David Waite <[email-masked]>
Date: Wed, 12 Oct 2011 19:49:53 -0600

> If more flexibility is needed then we can define a new scheme for that.

I agree. The use of "Bearer" is enough to allow for future extension if needed, by using one of the many other character sequences allowed for the scheme.

-DW

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Oct 2011 09:13:12 +0200

On 2011-10-13 02:38, Manger, James H wrote:
> It is great to see an example explaining the intention of the "b64token / #auth-param" part of the draft. These details need to be in the spec. Draft 9 makes no mention of an "access_token" parameter for the HTTP header -- in sharp contrast to mentioning such a parameter for the URI query string and POST body mechanisms. Can the "access_token" value be a<token>  (as in the above example)? Can it be a<quoted-string>? Can it use RFC5987 (eg access_token*=UTF-8''...)?
>
> I thought the consensus was that bearer tokens were so simple that "Bearer<b64token>" was sufficient. In the unlikely event that more parameters were required in future, a new scheme (eg Bearer2) could be defined. If this is no longer the consensus then lets:
>
> 3. Don't allow the value to be either a<token>  or<quoted-string>  -- just pick one (I suggest<quoted-string>). It doesn't help developers or interop to offer a pointless choice.
>
> 5. Add an informative note that some servers might also accept a header of the form "Bearer<access_token>", but clients using this form are not compliant to this spec.
>
> 6. Explicitly state that when the type is "bearer" in an OAuth2 token response, the "access_token" MUST only consist of characters that can be represented in a<quoted-string>, ie %x20-7E (assuming<quoted-string>  was picked at #3).
>

+1

Except for:

 > 3. Don't allow the value to be either a<token>  or<quoted-string>  -- 
just pick one (I suggest<quoted-string>). It doesn't help developers or 
interop to offer a pointless choice.

...allow both, because otherwise you'll need custom parsers to process 
the header field.

Best regards, Julian