Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt

From: [email-masked]
Date: Wed, 27 Jul 2011 06:17:00 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF.

	Title           : The OAuth 2.0 Protocol: Bearer Tokens
	Author(s)       : Michael B. Jones
                          Dick Hardt
                          David Recordon
	Filename        : draft-ietf-oauth-v2-bearer-07.txt
	Pages           : 17
	Date            : 2011-07-27

   This specification describes how to use bearer tokens when accessing
   OAuth 2.0 protected resources.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-07.txt

---

From: Mike Jones <[email-masked]>
Date: Wed, 27 Jul 2011 13:20:47 +0000

This version adds a missing comma in an error response example.  Thanks to Stephen Farrell for his donation of the comma.

This version should be the subject of the working group last call.

					-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 27, 2011 6:17 AM
To: [email-masked]
Cc: [email-masked]
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-07.txt
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Barry Leiba <[email-masked]>
Date: Wed, 27 Jul 2011 13:44:27 -0400

> This version should be the subject of the working group last call.

As announced in the working group session this morning at IETF 81:

This document goes into working-group last call today, ending on 12
August.  Everyone: please review this version of the document, and
make any comments by 12 August.  The goal will be to have Mike
incorporate any comments at that point, put out a final version, and
send it to the IESG.

Barry, as chair

---

From: Mike Jones <[email-masked]>
Date: Wed, 27 Jul 2011 17:48:17 +0000

Thanks, Barry.  For what it's worth, after submitting -07, I realized that the references to the oauth-v2 and httpbis specs needed to be updated, and did this in -08 (making no other changes).  Thus, -08 should be the version that is the subject of the working group last call.

				Cheers,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Wednesday, July 27, 2011 10:44 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt

This document goes into working-group last call today, ending on 12 August.  Everyone: please review this version of the document, and make any comments by 12 August.  The goal will be to have Mike incorporate any comments at that point, put out a final version, and send it to the IESG.

Barry, as chair

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 29 Jul 2011 13:51:12 +1000

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