Re: [OAUTH-WG] Bearer Token Last Call Comments

Mike Jones <Michael.Jones@microsoft.com> Wed, 19 October 2011 23:57 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DB011E80AF for <oauth@ietfa.amsl.com>; Wed, 19 Oct 2011 16:57:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.984
X-Spam-Level:
X-Spam-Status: No, score=-9.984 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCmKCxyUnsa1 for <oauth@ietfa.amsl.com>; Wed, 19 Oct 2011 16:57:52 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id B521C11E8095 for <oauth@ietf.org>; Wed, 19 Oct 2011 16:57:52 -0700 (PDT)
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Oct 2011 16:57:52 -0700
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0339.002; Wed, 19 Oct 2011 16:57:51 -0700
From: Mike Jones <Michael.Jones@microsoft.com>
To: Justin Richer <jricher@mitre.org>, "Anganes, Amanda L" <aanganes@mitre.org>
Thread-Topic: [OAUTH-WG] Bearer Token Last Call Comments
Thread-Index: AcyOuuIGob2s/4J+RN6XsYxNdEm67w==
Date: Wed, 19 Oct 2011 23:57:51 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24B250@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.37]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C24B250TK5EX14MBXC283r_"
MIME-Version: 1.0
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Bearer Token Last Call Comments
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2011 23:57:53 -0000

Thanks for the useful feedback, Justin and Amanda.  Actions taken in response in draft 10 are described inline.



-----Original Message-----
From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org]<mailto:[mailto:oauth-bounces@ietf.org]> On Behalf Of Justin Richer
Sent: Friday, August 12, 2011 11:32 AM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Cc: Anganes, Amanda L
Subject: [OAUTH-WG] Bearer Token Last Call Comments



1.3: This draft still uses the term "access grant" where the core now uses "authorization grant". Change all references to "authorization grant" and reference section 1.4 in core. Also, too many parenthetical statements in opening paragraph -- suggested rewrite of this bit:

               Before a client can access a protected resource, it must first

               obtain an authorization grant [[link to core S.1.4]] from the

               resource owner, and then exchange the authorization grant for

               an access token. The access token then represents the scope,

               duration, and other access attributes granted by the

               authorization grant.

Done


2: "...SHOULD NOT be used unless no other..." is a triple negative and while technically correct it is a bit head-spinny to read. Suggested

rewrite: "Due to the Security Considerations (S.3) associated with the URI method, this method SHOULD NOT be used unless it is the only feasible method."

Done


2.1/2.2/2.3: Introductory text is non-parallel. Suggest changing intro to 2.1 to parallel 2.2 and 2.3, with a "When including the access token in the Authorization header, the client ..." construct.

Done


2.2: "unless the following conditions are met" is ambiguous. All conditions are met? At least one?

Now reads “unless all of the following conditions are met”.


2.3: Are there conditions for this use as well, to match 2.2?

Just the statement about “SHOULD NOT be used unless it is the only feasible method”.


2.2/2.3: Add normative language to: "The entity-body MAY include other request specific parameters. In which case..." (similar in 2.3's request

URI)

Done


Might be useful to have the example show an additional parameter.

Not done, as the additional parameter could also confuse developers reading the specification.


2.4: Should this be a top-level section? Since it's dealing with the from-the-server bit instead of the to-the-server bit that the rest of 2.

is dealing with.

Done


3.1: Missing word: "Token redirect:  An attacker uses the token generated for consumption by [one] resource server to obtain access to another resource server."

Done


3: There's a mix of normative and non-normative language throughout this section, as well as a mix of imperative and descriptive language. We suggest making the whole section normative and imperative to be consistent. Particular instances:



  3.2: "the lifetime of the token MUST be limited”

Done


  3.3: validate SSL certificate chains: "The client MUST..."

Done


  3.3: issue short lived bearer tokens: Change to something like "Token

               servers SHOULD issue short-lived (one hour or less) bearer

               tokens, particularly when issuing tokens to clients that run

               within a web browser or other environments where information

               leakage may occur. Using short-lived bearer tokens can reduce

               the impact of one of them being leaked."

Done


  3.3: scoped bearer tokens: "Token servers SHOULD issue bearer tokens

               that contain an audience restriction..."

Done


  3.3: don't pass: "Bearer tokens SHOULD NOT be passed in page URLs

               (for example as query string parameters). Instead, bearer

               tokens SHOULD be passed in HTTP message headers or message

               bodies for which confidentiality measures are taken. Browsers,

               web servers, and other software may not adequately secure URLs

               in the browser history, web server logs, and other data

               structures. If bearer tokens are passed in page URLs, attackers

               might be able to steal them from the history data, logs, or

               other unsecured locations."

Done


-- Justin Richer



_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth

                                                            -- Mike