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

"William J. Mills" <> Wed, 31 August 2011 05:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 187D221F8C4E for <>; Tue, 30 Aug 2011 22:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.288
X-Spam-Status: No, score=-17.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hh2bbb8MMPYP for <>; Tue, 30 Aug 2011 22:13:36 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 158FE21F8C4C for <>; Tue, 30 Aug 2011 22:13:36 -0700 (PDT)
Received: from [] by with NNFMP; 31 Aug 2011 05:14:59 -0000
Received: from [] by with NNFMP; 31 Aug 2011 05:14:59 -0000
Received: from [] by with NNFMP; 31 Aug 2011 05:14:59 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 47070 invoked by uid 60001); 31 Aug 2011 05:14:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ginc1024; t=1314767698; bh=JCSF1qHyr7+XV6OndNsXaisNZjuB3SHYr+dEqm2TU0E=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=h8WzN5HKrUhZXKAJosH8fzLgi/TPZYAZm/5tftkDW9JNzkJQiOcTpo+ODObBiWcmmjC8kp55Shx3Ir7KEYX2i9PpOUMZFx73qQdAROnJ8sDY2osJR8fPTawzNsVGSCcjpf8buGoll/WagEiqLTkdi5/G6qXuTO/EDC12F+kZVxs=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024;; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=mg/c5FDnK11lFakq9uJ13rMY7hfZq0R/XLUfIxYzrLpV2/IsO4jNT2Nom3Jlvo2XdGN1xEWHB5qhxplSYnmYTwbXifscDvcXWTwk5svFXqZgcfD8xxWD91VGSBJLh8sg2mUUXmoF6j73xBTBqX6O2UArTztU1stV4Hkfny8eh+k=;
X-YMail-OSG: 0bRtgKsVM1kpG2_1JwOXqBZtoAnUGWqDajKHhhK8JLm4XYC KaIXYPuhzRN970xQz5kPJBdpzL0XE.pJsRELxTEmfCGNPZaNzObG2UZGUMLx MIk8DXocmBgOyAhqN7rkRh4qw7xj79gY.IaYxLiFI_48BvImGRxNa28TBF30 R31yIUaF9cjs8HU0PJnvfOuLF4fUeSRRCazRV9N7V5aOH2lueA3JK6ih4xjO _E9hhoH9GMEk1qTIgb4QNSsn3LtLrJK6r_wEEEGorfk4eN2blnOm07Bs24rU UEGztgsxeoGdJUzcXkOGPpVRO6DaYnPPc_hsTOuM94allA4LhCtJNIIH2d2o R1tMqpYCjgXBTXRiFo464U8WJSs2m.EJo2KU8o9vkPCjiW9ZuX6Jh.Nr9tKv 6wIzWhhTQa7G9JtF5tpGK
Received: from [] by via HTTP; Tue, 30 Aug 2011 22:14:58 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/
References: <> <> <> <>
Message-ID: <>
Date: Tue, 30 Aug 2011 22:14:58 -0700
From: "William J. Mills" <>
To: "Manger, James H" <>, "" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1856681075-1314767698=:36186"
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "William J. Mills" <>
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Aug 2011 05:13:37 -0000

Did item #2 below get resolved?  I haven't seen any more traffic about it and it seems pretty significant.



From: "Manger, James H" <>
To: "" <>
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.
  "The BEARER HTTP authentication mechanism for use with OAuth 2"
  "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).

  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