From bcampbell@pingidentity.com Wed Feb 1 08:07:52 2012 Return-Path: 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 E473B11E80BA for ; Wed, 1 Feb 2012 08:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.56 X-Spam-Level: X-Spam-Status: No, score=-5.56 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 iodXKjkHFIxp for ; Wed, 1 Feb 2012 08:07:52 -0800 (PST) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id EE94411E80A3 for ; Wed, 1 Feb 2012 08:07:51 -0800 (PST) Received: from mail-vx0-f177.google.com ([209.85.220.177]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTyljV47xwAQIZWJv++hMpxflZmxCp0HH@postini.com; Wed, 01 Feb 2012 08:07:52 PST Received: by mail-vx0-f177.google.com with SMTP id f1so1316544vcb.8 for ; Wed, 01 Feb 2012 08:07:51 -0800 (PST) Received: by 10.220.148.132 with SMTP id p4mr15256887vcv.31.1328112470832; Wed, 01 Feb 2012 08:07:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.37.42 with HTTP; Wed, 1 Feb 2012 08:07:18 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Wed, 1 Feb 2012 09:07:18 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=f46d043c09220bb66b04b7e9481d Subject: [OAUTH-WG] Fwd: [OAuth2.0][SAML2.0] 2.2. Using SAML Assertions for Client Authentication Problem ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 16:07:53 -0000 --f46d043c09220bb66b04b7e9481d Content-Type: text/plain; charset=ISO-8859-1 I wanted to get the below question and answer to the right place. ---------- Forwarded message ---------- From: Brian Campbell Date: Wed, Feb 1, 2012 at 9:01 AM Subject: Re: [OAuth2.0][SAML2.0] 2.2. Using SAML Assertions for Client Authentication Problem ? To: Shiu Fun Poon Cc: cmortimore@salesforce.com Hi Shiu, Section 2.2 is about client authentication and the parameter names are correct for that context (the names are defined in http://tools.ietf.org/html/draft-ietf-oauth-assertions and this profile defines the values for use with SAML). The example in Section 4 that uses assertion and grant_type is about authorization and not client authentication. And it is consistent with section 2.1 Thanks, B On Tue, Jan 31, 2012 at 10:29 PM, Shiu Fun Poon wrote: > Hi.. > Reading the latest spec.. are there typos in the following section ? > > 2.2. Using SAML Assertions for Client Authentication > > > he value of "client_assertion_type" parameter MUST ?? Should this be grant_type > The value of the "client_assertion" parameter ?? Is this assertion (which is what is shown in the example). > > > > > Thanks. > > --f46d043c09220bb66b04b7e9481d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I wanted to get the below question and answer to the right place.

---------- Forwarded me= ssage ----------
From: Brian Campbell = <brian.d.campbell@gmail.com>
Date: Wed, Feb 1, 2012 at 9:01 AM
Subject: Re: [OAuth2.0][SAML2.0] 2.2. = Using SAML Assertions for Client Authentication Problem ?
To: Shiu Fun P= oon <shiufunp= oon@gmail.com>
Cc: cmortimo= re@salesforce.com


Hi Shiu,

Section 2.2 is= about client=A0authentication and the parameter names are correct for that= context (the names are defined in=A0http://tools.ietf.org/html/d= raft-ietf-oauth-assertions and this profile defines the values for use = with SAML).

The example in Section 4 that uses assertion and grant_= type is about authorization and not client=A0authentication. And it is cons= istent with section 2.1=A0

Thanks,
B

On Tue, Jan 31, 2012 at 10:29 PM, Shiu = Fun Poon <shiufunpoon@gmail.com> wrote:
Hi..
Reading the latest spec.. are there typos in the following section = ?
2.2.  Using SAML Assertions for Client Authenticati=
on




he value of "client_assertion_type" parameter MUST  ??  Shou=
ld this be grant_type
The value of the "client_assertion" para=
meter   ?? Is this assertion (which is what is shown in the example).






Thanks.



--f46d043c09220bb66b04b7e9481d-- From sakimura@gmail.com Thu Feb 2 01:25:12 2012 Return-Path: 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 5CD6721F8A55 for ; Thu, 2 Feb 2012 01:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 85ssJVC14Ro6 for ; Thu, 2 Feb 2012 01:25:11 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3D721F8A27 for ; Thu, 2 Feb 2012 01:25:11 -0800 (PST) Received: by lahl5 with SMTP id l5so1323062lah.31 for ; Thu, 02 Feb 2012 01:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=v3iVZF23P8vTgVn7oUC7GPVTbrOqG/IX4JppwDSOyJw=; b=tvyZNxOvYG0Xza0xNcL+sv82auI8rdbNNeAnTcw0yuW2dgyN1OfW/kowt7qC3lSUO8 cdLFV08OcspJtU1jmF5nkpYIvmpZkOHVs6c8bGbD3LmkL6A2inVge89KnIcz/7Fe88GA KB8GO66mFrqmI2pkEidZ6yhOm/ES5c0ECzZEg= MIME-Version: 1.0 Received: by 10.152.147.137 with SMTP id tk9mr1093946lab.8.1328174710237; Thu, 02 Feb 2012 01:25:10 -0800 (PST) Received: by 10.152.21.133 with HTTP; Thu, 2 Feb 2012 01:25:10 -0800 (PST) Date: Thu, 2 Feb 2012 18:25:10 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Clarification request on draft-ietf-oauth-v2-23#section-10.10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 09:25:12 -0000 hi. The rev. 23 has a normative change in section 10.10 as: 10.10. Credentials Guessing Attacks [...] Generated tokens and other credentials not intended for handling by end-users MUST be constructed from a cryptographically strong random or pseudo-random number sequence ([RFC1750]) generated by the authorization server. Does this normative requirement only allows pseudo-random number sequence described as in Section 6.3 of RFC1750? Or does it allow something that includes it? I gather that it is the later, but the wording "constructed from" sounds a little vague. It also states: The probability of any two values being identical MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160). It is "the probability that a randomly generated guessed value being identical to the authoritatively generated token or credential value", I suppose. -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From igor.faynberg@alcatel-lucent.com Thu Feb 2 16:37:05 2012 Return-Path: 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 CF53211E8072 for ; Thu, 2 Feb 2012 16:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.884 X-Spam-Level: X-Spam-Status: No, score=-8.884 tagged_above=-999 required=5 tests=[AWL=1.714, 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 uW5DiKt2yHfW for ; Thu, 2 Feb 2012 16:37:05 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D53B611E8071 for ; Thu, 2 Feb 2012 16:37:04 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q130b11E024937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 Feb 2012 18:37:02 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q130b10w017637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 2 Feb 2012 18:37:01 -0600 Received: from [135.244.18.27] (faynberg.lra.lucent.com [135.244.18.27]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q130b1f9029739; Thu, 2 Feb 2012 18:37:01 -0600 (CST) Message-ID: <4F2B2C2C.3010505@alcatel-lucent.com> Date: Thu, 02 Feb 2012 19:37:00 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070600050404010209000400" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [OAUTH-WG] Clarification request on draft-ietf-oauth-v2-23#section-10.10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 00:37:06 -0000 This is a multi-part message in MIME format. --------------070600050404010209000400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nat, Your note made me think (as always), so maybe some text clarification is indeed in order. I have a slightly different understanding of the items you brought up. RFC 1750 is Informational, and I thought (maybe mistakenly?) that it cannot be used as a norm in a MUST clause. Therefore, I assumed that the clause prescribes the use of /cryptographically-strong/ pseudo-random generators but stopped short of listing them. The second item, I read as defining the strength, giving the necessary and desired bounds for a collision probability of two generated values. Igor On 2/2/2012 4:25 AM, Nat Sakimura wrote: > hi. > > The rev. 23 has a normative change in section 10.10 as: > > 10.10. Credentials Guessing Attacks > [...] > Generated tokens and other credentials not intended for handling by > end-users MUST be constructed from a cryptographically strong random > or pseudo-random number sequence ([RFC1750]) generated by the > authorization server. > > Does this normative requirement only allows pseudo-random number > sequence described as in Section 6.3 of RFC1750? > Or does it allow something that includes it? I gather that it is the later, > but the wording "constructed from" sounds a little vague. > > It also states: > > The probability of any two values being > identical MUST be less than or equal to 2^(-128) and SHOULD be less > than or equal to 2^(-160). > > It is "the probability that a randomly generated guessed value being > identical to > the authoritatively generated token or credential value", I suppose. > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------070600050404010209000400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nat,

Your note made me think (as always), so maybe some text clarification is indeed in order.

I have a slightly different understanding of the items you brought up.  RFC 1750 is Informational, and I thought (maybe mistakenly?) that it cannot be used as a norm in a MUST clause.  Therefore, I assumed that the clause prescribes the use of cryptographically-strong pseudo-random generators but stopped short of listing them.

The second item, I read as defining the strength, giving the necessary and desired bounds for a collision probability of two generated values.

Igor


On 2/2/2012 4:25 AM, Nat Sakimura wrote: 
hi.

The rev. 23 has a normative change in section 10.10 as:

10.10.  Credentials Guessing Attacks
  [...]
 Generated tokens and other credentials not intended for handling by
   end-users MUST be constructed from a cryptographically strong random
   or pseudo-random number sequence ([RFC1750]) generated by the
   authorization server.

Does this normative requirement only allows pseudo-random number
sequence described as in Section 6.3 of RFC1750?
Or does it allow something that includes it? I gather that it is the later,
but the wording "constructed from" sounds a little vague.

It also states:

 The probability of any two values being
   identical MUST be less than or equal to 2^(-128) and SHOULD be less
   than or equal to 2^(-160).

It is "the probability that a randomly generated guessed value being
identical to
the authoritatively generated token or credential value", I suppose.

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------070600050404010209000400-- From alexey.melnikov@isode.com Fri Feb 3 05:14:21 2012 Return-Path: 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 46D5A21F8625; Fri, 3 Feb 2012 05:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1wLe8FBT9DWy; Fri, 3 Feb 2012 05:14:20 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E70E21F856D; Fri, 3 Feb 2012 05:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1328274857; d=isode.com; s=selector; i=@isode.com; bh=p040+9qOAPW1BYfPD5JvCq4sWOPy7yNFjhEkpCArW6Q=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Jhds+fq1zgVGtDOykvZX7ojd9Hz51G15ZXla6PpoaXs456uWdvdo/OTl77qxMOrZs/9toH hgo90Dzu26awl06pNURGGIR6C9/wBf1FqRoSGLwSZva5O97JqsEsHTXBpjEYnFe+5FY6zL +izWzbQRGOcjxPG5h1xJy+tsM+jxuTg=; Received: from [144.254.105.99] (dhcp-guest-bru-peg1-144-254-105-99.cisco.com [144.254.105.99]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 3 Feb 2012 13:14:17 +0000 Message-ID: <4F2BDDB1.8030709@isode.com> Date: Fri, 03 Feb 2012 13:14:25 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 To: Mike Jones , Stephen Farrell References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F27C37C.1090008@isode.com> In-Reply-To: <4F27C37C.1090008@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: General Area Review Team , "oauth@ietf.org" , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , IETF-Discussion Discussion Subject: Re: [OAUTH-WG] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 13:14:21 -0000 On 31/01/2012 10:33, Alexey Melnikov wrote: > On 30/01/2012 05:20, Mike Jones wrote: [...] >> About your third minor issue on RFC 6125 versus RFC 2818, you'll find >> that, per the history entries, a previous reference to RFC 2818 was >> changed to RFC 6125 in draft 14 at the request of Security Area >> Director Stephen Farrell. I've quickly chatted with Stephen and he said that he only asked the question and didn't necessarily instructed the WG to do the change from RFC 2818 to RFC 6125. Keeping this in mind... >> If you'd like to see this reference reintroduced, I'd request that >> you work with Stephen on specific alternative proposed wording that >> is acceptable to both of you. > Ok, I can work with Stephen and Peter Saint-Andre (RFC 6125 > co-author) on some text. So, here are the proposed changes: 4.2. Threat Mitigation To protect against token disclosure, confidentiality protection MUST be applied using TLS [RFC5246] with a ciphersuite that provides confidentiality and integrity protection. This requires that the communication interaction between the client and the authorization server, as well as the interaction between the client and the resource server, utilize confidentiality and integrity protection. Since TLS is mandatory to implement and to use with this specification, it is the preferred approach for preventing token disclosure via the communication channel. For those cases where the client is prevented from observing the contents of the token, token encryption MUST be applied in addition to the usage of TLS protection. As a further defense against token disclosure, the client MUST validate the TLS certificate chain when making requests to protected resources. I suggest inserting "[RFC5280]" at the end of the last sentence above. To deal with token capture and replay, the following recommendations are made: First, the lifetime of the token MUST be limited; one means of achieving this is by putting a validity time field inside the protected part of the token. Note that using short-lived (one hour or less) tokens reduces the impact of them being leaked. Second, confidentiality protection of the exchanges between the client and the authorization server and between the client and the resource server MUST be applied. As a consequence, no eavesdropper along the communication path is able to observe the token exchange. Consequently, such an on-path adversary cannot replay the token. Furthermore, when presenting the token to a resource server, the client MUST verify the identity of that resource server, as per Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) [RFC6125]. Please replace the last sentence quoted above with: Furthermore, when presenting the token to a resource server, the client MUST verify the identity of that resource server, as per section 3.1 of [RFC2818]. [Expanded motivation for the change: I think the reference to RFC 6125 needs to be replaced with the reference to section 3.1 of RFC 2818. Firstly, the procedure described in RFC 6125 differs slightly from RFC 2818 (matching of IP addresses is allowed, wildcards can be used with partial hostnames (e.g. foo* is allowed, where RFC 6125 doesn't allow for that). Secondly, if RFC 6125 is referenced, then the OAuth document needs to say whether SRV-ID/URI-IDs are allowed and whether wildcards are allowed.] From stephen.farrell@cs.tcd.ie Fri Feb 3 05:17:54 2012 Return-Path: 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 53A7721F856A; Fri, 3 Feb 2012 05:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 hE7aKXORzqe0; Fri, 3 Feb 2012 05:17:53 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A12D21F8559; Fri, 3 Feb 2012 05:17:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DD507171C25; Fri, 3 Feb 2012 13:17:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1328275071; bh=rCgo3aUfHyU0P3 j7PcJYxpIPsDcKFJXdpbM26as6Ppw=; b=YJIRE6iyfjwsolXos24jUKGEwv6qRf mVO2dOuqU/1OXTPfZviMP1OxLA7bxFdJLzfLOqh7qKmjawKuSSZfHcwPZABidHnh 6RYTi88X0vHVflGodBqSdZndrK+o2EtAbjGuuV7QNzoS0RwxTuLX8ADFo0/3Ns4B EhMbXl7w3/WamgqGdjH9NqiBxEXPVRniemdh2l3WUv7DztunB23bHp2JPFBBLFZh YajHxpspA5oxVvigPinKf6vqgBlEBCEapMOnNhHzzFUNa/a9pRWtVRzu8AMSeHX5 ffg5kMJhwf6A/QRgMZ+T33J9z/MVfZUMGu14BwerXhH/6/wP85N/QgcQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 6BKpEOxwmkm1; Fri, 3 Feb 2012 13:17:51 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C3537171C06; Fri, 3 Feb 2012 13:17:50 +0000 (GMT) Message-ID: <4F2BDE75.4080405@cs.tcd.ie> Date: Fri, 03 Feb 2012 13:17:41 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F27C37C.1090008@isode.com> <4F2BDDB1.8030709@isode.com> In-Reply-To: <4F2BDDB1.8030709@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF-Discussion Discussion , General Area Review Team , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 13:17:54 -0000 That looks fine to me fwiw, Thanks, S. On 02/03/2012 01:14 PM, Alexey Melnikov wrote: > On 31/01/2012 10:33, Alexey Melnikov wrote: >> On 30/01/2012 05:20, Mike Jones wrote: > [...] >>> About your third minor issue on RFC 6125 versus RFC 2818, you'll find >>> that, per the history entries, a previous reference to RFC 2818 was >>> changed to RFC 6125 in draft 14 at the request of Security Area >>> Director Stephen Farrell. > I've quickly chatted with Stephen and he said that he only asked the > question and didn't necessarily instructed the WG to do the change from > RFC 2818 to RFC 6125. Keeping this in mind... >>> If you'd like to see this reference reintroduced, I'd request that >>> you work with Stephen on specific alternative proposed wording that >>> is acceptable to both of you. >> Ok, I can work with Stephen and Peter Saint-Andre (RFC 6125 co-author) >> on some text. > > So, here are the proposed changes: > > 4.2. Threat Mitigation > > To protect against token disclosure, confidentiality protection MUST > be applied using TLS [RFC5246] with a ciphersuite that provides > confidentiality and integrity protection. This requires that the > communication interaction between the client and the authorization > server, as well as the interaction between the client and the > resource server, utilize confidentiality and integrity protection. > Since TLS is mandatory to implement and to use with this > specification, it is the preferred approach for preventing token > disclosure via the communication channel. For those cases where the > client is prevented from observing the contents of the token, token > encryption MUST be applied in addition to the usage of TLS > protection. As a further defense against token disclosure, the > client MUST validate the TLS certificate chain when making requests > to protected resources. > > I suggest inserting "[RFC5280]" at the end of the last sentence above. > > To deal with token capture and replay, the following recommendations > are made: First, the lifetime of the token MUST be limited; one means > of achieving this is by putting a validity time field inside the > protected part of the token. Note that using short-lived (one hour > or less) tokens reduces the impact of them being leaked. Second, > confidentiality protection of the exchanges between the client and > the authorization server and between the client and the resource > server MUST be applied. As a consequence, no eavesdropper along the > communication path is able to observe the token exchange. > Consequently, such an on-path adversary cannot replay the token. > Furthermore, when presenting the token to a resource server, the > client MUST verify the identity of that resource server, as per > Representation and Verification of Domain-Based Application Service > Identity within Internet Public Key Infrastructure Using X.509 (PKIX) > Certificates in the Context of Transport Layer Security (TLS) > [RFC6125]. > > Please replace the last sentence quoted above with: > > Furthermore, when presenting the token to a resource server, the > client MUST verify the identity of that resource server, as per > section 3.1 of [RFC2818]. > > [Expanded motivation for the change: > I think the reference to RFC 6125 needs to be replaced with the > reference to section 3.1 of RFC 2818. Firstly, the procedure described > in RFC 6125 differs slightly from RFC 2818 (matching of IP addresses is > allowed, wildcards can be used with partial hostnames (e.g. foo* is > allowed, where RFC 6125 doesn't allow for that). Secondly, if RFC 6125 > is referenced, then the OAuth document needs to say whether > SRV-ID/URI-IDs are allowed and whether wildcards are allowed.] > > From aanganes@mitre.org Fri Feb 3 06:24:25 2012 Return-Path: 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 85F3521F84F8 for ; Fri, 3 Feb 2012 06:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 paFo8Ebf8Qbc for ; Fri, 3 Feb 2012 06:24:24 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3782E21F84E2 for ; Fri, 3 Feb 2012 06:24:24 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 86B2A21B040D for ; Fri, 3 Feb 2012 09:24:23 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 70F3D21B03E2 for ; Fri, 3 Feb 2012 09:24:23 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.153]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Fri, 3 Feb 2012 09:24:23 -0500 From: "Anganes, Amanda L" To: "oauth@ietf.org" Thread-Topic: OAuth 2 flow diagrams Thread-Index: Aczif4PCcrk7k9BXRael3a751ffYQA== Date: Fri, 3 Feb 2012 14:24:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.56] Content-Type: multipart/alternative; boundary="_000_B61A05DAABADEA4EA2F19424825286FA181D05DFIMCMBX04MITREOR_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth 2 flow diagrams X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 14:24:25 -0000 --_000_B61A05DAABADEA4EA2F19424825286FA181D05DFIMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I've developed a set of flow diagrams for the OAuth 2.0 spec, with separate= diagrams for the Access Code, Implicit Grant, Resource Owner Password Cred= entials, and the Client Credentials flows. These were inspired by the diagr= ams for 1.0 and 1.0a that Idan Gazit posted in http://www.ietf.org/mail-arc= hive/web/oauth/current/msg00696.html, which Justin Richer pointed me to whe= n I first started trying to read and understand the OAuth2.0 spec. I find t= hese types of diagrams to be incredibly useful, so I updated them again to = (hopefully) reflect the 2.0 spec. I'd appreciate any comments/corrections. If anyone finds the diagrams to be= useful, please feel free to rehost or reference them. https://github.com/jricher/OpenID-Connect-Java-Spring-Server/blob/master/do= cs/OAuth2.0_Diagrams.pdf?raw=3Dtrue Thanks, Amanda Anganes Info Sys Engineer, G061 The MITRE Corporation 782-271-3103 aanganes@mitre.org --_000_B61A05DAABADEA4EA2F19424825286FA181D05DFIMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I’ve developed a set of flow diagrams for the = OAuth 2.0 spec, with separate diagrams for the Access Code, Implicit Grant,= Resource Owner Password Credentials, and the Client Credentials flows. The= se were inspired by the diagrams for 1.0 and 1.0a that Idan Gazit posted in http://www.ietf.org/mail-archive/web/oauth/current/msg00696.html, which= Justin Richer pointed me to when I first started trying to read and unders= tand the OAuth2.0 spec. I find these types of diagrams to be incredibly use= ful, so I updated them again to (hopefully) reflect the 2.0 spec.  

 

I’d appreciate any comments/corrections. If an= yone finds the diagrams to be useful, please feel free to rehost or referen= ce them.

 

http= s://github.com/jricher/OpenID-Connect-Java-Spring-Server/blob/master/docs/O= Auth2.0_Diagrams.pdf?raw=3Dtrue

 

Thanks,

 

Amanda Anganes=

Info Sys Engineer, G06= 1

The MITRE Corporation<= o:p>

782-271-3103

aanganes@mitre.org

 

--_000_B61A05DAABADEA4EA2F19424825286FA181D05DFIMCMBX04MITREOR_-- From hardjono@mit.edu Fri Feb 3 10:26:56 2012 Return-Path: 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 AFDEE21F85AA for ; Fri, 3 Feb 2012 10:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 QjDLHVeH2PmK for ; Fri, 3 Feb 2012 10:26:56 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 06C3021F84EF for ; Fri, 3 Feb 2012 10:26:55 -0800 (PST) X-AuditID: 1209190f-b7f8a6d000000914-47-4f2c26efacd4 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F1.A7.02324.FE62C2F4; Fri, 3 Feb 2012 13:26:55 -0500 (EST) Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q13IQt4q003800 for ; Fri, 3 Feb 2012 13:26:55 -0500 Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (OC11EXEDGE3.EXCHANGE.MIT.EDU [18.9.3.21]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id q13IQsBW028065 for ; Fri, 3 Feb 2012 13:26:55 -0500 Received: from W92EXHUB12.exchange.mit.edu (18.7.73.21) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Feb 2012 13:26:46 -0500 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.214]) by W92EXHUB12.exchange.mit.edu ([18.7.73.21]) with mapi id 14.01.0355.002; Fri, 3 Feb 2012 13:26:54 -0500 From: Thomas Hardjono To: "oauth (oauth@ietf.org)" Thread-Topic: New Version Notification for draft-hardjono-oauth-umacore-03.txt Thread-Index: AQHM4qDJWlkr+1nhdU2O4wNEekVy05YrfVeQ Date: Fri, 3 Feb 2012 18:26:53 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A085820@OC11EXPO24.exchange.mit.edu> References: <20120203182227.11892.21900.idtracker@ietfa.amsl.com> In-Reply-To: <20120203182227.11892.21900.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.111.70.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDKsWRmVeSWpSXmKPExsUixCmqrPteTcffYMoJCYuTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEro/H1W7aCL9wVz/ZtZWlgPMPdxcjJISFgItG86g0LhC0mceHe erYuRi4OIYF9jBJPzi6Bcq4wShz6spEFwnnJKLHs4RqwFiGBbYwS13YkQSRWMUr83XiDCSTB JqAhce73XnYQW0RAV2L1p14wW1jAV+LRtitQ8QCJrxNfsUDYRhKbOleDxVkEVCTuzVzLCGLz AtXc/NgPFOcAWuAo8WtTHkiYU8BJ4sW6RWDljEBnfz+1Bmwts4C4xK0n85kg3hGUWDR7DzPM a/92PWQDGSMhoCDx6pMKiMksoCmxfpc+RKeixJTuh+wQSwUlTs58wjKBUWIWkqGzEDpmIemY haRjASPLKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0TvdzMEr3UlNJNjOBIk+TfwfjtoNIhRgEO RiUe3gNHtfyFWBPLiitzDzFKcjApifIaA+NUiC8pP6UyI7E4I76oNCe1+BCjBAezkghv6itt fyHelMTKqtSifJiUNAeLkjivmtY7PyGB9MSS1OzU1ILUIpisDAeHkgSvG8hQwaLU9NSKtMyc EoQ0EwcnyHAeoOH2IDW8xQWJucWZ6RD5U4yKUuK8riAJAZBERmkeXC8sEb5iFAd6RZjXCKSK B5hE4bpfAQ1mAhrMYKEJMrgkESEl1cDIXi/JJ5vQIdN/Kdu0+sSLYOv3gu5xi2e3uVeL/8h6 X75UOq9HavKWiXIrZF/ei6t9Y6bRWR50NDE/2HnHLLHtRldb0s/xea58waG563u6+5cjeRwp Ew8Gram1e9p7Ojumfv6n8ob1p89bCDxmXVFe4Kt4YCXb1OnJUf+UMqcXRZ7Jflu/jlGJpTgj 0VCLuag4EQAVuAPlXwMAAA== Subject: [OAUTH-WG] FW: New Version Notification for draft-hardjono-oauth-umacore-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 18:26:56 -0000 DQpGWUkuIFVwZGF0ZWQgdmVyc2lvbiBvZiBVTUEgQ29yZSBkcmFmdC4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAwMywgMjAxMiAxOjIyIFBNDQpU bzogVGhvbWFzIEhhcmRqb25vDQpDYzogVGhvbWFzIEhhcmRqb25vDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhcmRqb25vLW9hdXRoLXVtYWNvcmUtMDMudHh0 DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1oYXJkam9uby1vYXV0aC11bWFjb3JlLTAz LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRob21hcyBIYXJkam9ubyBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtaGFy ZGpvbm8tb2F1dGgtdW1hY29yZQ0KUmV2aXNpb246CSAwMw0KVGl0bGU6CQkgVXNlci1NYW5hZ2Vk IEFjY2VzcyAoVU1BKSBDb3JlIFByb3RvY29sDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wMi0wMw0K V0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDQ1DQoNCkFi c3RyYWN0Og0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgdGhlIFVzZXItTWFuYWdlZCBB Y2Nlc3MgKFVNQSkgY29yZQ0KICAgcHJvdG9jb2wuICBUaGlzIHByb3RvY29sIHByb3ZpZGVzIGEg bWV0aG9kIGZvciB1c2VycyB0byBjb250cm9sDQogICBhY2Nlc3MgdG8gdGhlaXIgcHJvdGVjdGVk IHJlc291cmNlcywgcmVzaWRpbmcgb24gYW55IG51bWJlciBvZiBob3N0DQogICBzaXRlcywgdGhy b3VnaCBhbiBhdXRob3JpemF0aW9uIG1hbmFnZXIgdGhhdCBnb3Zlcm5zIGFjY2VzcyBkZWNpc2lv bnMNCiAgIGJhc2VkIG9uIHVzZXIgcG9saWN5Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From sakimura@gmail.com Sun Feb 5 19:57:09 2012 Return-Path: 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 515A121F853A for ; Sun, 5 Feb 2012 19:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] 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 zIg09KVGt8z1 for ; Sun, 5 Feb 2012 19:57:08 -0800 (PST) Received: from mail-lpp01m020-f172.google.com (mail-lpp01m020-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3432021F84F5 for ; Sun, 5 Feb 2012 19:57:08 -0800 (PST) Received: by lbbgk8 with SMTP id gk8so1065368lbb.31 for ; Sun, 05 Feb 2012 19:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wAJEdiG/xVicr/bluGpGpDHMMj36LPK6FG/ivdfl3L4=; b=R0ICN8iK8/YfZZZB0vk49f9DmVh90OwE2uSuWZIeK/xV1IH/06GGd7dVy3En9FplZ8 FwSxr0VU7e6wLnqDY2SN/ojAJLXRlT2hIM2B9qRJ5gGJ1K7A4udWHArcHGX9WqI0zLAT uznY4cR/2X6ti+wbASZ7AWi9Za+ZhrmZvuQK8= MIME-Version: 1.0 Received: by 10.112.44.101 with SMTP id d5mr4233351lbm.40.1328500627139; Sun, 05 Feb 2012 19:57:07 -0800 (PST) Received: by 10.152.21.133 with HTTP; Sun, 5 Feb 2012 19:57:07 -0800 (PST) In-Reply-To: <4F2B2C2C.3010505@alcatel-lucent.com> References: <4F2B2C2C.3010505@alcatel-lucent.com> Date: Mon, 6 Feb 2012 12:57:07 +0900 Message-ID: From: Nat Sakimura To: igor.faynberg@alcatel-lucent.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Clarification request on draft-ietf-oauth-v2-23#section-10.10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 03:57:09 -0000 Igor, Yes. Since it is a normative "MUST" text, it should be crystal clear. For the second item, personally, I believe that it actually should depend on the risk profile that the application is exposed to. It could be such that there are other controls in place, so that it does not have to be addressed via entropy requirement of the token. It is especially true for a scenario where limited capability entities are interacting with a very confined and controlled environment. The current requirement may inhibit the use of OAuth 2.0 in such an environment. We probably should put some text that gives flexibility in that respect, such as " or put in place the controls that achieves equivalent risk mitigation." etc. =3Dnat On Fri, Feb 3, 2012 at 9:37 AM, Igor Faynberg wrote: > Nat, > > Your note made me think (as always), so maybe some text clarification is > indeed in order. > > I have a slightly different understanding of the items you brought up.=A0= RFC > 1750 is Informational, and I thought (maybe mistakenly?) that it cannot b= e > used as a norm in a MUST clause.=A0 Therefore, I assumed that the clause > prescribes the use of cryptographically-strong pseudo-random generators b= ut > stopped short of listing them. > > The second item, I read as defining the strength, giving the necessary an= d > desired bounds for a collision probability of two generated values. > > Igor > > > > On 2/2/2012 4:25 AM, Nat Sakimura wrote: > > hi. > > The rev. 23 has a normative change in section 10.10 as: > > 10.10. Credentials Guessing Attacks > [...] > Generated tokens and other credentials not intended for handling by > end-users MUST be constructed from a cryptographically strong random > or pseudo-random number sequence ([RFC1750]) generated by the > authorization server. > > Does this normative requirement only allows pseudo-random number > sequence described as in Section 6.3 of RFC1750? > Or does it allow something that includes it? I gather that it is the late= r, > but the wording "constructed from" sounds a little vague. > > It also states: > > The probability of any two values being > identical MUST be less than or equal to 2^(-128) and SHOULD be less > than or equal to 2^(-160). > > It is "the probability that a randomly generated guessed value being > identical to > the authoritatively generated token or credential value", I suppose. > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From eran@hueniverse.com Mon Feb 6 11:35:55 2012 Return-Path: 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 6113421F8735 for ; Mon, 6 Feb 2012 11:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 JLJ2gSmOAD63 for ; Mon, 6 Feb 2012 11:35:53 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id D2B2821F85F9 for ; Mon, 6 Feb 2012 11:35:53 -0800 (PST) Received: (qmail 7447 invoked from network); 6 Feb 2012 19:35:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Feb 2012 19:35:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Mon, 6 Feb 2012 12:35:48 -0700 From: Eran Hammer To: OAuth WG Date: Mon, 6 Feb 2012 12:35:45 -0700 Thread-Topic: Mail regarding draft-ietf-oauth-v2 Thread-Index: AczlBhrNH+526buyRFqZQkNBmvushgAAGBhw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AADDD18C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6B9B0CEF7F409D439E78288D8665BD8FAEAC63@oakmont.llu.ad.lluahsc.org> In-Reply-To: <6B9B0CEF7F409D439E78288D8665BD8FAEAC63@oakmont.llu.ad.lluahsc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD18CP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "Thomas, Christopher \(LLU\)" Subject: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 19:35:55 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD18CP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sending to the right place. From: Thomas, Christopher (LLU) [mailto:cwthomas@llu.edu] Sent: Monday, February 06, 2012 11:33 AM To: draft-ietf-oauth-v2@tools.ietf.org Subject: Mail regarding draft-ietf-oauth-v2 Hello, I'm looking into implementing the Oauth2 spec for a work project and I thin= k I ran into an issue with the version 23 documentation. According to the O= auth2 documentation, a client can send it's credentials one of two ways: 1)= via HTTP Basic Auth 2) via the request body parameters. Section 2.3.1 says= "....the HTTP Basic authentication scheme as defined in [RFC2617] to authe= nticate with the authorization server. The client identifier is used as th= e username, and the client password is used as the password." The example given in Section 2.3.1 is: Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW According to RFC2617 Section 2, the value of the credential is a base64 rep= resentation of "username:password" (no quotes). This means when the value i= s decoded, it is "s6BhdRkqt3:gX1fBat3bV". So, according to the HTTP Basic A= uth example, the client_id is s6BhdRkqt3 and the client_secret is gX1fBat3b= V. Just below the basic auth example is the request body example: POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded;charset=3DUTF-8 grant_type=3Drefresh_token&refresh_token=3DtGzv3JOkF0XG5Qx2TlKWIA &client_id=3Ds6BhdRkqt3&client_secret=3D7Fjfp0ZBr1KtDRbnfVdmIw In the request body example, the client_secret does not match the client_se= cret in the HTTP Basic Auth example. I think the two should match for consi= stency. I propose the change that is in the patch attached to this email. Thank you for considering my suggestion. Chris Christopher Thomas, BA - Systems Analyst LOMA LINDA UNIVERSITY | Information Systems Loma Linda University, Loma Linda, California 92350 x87866 or (909) 558-7866 --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD18CP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sending t= o the right place.

&n= bsp;

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Thomas, = Christopher (LLU) [mailto:cwthomas@llu.edu]
Sent: Monday, Februa= ry 06, 2012 11:33 AM
To: draft-ietf-oauth-v2@tools.ietf.org
Subject: Mail regarding draft-ietf-oauth-v2

 

Hello,

 

= I’m= looking into implementing the Oauth2 spec for a work project and I think I= ran into an issue with the version 23 documentation. According to the Oaut= h2 documentation, a client can send it’s credentials one of two ways:= 1) via HTTP Basic Auth 2) via the request body parameters. Section 2.3.1 s= ays “….the HTTP Basic authentication scheme as defined in [RFC2= 617] to authenticate with the authorization server.  The client identi= fier is used as the username, and the client password is    =        used as the password.”=

 

The ex= ample given in Section 2.3.1 is:

&nb= sp;

Authorization: Basic czZCaGRSa3F0MzpnWDFmQm= F0M2JW

 

According to RFC2617 Section 2, the value of the credential is a base6= 4 representation of “username:password” (no quotes). This means= when the value is decoded, it is “s6BhdRkqt3:gX1fBat3bV”. So, = according to the HTTP Basic Auth example, the client_id is s6BhdRkqt3 and t= he client_secret is gX1fBat3bV. Just below the basic auth example is the re= quest body example:

 

POST /token HTTP/1.1

&= nbsp;    Host: server.example.com

     Content-Type: application/x-www-form-urlenc= oded;charset=3DUTF-8

 

     grant_type=3Drefresh_token&= ;refresh_token=3DtGzv3JOkF0XG5Qx2TlKWIA

&n= bsp;    &client_id=3Ds6BhdRkqt3&client_secret=3D7Fjf= p0ZBr1KtDRbnfVdmIw

 

 

In the request bod= y example, the client_secret does not match the client_secret in the HTTP B= asic Auth example. I think the two should match for consistency. I propose = the change that is in the patch attached to this email.

 

Thank you for consid= ering my suggestion.

 

 

Chris

 

 =

Christopher Thomas, BA — Systems Analyst
LOM= A LINDA UNIVERSITY | Information Systems

Loma Linda University, Loma Linda, California 92= 350
x87866 or (909) 558-7866

<= o:p> 

= --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD18CP3PW5EX1MB01E_-- From jricher@mitre.org Mon Feb 6 11:50:29 2012 Return-Path: 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 5E0B821F863B for ; Mon, 6 Feb 2012 11:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 JhiCND0akROO for ; Mon, 6 Feb 2012 11:50:28 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E220D21F862D for ; Mon, 6 Feb 2012 11:50:25 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5B6DE21B1057; Mon, 6 Feb 2012 14:50:23 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3C5D821B0BFE; Mon, 6 Feb 2012 14:50:23 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 6 Feb 2012 14:50:22 -0500 Message-ID: <4F302EB0.9070305@mitre.org> Date: Mon, 6 Feb 2012 14:49:04 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Eran Hammer References: <6B9B0CEF7F409D439E78288D8665BD8FAEAC63@oakmont.llu.ad.lluahsc.org> <90C41DD21FB7C64BB94121FBBC2E723453AADDD18C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AADDD18C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------010505050109060506010007" X-Originating-IP: [129.83.31.51] Cc: OAuth WG , "Thomas, Christopher \(LLU\)" Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 19:50:29 -0000 --------------010505050109060506010007 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit +1 for consistent examples. -- Justin On 02/06/2012 02:35 PM, Eran Hammer wrote: > > Sending to the right place. > > *From:*Thomas, Christopher (LLU) [mailto:cwthomas@llu.edu] > *Sent:* Monday, February 06, 2012 11:33 AM > *To:* draft-ietf-oauth-v2@tools.ietf.org > *Subject:* Mail regarding draft-ietf-oauth-v2 > > Hello, > > I'm looking into implementing the Oauth2 spec for a work project and I > think I ran into an issue with the version 23 documentation. According > to the Oauth2 documentation, a client can send it's credentials one of > two ways: 1) via HTTP Basic Auth 2) via the request body parameters. > Section 2.3.1 says "....the HTTP Basic authentication scheme as > defined in [RFC2617] to authenticate with the authorization server. > The client identifier is used as the username, and the client password > is used as the password." > > The example given in Section 2.3.1 is: > > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > > According to RFC2617 Section 2, the value of the credential is a > base64 representation of "username:password" (no quotes). This means > when the value is decoded, it is "s6BhdRkqt3:gX1fBat3bV". So, > according to the HTTP Basic Auth example, the client_id is s6BhdRkqt3 > and the client_secret is gX1fBat3bV. Just below the basic auth example > is the request body example: > > POST /token HTTP/1.1 > > Host: server.example.com > > Content-Type: application/x-www-form-urlencoded;charset=UTF-8 > > grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA > > &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw > > In the request body example, the client_secret does not match the > client_secret in the HTTP Basic Auth example. I think the two should > match for consistency. I propose the change that is in the patch > attached to this email. > > Thank you for considering my suggestion. > > Chris > > Christopher Thomas, BA --- Systems Analyst/ > /LOMA LINDA UNIVERSITY | Information Systems > > Loma Linda University, Loma Linda, California 92350 > x87866 or (909) 558-7866 > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010505050109060506010007 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit +1 for consistent examples.

 -- Justin

On 02/06/2012 02:35 PM, Eran Hammer wrote:

Sending to the right place.

 

From: Thomas, Christopher (LLU) [mailto:cwthomas@llu.edu]
Sent: Monday, February 06, 2012 11:33 AM
To: draft-ietf-oauth-v2@tools.ietf.org
Subject: Mail regarding draft-ietf-oauth-v2

 

Hello,

 

I’m looking into implementing the Oauth2 spec for a work project and I think I ran into an issue with the version 23 documentation. According to the Oauth2 documentation, a client can send it’s credentials one of two ways: 1) via HTTP Basic Auth 2) via the request body parameters. Section 2.3.1 says “….the HTTP Basic authentication scheme as defined in [RFC2617] to authenticate with the authorization server.  The client identifier is used as the username, and the client password is           used as the password.”

 

The example given in Section 2.3.1 is:

 

Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

 

According to RFC2617 Section 2, the value of the credential is a base64 representation of “username:password” (no quotes). This means when the value is decoded, it is “s6BhdRkqt3:gX1fBat3bV”. So, according to the HTTP Basic Auth example, the client_id is s6BhdRkqt3 and the client_secret is gX1fBat3bV. Just below the basic auth example is the request body example:

 

POST /token HTTP/1.1

     Host: server.example.com

     Content-Type: application/x-www-form-urlencoded;charset=UTF-8

 

     grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

     &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

 

 

In the request body example, the client_secret does not match the client_secret in the HTTP Basic Auth example. I think the two should match for consistency. I propose the change that is in the patch attached to this email.

 

Thank you for considering my suggestion.

 

 

Chris

 

 

Christopher Thomas, BA — Systems Analyst
LOMA LINDA UNIVERSITY | Information Systems

Loma Linda University, Loma Linda, California 92350
x87866 or (909) 558-7866

 



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------010505050109060506010007-- From torsten@lodderstedt.net Mon Feb 6 12:07:11 2012 Return-Path: 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 2643F21F8739 for ; Mon, 6 Feb 2012 12:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 vmedaoCDXzsj for ; Mon, 6 Feb 2012 12:07:10 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by ietfa.amsl.com (Postfix) with ESMTP id EDE6A21F873E for ; Mon, 6 Feb 2012 12:07:09 -0800 (PST) Received: from [91.2.94.245] (helo=[192.168.71.36]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1RuUqC-0004ka-3j; Mon, 06 Feb 2012 21:07:08 +0100 Message-ID: <4F3032E9.8050109@lodderstedt.net> Date: Mon, 06 Feb 2012 21:07:05 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Nat Sakimura References: <4F2B2C2C.3010505@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Clarification request on draft-ietf-oauth-v2-23#section-10.10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 20:07:11 -0000 Hi Nat, > ... > We probably should put some text that gives flexibility > in that respect, such as " or put in place the controls that achieves > equivalent risk mitigation." etc. One could add this text to nearly any of the guidelines given in Section 10. But how do you assess the equivalence of the respective control? The intention of the security considerations section was to give clear guidance even for implementors unfamiliar with security and threat analysis. We therefore gave simple guidelines without much explanation of the rationale. I think this will work for most implementations. Implementors confronted with circumstances which do not allow them to adhere to the security considerations should create an appropriate security design based on the threat model and security considerations document. regards, Torsten. > =nat > > On Fri, Feb 3, 2012 at 9:37 AM, Igor Faynberg > wrote: >> Nat, >> >> Your note made me think (as always), so maybe some text clarification is >> indeed in order. >> >> I have a slightly different understanding of the items you brought up. RFC >> 1750 is Informational, and I thought (maybe mistakenly?) that it cannot be >> used as a norm in a MUST clause. Therefore, I assumed that the clause >> prescribes the use of cryptographically-strong pseudo-random generators but >> stopped short of listing them. >> >> The second item, I read as defining the strength, giving the necessary and >> desired bounds for a collision probability of two generated values. >> >> Igor >> >> >> >> On 2/2/2012 4:25 AM, Nat Sakimura wrote: >> >> hi. >> >> The rev. 23 has a normative change in section 10.10 as: >> >> 10.10. Credentials Guessing Attacks >> [...] >> Generated tokens and other credentials not intended for handling by >> end-users MUST be constructed from a cryptographically strong random >> or pseudo-random number sequence ([RFC1750]) generated by the >> authorization server. >> >> Does this normative requirement only allows pseudo-random number >> sequence described as in Section 6.3 of RFC1750? >> Or does it allow something that includes it? I gather that it is the later, >> but the wording "constructed from" sounds a little vague. >> >> It also states: >> >> The probability of any two values being >> identical MUST be less than or equal to 2^(-128) and SHOULD be less >> than or equal to 2^(-160). >> >> It is "the probability that a randomly generated guessed value being >> identical to >> the authoritatively generated token or credential value", I suppose. >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > From sakimura@gmail.com Mon Feb 6 16:58:35 2012 Return-Path: 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 DDF4311E80CB for ; Mon, 6 Feb 2012 16:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 igKI6fU4iGED for ; Mon, 6 Feb 2012 16:58:35 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 289EA11E80B5 for ; Mon, 6 Feb 2012 16:58:31 -0800 (PST) Received: by lahl5 with SMTP id l5so4203357lah.31 for ; Mon, 06 Feb 2012 16:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yThjaG0gTV4Di9Rm+XHRQA5CWi+RhetL1OKe29qWT3c=; b=tx2m597uzuMgkdzz0BEOJJdylplJYvsWHZAmsMEmsNFVkFopbGlkF8DmDW+7tCd1VT QDRXg0Kg1GLL31yDmeHe/gSWw/hdVcJL06+D+jPd2ETkZbjhjRlOVk+uM3Y8HdG+nVMv AO92Q8YU4Xow/LGtJNPN+oN5jtvo3iqe1yeLg= MIME-Version: 1.0 Received: by 10.112.44.101 with SMTP id d5mr5510373lbm.40.1328576311168; Mon, 06 Feb 2012 16:58:31 -0800 (PST) Received: by 10.152.21.133 with HTTP; Mon, 6 Feb 2012 16:58:31 -0800 (PST) In-Reply-To: <4F3032E9.8050109@lodderstedt.net> References: <4F2B2C2C.3010505@alcatel-lucent.com> <4F3032E9.8050109@lodderstedt.net> Date: Tue, 7 Feb 2012 09:58:31 +0900 Message-ID: From: Nat Sakimura To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Clarification request on draft-ietf-oauth-v2-23#section-10.10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 00:58:36 -0000 Hi Torsten, If it were a guideline, it should not have a normative text in it. Even if it did, it MUST NOT have a "MUST" in the sentence. But since it has those normative text, I gather that it is normative. If it were only "SHOULD" or "RECOMMENDED", I would have less problem. (Though counting only on the entropy is not so good, IMHO.) So, I would like to see the "MUST" removed at the very least. Regards, =3Dnat On Tue, Feb 7, 2012 at 5:07 AM, Torsten Lodderstedt wrote: > Hi Nat, > >> ... >> >> We probably should put some text that gives flexibility >> in that respect, such as " or put in place the controls that achieves >> equivalent risk mitigation." etc. > > > One could add this text to nearly any of the guidelines given in Section = 10. > But how do you assess the equivalence of the respective control? > > The intention of the security considerations section was to give clear > guidance even for implementors unfamiliar with security and threat analys= is. > We therefore gave simple guidelines without much explanation of the > rationale. I think this will work for most implementations. Implementors > confronted with circumstances which do not allow them to adhere to the > security considerations should create an appropriate security design base= d > on the threat model and security considerations document. > > regards, > Torsten. > > >> =3Dnat >> >> On Fri, Feb 3, 2012 at 9:37 AM, Igor Faynberg >> =A0wrote: >>> >>> Nat, >>> >>> Your note made me think (as always), so maybe some text clarification i= s >>> indeed in order. >>> >>> I have a slightly different understanding of the items you brought up. >>> =A0RFC >>> 1750 is Informational, and I thought (maybe mistakenly?) that it cannot >>> be >>> used as a norm in a MUST clause. =A0Therefore, I assumed that the claus= e >>> prescribes the use of cryptographically-strong pseudo-random generators >>> but >>> stopped short of listing them. >>> >>> The second item, I read as defining the strength, giving the necessary >>> and >>> desired bounds for a collision probability of two generated values. >>> >>> Igor >>> >>> >>> >>> On 2/2/2012 4:25 AM, Nat Sakimura wrote: >>> >>> hi. >>> >>> The rev. 23 has a normative change in section 10.10 as: >>> >>> 10.10. =A0Credentials Guessing Attacks >>> =A0 [...] >>> =A0Generated tokens and other credentials not intended for handling by >>> =A0 =A0end-users MUST be constructed from a cryptographically strong ra= ndom >>> =A0 =A0or pseudo-random number sequence ([RFC1750]) generated by the >>> =A0 =A0authorization server. >>> >>> Does this normative requirement only allows pseudo-random number >>> sequence described as in Section 6.3 of RFC1750? >>> Or does it allow something that includes it? I gather that it is the >>> later, >>> but the wording "constructed from" sounds a little vague. >>> >>> It also states: >>> >>> =A0The probability of any two values being >>> =A0 =A0identical MUST be less than or equal to 2^(-128) and SHOULD be l= ess >>> =A0 =A0than or equal to 2^(-160). >>> >>> It is "the probability that a randomly generated guessed value being >>> identical to >>> the authoritatively generated token or credential value", I suppose. >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From sakimura@gmail.com Mon Feb 6 17:01:45 2012 Return-Path: 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 4765A11E80B5 for ; Mon, 6 Feb 2012 17:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] 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 mOGpQ8ILV11M for ; Mon, 6 Feb 2012 17:01:44 -0800 (PST) Received: from mail-lpp01m020-f172.google.com (mail-lpp01m020-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F23D11E8085 for ; Mon, 6 Feb 2012 17:01:43 -0800 (PST) Received: by lbbgk8 with SMTP id gk8so1538156lbb.31 for ; Mon, 06 Feb 2012 17:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2qP1jDuNhHjkOX1yjuMmXa+sXedAzJNZ/HtZhCgUwhw=; b=al11jnV81cq3xSneky1bw/yTpYEL0OASHSGGmHA6rLGSlueW4JsEPGoTvBG5Q8QaFX A4LRIAqkJYMCQLo36Nz8h9mEMRkpPBOTgqNBJQhac/WH8sTRW/Bdvg5DgLb2KffOZ+m+ ZjUctQzfKO7Pl6sInE4NPfrAvFcItm6B2Fh1o= MIME-Version: 1.0 Received: by 10.112.48.193 with SMTP id o1mr5713581lbn.1.1328576503078; Mon, 06 Feb 2012 17:01:43 -0800 (PST) Received: by 10.152.21.133 with HTTP; Mon, 6 Feb 2012 17:01:43 -0800 (PST) In-Reply-To: <4F302EB0.9070305@mitre.org> References: <6B9B0CEF7F409D439E78288D8665BD8FAEAC63@oakmont.llu.ad.lluahsc.org> <90C41DD21FB7C64BB94121FBBC2E723453AADDD18C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F302EB0.9070305@mitre.org> Date: Tue, 7 Feb 2012 10:01:43 +0900 Message-ID: From: Nat Sakimura To: Justin Richer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG , "Thomas, Christopher \(LLU\)" Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 01:01:45 -0000 Should somebody just forward this to ietf@ietf.org mailing list so that it will be taken as the response to the last call? =3Dnat On Tue, Feb 7, 2012 at 4:49 AM, Justin Richer wrote: > +1 for consistent examples. > > =A0-- Justin > > > On 02/06/2012 02:35 PM, Eran Hammer wrote: > > Sending to the right place. > > > > From: Thomas, Christopher (LLU) [mailto:cwthomas@llu.edu] > Sent: Monday, February 06, 2012 11:33 AM > To: draft-ietf-oauth-v2@tools.ietf.org > Subject: Mail regarding draft-ietf-oauth-v2 > > > > Hello, > > > > I=92m looking into implementing the Oauth2 spec for a work project and I = think > I ran into an issue with the version 23 documentation. According to the > Oauth2 documentation, a client can send it=92s credentials one of two way= s: 1) > via HTTP Basic Auth 2) via the request body parameters. Section 2.3.1 say= s > =93=85.the HTTP Basic authentication scheme as defined in [RFC2617] to > authenticate with the authorization server.=A0 The client identifier is u= sed > as the username, and the client password is =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0used as the password.=94 > > > > The example given in Section 2.3.1 is: > > > > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > > > > According to RFC2617 Section 2, the value of the credential is a base64 > representation of =93username:password=94 (no quotes). This means when th= e value > is decoded, it is =93s6BhdRkqt3:gX1fBat3bV=94. So, according to the HTTP = Basic > Auth example, the client_id is s6BhdRkqt3 and the client_secret is > gX1fBat3bV. Just below the basic auth example is the request body example= : > > > > POST /token HTTP/1.1 > > =A0=A0=A0=A0 Host: server.example.com > > =A0=A0=A0=A0 Content-Type: application/x-www-form-urlencoded;charset=3DUT= F-8 > > > > =A0=A0=A0=A0 grant_type=3Drefresh_token&refresh_token=3DtGzv3JOkF0XG5Qx2T= lKWIA > > =A0=A0=A0=A0 &client_id=3Ds6BhdRkqt3&client_secret=3D7Fjfp0ZBr1KtDRbnfVdm= Iw > > > > > > In the request body example, the client_secret does not match the > client_secret in the HTTP Basic Auth example. I think the two should matc= h > for consistency. I propose the change that is in the patch attached to th= is > email. > > > > Thank you for considering my suggestion. > > > > > > Chris > > > > > > Christopher Thomas, BA =97=A0Systems Analyst > LOMA LINDA UNIVERSITY | Information Systems > > Loma Linda University, Loma Linda, California 92350 > x87866 or (909) 558-7866 > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From ve7jtb@ve7jtb.com Mon Feb 6 17:07:13 2012 Return-Path: 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 5B42C21F863C; Mon, 6 Feb 2012 17:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 VYgjZSNNlfvm; Mon, 6 Feb 2012 17:07:12 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99D2821F8636; Mon, 6 Feb 2012 17:07:12 -0800 (PST) Received: by yenm3 with SMTP id m3so3135403yen.31 for ; Mon, 06 Feb 2012 17:07:12 -0800 (PST) Received: by 10.236.182.2 with SMTP id n2mr28926322yhm.11.1328576832240; Mon, 06 Feb 2012 17:07:12 -0800 (PST) Received: from [192.168.1.213] ([190.22.43.24]) by mx.google.com with ESMTPS id k16sm39280147ani.5.2012.02.06.17.07.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Feb 2012 17:07:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_AA4301CA-C6FB-4ADE-A185-D4A8447AAF67"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB9682E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 6 Feb 2012 22:07:04 -0300 Message-Id: <7D4DB9C9-7194-42A0-A573-4243FE27E512@ve7jtb.com> References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> <4F1F3D84.1030300@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723453AAB9682E@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer X-Mailer: Apple Mail (2.1257) Cc: Julian Reschke , "oauth@ietf.org" , "ietf@ietf.org" , The IESG Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 01:07:13 -0000 --Apple-Mail=_AA4301CA-C6FB-4ADE-A185-D4A8447AAF67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii RE new text in Draft 23 http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-10.10 Generated tokens and other credentials not intended for handling by end-users MUST be constructed from a cryptographically strong random or pseudo-random number sequence ([RFC1750]) generated by the authorization server. Given that many implementations may elect to use signed tokens, such as = SAML or JWT (JOSE) this should not be a MUST. Giving people sensible defaults such as the probability of an attacker = guessing a valid access token for the protected resource should be less = than 2^(-128). The probability of generating hash colisions randomly is a odd metric, = 2^(-128) for a SHA256 as I recall. =20 Many factors play into what is secure, token lifetime etc. =20 I don't mind some reasonable defaults but adding a requirement for = unstructured tokens is a bit much. Regards John B. --Apple-Mail=_AA4301CA-C6FB-4ADE-A185-D4A8447AAF67 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MDcwMTA3MDVaMCMGCSqGSIb3DQEJBDEWBBQWK/uj8aETvEvLNway5KKCugBzKDCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQBWRTWqwRMsdSi0025K+czNfE1RtshaIMh+absgw4E/WxWc9A7AtOHjqD7or1XR9rfqYT2X9O1E i331Ps9yumoTgxJ6CfITjjBESR8nNYyT7LaBh1SHUmFuhGGBlBHfWRAWPwaMqQverGYDMUAbCsGl ATSijKTgntQGHSgrpmSiX6zRZP4RQVVaJWpJffKHIKtx307YS62YK3EHuGe8Eyiks/2qliXxe8un yNkIbQnCDDbnMZ8G0Yi7EE6YtHmA3oHOjstCIN1a458Qwght5ZZBxbpZnsZt6OqN7otShNb7ihPA V6aejiV3HlTCLm3MC7VaIYTbhmKr90t8CbmoOMWdAAAAAAAA --Apple-Mail=_AA4301CA-C6FB-4ADE-A185-D4A8447AAF67-- From aanganes@mitre.org Tue Feb 7 06:46:17 2012 Return-Path: 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 7FF7321F85C0 for ; Tue, 7 Feb 2012 06:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 CFCKNtrSDXek for ; Tue, 7 Feb 2012 06:46:15 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2A421F87EB for ; Tue, 7 Feb 2012 06:46:15 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3E33B21B12C4 for ; Tue, 7 Feb 2012 09:46:15 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2D36821B12C3 for ; Tue, 7 Feb 2012 09:46:15 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.153]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Tue, 7 Feb 2012 09:46:14 -0500 From: "Anganes, Amanda L" To: "oauth@ietf.org" Thread-Topic: OAuth 2 flow diagrams Thread-Index: Aczif4PCcrk7k9BXRael3a751ffYQADJuVhw Date: Tue, 7 Feb 2012 14:46:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.57] Content-Type: multipart/alternative; boundary="_000_B61A05DAABADEA4EA2F19424825286FA181D1050IMCMBX04MITREOR_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth 2 flow diagrams X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 14:46:17 -0000 --_000_B61A05DAABADEA4EA2F19424825286FA181D1050IMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello again, Based on some feedback I have received I have updated my diagrams. Changes = are listed below, and the link (https://github.com/jricher/OpenID-Connect-J= ava-Spring-Server/blob/master/docs/OAuth2.0_Diagrams.pdf?raw=3Dtrue) will a= lways point to the latest version. * Changed the title of the diagrams to "OAuth 2.0 Authorization" (from "OAu= th 2.0 Authentication", which was incorrect). * Removed refresh_token from the Access Token response on the Client Creden= tials flow. Ref: http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4.3 says "= A refresh token SHOULD NOT be included." * Changed "Consumer" to "Client" to better match the 2.0 terminology. Amanda Anganes Info Sys Engineer, G061 The MITRE Corporation 782-271-3103 aanganes@mitre.org From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= nganes, Amanda L Sent: Friday, February 03, 2012 9:24 AM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth 2 flow diagrams Hello, I've developed a set of flow diagrams for the OAuth 2.0 spec, with separate= diagrams for the Access Code, Implicit Grant, Resource Owner Password Cred= entials, and the Client Credentials flows. These were inspired by the diagr= ams for 1.0 and 1.0a that Idan Gazit posted in http://www.ietf.org/mail-arc= hive/web/oauth/current/msg00696.html, which Justin Richer pointed me to whe= n I first started trying to read and understand the OAuth2.0 spec. I find t= hese types of diagrams to be incredibly useful, so I updated them again to = (hopefully) reflect the 2.0 spec. I'd appreciate any comments/corrections. If anyone finds the diagrams to be= useful, please feel free to rehost or reference them. https://github.com/jricher/OpenID-Connect-Java-Spring-Server/blob/master/do= cs/OAuth2.0_Diagrams.pdf?raw=3Dtrue Thanks, Amanda Anganes Info Sys Engineer, G061 The MITRE Corporation 782-271-3103 aanganes@mitre.org --_000_B61A05DAABADEA4EA2F19424825286FA181D1050IMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello again,

 

Based on some feedback= I have received I have updated my diagrams. Changes are listed below, and = the link (https://gi= thub.com/jricher/OpenID-Connect-Java-Spring-Server/blob/master/docs/OAuth2.= 0_Diagrams.pdf?raw=3Dtrue) will always point to the latest version.

 

* Changed the title of= the diagrams to “OAuth 2.0 Authorization” (from “OAuth 2= .0 Authentication”, which was incorrect).

 

* Removed refresh_toke= n from the Access Token response on the Client Credentials flow.

Ref: http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4.3 says &q= uot;A refresh token SHOULD NOT be included."

 

* Changed "Consum= er" to "Client" to better match the 2.0 terminology.

 

Amanda Anganes=

Info Sys Engineer, G06= 1

The MITRE Corporation<= o:p>

782-271-3103

aanganes@mitre.org

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Anganes, Amanda L
Sent: Friday, February 03, 2012 9:24 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth 2 flow diagrams

 

Hello,

 

I’ve developed a se= t of flow diagrams for the OAuth 2.0 spec, with separate diagrams for the A= ccess Code, Implicit Grant, Resource Owner Password Credentials, and the Cl= ient Credentials flows. These were inspired by the diagrams for 1.0 and 1.0a that Idan Gazit posted in http://www.ietf.org/mail-archive/web/oauth/current/msg00696.html, which= Justin Richer pointed me to when I first started trying to read and unders= tand the OAuth2.0 spec. I find these types of diagrams to be incredibly use= ful, so I updated them again to (hopefully) reflect the 2.0 spec.  

 

I’d appreciate any = comments/corrections. If anyone finds the diagrams to be useful, please fee= l free to rehost or reference them.

 

https://github.com/jricher/OpenID-Connect-Java-Sprin= g-Server/blob/master/docs/OAuth2.0_Diagrams.pdf?raw=3Dtrue

 

Thanks,

 

Amanda Anganes

Info Sys Engineer, G061

The MITRE Corporation

782-271-3103

aanganes@mitre.org

 

--_000_B61A05DAABADEA4EA2F19424825286FA181D1050IMCMBX04MITREOR_-- From eran@hueniverse.com Tue Feb 7 10:05:22 2012 Return-Path: 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 7415621F8929 for ; Tue, 7 Feb 2012 10:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] 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 saKO-gaJ4hoY for ; Tue, 7 Feb 2012 10:05:21 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 3235E21F8928 for ; Tue, 7 Feb 2012 10:05:20 -0800 (PST) Received: (qmail 16165 invoked from network); 7 Feb 2012 18:05:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Feb 2012 18:05:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Tue, 7 Feb 2012 11:05:05 -0700 From: Eran Hammer To: OAuth WG Date: Tue, 7 Feb 2012 11:04:59 -0700 Thread-Topic: Appsdir review of draft-ietf-oauth-v2-23 Thread-Index: AczlvkX9Wm7N4OupT3CF98JH152i4AABLmug Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AADDD2D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 18:05:22 -0000 -----Original Message----- From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk]=20 Sent: Tuesday, February 07, 2012 9:31 AM To: apps-discuss@ietf.org; barryleiba@gmail.com; dick.hardt@gmail.com; dr@f= b.com; Eran Hammer; hannes.tschofenig@gmx.net; stephen.farrell@cs.tcd.ie Cc: iesg@ietf.org Subject: Appsdir review of draft-ietf-oauth-v2-23 I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/ar= ea/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-ietf-oauth-v2-23 Title: The OAuth 2.0 Authorization Protocol Reviewer: Henry S. Thompson Review Date: 2012-02-07 IETF Last Call Date: 2012-01-24 Summary: This draft is almost ready for publication as an Proposed Standard but has a few issues that should be fixed before publication [Note - My expertise is in the areas of markup and architecture, with only = the average geek's understanding of security and cryptographic technologies= . Any comments below on security issues are therefore of the nature of gen= eral audience concerns, rather than technical worries.] Major Issues:=20 3.1.2.1 The failure to require TLS here is worrying. At the very least I = would expect a requirement that clients which do _not_ require TLS MUST pro= vide significant user feedback calling attention to this -- by analogy, absence of a padlock does _not_ suffice. . . 2.1.2.5 In a somewhat parallel case, I would expect this section to at lea= st explain why the SHOULD NOT is not a MUST NOT. Since in practice the dist= inction between trusted and untrusted 3rd-party scripting is difficult if n= ot impossible to draw, as written the 2nd para is effectively overriden by = the third. 11 It seems at best old-fashioned that the designer of a new access token = type, parameter, endpoint response type or extension error has no better to= ol available than Google to help him/her discover whether the name they hav= e in mind is in use already. The same is true under the proposed approach = for any developer trying to determine what they can use or must support. I= s there some reason that mandated URI templates, after the fashion of http://www.iana.org/assignments/media-types/text/... are not mandated for the registries, e.g. http://www.iana.org/assignments/access-token-types/bearer ? If there is a good reason, please use it to at least explicitly acknowle= dge and justify the basis for failing to provide a way for users and develo= pers to use the "follow your nose" strategy [1]. If there is no good reaso= n, please include the appropriate language to require something along the l= ines suggested above. If you need a model, see [2]. Minor Issues: A short summary of the changes from OAuth 1.0/RFC5849 would have been helpf= ul, and it might still be a good idea to add one. . . 4.1 Would it be helpful to indicate that steps D&E may occur at any time a= fter C, and may be repeated subsequently? 11.1 It might be useful to have an 11.1.2, which repeats references to the= bearer and mac access token type registration drafts? Nits: Apostrophes are missing in a few places in the text ("end-user s", "OAuth s= "), presumably because a non-standard character encoding was used by one of= the editors. 9 The bulleted list after "When choosing between an external or embedded u= ser-agent, developers should consider:" contains several grammatical errors= , e.g. "External user-agents. . . It" and "Embedded user-agents educate end= -user" . . . ht [1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html [2] http://www.w3.org/2005/04/xpointer-schemes/ --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _al= ways_ has a .sig like this -- mail without it is forged spam] From ngarthl@gmail.com Tue Feb 7 11:02:14 2012 Return-Path: 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 3552C21F88D4 for ; Tue, 7 Feb 2012 11:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 3oWcpRUr29Cm for ; Tue, 7 Feb 2012 11:02:13 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8AA21F88DA for ; Tue, 7 Feb 2012 11:02:13 -0800 (PST) Received: by obbwd15 with SMTP id wd15so10550445obb.31 for ; Tue, 07 Feb 2012 11:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=yySng1C/HnE5l++N9YmwhFDBaipdMHV41jqI0GI68d0=; b=TUyVzU0ZAK1JShDID/cUw57PBsVM8xWGbOWFsW/fJ0kA8cb7SmrpuqJ14Os9UkjTJQ jdS9iFz9nOx+Dl9GE0lhOHT5bm7Yar62YgISr/JF/RsqCPx4pmjJ6P9pdvHTDYQopOHr ICJh06/z+D6DVTfVDk7z6ldwW/yZeexRjfr2I= MIME-Version: 1.0 Received: by 10.182.182.69 with SMTP id ec5mr7431302obc.48.1328641332968; Tue, 07 Feb 2012 11:02:12 -0800 (PST) Received: by 10.182.117.70 with HTTP; Tue, 7 Feb 2012 11:02:12 -0800 (PST) Date: Tue, 7 Feb 2012 20:02:12 +0100 Message-ID: From: Erlend Hamnaberg To: OAuth@ietf.org Content-Type: multipart/alternative; boundary=14dae939954faf7da604b8646a0a Subject: [OAUTH-WG] Implementing MAC bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 19:03:23 -0000 --14dae939954faf7da604b8646a0a Content-Type: text/plain; charset=ISO-8859-1 Hi guys and gals. I am trying to implement the MAC bearer within a client library. Searching the Archive I find that the current draft version of the MAC bearer is incorrect. For instance the body-hash is no longer supported. Is there a new draft planned soon? For implementers there would be great help in more examples. That way we can write test cases which conforms to the spec more easily. Best regards Erlend --14dae939954faf7da604b8646a0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi guys and gals.

I am trying to implement the MAC beare= r within a client library.

Searching the Archive I= find that the current draft version of the MAC bearer is incorrect.

For instance the body-hash is no longer supported. Is t= here a new draft planned soon?
For implementers there would be gr= eat help in more examples.=A0
That way we can write test cases wh= ich conforms to the spec more easily.

Best regards

Erlend
--14dae939954faf7da604b8646a0a-- From wmills@yahoo-inc.com Tue Feb 7 11:28:04 2012 Return-Path: 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 E7CD721F8864 for ; Tue, 7 Feb 2012 11:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.201 X-Spam-Level: X-Spam-Status: No, score=-17.201 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 cn2plGMJGOos for ; Tue, 7 Feb 2012 11:28:04 -0800 (PST) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) by ietfa.amsl.com (Postfix) with SMTP id C956B21F885F for ; Tue, 7 Feb 2012 11:28:03 -0800 (PST) Received: from [98.139.215.141] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 07 Feb 2012 19:27:57 -0000 Received: from [98.139.215.250] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 07 Feb 2012 19:27:57 -0000 Received: from [127.0.0.1] by omp1063.mail.bf1.yahoo.com with NNFMP; 07 Feb 2012 19:27:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 153268.82660.bm@omp1063.mail.bf1.yahoo.com Received: (qmail 51057 invoked by uid 60001); 7 Feb 2012 19:27:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1328642876; bh=dr53nTcKdRgbB5nXHQpFjlDJBgiz+pcMUjI+0uQlMPk=; 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=NRIIgkPNX2Y3ZsLnGIUjLRJhaxun3S1naHlizL5Y4B1Q/0xLfDvwT4LeX0ZUwEo/ZhAsXKjNSOj4XeIryXKXcegG1oA0LmKxo9A9EVOlmrndk4owfSoBICKC7Rov8X3VVMMVippHIcv3iYQR0CUtjP5t/KDGTp34EnaRaSX7IfY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; 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=ULhg0oxjx7NidMYFrpXPFz36f3Ai9Pb5yA378rFvCa/8vqYY0xj5Ld5ZLPXEijLstLusupgVF8S6d5x5hsHxaeRA4bObF8QjLbPjgubqqPTakT3Dg1EFOZ/I4IbAGqpnRlPQMIjAGHxNAGipd7E8CTrnXrMdFrjA28crd1iXww8=; X-YMail-OSG: F_mOH80VM1k36XGT8rw1GY1UErsJ1.0.KGp9pXBRlJb3d3i YsDE4qZfqP4Kp4aIqaF0q1h0HEbDlsIyqecoCic4VVyTPbBaORHHIJ8U.BgW gD0BkrN0n4bNGL74SmP4e_S10Yfuoi5WV7Yn7RRk2TGMJFd4bzTdjCaM5UZ. oxpY9wRMp0WtC4v8wmFaYioTDiXsyjwNglfpXAQSouMaJCiDLxxsVXt1zX81 gsDehSE0Digb8uPeO3CgxuY.uTe3jrQEJnscNIbbn89gGIHMy6WjL6KQWTb9 ap6rc_ZX_9qXfzQlkwTxE42LnLeTpmUE6VXlhUJM6rG4u5hp7.rIhowB1AlJ CBsZN7391xi.fHKMv9.OYA7ZV4RtUaIq_7ASsHvjGR_znqIt97_I6pwDprTp MliWuFFYSHsRflkWeGj0fQUTqxGpSVehSyoojKa1Su.AFWFkQ3jA- Received: from [209.131.62.115] by web31802.mail.mud.yahoo.com via HTTP; Tue, 07 Feb 2012 11:27:56 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340031 References: Message-ID: <1328642876.38180.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Tue, 7 Feb 2012 11:27:56 -0800 (PST) From: William Mills To: Erlend Hamnaberg , "OAuth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-694754553-1328642876=:38180" Subject: Re: [OAUTH-WG] Implementing MAC bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 19:28:05 -0000 ---1036955950-694754553-1328642876=:38180 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable You're asking about MAC tokens right?=A0 The term "bearer" on this list usu= ally refers to the Bearer Token draft style stuff.=A0=A0=0A=0A=0A=0A=0A____= ____________________________=0A From: Erlend Hamnaberg = =0ATo: OAuth@ietf.org =0ASent: Tuesday, February 7, 2012 11:02 AM=0ASubject= : [OAUTH-WG] Implementing MAC bearer=0A =0A=0AHi guys and gals.=0A=0AI am t= rying to implement the MAC bearer within a client library.=0A=0ASearching t= he Archive I find that the current draft version of the MAC bearer is incor= rect.=0A=0AFor instance the body-hash is no longer supported. Is there a ne= w draft planned soon?=0AFor implementers there would be great help in more = examples.=A0=0AThat way we can write test cases which conforms to the spec = more easily.=0A=0ABest regards=0A=0AErlend=0A______________________________= _________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.= org/mailman/listinfo/oauth ---1036955950-694754553-1328642876=:38180 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
You're asking about MAC tokens right?  The term "bearer" on this lis= t usually refers to the Bearer Token draft style stuff.  <= /div>



From: Er= lend Hamnaberg <ngarthl@gmail.com>
To: OAuth@ietf.org
Sent: Tuesday, February 7, 2012 11:02 AM
Subject: [OAUTH-WG] Implementing MAC be= arer

=0A
Hi guys and gals.

<= /div>
I am trying to implement the MAC bearer within a client library.<= /div>

Searching the Archive I find that the current draf= t version of the MAC bearer is incorrect.
=0A

For i= nstance the body-hash is no longer supported. Is there a new draft planned = soon?
For implementers there would be great help in more examples= . 
That way we can write test cases which conforms to the sp= ec more easily.
=0A

Best regards

Erlend
=0A

___________________________________________= ____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/li= stinfo/oauth


---1036955950-694754553-1328642876=:38180-- From crew@cs.stanford.edu Tue Feb 7 12:50:44 2012 Return-Path: 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 9DD7B11E8088 for ; Tue, 7 Feb 2012 12:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 p+eYm89zedew for ; Tue, 7 Feb 2012 12:50:44 -0800 (PST) Received: from mail.fyigm.com (mail.fyigm.com [69.17.114.80]) by ietfa.amsl.com (Postfix) with ESMTP id 96E0E21F86F8 for ; Tue, 7 Feb 2012 12:50:42 -0800 (PST) Received: from rfc by mail.fyigm.com with local (Exim 4.72) (envelope-from ) id 1Rus23-0000N8-Tz; Tue, 07 Feb 2012 12:52:56 -0800 From: Roger Crew MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20273.36647.811224.493136@hagen.valhalla> Date: Tue, 7 Feb 2012 12:52:55 -0800 To: Eran Hammer In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB964C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20160.24172.942808.563672@hagen.valhalla> <90C41DD21FB7C64BB94121FBBC2E723453AAB964C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: VM 8.1.0 under 23.2.1 (x86_64-pc-linux-gnu) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] error codes in 4.1.2.1 and 4.2.2.1 and extension response types (8.4) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 20:50:44 -0000 > > (2) [in 4.2.2.1] If the response_type is provided but unknown, > > is that an 'invalid_request' (since this is clearly an > > "unsupported parameter value") or is it an > > 'unsupported_response_type'? > > > > Seems to me it should be the latter. If so, then... > > ... > > should the description for 'invalid_request' even be referring to > > "unsupported" values at all? > > ... > > Section 5.2 has the same problem w.r.t. 'unsupported_grant_type' > > Changed the definition of invalid_request to: > > The request is missing a required parameter, includes an invalid > parameter value, or is otherwise malformed. Just noticed in draft 23 that you changed 4.2.2.1 but didn't change 5.2, which still refers to "unsupported" parameter values and thus similarly conflicts with the definition of 'unsupported_grant_type'. -- Roger Crew crew@cs.stanford.edu From jricher@mitre.org Tue Feb 7 13:20:25 2012 Return-Path: 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 6084621F87C3 for ; Tue, 7 Feb 2012 13:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dixolki-TObT for ; Tue, 7 Feb 2012 13:20:24 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3998E21F87B7 for ; Tue, 7 Feb 2012 13:20:10 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D111E21B13E1; Tue, 7 Feb 2012 16:20:09 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BDF4E21B13F6; Tue, 7 Feb 2012 16:20:08 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 7 Feb 2012 16:20:08 -0500 Message-ID: <4F319539.5070606@mitre.org> Date: Tue, 7 Feb 2012 16:18:49 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Eran Hammer References: <90C41DD21FB7C64BB94121FBBC2E723453AADDD2D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AADDD2D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: OAuth WG Subject: Re: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 21:20:25 -0000 Responses inline. Don't know if you want to forward these to the appropriate other lists/authors as well. On 02/07/2012 01:04 PM, Eran Hammer wrote: > > -----Original Message----- > From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] > Sent: Tuesday, February 07, 2012 9:31 AM > To: apps-discuss@ietf.org; barryleiba@gmail.com; dick.hardt@gmail.com; dr@fb.com; Eran Hammer; hannes.tschofenig@gmx.net; stephen.farrell@cs.tcd.ie > Cc: iesg@ietf.org > Subject: Appsdir review of draft-ietf-oauth-v2-23 > > I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. > > Document: draft-ietf-oauth-v2-23 > > Title: The OAuth 2.0 Authorization Protocol > > Reviewer: Henry S. Thompson > > Review Date: 2012-02-07 > > IETF Last Call Date: 2012-01-24 > > Summary: This draft is almost ready for publication as an Proposed > Standard but has a few issues that should be fixed > before publication > > [Note - My expertise is in the areas of markup and architecture, with only the average geek's understanding of security and cryptographic technologies. Any comments below on security issues are therefore of the nature of general audience concerns, rather than technical worries.] > > Major Issues: > > 3.1.2.1 The failure to require TLS here is worrying. At the very least I would expect a requirement that clients which do _not_ require TLS MUST provide significant user feedback calling attention to this > -- by analogy, absence of a padlock does _not_ suffice. . . There are two bits going on here, and I think there's confusion again about this being a *client* controlled endpoint. First, not all callback redirects are remote HTTP URLs. A http://localhost/ callback or an app:// callback are going to be very common with installed clients, and in both of these cases TLS makes no sense to require. Second, and this is the reason spelled out in the text, you can't really expect all *clients* to use proper TLS on their redirects. If it's a remote HTTP call, then it's likely a very Bad Idea to go over a plaintext socket, yes. But there are enough other cases where mandating it doesn't make sense. Suggestion: call out second non-HTTP use case here as well, perhaps stop calling it an "endpoint" to differentiate it from the server-side pieces. > 2.1.2.5 In a somewhat parallel case, I would expect this section to at least explain why the SHOULD NOT is not a MUST NOT. Since in practice the distinction between trusted and untrusted 3rd-party scripting is difficult if not impossible to draw, as written the 2nd para is effectively overriden by the third. Assuming this means 3.1.2.5 A MUST NOT is impossible to enforce here. You're telling people to not include jQuery in their JavaScript app. Truth is, any third party library that you include in your app could get access to the security bits whether it's on the callback page or not. I think it's appropriate to provide guidance for best practices here, and the MUST be first and SHOULD be only makes sense. People will get it wrong in spite of what the spec says here one way or another. Suggestion: drop the requirements (and move them to the security doc), or otherwise no change. > 11 It seems at best old-fashioned that the designer of a new access token type, parameter, endpoint response type or extension error has no better tool available than Google to help him/her discover whether the name they have in mind is in use already. The same is true under the proposed approach for any developer trying to determine what they can use or must support. Is there some reason that mandated URI templates, after the fashion of > > http://www.iana.org/assignments/media-types/text/... > > are not mandated for the registries, e.g. > > http://www.iana.org/assignments/access-token-types/bearer > > ? If there is a good reason, please use it to at least explicitly acknowledge and justify the basis for failing to provide a way for users and developers to use the "follow your nose" strategy [1]. If there is no good reason, please include the appropriate language to require something along the lines suggested above. If you need a model, see [2]. I'm confused - is this a request to use a full URI for all extension values? I thought the purpose of a registry was to deconflict the short names, and that URIs could be used for anything else. > Minor Issues: > > A short summary of the changes from OAuth 1.0/RFC5849 would have been helpful, and it might still be a good idea to add one. . . I don't think this is possible. OAuth2 is built fundamentally differently from OAuth1, so this paragraph might as well read "just about everything but the concept". Suggestion: don't add this, unless someone can come up with a succinct way to summarize the decision to build on a new foundation. > 4.1 Would it be helpful to indicate that steps D&E may occur at any time after C, and may be repeated subsequently? D&E may be delayed, but shouldn't be repeated. The Access Code is one-time-use, and in the best deployments will expire after a short period of time. Suggestion: leave as is. > 11.1 It might be useful to have an 11.1.2, which repeats references to the bearer and mac access token type registration drafts? Is this a request to pre-register the two "core" token types? I'm fine with that, if that's valid. I've long thought that the "core" document needs stronger pointers to the other two. Suggestion: add in the refs if it's editorially valid to do so. (Nits mentioned are valid formatting errors, should be fixed.) -- Justin From ngarthl@gmail.com Tue Feb 7 23:53:25 2012 Return-Path: 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 72E9021F864C for ; Tue, 7 Feb 2012 23:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 gVU1jqWtIAQk for ; Tue, 7 Feb 2012 23:53:24 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC4AB21F8613 for ; Tue, 7 Feb 2012 23:53:24 -0800 (PST) Received: by obbwd15 with SMTP id wd15so521544obb.31 for ; Tue, 07 Feb 2012 23:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VNb50MdqpvQPOV+l3NAZmiRukwWnWTJ47QzJQa4f2I8=; b=NIMoWybui1rXZBI8RRlIXAbCEyVckyeesUtxV8M+UXFXUEfd1l+tr/elTtutgNmmbP y/6ZNW7tTIdzXuHScfYQ0iOJjxlKBXHZEwN/OV+wCAHGv6gsqE5kqxdcdJ3VqzgMXaEi NaMQ+bPvM3vmKUsM+tFfYeVosOX4tlXzkxwWI= MIME-Version: 1.0 Received: by 10.182.182.69 with SMTP id ec5mr9674120obc.48.1328687604417; Tue, 07 Feb 2012 23:53:24 -0800 (PST) Received: by 10.182.117.70 with HTTP; Tue, 7 Feb 2012 23:53:24 -0800 (PST) In-Reply-To: <1328642876.38180.YahooMailNeo@web31802.mail.mud.yahoo.com> References: <1328642876.38180.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Wed, 8 Feb 2012 08:53:24 +0100 Message-ID: From: Erlend Hamnaberg To: William Mills Content-Type: multipart/alternative; boundary=14dae939954fadc2df04b86f30d7 Cc: "OAuth@ietf.org" Subject: Re: [OAUTH-WG] Implementing MAC bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 07:53:25 -0000 --14dae939954fadc2df04b86f30d7 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 7, 2012 at 8:27 PM, William Mills wrote: > You're asking about MAC tokens right? The term "bearer" on this list > usually refers to the Bearer Token draft style stuff. > > > > ------------------------------ > *From:* Erlend Hamnaberg > *To:* OAuth@ietf.org > *Sent:* Tuesday, February 7, 2012 11:02 AM > *Subject:* [OAUTH-WG] Implementing MAC bearer > > Hi guys and gals. > > I am trying to implement the MAC bearer within a client library. > > Searching the Archive I find that the current draft version of the MAC > bearer is incorrect. > > For instance the body-hash is no longer supported. Is there a new draft > planned soon? > For implementers there would be great help in more examples. > That way we can write test cases which conforms to the spec more easily. > > Best regards > > Erlend > Yes, of course. Sorry for the confusion. http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05 -- Erlend --14dae939954fadc2df04b86f30d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 7, 2012 at 8:27 PM, William Mil= ls <wmills@yah= oo-inc.com> wrote:
You're asking about MAC tokens right?=A0= The term "bearer" on this list usually refers to the Bearer Toke= n draft style stuff.=A0=A0



=
From: Erlend Hamnaberg <ngarthl@gmail.com>
To: OAuth@ietf.org
Sent: Tuesday, February 7, = 2012 11:02 AM
Subject: [= OAUTH-WG] Implementing MAC bearer

Hi guys and gals.

I am trying to implement the MAC = bearer within a client library.

Searching the Arch= ive I find that the current draft version of the MAC bearer is incorrect.

For instance the body-hash is no longer supported. Is t= here a new draft planned soon?
For implementers there would be gr= eat help in more examples.=A0
That way we can write test cases wh= ich conforms to the spec more easily.

Best regards

Erlend

Yes, of co= urse.

Sorry for the confusion.

=

--
Erlend=A0

--14dae939954fadc2df04b86f30d7-- From internet-drafts@ietf.org Wed Feb 8 09:52:10 2012 Return-Path: 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 C911A21F873D; Wed, 8 Feb 2012 09:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 suKp2k53bVXT; Wed, 8 Feb 2012 09:52:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190E321F8522; Wed, 8 Feb 2012 09:52:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120208175209.30915.17732.idtracker@ietfa.amsl.com> Date: Wed, 08 Feb 2012 09:52:09 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 17:52:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : HTTP Authentication: MAC Access Authentication Author(s) : Eran Hammer-Lahav Filename : draft-ietf-oauth-v2-http-mac-01.txt Pages : 20 Date : 2012-02-08 This document specifies the HTTP MAC access authentication scheme, an HTTP authentication method using a message authentication code (MAC) algorithm to provide cryptographic verification of portions of HTTP requests. The document also defines an OAuth 2.0 binding for use as an access-token type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-http-mac-01.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-http-mac-01.txt From eran@hueniverse.com Wed Feb 8 10:00:40 2012 Return-Path: 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 D1B5521F85B9 for ; Wed, 8 Feb 2012 10:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] 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 YDx2XuIyAwMK for ; Wed, 8 Feb 2012 10:00:39 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 6D4F221F859E for ; Wed, 8 Feb 2012 10:00:39 -0800 (PST) Received: (qmail 24432 invoked from network); 8 Feb 2012 17:55:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Feb 2012 17:55:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 8 Feb 2012 10:54:55 -0700 From: Eran Hammer To: "oauth@ietf.org" Date: Wed, 8 Feb 2012 10:54:40 -0700 Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt Thread-Index: Aczmin72I/oJpkoTSO+o8M4FxeCnXQAAACOQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AADDD3F6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20120208175209.30915.17732.idtracker@ietfa.amsl.com> In-Reply-To: <20120208175209.30915.17732.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:00:40 -0000 Main changes: Removed cookies support Removed body hash Clarified timestamp verification I still have more comments to process but wanted to get a new draft out fir= st as the current one expired. Please review the new timestamp prose and let me know what you think. I'm t= rying to allow the client to use any timestamp it can easily produce, and m= ove the verification logic to the server as much as possible. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Wednesday, February 08, 2012 9:52 AM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of > the IETF. >=20 > Title : HTTP Authentication: MAC Access Authentication > Author(s) : Eran Hammer-Lahav > Filename : draft-ietf-oauth-v2-http-mac-01.txt > Pages : 20 > Date : 2012-02-08 >=20 > This document specifies the HTTP MAC access authentication scheme, an > HTTP authentication method using a message authentication code (MAC) > algorithm to provide cryptographic verification of portions of HTTP > requests. The document also defines an OAuth 2.0 binding for use as > an access-token type. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-http-mac-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-http-mac-01.txt >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Wed Feb 8 10:41:08 2012 Return-Path: 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 BAA1121E800E for ; Wed, 8 Feb 2012 10:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.216 X-Spam-Level: X-Spam-Status: No, score=-17.216 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 PH5n5HKAgaxa for ; Wed, 8 Feb 2012 10:41:08 -0800 (PST) Received: from nm25.bullet.mail.ne1.yahoo.com (nm25.bullet.mail.ne1.yahoo.com [98.138.90.88]) by ietfa.amsl.com (Postfix) with SMTP id 9939621F85C4 for ; Wed, 8 Feb 2012 10:41:07 -0800 (PST) Received: from [98.138.90.50] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 08 Feb 2012 18:41:04 -0000 Received: from [98.138.89.173] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 08 Feb 2012 18:41:04 -0000 Received: from [127.0.0.1] by omp1029.mail.ne1.yahoo.com with NNFMP; 08 Feb 2012 18:41:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 334285.72312.bm@omp1029.mail.ne1.yahoo.com Received: (qmail 39895 invoked by uid 60001); 8 Feb 2012 18:41:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1328726463; bh=f33bu/xgSBIJIlDlo6i+Hl+N0rQ8FMUuuoF2BWWqgk0=; 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=GimwVQ9k3dqhAFOeb4gKMYNF99QZqz1TMW+plbgXbAdyx7IwJGvBoHdK+3kMsq6XlhWzoMAsAIfdlgu1f6tc38rOG2ZpbL4x+1mtevgKlmm3m43GdNtn7ct3Q3ryUs/eCsXRANLAjL/TjAqxDm3jpOYMDDbXCzv9LHSlv1H74ho= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; 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=J/izqmQBgds6n0pMgQp8dEFE5YqqKLiAMByRePKpZyticlgyX0HaTyEoiTKdB2j+11f2glg5siDxT0fn/8QAaATBFYU5L0y06KKwPK0eet+qERzhaUqOI1QVkFtFoZqfwzDfhkVIjAbLOrP1Kz/iDw+veobWVvGgVlGkml3vSIw=; X-YMail-OSG: LdMmzB4VM1kBxns.zdJlqin6ypoqWWY7Mmq847LZG36kvpq VcUtLPBdXMEoncHmRPrlw5.MntqqR91c1u75mCNPheGmddSYkReMnxjIW3o5 vKfvVHAOm1I0_MrABrNHu60vbuieuV.4ZcEUpAnZ1zHMpLdbp2NlvnODDuV4 ufGZMzosUPj5mQjqO1tJxEWrEr4TtLmJ3mrtWgI1QoKplggHa0hBMybF9sBj gKIY4jkKUyxm06WJTL_mVKmmb_tdazSIQGpGfxtXKVbSTf9ce2VipaMB4IHG 0tIHs4vuZ0XStQoR90JHuAMW8fRrZxHWssPyId3tFixkN1av.Dme4jDJvrS1 m0srrNYoeo880jyU9WY1ySJDJNBagocjX3UY9Q0slO1FkDtUSK8ZdBttTvJQ HRlpGKZ9NG2CG4TelIgdWdPA60FpAPjO8KIubnP4XMY0qvrcOIg-- Received: from [209.131.62.113] by web31809.mail.mud.yahoo.com via HTTP; Wed, 08 Feb 2012 10:41:03 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340031 References: <20120208175209.30915.17732.idtracker@ietfa.amsl.com> <90C41DD21FB7C64BB94121FBBC2E723453AADDD3F6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1328726463.99812.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Wed, 8 Feb 2012 10:41:03 -0800 (PST) From: William Mills To: Eran Hammer , "oauth@ietf.org" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AADDD3F6@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-161629053-1328726463=:99812" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:41:08 -0000 ---1395015409-161629053-1328726463=:99812 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Might be worthwhile to ask to have the previous draft marked as superceded = by this one.=0A=0A=0A=0A________________________________=0A From: Eran Hamm= er =0ATo: "oauth@ietf.org" =0ASent: W= ednesday, February 8, 2012 9:54 AM=0ASubject: Re: [OAUTH-WG] I-D Action: dr= aft-ietf-oauth-v2-http-mac-01.txt=0A =0AMain changes:=0A=0ARemoved cookies = support=0ARemoved body hash=0AClarified timestamp verification=0A=0AI still= have more comments to process but wanted to get a new draft out first as t= he current one expired.=0A=0APlease review the new timestamp prose and let = me know what you think. I'm trying to allow the client to use any timestamp= it can easily produce, and move the verification logic to the server as mu= ch as possible.=0A=0AEH=0A=0A> -----Original Message-----=0A> From: oauth-b= ounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=0A> Of internet-d= rafts@ietf.org=0A> Sent: Wednesday, February 08, 2012 9:52 AM=0A> To: i-d-a= nnounce@ietf.org=0A> Cc: oauth@ietf.org=0A> Subject: [OAUTH-WG] I-D Action:= draft-ietf-oauth-v2-http-mac-01.txt=0A> =0A> =0A> A New Internet-Draft is = available from the on-line Internet-Drafts directories.=0A> This draft is a= work item of the Web Authorization Protocol Working Group of=0A> the IETF.= =0A> =0A> =A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : HTTP Authentication: MAC Ac= cess Authentication=0A> =A0=A0=A0 Author(s)=A0 =A0 =A0 : Eran Hammer-Lahav= =0A> =A0=A0=A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-oauth-v2-http-mac-01.tx= t=0A> =A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0 : 20=0A> =A0=A0=A0 Date=A0 =A0 = =A0 =A0 =A0 =A0 : 2012-02-08=0A> =0A>=A0 =A0 This document specifies the HT= TP MAC access authentication scheme, an=0A>=A0 =A0 HTTP authentication meth= od using a message authentication code (MAC)=0A>=A0 =A0 algorithm to provid= e cryptographic verification of portions of HTTP=0A>=A0 =A0 requests.=A0 Th= e document also defines an OAuth 2.0 binding for use as=0A>=A0 =A0 an acces= s-token type.=0A> =0A> =0A> A URL for this Internet-Draft is:=0A> http://ww= w.ietf.org/internet-drafts/draft-ietf-oauth-v2-http-mac-01.txt=0A> =0A> Int= ernet-Drafts are also available by anonymous FTP at:=0A> ftp://ftp.ietf.org= /internet-drafts/=0A> =0A> This Internet-Draft can be retrieved at:=0A> ftp= ://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-http-mac-01.txt=0A> =0A= > _______________________________________________=0A> OAuth mailing list=0A= > OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth=0A________= _______________________________________=0AOAuth mailing list=0AOAuth@ietf.o= rg=0Ahttps://www.ietf.org/mailman/listinfo/oauth ---1395015409-161629053-1328726463=:99812 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Might be worthwhile to ask to have the previous draft marked as supercede= d by this one.

= From: Eran Hammer <era= n@hueniverse.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Sent: Wednesday, February 8, 2012 9:54 AM
Subject: Re: [OAUTH-WG] I-D Actio= n: draft-ietf-oauth-v2-http-mac-01.txt

=0AMain chang= es:

Removed cookies support
Removed body hash
Clarified timest= amp verification

I still have more comments to process but wanted to= get a new draft out first as the current one expired.

Please review= the new timestamp prose and let me know what you think. I'm trying to allo= w the client to use any timestamp it can easily produce, and move the verif= ication logic to the server as much as possible.

EH

> ----= -Original Message-----
> From: oauth-bounces@ietf.org [m= ailto:oauth-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.org
> Sent: Wednesday, February 08, 2012 = 9:52 AM
> To: i-d-announce@ietf.org
> Cc= : oauth= @ietf.org
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-h= ttp-mac-01.txt
>
>
> 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          = : HTTP Authentication: MAC Access Authentication
>    = ; Author(s)      : Eran Hammer-Lahav
>   &n= bsp; Filename        : draft-ietf-oauth-v2-http-mac-01.= txt
>     Pages          : 2= 0
>     Date            = : 2012-02-08
>
>    This document specifies the HTTP MAC access authentication scheme, an
>    HTTP authen= tication method using a message authentication code (MAC)
>  &nb= sp; algorithm to provide cryptographic verification of portions of HTTP
= >    requests.  The document also defines an OAuth 2.0 bi= nding for use as
>    an access-token type.
>
>= ;
> A URL for this Internet-Draft is:
> http://www.ietf.org/in= ternet-drafts/draft-ietf-oauth-v2-http-mac-01.txt
>
> Internet= -Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-= drafts/
>
> This Internet-Draft can be retrieved at:
&g= t; ftp://ftp.ietf.org/internet-drafts/draft-ietf-= oauth-v2-http-mac-01.txt
>
> _______________________________________________
> OAuth mailing list=
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth=
_______________________________________________
OAuth mailing listOAuth= @ietf.org
https://www.ietf.org/mailman/listinfo/oauth


=
---1395015409-161629053-1328726463=:99812-- From eran@hueniverse.com Wed Feb 8 14:59:45 2012 Return-Path: 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 399B311E807F for ; Wed, 8 Feb 2012 14:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 rwhTDbssIWRp for ; Wed, 8 Feb 2012 14:59:44 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id B1FA021F8510 for ; Wed, 8 Feb 2012 14:59:44 -0800 (PST) Received: (qmail 32528 invoked from network); 8 Feb 2012 22:59:43 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Feb 2012 22:59:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 8 Feb 2012 15:59:29 -0700 From: Eran Hammer To: Erlend Hamnaberg , "OAuth@ietf.org" Date: Wed, 8 Feb 2012 15:59:22 -0700 Thread-Topic: [OAUTH-WG] Implementing MAC bearer Thread-Index: AczlyyvZOVuWjvz3RDKFuWVC6N+YEAA6geDg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AADDD47B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD47BP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Implementing MAC bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 22:59:45 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD47BP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New draft: http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= rlend Hamnaberg Sent: Tuesday, February 07, 2012 11:02 AM To: OAuth@ietf.org Subject: [OAUTH-WG] Implementing MAC bearer Hi guys and gals. I am trying to implement the MAC bearer within a client library. Searching the Archive I find that the current draft version of the MAC bear= er is incorrect. For instance the body-hash is no longer supported. Is there a new draft pla= nned soon? For implementers there would be great help in more examples. That way we can write test cases which conforms to the spec more easily. Best regards Erlend --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD47BP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

New draft= :

 =

http://tools.ietf.org/html/draft-ietf-oauth-v2-http-ma= c-01

 

EH

 

 

From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Erlend Hamnaberg
= Sent: Tuesday, February 07, 2012 11:02 AM
To: OAuth@ietf.org<= br>Subject: [OAUTH-WG] Implementing MAC bearer

=

 

= Hi guys and gals.

 =

I am trying to implement the MAC bearer= within a client library.

 

Searching the Archive I f= ind that the current draft version of the MAC bearer is incorrect.

 

For instance the body-hash is no longer supported. Is there= a new draft planned soon?

Fo= r implementers there would be great help in more examples. =

That way we can write test cases which = conforms to the spec more easily.

 

Best regards=

 

<= p class=3DMsoNormal>Erlend

= --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD47BP3PW5EX1MB01E_-- From sakimura@gmail.com Wed Feb 8 17:23:27 2012 Return-Path: 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 83BA611E8087 for ; Wed, 8 Feb 2012 17:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, DEAR_SOMETHING=1.605, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 R7sXQQ8sVOuP for ; Wed, 8 Feb 2012 17:23:26 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1B8411E8075 for ; Wed, 8 Feb 2012 17:23:25 -0800 (PST) Received: by lahl5 with SMTP id l5so1226580lah.31 for ; Wed, 08 Feb 2012 17:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OxY0ZSDjukaYMD9+nyjxb6jQ4QQQPuz72KmSdmDjMto=; b=rePG6jc5SmEHaNDesBO3rzf28pCVNGja2HPmP4a/BsgwhRv6mXbmGOaXT5NUS+DYdK t1QhFgPYMUfUZ3nmJxYjQWMuhwW8oAZcGOCmK8OfiK05rKicIqCJN2IKU58P1dsQkkz6 TTCOi9uV6Vk3UT9uas7iV213fsvlwMuAcnMpU= MIME-Version: 1.0 Received: by 10.112.44.101 with SMTP id d5mr8522981lbm.40.1328750604820; Wed, 08 Feb 2012 17:23:24 -0800 (PST) Received: by 10.152.21.133 with HTTP; Wed, 8 Feb 2012 17:23:24 -0800 (PST) In-Reply-To: References: Date: Thu, 9 Feb 2012 10:23:24 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=bcaec554d52ccba41004b87ddb07 Subject: [OAUTH-WG] Fwd: Comments on Section 10.10 of OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 01:23:27 -0000 --bcaec554d52ccba41004b87ddb07 Content-Type: text/plain; charset=ISO-8859-1 Forgot to cc the oauth list on this, so here it goes! =nat ---------- Forwarded message ---------- From: Nat Sakimura Date: Tue, Feb 7, 2012 at 12:46 PM Subject: Comments on Section 10.10 of OAuth 2.0 To: ietf@ietf.org Dear Sir/Madam: Attached below, please find the comment in response to the Last Call: (The OAuth 2.0 Authorization Protocol) to Proposed Standard. These comments are on the changes between rev.22 and rev.23. Yours faithfully, Nat Sakimura =============================== Comment on Section 10.10 =============================== Title: "constructed from" vague ================================ Comment -------- The current text goes as: The authorization server MUST prevent attackers from guessing access tokens, authorization codes, refresh tokens, resource owner passwords, and client credentials. Generated tokens and other credentials not intended for handling by end-users MUST be constructed from a cryptographically strong random or pseudo-random number sequence ([RFC4086]) generated by the authorization server. (Note: 1750 was modifed to be 4086) It is unclear from this sentence if it only allows the sequence that is compliant to Section 6.2 of RFC4086. It is also unclear whether it could be a string that included such random string during the generation, or has to be the prn sequence. I believe the former is the case. Clarification is desired. Title: Only allowing the construction from PRN sequence too limiting ==================================================================== Comment ------- An alternative measure would be to use digital signatures. The current text seem to only allow PRN sequence. Other measures should be allowed as well. Title: Probability requirement needs refinement ================================================ Comment -------- The current text goes: The probability of any two values being identical MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160). This seems to be simply stating the randomness requirement. What we would like to do to control the credentials guessing attacks depends on the kind of token in question. Title: Last para 10.10 is normative yet undefined =================================================== Comment -------- It goes: The authorization server MUST utilize other means to protect credentials intended for end-user usage. Since it has a "MUST", it is a normative language. Yet it only requires "other means", which is undefined. It also excludes the possibility of using server generated PRN sequece as the user password. ======== Proposal ======== 10.10. Credentials Guessing Attacks The authorization server MUST prevent attackers from guessing access tokens, authorization codes, refresh tokens, resource owner passwords, and client credentials. The appropriate probability of the success of the attack during the lifetime of the tokens and credentials depends on the risk profile of the application in question. The application SHOULD set the policy requiring the probability of the success of the attack during the lifetime of each type of tokens and credentials and implementations MUST adhere to such policy. For the generated tokens and other credentials that are not intended for handling by end-users, one way to achieve it is to construct them including a cryptographically strong random or pseudo-random number sequence described in Section 6.2 of [RFC4086] generated by the authorization server. Typically, the probability of any two values being identical is set to be less than or equal to 2^(-128) and often considered desirable to be less than or equal to 2^(-160). Other possible control measures includes: - Progressive slow down and token revocation on the failed attempts - Pattern analysis of failed token and credential usage For the credentials intended for end-user usages, typical controls includes: - Progressive slow down and other mechanisms such as captcha on the failed attempts to thwart brute force - Pattern analysis of failed token and credential usage - Enforce the use of strong passwords (e.g., complex, non-dictionary strings that contain mixtures of upper case, lower case, numeric, and special characters) - Enforce the use of Multi-Factor authentication and other strong authentication mechanisms END -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --bcaec554d52ccba41004b87ddb07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Forgot to cc the oauth list on this, so here it goes!

= =3Dnat

---------- Forwarded message -----= -----
From: Nat Sakimura <sakimura@gmail.com>
Date: Tue, Feb 7, 2012 at 12:46 PM
Subject: Comments on Section 10.10 of= OAuth 2.0
To: ietf@ietf.org

Dear Sir/Madam:

Attached below, please find the comment in response to the
Last Call: <draft-ietf-oauth-v2-23.txt> (The OAuth 2.0 =A0Authorizati= on
Protocol) to Proposed Standard.

These comments are on the changes between rev.22 and rev.23.

Yours faithfully,

Nat Sakimura


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Comment on Section 10.10
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D


Title: "constructed from" vague
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

Comment
--------

The current text goes as:

=A0 =A0The authorization server MUST prevent attackers from guessing access=
=A0 =A0tokens, authorization codes, refresh tokens, resource owner
=A0 =A0passwords, and client credentials.

=A0 =A0Generated tokens and other credentials not intended for handling by<= br> =A0 =A0end-users MUST be constructed from a cryptographically strong random=
=A0 =A0or pseudo-random number sequence ([RFC4086]) generated by the
=A0 =A0authorization server.

=A0 =A0(Note: 1750 was modifed to be 4086)

It is unclear from this sentence if it only allows the sequence
that is compliant to Section 6.2 of RFC4086.
It is also unclear whether it could be a string that included
such random string during the generation, or has to be the
prn sequence. I believe the former is the case.
Clarification is desired.




Title: Only allowing the construction from PRN sequence too limiting
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Comment
-------
An alternative measure would be to use digital signatures.
The current text seem to only allow PRN sequence.
Other measures should be allowed as well.


Title: Probability requirement needs refinement
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Comment
--------
The current text goes:

=A0 =A0The probability of any two values being
=A0 =A0identical MUST be less than or equal to 2^(-128) and SHOULD be less<= br> =A0 =A0than or equal to 2^(-160).

This seems to be simply stating the randomness requirement.
What we would like to do to control the credentials guessing attacks
depends on the kind of token in question.


Title: Last para 10.10 is normative yet undefined
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Comment
--------
It goes:

=A0 =A0The authorization server MUST utilize other means to protect
=A0 =A0credentials intended for end-user usage.

Since it has a "MUST", it is a normative language.
Yet it only requires "other means", which is undefined.
It also excludes the possibility of using server generated
PRN sequece as the user password.


=3D=3D=3D=3D=3D=3D=3D=3D
Proposal
=3D=3D=3D=3D=3D=3D=3D=3D

10.10. =A0Credentials Guessing Attacks

=A0 =A0The authorization server MUST prevent attackers from guessing access=
=A0 =A0tokens, authorization codes, refresh tokens, resource owner
=A0 =A0passwords, and client credentials.

=A0 =A0The appropriate probability of the success of the attack
=A0 =A0during the lifetime of the tokens and credentials depends
=A0 =A0on the risk profile of the application in question.
=A0 =A0The application SHOULD set the policy requiring the probability
=A0 =A0of the success of the attack during the lifetime of each type
=A0 =A0of tokens and credentials and implementations MUST adhere to
=A0 =A0such policy.

=A0 =A0For the generated tokens and other credentials that are not
=A0 =A0intended for handling by end-users, one way to achieve it is
=A0 =A0to construct them including a cryptographically strong random
=A0 =A0or pseudo-random number sequence described in Section 6.2
=A0 =A0of [RFC4086] generated by the authorization server.
=A0 =A0Typically, the probability of any two values being
=A0 =A0identical is set to be less than or equal to 2^(-128) and
=A0 =A0often considered desirable to be less than or equal to 2^(-160).

=A0 =A0Other possible control measures includes:

=A0 =A0- Progressive slow down and token revocation on the failed attempts<= br> =A0 =A0- Pattern analysis of failed token and credential usage

=A0 =A0For the credentials intended for end-user usages,
=A0 =A0typical controls includes:

=A0 =A0- Progressive slow down and other mechanisms such as captcha
=A0 =A0 =A0on the failed attempts to thwart brute force
=A0 =A0- Pattern analysis of failed token and credential usage
=A0 =A0- Enforce the use of strong passwords (e.g., complex, non-dictionary=
=A0 =A0 =A0strings that contain mixtures of upper case, lower case,
=A0 =A0 =A0numeric, and special characters)
=A0 =A0- Enforce the use of Multi-Factor authentication and other
=A0 =A0 =A0strong authentication mechanisms


END



--
Nat Sakimura (=3Dnat)Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--bcaec554d52ccba41004b87ddb07-- From James.H.Manger@team.telstra.com Wed Feb 8 22:51:29 2012 Return-Path: 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 99AFB21F85C2 for ; Wed, 8 Feb 2012 22:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-2.048, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 99glduO-NuQ8 for ; Wed, 8 Feb 2012 22:51:27 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8B66321F8575 for ; Wed, 8 Feb 2012 22:51:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,388,1325422800"; d="scan'208";a="61668987" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 09 Feb 2012 17:51:10 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6614"; a="50311615" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcavi.tcif.telstra.com.au with ESMTP; 09 Feb 2012 17:51:10 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Thu, 9 Feb 2012 17:51:09 +1100 From: "Manger, James H" To: Eran Hammer , "oauth@ietf.org" Date: Thu, 9 Feb 2012 17:51:08 +1100 Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt Thread-Index: Aczmin72I/oJpkoTSO+o8M4FxeCnXQAAACOQABVWq0A= Message-ID: <255B9BB34FB7D647A506DC292726F6E114EBBDE0DD@WSMSG3153V.srv.dir.telstra.com> References: <20120208175209.30915.17732.idtracker@ietfa.amsl.com> <90C41DD21FB7C64BB94121FBBC2E723453AADDD3F6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AADDD3F6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 06:51:29 -0000 Eran, a couple of comments on the new MAC spec: The example (=A71.1) does not seem to be correct. That is, I calculate mac= =3D"6T3zZzy2Emppni6bzL7kdRxUWL4=3D" instead of the given value. The example in =A73.2.1 has a typo. It says "using timestamp "264095:7d8f3e= 4a"", but should say "using timestamp "264095"". Timestamp verification (=A74.1) is described as preventing replay attacks. = However, the 3 dot points that server MUST do only ensure that requests (o= ther than the first) are approximately fresh (assuming the first was fresh)= . Of course, it is fairly obvious that the service can keep a copy of {ts,n= once,id} tuples (while the ts is still approximately fresh) to detect repla= ys. When the ts field is defined (=A73.1) it is probably worth mentioning that = the fixed point in time (epoch) chosen to calculate ts MUST remain the same= for the lifetime of the key. That is, a client app cannot pick a new epoch= each time it starts if it is using the same key across restarts. Personally, I would almost prefer it to say: ts is seconds since 1970 were = possible; clients without a real-time clock can choose an arbitrary epoch, = but it must remain the same for the lifetime of the key; servers SHOULD NOT= assume client clocks are well synchronized to their own. It is RECOMMENDED= that a server assumes the 1st request with a given key is fresh, and use t= he ts value in that request to determine the offset between the client & se= rvers clocks. That offset (assumed to remain constant) can be used to deter= mine if subsequent requests are fresh. -- James Manger -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer Sent: Thursday, 9 February 2012 4:55 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt Main changes: Removed cookies support Removed body hash Clarified timestamp verification I still have more comments to process but wanted to get a new draft out fir= st as the current one expired. Please review the new timestamp prose and let me know what you think. I'm t= rying to allow the client to use any timestamp it can easily produce, and m= ove the verification logic to the server as much as possible. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Wednesday, February 08, 2012 9:52 AM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of > the IETF. >=20 > Title : HTTP Authentication: MAC Access Authentication > Author(s) : Eran Hammer-Lahav > Filename : draft-ietf-oauth-v2-http-mac-01.txt > Pages : 20 > Date : 2012-02-08 >=20 > This document specifies the HTTP MAC access authentication scheme, an > HTTP authentication method using a message authentication code (MAC) > algorithm to provide cryptographic verification of portions of HTTP > requests. The document also defines an OAuth 2.0 binding for use as > an access-token type. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-http-mac-01.txt From ngarthl@gmail.com Thu Feb 9 00:11:33 2012 Return-Path: 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 4FFF221F8592 for ; Thu, 9 Feb 2012 00:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.525 X-Spam-Level: X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 hrSgEldk+O3Y for ; Thu, 9 Feb 2012 00:11:31 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3F221F85AA for ; Thu, 9 Feb 2012 00:11:30 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2380488obb.31 for ; Thu, 09 Feb 2012 00:11:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uLp10g/KGFlt5xNXxRbefi7kh+Y08IL4odxM3sEYXLQ=; b=iof5Wb0CUKYsFfQunhNfoc94wbNnvf59WumWtKNa0zOvYckhDZlJ0MN37u4QSf5QXz aExH05vHn4Xn89gW+ywgPmMyPOVnrQLnXGtBMBAQzBZ9RmWxJMnwm+LNHeq1dnVI2it6 1flWcfz4rX0M8YYWfMAo+FjWfD3TeBS+epVBU= MIME-Version: 1.0 Received: by 10.182.2.135 with SMTP id 7mr650454obu.78.1328775090178; Thu, 09 Feb 2012 00:11:30 -0800 (PST) Received: by 10.182.117.70 with HTTP; Thu, 9 Feb 2012 00:11:30 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AADDD47B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453AADDD47B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 9 Feb 2012 09:11:30 +0100 Message-ID: From: Erlend Hamnaberg To: Eran Hammer Content-Type: multipart/alternative; boundary=f46d044519e33c8af904b8838f92 Cc: "OAuth@ietf.org" Subject: Re: [OAUTH-WG] Implementing MAC bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 08:11:33 -0000 --f46d044519e33c8af904b8838f92 Content-Type: text/plain; charset=ISO-8859-1 Great. Thanks. One question: Is it possible to use mac tokens in a non-OAuth setting? How would a UA get the MAC id and algorithm then? The old spec had a version where you could use Cookies to do this. Is there a reason why this couldn't work as with Digest authentication? -E On Wed, Feb 8, 2012 at 11:59 PM, Eran Hammer wrote: > New draft:**** > > ** ** > > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01**** > > ** ** > > EH**** > > ** ** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Erlend Hamnaberg > *Sent:* Tuesday, February 07, 2012 11:02 AM > *To:* OAuth@ietf.org > > *Subject:* [OAUTH-WG] Implementing MAC bearer**** > > ** ** > > Hi guys and gals.**** > > ** ** > > I am trying to implement the MAC bearer within a client library.**** > > ** ** > > Searching the Archive I find that the current draft version of the MAC > bearer is incorrect.**** > > ** ** > > For instance the body-hash is no longer supported. Is there a new draft > planned soon?**** > > For implementers there would be great help in more examples. **** > > That way we can write test cases which conforms to the spec more easily.** > ** > > ** ** > > Best regards**** > > ** ** > > Erlend**** > --f46d044519e33c8af904b8838f92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Great. Thanks.

One question:
=A0Is it possible= to use mac tokens in a non-OAuth setting?

How wou= ld a UA get the MAC id and algorithm then?

The old= spec had a version where you could use Cookies to do this.

Is there a reason why this couldn't work as with Di= gest authentication?

-E

On Wed, Feb 8, 2012 at 11:59 PM, Eran Hammer <eran@hueniverse.com>= wrote:

New draft:=

=A0<= /p>

http://tools.ietf.org/html/draft-ie= tf-oauth-v2-http-mac-01

=A0

EH

=A0

=A0<= /p>

From: oauth-bou= nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Erlend Hamnaber= g
Sent: Tuesday, February 07, 2012 11:02 AM
To: OAuth@ietf.org


Subject: [OAUTH-WG] Implementing MAC bearer

=A0

Hi guys and gals.

<= p class=3D"MsoNormal">=A0

I am trying to implement the MAC bearer within a client library.

=A0

Searching the Archive I find that the current draft version = of the MAC bearer is incorrect.

=A0

For instance the bod= y-hash is no longer supported. Is there a new draft planned soon?=

For implementers there would be g= reat help in more examples.=A0

That way we can write test cases which co= nforms to the spec more easily.

=A0

Best regards=

=A0

Erlend

=

--f46d044519e33c8af904b8838f92-- From wmills@yahoo-inc.com Thu Feb 9 02:46:50 2012 Return-Path: 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 0D81721F86AB for ; Thu, 9 Feb 2012 02:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.381 X-Spam-Level: X-Spam-Status: No, score=-17.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 SRPW8QfYOl64 for ; Thu, 9 Feb 2012 02:46:49 -0800 (PST) Received: from nm2.bullet.mail.ac4.yahoo.com (nm2.bullet.mail.ac4.yahoo.com [98.139.52.199]) by ietfa.amsl.com (Postfix) with SMTP id 3126E21F8699 for ; Thu, 9 Feb 2012 02:46:48 -0800 (PST) Received: from [98.139.52.196] by nm2.bullet.mail.ac4.yahoo.com with NNFMP; 09 Feb 2012 10:46:46 -0000 Received: from [98.139.52.136] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 09 Feb 2012 10:46:46 -0000 Received: from [127.0.0.1] by omp1019.mail.ac4.yahoo.com with NNFMP; 09 Feb 2012 10:46:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 991326.9016.bm@omp1019.mail.ac4.yahoo.com Received: (qmail 9206 invoked by uid 60001); 9 Feb 2012 10:46:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1328784405; bh=wlwVu3XiNj7s3gi6AGLahANqoCXp/pwq1hOg9XFALsY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NyyBKZ3sAlOceRH23jmG4xcyEitVPUW4dUWXgDndhEi4pPMFRDLQrFS3+4X5rzanzav0XOfGCvtC6Kgwe6sfixmIjserUCFfzKJhx8cXDpe0i0opj9pV+Wa7TDX81dh9ykb5ImCEYM8uN8pvwxw6ainRq6Q/qQFdmV3uToMuVI0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ULDDRItVqxZ0PUKebHayRNufwOmNzjpyHRJkYWXSZr5jzBbXMGy8AYtWzHzSrZNBQmpxKWNnjjtNkT7TsTHox+zmfoOvZatQQzXv/JlGkGwbiJFyIWrjhYabw1+jxmQ7Rs4LTVEO/Mk3I+t2K/TGVTtoF85w+767XR9DZNKQ12A=; X-YMail-OSG: oh6bg94VM1kD5hJt_P0hylwRik1jJ2_Dxskh.IeypM_k8eZ D7YisM3fgRnNRq68aZPbUCxBsSTBUrtRpuQINdfgM3tbcoWY_dKsMgZ9voeF 92dpuW3bXIYhuM0MzfiASmhpP4vcEi9cE7uewzaNUsXPmSQ_KXing6FBbhCU EeFWEe_2rZm3_mm_ooyrNj9ryd4xU78w_Y.TL3ckXTayhJOY5u7693_xBJ6o G7GLaV5WexFeUIlyaAFGaRqHjeyknvWEZjwXL.AoLMKeogc7dWVh41azRimu sHjdAveDLk24LXeTqbPWru9xlt9yG6_ou71sIYnIEMaqFnuoCyRwG_7eA9PZ lmlIUlHHH7SFGpmyS1rK9ymkRMT7Zj2rphwKjIX4ae4u9IIAJ49YCTf4aIxe 7TZ5IGCvLXMzc_1eMN4zcWAjhiKzTvg-- Received: from [99.31.212.42] by web31801.mail.mud.yahoo.com via HTTP; Thu, 09 Feb 2012 02:46:45 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340031 References: <90C41DD21FB7C64BB94121FBBC2E723453AADDD47B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1328784405.47127.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Thu, 9 Feb 2012 02:46:45 -0800 (PST) From: William Mills To: Erlend Hamnaberg , Eran Hammer In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-89069321-1328784405=:47127" Cc: "OAuth@ietf.org" Subject: Re: [OAUTH-WG] Implementing MAC bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 10:46:50 -0000 ---368338466-89069321-1328784405=:47127 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It's designed to be a form of HTTP auth independent of OAuth 2.0, however y= ou get your credentials you can still use it.=A0 OAuth 2.0 auth bindings ar= e defined but not required.=0A=0A=0A=0A________________________________=0A = From: Erlend Hamnaberg =0ATo: Eran Hammer =0ACc: "OAuth@ietf.org" =0ASent: Thursday, Februar= y 9, 2012 12:11 AM=0ASubject: Re: [OAUTH-WG] Implementing MAC bearer=0A =0A= =0AGreat. Thanks.=0A=0AOne question:=0A=A0Is it possible to use mac tokens = in a non-OAuth setting?=0A=0AHow would a UA get the MAC id and algorithm th= en?=0A=0AThe old spec had a version where you could use Cookies to do this.= =0A=0AIs there a reason why this couldn't work as with Digest authenticatio= n?=0A=0A-E=0A=0A=0AOn Wed, Feb 8, 2012 at 11:59 PM, Eran Hammer wrote:=0A=0ANew draft:=0A>=A0=0A>http://tools.ietf.org/html/draf= t-ietf-oauth-v2-http-mac-01=0A>=A0=0A>EH=0A>=A0=0A>=A0=0A>From:oauth-bounce= s@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Erlend Hamnaberg=0A= >Sent: Tuesday, February 07, 2012 11:02 AM=0A>To: OAuth@ietf.org=0A>=0A>Sub= ject: [OAUTH-WG] Implementing MAC bearer=0A>=A0=0A>Hi guys and gals.=0A>=A0= =0A>I am trying to implement the MAC bearer within a client library.=0A>=A0= =0A>Searching the Archive I find that the current draft version of the MAC = bearer is incorrect.=0A>=A0=0A>For instance the body-hash is no longer supp= orted. Is there a new draft planned soon?=0A>For implementers there would b= e great help in more examples.=A0=0A>That way we can write test cases which= conforms to the spec more easily.=0A>=A0=0A>Best regards=0A>=A0=0A>Erlend= =0A=0A_______________________________________________=0AOAuth mailing list= =0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth ---368338466-89069321-1328784405=:47127 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It's designed to be a form of HTTP auth independent of OAuth 2.0, however= you get your credentials you can still use it.  OAuth 2.0 auth bindin= gs are defined but not required.

From: E= rlend Hamnaberg <ngarthl@gmail.com>
To: Eran Hammer <eran@hueniverse.com>
Cc: "OAuth@ietf.org" <OAuth@ie= tf.org>
Sent: Thur= sday, February 9, 2012 12:11 AM
Subject:= Re: [OAUTH-WG] Implementing MAC bearer

=0A
Great. Thanks.

One question:
<= div> Is it possible to use mac tokens in a non-OAuth setting?

How would a UA get the MAC id and algorithm then?

The old spec had a version where you could use Cookies to = do this.
=0A

Is there a reason why this couldn't wo= rk as with Digest authentication?

-E
On Wed, Feb 8, 2012 at 11:59 PM, E= ran Hammer <eran= @hueniverse.com> wrote:
=0A

=0A

_= ______________________________________________
OAuth mailing list
OAuth@ietf= .org
https://www.ietf.org/mailman/listinfo/oauth


---368338466-89069321-1328784405=:47127-- From andrewarnott@gmail.com Sun Feb 12 20:22:15 2012 Return-Path: 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 53BE621F873A for ; Sun, 12 Feb 2012 20:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 WhtNgn6yKhU1 for ; Sun, 12 Feb 2012 20:22:14 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B77EC21F8730 for ; Sun, 12 Feb 2012 20:22:14 -0800 (PST) Received: by qan41 with SMTP id 41so2824048qan.10 for ; Sun, 12 Feb 2012 20:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=5aOqVq87I+sbhjEyT8m1bZkipExl6GKAejKTlTcJooE=; b=hicqOahS2br/rCu3x4ybr0aIHV7nYH86BS2BTAJMoRbzH6bdy4fbQcrEEaDsAyMY8e oiSfjWNecFRG5tCnofLt2TyrBMc9cLI90sj+VFkynX9RG2USma4roJxsJ7g2/0H/TB/D 7GBKpuoVcI76vtsiDLkxVF5/QZXZjFKJ4gHdI= Received: by 10.229.136.193 with SMTP id s1mr7875202qct.18.1329106934178; Sun, 12 Feb 2012 20:22:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.25.8 with HTTP; Sun, 12 Feb 2012 20:21:54 -0800 (PST) From: Andrew Arnott Date: Sun, 12 Feb 2012 20:21:54 -0800 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=00235452e7b0ae248504b8d0d217 Subject: [OAUTH-WG] Reconciling section 2.2 with 3.2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 04:22:15 -0000 --00235452e7b0ae248504b8d0d217 Content-Type: text/plain; charset=ISO-8859-1 Can anyone please help me understand how these two sentences do not contradict? >From section 2.2 Client Identifier > The client identifier is not a secret, it is exposed to the resource > owner, and *MUST NOT be used alone* for client authentication. >From section 3.2.1 Client Authentication > > A public client that was not issued a client password MAY use the > client_id request parameter to identify itself when sending requests to > the token endpoint. Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --00235452e7b0ae248504b8d0d217 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Can anyone please help me understand how these two sentences do not co= ntradict?

From section 2.2 Client Identifier
=
The client identifier is not a secret, it is= exposed to the resource owner, and MUST NOT be used alone for clien= t authentication.

From section 3.2.1 Client Authentication A public client that was not issued a client= password MAY use the=A0client_id=A0request parameter to ident= ify itself when sending requests to the token endpoint.

Thanks.

--
= Andrew Arnott
"I [may] not agree with what you have to say, but I&#= 39;ll defend to the death your right to say it." - S. G. Tallentyre
--00235452e7b0ae248504b8d0d217-- From andrewarnott@gmail.com Sun Feb 12 20:44:40 2012 Return-Path: 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 807F121F85E3 for ; Sun, 12 Feb 2012 20:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 TGftNtbuO2Ea for ; Sun, 12 Feb 2012 20:44:40 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABF8421F85E1 for ; Sun, 12 Feb 2012 20:44:39 -0800 (PST) Received: by qafi29 with SMTP id i29so1365597qaf.10 for ; Sun, 12 Feb 2012 20:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=1CXIy23cNgT6GeNOqclK416vSDdrvX7OUn54u9AEuw4=; b=RJT/bBq0+HzcZos1px/80GPSvS6QKVXHuE4MharebC4DN8h7A7+kILHV+wsn8fbHWn VQBxT8LvL1LHIeQKchlA9rqN7cLIT/Xx2xldGB/rWELvLxWyyqK6zcarDZjgPrspBPjU /okcCedmInRb6sM2eGOy8knedl9NoidF4UOp4= Received: by 10.229.106.134 with SMTP id x6mr8053721qco.138.1329108279218; Sun, 12 Feb 2012 20:44:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.25.8 with HTTP; Sun, 12 Feb 2012 20:44:19 -0800 (PST) From: Andrew Arnott Date: Sun, 12 Feb 2012 20:44:19 -0800 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=002354332a3ad9d33b04b8d1225c Subject: [OAUTH-WG] Clarification on section 3.3: missing scope parameter in access token request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 04:44:40 -0000 --002354332a3ad9d33b04b8d1225c Content-Type: text/plain; charset=ISO-8859-1 >From section 3.3 (draft 23): > If the client omits the scope parameter when requesting authorization, the > authorization server MUST either process the request using* a pre-defined > default value*, or fail the request indicating an invalid scope. The > authorization server SHOULD document its scope requirements and default > value (if defined). Is this saying that the pre-defined default value must be a FIXED value for all clients and all grants? Or might the predefined default value actually be a derivation of the grant? (for example, by default the access token scope is simply the maximum scope allowed by the grant) Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --002354332a3ad9d33b04b8d1225c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
From section 3.3 (draft 23):
If the client omits the scope parameter when= requesting authorization, the authorization server MUST either process the= request using a pre-defined default value, or fail the request indi= cating an invalid scope. The authorization server SHOULD document its scope= requirements and default value (if defined).

Is this saying that the pre-defined defaul= t value must be a FIXED value for all clients and all grants? =A0Or might t= he predefined default value actually be a derivation of the grant? (for exa= mple, by default the access token scope is simply the maximum scope allowed= by the grant)

Thanks.

--
Andrew Arnott
&= quot;I [may] not agree with what you have to say, but I'll defend to th= e death your right to say it." - S. G. Tallentyre
--002354332a3ad9d33b04b8d1225c-- From eran@hueniverse.com Sun Feb 12 22:13:06 2012 Return-Path: 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 3862D21F8655 for ; Sun, 12 Feb 2012 22:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 SVU08uMvZ-PF for ; Sun, 12 Feb 2012 22:12:32 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 8817C21F8559 for ; Sun, 12 Feb 2012 22:12:23 -0800 (PST) Received: (qmail 30455 invoked from network); 13 Feb 2012 06:12:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Feb 2012 06:12:23 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 12 Feb 2012 23:12:18 -0700 From: Eran Hammer To: Andrew Arnott , "OAuth WG (oauth@ietf.org)" Date: Sun, 12 Feb 2012 23:12:14 -0700 Thread-Topic: [OAUTH-WG] Reconciling section 2.2 with 3.2.1 Thread-Index: AczqBxObK4zqloR/QMyyYvjlhUexqQADxlxA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AADDD762@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD762P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Reconciling section 2.2 with 3.2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 06:13:06 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD762P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Identification isn't authentication. A public client can identify itself fo= r the purpose of providing user context, statistics, etc. EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Sunday, February 12, 2012 8:22 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Reconciling section 2.2 with 3.2.1 Can anyone please help me understand how these two sentences do not contrad= ict? >From section 2.2 Client Identifier The client identifier is not a secret, it is exposed to the resource owner,= and MUST NOT be used alone for client authentication. >From section 3.2.1 Client Authentication A public client that was not issued a client password MAY use the client_id= request parameter to identify itself when sending requests to the token en= dpoint. Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD762P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Identific= ation isn’t authentication. A public client can identify itself for t= he purpose of providing user context, statistics, etc.

 

EH

 

From: oauth-bounces@= ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew Arnott<= br>Sent: Sunday, February 12, 2012 8:22 PM
To: OAuth WG (o= auth@ietf.org)
Subject: [OAUTH-WG] Reconciling section 2.2 with 3= .2.1

 

Can anyone please help me understand how the= se two sentences do not contradict?

 

From section 2.= 2 Client Identifier

The client identifier is not a secret, it is= exposed to the resource owner, and MUST NOT be used alone for clien= t authentication.

 

From section 3.2.1 Clie= nt Authentication

A public client that was not = issued a client password MAY use the client_id request para= meter to identify itself when sending requests to the token endpoint.

 

=

Thanks.

=
--
Andrew Arnott
"I [may] not agree with what yo= u have to say, but I'll defend to the death your right to say it." - S= . G. Tallentyre

= --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD762P3PW5EX1MB01E_-- From stephen.farrell@cs.tcd.ie Mon Feb 13 06:37:29 2012 Return-Path: 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 E5E6721F84C8 for ; Mon, 13 Feb 2012 06:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Et-DZei2gJlz for ; Mon, 13 Feb 2012 06:37:29 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3607D21F84B8 for ; Mon, 13 Feb 2012 06:37:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 90B5D157ABA; Mon, 13 Feb 2012 14:37:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1329143848; bh=xWkrf5RiMwBQcpg00ghy7dDV 1K+H3vlpQ/7xqG/fFSQ=; b=Wdj3iiil9drp9KMrYHs6lguEa0Slr278Tb+mFOpW EZhgnU9DzOABtBS3wOjy0edUdWfsN1yRMTtuXi0qYgKo8r7opKNOwVCQQullNUDO +xLKh7QteMcPBhkcMjjFdc5fzYMp3vlL1IDe4EiZGS5jLTJD+OaYrULw3bKQxU0r dyQ+Fs/78jeE6I13FiYdBbx1VJoESQh9iJ4On0quYNno/C34KtcfhK01oPxey0Gn 3MkWbh1kK/OFdVkOq0NtkQ7Dg1nd4vm/Z/3l7tSgkW8UcnP1WGY8WzAJKu4RFQoO gz+anWJReATZhQRB8aaRqL56WOE66dXvZE+LI7av3wzrqQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id KNbkDxLMtvPl; Mon, 13 Feb 2012 14:37:28 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 41732157ABB; Mon, 13 Feb 2012 14:37:28 +0000 (GMT) Message-ID: <4F39201E.1020400@cs.tcd.ie> Date: Mon, 13 Feb 2012 14:37:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Derek Atkins Subject: [OAUTH-WG] New co-chair for OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 14:37:30 -0000 Hi all, As some of you will have noticed Barry will be taking over as an IETF applications area director in Paris which means that he'll no longer be able to help out as OAuth chair after that. However, we've been quite lucky in that Derek Atkins (cc'd) has agreed to help out along with Hannes as OAuth re-charters and goes on to do more good stuff. Derek has previously chaired kink, openpgp and impp so has lots of experience with this kind of thing and will I'm sure do a great job. Barry will stay on as chair until Paris so we'll have 3 co-chairs for a short while. Many thanks to Barry for all his hard work helping to get OAuth to where we have documents about to go into IESG review. Continuing thanks to Hannes for the same, and new thanks to Derek for agreeing to take on this important role. Regards, Stephen. From jricher@mitre.org Mon Feb 13 08:15:03 2012 Return-Path: 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 29D4121F869D for ; Mon, 13 Feb 2012 08:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4] 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 2kjTKnWwfGT5 for ; Mon, 13 Feb 2012 08:15:02 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3094D21F86C9 for ; Mon, 13 Feb 2012 08:15:02 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C7E2521B00C3; Mon, 13 Feb 2012 11:15:01 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 99AD621B0404; Mon, 13 Feb 2012 11:15:01 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 13 Feb 2012 11:15:01 -0500 Message-ID: <4F3936AF.90402@mitre.org> Date: Mon, 13 Feb 2012 11:13:35 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Andrew Arnott References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050609050907030902070608" X-Originating-IP: [129.83.31.51] Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Clarification on section 3.3: missing scope parameter in access token request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 16:15:03 -0000 --------------050609050907030902070608 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit In most cases, it will likely be a fixed value, but there's nothing indicating that it can't be contextual. Especially in cases where you've got public, confidential, and dynamically-registered clients all acting on the same host, the default value will depend completely on what kind of client is asking. Really, this is a way of saying "scope is up to the AS", which it is, even if the client asks for something else. -- Justin On 02/12/2012 11:44 PM, Andrew Arnott wrote: > From section 3.3 (draft 23): > > If the client omits the scope parameter when requesting > authorization, the authorization server MUST either process the > request using*a pre-defined default value*, or fail the request > indicating an invalid scope. The authorization server SHOULD > document its scope requirements and default value (if defined). > > > Is this saying that the pre-defined default value must be a FIXED > value for all clients and all grants? Or might the predefined default > value actually be a derivation of the grant? (for example, by default > the access token scope is simply the maximum scope allowed by the grant) > > Thanks. > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the > death your right to say it." - S. G. Tallentyre > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050609050907030902070608 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit In most cases, it will likely be a fixed value, but there's nothing indicating that it can't be contextual. Especially in cases where you've got public, confidential, and dynamically-registered clients all acting on the same host, the default value will depend completely on what kind of client is asking.

Really, this is a way of saying "scope is up to the AS", which it is, even if the client asks for something else.

 -- Justin

On 02/12/2012 11:44 PM, Andrew Arnott wrote:
From section 3.3 (draft 23):
If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request using a pre-defined default value, or fail the request indicating an invalid scope. The authorization server SHOULD document its scope requirements and default value (if defined).

Is this saying that the pre-defined default value must be a FIXED value for all clients and all grants?  Or might the predefined default value actually be a derivation of the grant? (for example, by default the access token scope is simply the maximum scope allowed by the grant)

Thanks.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------050609050907030902070608-- From ve7jtb@ve7jtb.com Mon Feb 13 08:33:13 2012 Return-Path: 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 1C1AF21F854B for ; Mon, 13 Feb 2012 08:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 jGx5jPfrFnhM for ; Mon, 13 Feb 2012 08:33:12 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4036221F8532 for ; Mon, 13 Feb 2012 08:33:12 -0800 (PST) Received: by ggnq2 with SMTP id q2so2819742ggn.31 for ; Mon, 13 Feb 2012 08:33:11 -0800 (PST) Received: by 10.236.143.72 with SMTP id k48mr20829132yhj.37.1329150791674; Mon, 13 Feb 2012 08:33:11 -0800 (PST) Received: from [192.168.1.213] (186-107-148-253.baf.movistar.cl. [186.107.148.253]) by mx.google.com with ESMTPS id i12sm37397152anm.6.2012.02.13.08.33.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Feb 2012 08:33:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_89E6C1E0-A835-4A0C-AB15-66DF34763180"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4F3936AF.90402@mitre.org> Date: Mon, 13 Feb 2012 13:33:02 -0300 Message-Id: <6968E025-7D5D-40B4-A67B-475175815DF7@ve7jtb.com> References: <4F3936AF.90402@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmAj8KqlFmceR3u329M9siSR/8yG2aSNkQd7aQ662xlaU8ZJiVUjfwNIbarR7DADo7D70P9 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Clarification on section 3.3: missing scope parameter in access token request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 16:33:13 -0000 --Apple-Mail=_89E6C1E0-A835-4A0C-AB15-66DF34763180 Content-Type: multipart/alternative; boundary="Apple-Mail=_05B481D7-8140-462B-8924-44BC775B4B54" --Apple-Mail=_05B481D7-8140-462B-8924-44BC775B4B54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 It is a way of saying the AS doesn't need to return an error if scope is = not included, though it has the option to return an error if it has no = default scope. However what the server may use as a default value us application = specific. e.g. the client may have registered a default scope or = scopes, or a default is documented as part of some API. I think the goal is that the behaviour of the AS is in some way = predictable to the client, while leaving it to the individual API to = define the behaviour of scopes including what to do if you don't get an = explicit one in the request. John B. On 2012-02-13, at 1:13 PM, Justin Richer wrote: > In most cases, it will likely be a fixed value, but there's nothing = indicating that it can't be contextual. Especially in cases where you've = got public, confidential, and dynamically-registered clients all acting = on the same host, the default value will depend completely on what kind = of client is asking. >=20 > Really, this is a way of saying "scope is up to the AS", which it is, = even if the client asks for something else. >=20 > -- Justin >=20 > On 02/12/2012 11:44 PM, Andrew Arnott wrote: >>=20 >> =46rom section 3.3 (draft 23): >> If the client omits the scope parameter when requesting = authorization, the authorization server MUST either process the request = using a pre-defined default value, or fail the request indicating an = invalid scope. The authorization server SHOULD document its scope = requirements and default value (if defined). >>=20 >> Is this saying that the pre-defined default value must be a FIXED = value for all clients and all grants? Or might the predefined default = value actually be a derivation of the grant? (for example, by default = the access token scope is simply the maximum scope allowed by the grant) >>=20 >> Thanks. >>=20 >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the = death your right to say it." - S. G. Tallentyre >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_05B481D7-8140-462B-8924-44BC775B4B54 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 It is a way of saying the AS doesn't need to return an error if scope is not included, though it has the option to return an error if it has no default scope.

However what the server may use as a default value us application specific.  e.g. the client may have registered a default scope or scopes, or a default is documented as part of some API.

I think the goal is that the behaviour of the AS is in some way predictable to the client, while leaving it to the individual API to define the behaviour of scopes including what to do if you don't get an explicit one in the request.

John B.
On 2012-02-13, at 1:13 PM, Justin Richer wrote:

In most cases, it will likely be a fixed value, but there's nothing indicating that it can't be contextual. Especially in cases where you've got public, confidential, and dynamically-registered clients all acting on the same host, the default value will depend completely on what kind of client is asking.

Really, this is a way of saying "scope is up to the AS", which it is, even if the client asks for something else.

 -- Justin

On 02/12/2012 11:44 PM, Andrew Arnott wrote:
From section 3.3 (draft 23):
If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request using a pre-defined default value, or fail the request indicating an invalid scope. The authorization server SHOULD document its scope requirements and default value (if defined).

Is this saying that the pre-defined default value must be a FIXED value for all clients and all grants?  Or might the predefined default value actually be a derivation of the grant? (for example, by default the access token scope is simply the maximum scope allowed by the grant)

Thanks.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_05B481D7-8140-462B-8924-44BC775B4B54-- --Apple-Mail=_89E6C1E0-A835-4A0C-AB15-66DF34763180 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MTMxNjMzMDRaMCMGCSqGSIb3DQEJBDEWBBSJvymLDmrzSGutCMvwU4iLASBfaTCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQA4FtRDh37ER3cx4QrKBVTM/VeVjWvE4TCTjEbs1+OAH89ESbwdvD51ml39sY/ytfSFR8MMJ6oG oPr5yfB2/4VMIG55fDfzxc81YvQ91wuLALPlO+teQc3REqpvYlsZS1UYHOC7+1hXGilydTpl6lNC x1VRSAhBuFnJ/1ftqawBMsiBIqgbnJIN9NjNQMdLtAIXgJJg0TGBgoTAtUMjpaTn3Dbnk4nZ4vkQ jr67qOLqNfL/HZZJz+6gUSsVrdYEzz2yn0bS+bSRIcQykypsclL2cqbC8uylzsNxI5nmKpzAbPWP tr26zkM6wVVa/9PKOwSsXxZnUreHuScHKKoJy99kAAAAAAAA --Apple-Mail=_89E6C1E0-A835-4A0C-AB15-66DF34763180-- From eran@hueniverse.com Mon Feb 13 08:43:08 2012 Return-Path: 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 DA3CD21F8508 for ; Mon, 13 Feb 2012 08:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Hb2c6p1ggqMs for ; Mon, 13 Feb 2012 08:43:08 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 2FE3821F8504 for ; Mon, 13 Feb 2012 08:43:08 -0800 (PST) Received: (qmail 15185 invoked from network); 13 Feb 2012 16:42:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Feb 2012 16:42:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 13 Feb 2012 09:42:52 -0700 From: Eran Hammer To: Andrew Arnott , "OAuth WG (oauth@ietf.org)" Date: Mon, 13 Feb 2012 09:42:48 -0700 Thread-Topic: [OAUTH-WG] Clarification on section 3.3: missing scope parameter in access token request Thread-Index: AczqCjWpQvHPoiVaSfil0evmklCsPQAZAg0w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AADDD7E9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD7E9P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Clarification on section 3.3: missing scope parameter in access token request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 16:43:09 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD7E9P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The text serves two purposes: 1. Warn client developers that the server may have a default scope an= d that they should figure out what it is or what the scope requirements are 2. Make server developers aware that they should publish their defaul= t scope of scope handling preferences. As for your question, the pre-defined default value can be anything, includ= ing context-sensitive. It can even be random, but either way, it should be = documented. EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Sunday, February 12, 2012 8:44 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Clarification on section 3.3: missing scope parameter i= n access token request >From section 3.3 (draft 23): If the client omits the scope parameter when requesting authorization, the = authorization server MUST either process the request using a pre-defined de= fault value, or fail the request indicating an invalid scope. The authoriza= tion server SHOULD document its scope requirements and default value (if de= fined). Is this saying that the pre-defined default value must be a FIXED value for= all clients and all grants? Or might the predefined default value actuall= y be a derivation of the grant? (for example, by default the access token s= cope is simply the maximum scope allowed by the grant) Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD7E9P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The text = serves two purposes:

 

1.  &= nbsp;    Warn client developers that the server may have a default scope a= nd that they should figure out what it is or what the scope requirements ar= e

2.  &n= bsp;    Make server developers aware that they should publish their defaul= t scope of scope handling preferences.

 

As f= or your question, the pre-defined default value can be anything, including = context-sensitive. It can even be random, but either way, it should be docu= mented.

 <= /span>

EH

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Andrew Arnott
Sent: Sunday, February 12, 2012 8:44 = PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Cl= arification on section 3.3: missing scope parameter in access token request=

 

From section 3.3 (draft 23):

<= span style=3D'font-family:"Verdana","sans-serif";background:white'>If the c= lient omits the scope parameter when requesting authorization, the authoriz= ation server MUST either process the request using a pre-defined default= value, or fail the request indicating an invalid scope. The authorizat= ion server SHOULD document its scope requirements and default value (if def= ined).

&n= bsp;

Is this saying that the pre-d= efined default value must be a FIXED value for all clients and all grants? =  Or might the predefined default value actually be a derivation of the= grant? (for example, by default the access token scope is simply the maxim= um scope allowed by the grant)

 

Thanks.


--
Andrew Arnott
"I= [may] not agree with what you have to say, but I'll defend to the death yo= ur right to say it." - S. G. Tallentyre

= --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDD7E9P3PW5EX1MB01E_-- From andrewarnott@gmail.com Mon Feb 13 10:08:25 2012 Return-Path: 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 5203821F870A for ; Mon, 13 Feb 2012 10:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 RQouvSrrEFXI for ; Mon, 13 Feb 2012 10:08:24 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8769921F8704 for ; Mon, 13 Feb 2012 10:08:24 -0800 (PST) Received: by qcsq13 with SMTP id q13so1233039qcs.31 for ; Mon, 13 Feb 2012 10:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h2/xzW+/4V/2FC+N+cO1K5MJvTuyJTHNseKJUsNVY2Y=; b=cNT5aM0qsc+eivAQZMmWc6ZOSSx/KyAn/G3k6YLuv1Sxbb90ju6/dTKZeupHQ71pTn UVS8ltz47MZrbLIoF3G7q+Ogm3cScKVoJ4cyxP0G08mgYXQl5gKBYLrVj4aSWlveYgjg wQtXt1sRRlHProNKZ9jUIZNZSH9ri4K9dV5+s= MIME-Version: 1.0 Received: by 10.229.111.141 with SMTP id s13mr9645434qcp.38.1329156503884; Mon, 13 Feb 2012 10:08:23 -0800 (PST) Received: by 10.229.25.8 with HTTP; Mon, 13 Feb 2012 10:08:23 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AADDD762@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453AADDD762@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 13 Feb 2012 10:08:23 -0800 Message-ID: From: Andrew Arnott To: Eran Hammer Content-Type: multipart/alternative; boundary=00235447189c43d5de04b8dc5d9b Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Reconciling section 2.2 with 3.2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 18:08:25 -0000 --00235447189c43d5de04b8dc5d9b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Fair enough. Thanks, Eran. Is that generally a clear distinction to the rest of the community already, or should this distinction be described in section 3.2.1? On Sunday, February 12, 2012, Eran Hammer wrote: > Identification isn=92t authentication. A public client can identify itsel= f > for the purpose of providing user context, statistics, etc.**** > > ** ** > > EH**** > > ** ** > > *From:* oauth-bounces@ietf.org 'oauth-bounces@ietf.org');> [mailto:oauth-bounces@ietf.org] > *On Behalf Of *Andrew Arnott > *Sent:* Sunday, February 12, 2012 8:22 PM > *To:* OAuth WG (oauth@ietf.org 'oauth@ietf.org');>) > *Subject:* [OAUTH-WG] Reconciling section 2.2 with 3.2.1**** > > ** ** > > Can anyone please help me understand how these two sentences do not > contradict?**** > > ** ** > > From section 2.2 Client Identifier**** > > The client identifier is not a secret, it is exposed to the resource > owner, and *MUST NOT be used alone* for client authentication. **** > > ** ** > > From section 3.2.1 Client Authentication**** > > A public client that was not issued a client password MAY use the > client_id request parameter to identify itself when sending requests to > the token endpoint. **** > > ** ** > > Thanks.**** > > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the deat= h > your right to say it." - S. G. Tallentyre**** > --=20 -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --00235447189c43d5de04b8dc5d9b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Fair enough. =A0Thanks, Eran. =A0Is that generally a clear distinction to t= he rest of the community already, or should this distinction be described i= n section 3.2.1?

On Sunday, February 12, 2012, Eran Hammer wrote:

Identificatio= n isn=92t authentication. A public client can identify itself for the purpo= se of providing user context, statistics, etc.

=A0<= /p>

EH

=A0<= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew Arnott=
Sent: Sunday, February 12, 2012 8:22 PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Reconciling s= ection 2.2 with 3.2.1

=A0

Can anyone please help me understand how these two sentences do no= t contradict?

=A0=

From section 2.2 Client Identifier=

The client identifier is not a secret, it is exposed to the re= source owner, and MUST NOT be used alone for client authentication.<= /span>

=A0

From section 3.2.1 Client Authentication

<= p class=3D"MsoNormal">A public client that was not issued a cl= ient password MAY use the=A0client_id=A0request pa= rameter to identify itself when sending requests to the token endpoint.

=A0

Thanks.


--
Andrew Arnott
"I [may] not agree with what you have= to say, but I'll defend to the death your right to say it." - S. = G. Tallentyre



--
--
Andrew Arnott
= "I [may] not agree with what you have to say, but I'll defend to t= he death your right to say it." - S. G. Tallentyre
--00235447189c43d5de04b8dc5d9b-- From ht@inf.ed.ac.uk Tue Feb 14 09:10:12 2012 Return-Path: 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 28D4D21F87AB; Tue, 14 Feb 2012 09:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6WOfkjBifCCY; Tue, 14 Feb 2012 09:10:08 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9DECA21F87A1; Tue, 14 Feb 2012 09:10:05 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q1EH7EAI021667; Tue, 14 Feb 2012 17:07:18 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q1EH7DkH004957; Tue, 14 Feb 2012 17:07:13 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q1EH7DQG025047; Tue, 14 Feb 2012 17:07:13 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q1EH7DAr025043; Tue, 14 Feb 2012 17:07:13 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Justin Richer In-reply-to: 4F319539.5070606@mitre.org References: 90C41DD21FB7C64BB94121FBBC2E723453AADDD2D4@P3PW5EX1MB01.EX1.SECURESERVER.NET, f5bfwemh7pe.fsf@calexico.inf.ed.ac.uk From: ht@inf.ed.ac.uk (Henry S. Thompson) User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) Date: Tue, 14 Feb 2012 17:07:12 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 X-Mailman-Approved-At: Tue, 14 Feb 2012 09:18:58 -0800 Cc: barryleiba@gmail.com, apps-discuss@ietf.org, dr@fb.com, oauth@ietf.org Subject: Re: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:10:12 -0000 [Sigh, resending with corrected CC list] Justin writes: > [Henry wrote]: >> Subject: Appsdir review of draft-ietf-oauth-v2-23 >> >> I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on appsdir, please see > href="http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate">http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). >> >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-oauth-v2-23 >> >> Title: The OAuth 2.0 Authorization Protocol >> >> Reviewer: Henry S. Thompson >> >> Review Date: 2012-02-07 >> >> IETF Last Call Date: 2012-01-24 >> >> Summary: This draft is almost ready for publication as an Proposed >> Standard but has a few issues that should be fixed >> before publication >> >> [Note - My expertise is in the areas of markup and architecture, with >> only the average geek's understanding of security and cryptographic >> technologies. Any comments below on security issues are therefore of >> the nature of general audience concerns, rather than technical >> worries.] >> >> Major Issues: >> >> 3.1.2.1 The failure to require TLS here is worrying. At the very >> least I would expect a requirement that clients which do _not_ require >> TLS MUST provide significant user feedback calling attention to this >> -- by analogy, absence of a padlock does _not_ suffice. . . > There are two bits going on here, and I think there's confusion > again about this being a *client* controlled endpoint. First, not > all callback redirects are remote HTTP URLs. A href="http://localhost/">http://localhost/ callback or an app:// > callback are going to be very common with installed clients, and in > both of these cases TLS makes no sense to require. Second, and this > is the reason spelled out in the text, you can't really expect all > *clients* to use proper TLS on their redirects. If it's a remote > HTTP call, then it's likely a very Bad Idea to go over a plaintext > socket, yes. But there are enough other cases where mandating it > doesn't make sense. > Suggestion: call out second non-HTTP use case here as well, perhaps > stop calling it an "endpoint" to differentiate it from the > server-side pieces. OK, sounds like I didn't fully understand the context here. Providing the examples you give as motivation would help keep others from making the same mistake. . . >> [3].1.2.5 In a somewhat parallel case, I would expect this section to >> at least explain why the SHOULD NOT is not a MUST NOT. Since in >> practice the distinction between trusted and untrusted 3rd-party >> scripting is difficult if not impossible to draw, as written the 2nd >> para is effectively overriden by the third. > Assuming this means 3.1.2.5 Yes, sorry. > A MUST NOT is impossible to enforce here. You're telling people to > not include jQuery in their JavaScript app. Truth is, any third > party library that you include in your app could get access to the > security bits whether it's on the callback page or not. I think it's > appropriate to provide guidance for best practices here, and the > MUST be first and SHOULD be only makes sense. People will get it > wrong in spite of what the spec says here one way or another. Hmmm. Either I'm misreading the text, or I don't understand your argument. . . The existing "MUST NOT" para applies to untrusted js. The second para. is nearly identical in terms of what it wants done, but covers _all_ js. Writing MUST/SHOULD NOT and knowing people will get it wrong just undermines the value of the spec. > Suggestion: drop the requirements (and move them to the security > doc), or otherwise no change. If by that you mean, moving it to the security section, and observing there that _failure_ to sanitise early is a risk, by effectively changing MUST NOT to WILL RISK COMPROMISE and SHOULD NOT to MAY RISK COMPROMISE, that would work for me. >> 11 It seems at best old-fashioned that the designer of a new access >> token type, parameter, endpoint response type or extension error has >> no better tool available than Google to help him/her discover whether >> the name they have in mind is in use already. The same is true under >> the proposed approach for any developer trying to determine what they >> can use or must support. Is there some reason that mandated URI >> templates, after the fashion of >> http://www.iana.org/assignments/media-types/text/ >> are not mandated for the registries, e.g. >> http://www.iana.org/assignments/access-token-types/bearer >> ? If there is a good reason, please use it to at least explicitly >> acknowledge and justify the basis for failing to provide a way for >> users and developers to use the "follow your nose" strategy >> [1]. If there is no good reason, please include the appropriate >> language to require something along the lines suggested above. If you >> need a model, see [2]. > I'm confused - is this a request to use a full URI for all extension > values? I thought the purpose of a registry was to deconflict the > short names, and that URIs could be used for anything else. No, I appreciate that you want to use registered short names in the protocol, that's just fine. My problem is that you have left users, developers etc. with no way to discover what shortnames have been registered short of a non-trivial and error-prone informal search effort. What I'm asking for is support for probe URI prefixes for each family of shortnames. So, just as today I use "text/n3" as the media type for my Notation3 documents, I can check that this is a registered media type by attempting to retrieve http://www.iana.org/assignments/media-types/text/n3 and I can see all the registered text types by retrieving from http://www.iana.org/assignments/media-types/text likewise I ought to be able to check e.g. the "bearer" token type by attempting retrieval from (something along the lines of) http://www.iana.org/assignments/access-token-types/bearer and I should be able to see all the registered token types by retrieving from http://www.iana.org/assignments/access-token-types Hope this clarifies what I meant. >> Minor Issues: >> A short summary of the changes from OAuth 1.0/RFC5849 would have >> been helpful, and it might still be a good idea to add one. . . > I don't think this is possible. OAuth2 is built nfundamentally > differently from OAuth1, so this paragraph might as well read "just > about everything but the concept". Suggestion: don't add this, > unless someone can come up with a succinct way to summarize the > decision to build on a new foundation. OK, thanks. Even something like the above short statement would be useful . . . >> 4.1 Would it be helpful to indicate that steps D&E may occur at >> any time after C, and may be repeated subsequently? > D&E may be delayed, but shouldn't be repeated. The Access Code is > one-time-use, and in the best deployments will expire after a short > period of time. Suggestion: leave as is. OK, I just think as it is it invites misinterpretation. >> 11.1 It might be useful to have an 11.1.2, which repeats references >> to the bearer and mac access token type registration drafts? > Is this a request to pre-register the two 'core' token types? Yes, in that what I had in mind was making 11.1 parallel to ll.2, 3 and 4 in this regard. ht [I'm sorry about the mailing list confusion. But please don't punish me again by sending HTML change bar markup which I have to hand edit :-] -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From raf6439@yahoo.com Tue Feb 14 12:45:44 2012 Return-Path: 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 A52FD21E80F1 for ; Tue, 14 Feb 2012 12:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_43=0.6] 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 Rvu4QhBsQbeJ for ; Tue, 14 Feb 2012 12:45:43 -0800 (PST) Received: from nm38-vm0.bullet.mail.bf1.yahoo.com (nm38-vm0.bullet.mail.bf1.yahoo.com [72.30.239.16]) by ietfa.amsl.com (Postfix) with SMTP id 3723321E80EF for ; Tue, 14 Feb 2012 12:45:43 -0800 (PST) Received: from [98.139.214.32] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 14 Feb 2012 20:45:37 -0000 Received: from [98.139.212.225] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 14 Feb 2012 20:45:37 -0000 Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 14 Feb 2012 20:45:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 641978.64612.bm@omp1034.mail.bf1.yahoo.com Received: (qmail 6561 invoked by uid 60001); 14 Feb 2012 20:45:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1329252336; bh=OCE8lEpci8EgJPHZd8g0PT7AI1R4NLKUCkO6lkr08Ek=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WAg9ygu121GdirWP3anM/KA7fvjyqMNrUKup4pamN+VuNby1YkPlqcJU2OH0en9PC1tuCX19MVsfJUOdRbjPvrtheu+6kRco3ZPKFYobN/CxX2Lo6kiIJriQzk9byMJSLX/8Gx8YSdbMEbHCfHUwPRRUYSmMORsdliji21ib81I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cPMKQPZVB9+AItsku9gok8/tPQgSqxvDyRo90DzE8SqjCYNkHQgPDoyltuIAV82KoDIAn+cueVV4BmNEeXlZcWqvIfSalqBzJ1Y3Pwnr7CopcpzRpVKZTud0PC911VwkdUmiwYG/IDCEFjZn+Ov+iew9JQJeLwCCnKWztYJijtk=; X-YMail-OSG: EzHyDU8VM1nhToPQPz54m5hNzKtqFJm8t_MUyuK09QuPnO6 Rp6ZMmiDmyHpKQvXXgs8WRTK_2T41D.8sdPbn0kLh_Y0kyEdHGqg0JUdfQJL V3yOKTvmX2FErdlD8oQHE1j7mAn6HiEkFj84K3t6CLSUWaAVWEt05SGzpA2Y _sG5kHoc0.kpNtg9GpHP0pCNCM8pup5XgIsjSTmACPMo06L6Qsy8lfjBxw9w Ft5FQG61rsISkXDyP1s15INVwXtlwskUhQ1uDVtSF_sFzK0HbooHqTcMQ51Q MkwUJrGElcElmWVuzOg8MColP3cey.7bg6V7id3TVNWW6QA18jTdpbA3LCZl MflOoFSA8S55QuN5OPjO_gLPAo9Y9LSawM66Y_ezF5pSiY.luTnWTqMu_JDm gxEQrAv8NfMI75bxo4yqmGpvW2cAZ_4dLj9ntFRsJF01Pru5B9dATR3mAKUQ iyzYAmrycA5V4ZeOBbqnD.yw1tNxWro9J55XNHIpNWt1A1eAm6KXbcxH7WUd M_JMuHomi.nzm.2JJTyKo3oFekBPbj5e3by4LaS.4H1zlG9d4Dbmkc33BJHS bTI8BXzFQlZtzRzTO6Iw980s6yoP_Yg-- Received: from [68.205.198.178] by web30804.mail.mud.yahoo.com via HTTP; Tue, 14 Feb 2012 12:45:36 PST X-Mailer: YahooMailWebService/0.8.116.338427 Message-ID: <1329252336.74552.yint-ygo-j2me@web30804.mail.mud.yahoo.com> Date: Tue, 14 Feb 2012 12:45:36 -0800 (PST) From: robert flores To: oauth@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] OAuth Digest, Vol 40, Issue 12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 20:45:44 -0000 =0Are: New Exponent add to list of ad-list of : eucolypitcal value : majoru= s .=BF&: component: programe: save&ridity-Junquerah:@autoresponder.lawe:nee= d od:force@removal.point.maintree of all and any!logrithuime to product.ura= nium.overkilt:tiltdotlawe:of yucca&.junqureah=3Deucalypatuse.made.underrigh= te.lawe.via.cola!pont.point.excarpo'kexarp!warrant!clavic.lawe'!excalibure! subject:..motor:gift.law.for.scotalindudtrius!@reasone.@age'um:eucalip.lawe= =3Dbarracuda!pont.protriues:magna.carta'.lehale.issue(r):carnium:lawe!.mint= &.tea.pointe:excaliber.issue!&.add.programe: name'ded!'edd: (to.pro-type.is= ue:at.cloud.skype:programe&.lawe:name of reasearh.finite:editor:(self.fathe= r=3Dto.daughter.ph.=3Dcarivoreum.carniacium!=3D :"FOG!.(carl.sandburge.poem= e':22:29:20:20!issuer:r:r:5!)=A7=3D=B6!..Phineas.Fog!Programe.by.(owner:ord= er!u.l.d.):Honeywell.Products.Inc!.=A710-4+!good!oute!thank.you.&.Merry.Val= entine to All'e Persone' at V:Very.Goode!.over&.oute:10-4!. robert.a.bartok.h.clavic'.-Sr.Ph.! ------------------------------ On Tue, Feb 14, 2012 3:00 PM EST oauth-request@ietf.org wrote: >If you have received this digest without all the individual message >attachments you will need to update your digest options in your list >subscription. To do so, go to=20 > >https://www.ietf.org/mailman/listinfo/oauth > >Click the 'Unsubscribe or edit options' button, log in, and set "Get >MIME or Plain Text Digests?" to MIME. You can set this option >globally for all the list digests you receive at this point. > > > >Send OAuth mailing list submissions to >=09oauth@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit >=09https://www.ietf.org/mailman/listinfo/oauth >or, via email, send a message with subject or body 'help' to >=09oauth-request@ietf.org > >You can reach the person managing the list at >=09oauth-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of OAuth digest..." > > >Today's Topics: > > 1. Re: FW: Appsdir review of draft-ietf-oauth-v2-23 > (Henry S. Thompson) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Tue, 14 Feb 2012 17:07:12 +0000 >From: ht@inf.ed.ac.uk (Henry S. Thompson) >To: Justin Richer >Cc: barryleiba@gmail.com, apps-discuss@ietf.org, dr@fb.com, >=09oauth@ietf.org >Subject: Re: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 >Message-ID: >Content-Type: text/plain; charset=3Dus-ascii > >[Sigh, resending with corrected CC list] >Justin writes: > >> [Henry wrote]: >> Subject: Appsdir review of draft-ietf-oauth-v2-23 >>=20 >> I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on appsdir, please see > href=3D"http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDi= rectorate">http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDi= rectorate). >>=20 >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >>=20 >> Document: draft-ietf-oauth-v2-23 >>=20 >> Title: The OAuth 2.0 Authorization Protocol >>=20 >> Reviewer: Henry S. Thompson >>=20 >> Review Date: 2012-02-07 >>=20 >> IETF Last Call Date: 2012-01-24 >>=20 >> Summary: This draft is almost ready for publication as an Proposed >> Standard but has a few issues that should be fixed >> before publication >>=20 >> [Note - My expertise is in the areas of markup and architecture, with >> only the average geek's understanding of security and cryptographic >> technologies. Any comments below on security issues are therefore of >> the nature of general audience concerns, rather than technical >> worries.] >>=20 >> Major Issues: >>=20 >> 3.1.2.1 The failure to require TLS here is worrying. At the very >> least I would expect a requirement that clients which do _not_ require >> TLS MUST provide significant user feedback calling attention to this >> -- by analogy, absence of a padlock does _not_ suffice. . . > >> There are two bits going on here, and I think there's confusion >> again about this being a *client* controlled endpoint. First, not >> all callback redirects are remote HTTP URLs. A > href=3D"http://localhost/">http://localhost/ callback or an app:// >> callback are going to be very common with installed clients, and in >> both of these cases TLS makes no sense to require. Second, and this >> is the reason spelled out in the text, you can't really expect all >> *clients* to use proper TLS on their redirects. If it's a remote >> HTTP call, then it's likely a very Bad Idea to go over a plaintext >> socket, yes. But there are enough other cases where mandating it >> doesn't make sense. > >> Suggestion: call out second non-HTTP use case here as well, perhaps >> stop calling it an "endpoint" to differentiate it from the >> server-side pieces. > >OK, sounds like I didn't fully understand the context here. Providing >the examples you give as motivation would help keep others from making >the same mistake. . . > >> [3].1.2.5 In a somewhat parallel case, I would expect this section to >> at least explain why the SHOULD NOT is not a MUST NOT. Since in >> practice the distinction between trusted and untrusted 3rd-party >> scripting is difficult if not impossible to draw, as written the 2nd >> para is effectively overriden by the third. > >> Assuming this means 3.1.2.5 > >Yes, sorry. > >> A MUST NOT is impossible to enforce here. You're telling people to >> not include jQuery in their JavaScript app. Truth is, any third >> party library that you include in your app could get access to the >> security bits whether it's on the callback page or not. I think it's >> appropriate to provide guidance for best practices here, and the >> MUST be first and SHOULD be only makes sense. People will get it >> wrong in spite of what the spec says here one way or another. > >Hmmm. Either I'm misreading the text, or I don't understand your >argument. . . The existing "MUST NOT" para applies to untrusted js. >The second para. is nearly identical in terms of what it wants done, >but covers _all_ js. Writing MUST/SHOULD NOT and knowing people will >get it wrong just undermines the value of the spec. > >> Suggestion: drop the requirements (and move them to the security >> doc), or otherwise no change. > >If by that you mean, moving it to the security section, and observing >there that _failure_ to sanitise early is a risk, by effectively >changing MUST NOT to WILL RISK COMPROMISE and SHOULD NOT to MAY RISK >COMPROMISE, that would work for me. > >> 11 It seems at best old-fashioned that the designer of a new access >> token type, parameter, endpoint response type or extension error has >> no better tool available than Google to help him/her discover whether >> the name they have in mind is in use already. The same is true under >> the proposed approach for any developer trying to determine what they >> can use or must support. Is there some reason that mandated URI >> templates, after the fashion of > >> http://www.iana.org/assignments/media-types/text/ > >> are not mandated for the registries, e.g. > >> http://www.iana.org/assignments/access-token-types/bearer > >> ? If there is a good reason, please use it to at least explicitly >> acknowledge and justify the basis for failing to provide a way for >> users and developers to use the "follow your nose" strategy >> [1]. If there is no good reason, please include the appropriate >> language to require something along the lines suggested above. If you >> need a model, see [2]. > >> I'm confused - is this a request to use a full URI for all extension >> values? I thought the purpose of a registry was to deconflict the >> short names, and that URIs could be used for anything else. > >No, I appreciate that you want to use registered short names in the >protocol, that's just fine. My problem is that you have left users, >developers etc. with no way to discover what shortnames have been >registered short of a non-trivial and error-prone informal search >effort. > >What I'm asking for is support for probe URI prefixes for each family >of shortnames. So, just as today I use "text/n3" as the media type for >my Notation3 documents, I can check that this is a registered media >type by attempting to retrieve > > http://www.iana.org/assignments/media-types/text/n3 > >and I can see all the registered text types by retrieving from > > http://www.iana.org/assignments/media-types/text > >likewise I ought to be able to check e.g. the "bearer" token type by >attempting retrieval from (something along the lines of) > > http://www.iana.org/assignments/access-token-types/bearer > >and I should be able to see all the registered token types by retrieving f= rom > > http://www.iana.org/assignments/access-token-types > >Hope this clarifies what I meant. > >> Minor Issues: > >> A short summary of the changes from OAuth 1.0/RFC5849 would have >> been helpful, and it might still be a good idea to add one. . . > >> I don't think this is possible. OAuth2 is built nfundamentally >> differently from OAuth1, so this paragraph might as well read "just >> about everything but the concept". Suggestion: don't add this, >> unless someone can come up with a succinct way to summarize the >> decision to build on a new foundation. > >OK, thanks. Even something like the above short statement would be >useful . . . > >> 4.1 Would it be helpful to indicate that steps D&E may occur at >> any time after C, and may be repeated subsequently? > >> D&E may be delayed, but shouldn't be repeated. The Access Code is >> one-time-use, and in the best deployments will expire after a short >> period of time. Suggestion: leave as is. > >OK, I just think as it is it invites misinterpretation. > >> 11.1 It might be useful to have an 11.1.2, which repeats references >> to the bearer and mac access token type registration drafts? > >> Is this a request to pre-register the two 'core' token types? > >Yes, in that what I had in mind was making 11.1 parallel to ll.2, 3 >and 4 in this regard. > >ht > >[I'm sorry about the mailing list confusion. But please don't punish > me again by sending HTML change bar markup which I have to hand edit :-] >--=20 > Henry S. Thompson, School of Informatics, University of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is forged = spam] > > >------------------------------ > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > > >End of OAuth Digest, Vol 40, Issue 12 >************************************* From eran@hueniverse.com Tue Feb 14 22:32:51 2012 Return-Path: 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 B35E121F86C3 for ; Tue, 14 Feb 2012 22:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 MFflw5V5XcIz for ; Tue, 14 Feb 2012 22:32:50 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id DCE6821F86C7 for ; Tue, 14 Feb 2012 22:32:50 -0800 (PST) Received: (qmail 26856 invoked from network); 15 Feb 2012 06:32:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Feb 2012 06:32:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Tue, 14 Feb 2012 23:32:49 -0700 From: Eran Hammer To: OAuth WG Date: Tue, 14 Feb 2012 23:32:41 -0700 Thread-Topic: OAuth 2.0 LC conclusion Thread-Index: Aczrq3WfTOTtCjoOSGGvOv82lOxoug== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AADDDA68@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AADDDA68P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth 2.0 LC conclusion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 06:32:51 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDDA68P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Last call ended 2/6. I have got some notes but nothing significant. I think= I can resolve all of them with editorial tweaks. I am planning on posting = -24 this week and get this ready for IESG review. Any comments? EH --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDDA68P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Last call ended = 2/6. I have got some notes but nothing significant. I think I can resolve a= ll of them with editorial tweaks. I am planning on posting -24 this week an= d get this ready for IESG review.

&= nbsp;

Any comments?

 

EH

= = --_000_90C41DD21FB7C64BB94121FBBC2E723453AADDDA68P3PW5EX1MB01E_-- From haibin.song@huawei.com Wed Feb 15 01:33:42 2012 Return-Path: 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 ADE2421F8737; Wed, 15 Feb 2012 01:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UFpVpL4vbL0O; Wed, 15 Feb 2012 01:33:42 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id EF71621F855F; Wed, 15 Feb 2012 01:33:41 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZF00I1BH5U2B@szxga03-in.huawei.com>; Wed, 15 Feb 2012 17:32:18 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZF0015JH5UW6@szxga03-in.huawei.com>; Wed, 15 Feb 2012 17:32:18 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGV90365; Wed, 15 Feb 2012 17:32:17 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Feb 2012 17:32:07 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.222]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Wed, 15 Feb 2012 17:31:56 +0800 Date: Wed, 15 Feb 2012 09:33:22 +0000 From: Songhaibin X-Originating-IP: [10.138.41.129] To: "tsv-ads@tools.ietf.org" , "draft-ietf-oauth-v2@tools.ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: tsv-dir review of draft-ietf-oauth-v2-23 Thread-index: AczrxK1m0Cmrx5G1TqO2SHCpS5HjoQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 15 Feb 2012 05:23:00 -0800 Cc: Martin Stiemerling , "oauth@ietf.org" , "tsv-dir@ietf.org" Subject: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 09:33:42 -0000 I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. First, I should apologize for the delay in this review, I should have finished it two days ago. I have some common security knowledge but not an expert. Summary This draft is basically ready for publication, but has nits that should be fixed before publication. General issues need discussion: 1. Section 1.3.3 and 1.3.4 discuss two authorization grant type: resource owner password credentials, and client credentials. These two have the same flow and many in common, and they are significantly different than the authorization code grant type and implicit grant type described in previous sections. And in section 1.3.4, it also says " Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner),...". Is it better to combine these two grant types as one "client credentials" grant type where the client can be the resource owner? 2. Two concepts confused me in section 2.4, I don't know if I am the only person who is confusing here. One is user-agent-based application and another is native application, why are they executed on the device used by the resource owner? I think they can run on any device used by resource consumer instead of resource owner. Resource owner is only used to grant access to resources. Nits: 1. Section 3.1, paragraph 4, the last sentence is confusing, is it the authorization server who sends the request to the authorization endpoint? Or is it the resource owner? 2. Section 3.1.1, paragraph 3, "...where the order of values does not matter.." I think a little clarification on the reason for this would be better for people like me. 3. Section 3.2, paragraph 4, the last sentence is confusing, is it the authorization server who sends request to the token endpoint? 4. Section 10.12, paragraph 4, should the terminology "end-user" be changed to "resource owner"? There are same issues in other places of this document. 5. Section 10.6, paragraph 2, second sentence, When the attacker is sent to.../ When the authorization code request is sent to... Kind regards, -Haibin From jricher@mitre.org Wed Feb 15 05:46:04 2012 Return-Path: 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 77C5521F8709; Wed, 15 Feb 2012 05:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 L2glbgUQVz4e; Wed, 15 Feb 2012 05:46:03 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E99FD21F86E4; Wed, 15 Feb 2012 05:45:53 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 61A1121B0BEA; Wed, 15 Feb 2012 08:45:53 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3C2E421B09CA; Wed, 15 Feb 2012 08:45:53 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 15 Feb 2012 08:45:52 -0500 Message-ID: <4F3BB6B8.1030501@mitre.org> Date: Wed, 15 Feb 2012 08:44:24 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Songhaibin References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: "draft-ietf-oauth-v2@tools.ietf.org" , "tsv-ads@tools.ietf.org" , "tsv-dir@ietf.org" , "oauth@ietf.org" , Martin Stiemerling Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 13:46:04 -0000 On 02/15/2012 04:33 AM, Songhaibin wrote: > I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. > > First, I should apologize for the delay in this review, I should have finished it two days ago. I have some common security knowledge but not an expert. > > Summary > > This draft is basically ready for publication, but has nits that should be fixed before publication. > > General issues need discussion: > > 1. Section 1.3.3 and 1.3.4 discuss two authorization grant type: resource owner password credentials, and client credentials. These two have the same flow and many in common, and they are significantly different than the authorization code grant type and implicit grant type described in previous sections. And in section 1.3.4, it also says " Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner),...". Is it better to combine these two grant types as one "client credentials" grant type where the client can be the resource owner? No, they are quite distinct -- It all comes down to what you're authenticating. The Resource Owner Password Credentials flow *also* includes client credentials which are distinct from the resource owner's own credentials. The client's credentials are going to be the same for a given client across many different users, while the Resource Owner's credentials are going to be different across different users, but the same across different clients (for the same resource owner). In most flows, the client's credentials identify just the client, and the resource owner is identified through some other means (a direct password, a redirected login to the authz endpoint). In the Client Credentials flow, the client's credentials are the only ones that you have. > 2. Two concepts confused me in section 2.4, I don't know if I am the only person who is confusing here. One is user-agent-based application and another is native application, why are they executed on the device used by the resource owner? I think they can run on any device used by resource consumer instead of resource owner. Resource owner is only used to grant access to resources. OAuth's main 3-legged pattern allows what's called "Alice-to-Alice sharing", in that the Client is consuming on behalf of the resource owner. In cases where you have an in-user-agent app or a native app, the end user (resource owner) is going to be the one running it, and the one authorizing it. Thanks for your feedback, and I hope this can help clear up the intent of the working group here. If you can suggest language that will solidify these points further, it can help make sure this doesn't further confuse people. -- Justin From barryleiba.mailing.lists@gmail.com Wed Feb 15 15:09:25 2012 Return-Path: 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 D7EFD21F8499 for ; Wed, 15 Feb 2012 15:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 mPEcQRGXtiuE for ; Wed, 15 Feb 2012 15:09:18 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84FFE21F8476 for ; Wed, 15 Feb 2012 15:09:18 -0800 (PST) Received: by ggnq2 with SMTP id q2so1133685ggn.31 for ; Wed, 15 Feb 2012 15:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DSRB3bsLAVQ6+MjHhlJKnpdo7fWUr33Ob8kCoZDTYAM=; b=adu7D7ZmmX0tXC1GUnB7RRq2B5moEp8fA4x4kDn7RBxkXZKsUTRqYFfqgK6FN/Wa7O ulAIePUgeHa54mlKbx+AkgrNe3odHMQtcX5fqGa7crhQ9HLUp6nypKQ1dzfFxQlpER6N GVallpWZ3zWU4QgsipJ/VjPkTUNjZpDEWODiI= MIME-Version: 1.0 Received: by 10.236.197.33 with SMTP id s21mr187165yhn.40.1329347358190; Wed, 15 Feb 2012 15:09:18 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Wed, 15 Feb 2012 15:09:18 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AADDDA68@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453AADDDA68@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 15 Feb 2012 18:09:18 -0500 X-Google-Sender-Auth: njyXl8fopc-s1YHitu_NFZ6VDQo Message-ID: From: Barry Leiba To: Eran Hammer Content-Type: multipart/alternative; boundary=20cf303f6ad6116b9e04b908cdc7 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.0 LC conclusion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 23:09:25 -0000 --20cf303f6ad6116b9e04b908cdc7 Content-Type: text/plain; charset=ISO-8859-1 Do you have changes to make based on the Apps and TSV Directorate reviews? Barry --20cf303f6ad6116b9e04b908cdc7 Content-Type: text/html; charset=ISO-8859-1 Do you have changes to make based on the Apps and TSV Directorate reviews?

Barry
--20cf303f6ad6116b9e04b908cdc7-- From eran@hueniverse.com Wed Feb 15 17:34:27 2012 Return-Path: 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 EBD8521E803E for ; Wed, 15 Feb 2012 17:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] 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 TqrQrjtiPfPt for ; Wed, 15 Feb 2012 17:34:27 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 6C7E321E800E for ; Wed, 15 Feb 2012 17:34:27 -0800 (PST) Received: (qmail 7832 invoked from network); 16 Feb 2012 01:34:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Feb 2012 01:34:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 15 Feb 2012 18:34:23 -0700 From: Eran Hammer To: Barry Leiba Date: Wed, 15 Feb 2012 18:34:21 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 LC conclusion Thread-Index: AczsSxyPoOSUy5oeS6W6LPx7XXN+AA== Message-ID: <7D27AB20-5F74-4979-9286-93789A493DAD@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E723453AADDDA68@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.0 LC conclusion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 01:34:28 -0000 Purely editorial.=20 EH On Feb 15, 2012, at 15:09, "Barry Leiba" wrote: > Do you have changes to make based on the Apps and TSV Directorate reviews= ? >=20 > Barry From ngarthl@gmail.com Thu Feb 16 01:55:55 2012 Return-Path: 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 22AF821F8675 for ; Thu, 16 Feb 2012 01:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 AlKTgRgbF+z1 for ; Thu, 16 Feb 2012 01:55:54 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9535521F861E for ; Thu, 16 Feb 2012 01:55:53 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3175730obb.31 for ; Thu, 16 Feb 2012 01:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dBmo4Id7o0nlm9KCWQ7nd1SQmp0blVS8lz7JLdODP44=; b=LGTlcI8rvlKdoaqhWBoj2hmQ9v8ua6rHtYs9QskNIoOTT5X4dLeCc6RO9WSjwXWRan fccXSAI5Nk6z+8o6SV4wer0BU6/P0kcKBNS6t2Soo4dH+GUkBnhfHzfIF8jtI0feqyEi nJdoPJ7OKI0GzN7f967YcySfFEpViPgFR6vPc= MIME-Version: 1.0 Received: by 10.182.2.135 with SMTP id 7mr1315890obu.78.1329386153179; Thu, 16 Feb 2012 01:55:53 -0800 (PST) Received: by 10.182.117.70 with HTTP; Thu, 16 Feb 2012 01:55:53 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114EBBDE0DD@WSMSG3153V.srv.dir.telstra.com> References: <20120208175209.30915.17732.idtracker@ietfa.amsl.com> <90C41DD21FB7C64BB94121FBBC2E723453AADDD3F6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E114EBBDE0DD@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 16 Feb 2012 10:55:53 +0100 Message-ID: From: Erlend Hamnaberg To: "Manger, James H" Content-Type: multipart/alternative; boundary=f46d044519e36dfba304b911d5f7 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 09:55:55 -0000 --f46d044519e36dfba304b911d5f7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments inline: On Thu, Feb 9, 2012 at 7:51 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Eran, a couple of comments on the new MAC spec: > > The example (=A71.1) does not seem to be correct. That is, I calculate > mac=3D"6T3zZzy2Emppni6bzL7kdRxUWL4=3D" instead of the given value. > I get this as well. > The example in =A73.2.1 has a typo. It says "using timestamp > "264095:7d8f3e4a"", but should say "using timestamp "264095"". > > +1 > Timestamp verification (=A74.1) is described as preventing replay attacks= . > However, the 3 dot points that server MUST do only ensure that requests > (other than the first) are approximately fresh (assuming the first was > fresh). Of course, it is fairly obvious that the service can keep a copy = of > {ts,nonce,id} tuples (while the ts is still approximately fresh) to detec= t > replays. > > When the ts field is defined (=A73.1) it is probably worth mentioning tha= t > the fixed point in time (epoch) chosen to calculate ts MUST remain the sa= me > for the lifetime of the key. That is, a client app cannot pick a new epoc= h > each time it starts if it is using the same key across restarts. > > Personally, I would almost prefer it to say: ts is seconds since 1970 wer= e > possible; clients without a real-time clock can choose an arbitrary epoch= , > but it must remain the same for the lifetime of the key; servers SHOULD N= OT > assume client clocks are well synchronized to their own. It is RECOMMENDE= D > that a server assumes the 1st request with a given key is fresh, and use > the ts value in that request to determine the offset between the client & > servers clocks. That offset (assumed to remain constant) can be used to > determine if subsequent requests are fresh. > > Seems reasonable. -E --f46d044519e36dfba304b911d5f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments inline:

On Thu, Feb 9, 2012 at 7= :51 AM, Manger, James H <James.H.Manger@team.telstra.com> wrote:=
Eran, a couple of comments on the new MAC sp= ec:

The example (=A71.1) does not seem to be correct. That is, I calculate mac= =3D"6T3zZzy2Emppni6bzL7kdRxUWL4=3D" instead of the given value.

I get this as well.

=

The example in =A73.2.1 has a typo. It says "using timestamp "264= 095:7d8f3e4a"", but should say "using timestamp "264095= "".

+1
=A0
Timestamp verification (=A74.1) is described as preventing replay attacks. = However, the 3 dot points that server =A0MUST do only ensure that requests = (other than the first) are approximately fresh (assuming the first was fres= h). Of course, it is fairly obvious that the service can keep a copy of {ts= ,nonce,id} tuples (while the ts is still approximately fresh) to detect rep= lays.

When the ts field is defined (=A73.1) it is probably worth mentioning that = the fixed point in time (epoch) chosen to calculate ts MUST remain the same= for the lifetime of the key. That is, a client app cannot pick a new epoch= each time it starts if it is using the same key across restarts.

Personally, I would almost prefer it to say: ts is seconds since 1970 were = possible; clients without a real-time clock can choose an arbitrary epoch, = but it must remain the same for the lifetime of the key; servers SHOULD NOT= assume client clocks are well synchronized to their own. It is RECOMMENDED= that a server assumes the 1st request with a given key is fresh, and use t= he ts value in that request to determine the offset between the client &= ; servers clocks. That offset (assumed to remain constant) can be used to d= etermine if subsequent requests are fresh.

Seems reasonable.

-E
=A0
--f46d044519e36dfba304b911d5f7-- From Michael.Jones@microsoft.com Thu Feb 16 10:16:27 2012 Return-Path: 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 E848721F887C for ; Thu, 16 Feb 2012 10:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.26 X-Spam-Level: X-Spam-Status: No, score=-5.26 tagged_above=-999 required=5 tests=[AWL=1.338, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 TUGLMSPqPAfs for ; Thu, 16 Feb 2012 10:16:24 -0800 (PST) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id DA1C921F8860 for ; Thu, 16 Feb 2012 10:16:23 -0800 (PST) Received: from mail85-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 Feb 2012 18:16:23 +0000 Received: from mail85-tx2 (localhost [127.0.0.1]) by mail85-tx2-R.bigfish.com (Postfix) with ESMTP id 2B0BE4A0294 for ; Thu, 16 Feb 2012 18:16:23 +0000 (UTC) X-SpamScore: -24 X-BigFish: VS-24(zzc85fh4015Lzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail85-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail85-tx2 (localhost.localdomain [127.0.0.1]) by mail85-tx2 (MessageSwitch) id 1329416181439551_14417; Thu, 16 Feb 2012 18:16:21 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.235]) by mail85-tx2.bigfish.com (Postfix) with ESMTP id 5C463380275 for ; Thu, 16 Feb 2012 18:16:21 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 Feb 2012 18:16:17 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0247.005; Thu, 16 Feb 2012 10:16:05 -0800 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Ignoring unrecognized request parameters Thread-Index: Aczs1wtn/6RuTd6FSU2gMdrvLPHe9Q== Date: Thu, 16 Feb 2012 18:16:04 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943663A7EA2@TK5EX14MBXC284.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.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943663A7EA2TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] Ignoring unrecognized request parameters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:16:28 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943663A7EA2TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In core -23, the last paragraph of section 3.1 now says: The authorization server MUST ignore unrecognized request p= arameters. In -22, this said: The authorization server SHOULD ignore unrecognized request= parameters. In a security protocol, it seems unreasonable to require that information b= e ignored. As I see it, it SHOULD be legal to return an error if unrecogni= zed information is received. Why the change? And can we please have it changed back to SHOULD in -24? Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943663A7EA2TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In core -23, the last paragraph of section 3.1 now says:

 

        &nbs= p;       The authorization server MUST ignore= unrecognized request parameters.

 

In -22, this said:

 

        &nbs= p;       The authorization server SHOULD igno= re unrecognized request parameters.

 

In a security protocol, it seems unreasonable to req= uire that information be ignored.  As I see it, it SHOULD be legal to = return an error if unrecognized information is received.

 

Why the change?  And can we please have it chan= ged back to SHOULD in -24?

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Thanks,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_4E1F6AAD24975D4BA5B1680429673943663A7EA2TK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Thu Feb 16 10:22:37 2012 Return-Path: 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 8D9CC21F841B for ; Thu, 16 Feb 2012 10:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.793 X-Spam-Level: X-Spam-Status: No, score=-3.793 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 gKSrDisvinUZ for ; Thu, 16 Feb 2012 10:22:30 -0800 (PST) Received: from DB3EHSOBE001.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id CA35821F8715 for ; Thu, 16 Feb 2012 10:22:29 -0800 (PST) Received: from mail107-db3-R.bigfish.com (10.3.81.229) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 Feb 2012 18:22:29 +0000 Received: from mail107-db3 (localhost [127.0.0.1]) by mail107-db3-R.bigfish.com (Postfix) with ESMTP id BCA0E4054F for ; Thu, 16 Feb 2012 18:22:28 +0000 (UTC) X-SpamScore: -25 X-BigFish: VS-25(zz9371Ic85fh4015Lzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail107-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail107-db3 (localhost.localdomain [127.0.0.1]) by mail107-db3 (MessageSwitch) id 1329416546933822_8732; Thu, 16 Feb 2012 18:22:26 +0000 (UTC) Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.248]) by mail107-db3.bigfish.com (Postfix) with ESMTP id D64762004B for ; Thu, 16 Feb 2012 18:22:26 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 Feb 2012 18:22:23 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0247.005; Thu, 16 Feb 2012 10:22:10 -0800 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Ignoring unrecognized request parameters Thread-Index: Aczs1wtn/6RuTd6FSU2gMdrvLPHe9QAAJ0OQ Date: Thu, 16 Feb 2012 18:22:09 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943663A7F0E@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943663A7EA2@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663A7EA2@TK5EX14MBXC284.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.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943663A7F0ETK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:22:38 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943663A7F0ETK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And same change requested in 3.2 4.1.2, and 4.2.2, which also require ignor= ing unrecognized parameters. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Thursday, February 16, 2012 10:16 AM To: oauth@ietf.org Subject: [OAUTH-WG] Ignoring unrecognized request parameters In core -23, the last paragraph of section 3.1 now says: The authorization server MUST ignore unrecognized request p= arameters. In -22, this said: The authorization server SHOULD ignore unrecognized request= parameters. In a security protocol, it seems unreasonable to require that information b= e ignored. As I see it, it SHOULD be legal to return an error if unrecogni= zed information is received. Why the change? And can we please have it changed back to SHOULD in -24? Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943663A7F0ETK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And same change reques= ted in 3.2 4.1.2, and 4.2.2, which also require ignoring unrecognized param= eters.

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, February 16, 2012 10:16 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Ignoring unrecognized request parameters

 

In core -23, the last paragraph of section 3.1 now says:

 

        &nbs= p;       The authorization server MUST ignore= unrecognized request parameters.

 

In -22, this said:

 

        &nbs= p;       The authorization server SHOULD igno= re unrecognized request parameters.

 

In a security protocol, it seems unreasonable to req= uire that information be ignored.  As I see it, it SHOULD be legal to = return an error if unrecognized information is received.

 

Why the change?  And can we please have it chan= ged back to SHOULD in -24?

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Thanks,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_4E1F6AAD24975D4BA5B1680429673943663A7F0ETK5EX14MBXC284r_-- From wmills@yahoo-inc.com Thu Feb 16 10:33:08 2012 Return-Path: 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 EE35421F87AF for ; Thu, 16 Feb 2012 10:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.169 X-Spam-Level: X-Spam-Status: No, score=-17.169 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 TB2RtyNQSztT for ; Thu, 16 Feb 2012 10:33:04 -0800 (PST) Received: from nm12-vm3.bullet.mail.ne1.yahoo.com (nm12-vm3.bullet.mail.ne1.yahoo.com [98.138.91.142]) by ietfa.amsl.com (Postfix) with SMTP id CE14021F871B for ; Thu, 16 Feb 2012 10:33:02 -0800 (PST) Received: from [98.138.90.49] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 16 Feb 2012 18:32:59 -0000 Received: from [98.138.89.167] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 16 Feb 2012 18:32:59 -0000 Received: from [127.0.0.1] by omp1023.mail.ne1.yahoo.com with NNFMP; 16 Feb 2012 18:32:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 491829.49645.bm@omp1023.mail.ne1.yahoo.com Received: (qmail 45197 invoked by uid 60001); 16 Feb 2012 18:32:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1329417179; bh=O10/jyfuwDMV7435bpJGnhqdspA00dWKcsnD+MIzfUY=; 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=TmRHSYWXMVi7pCRv+vVOgntvRfRdUniS5BU0pWjjce/IGYDrgSicRzqzYDyZKDdEQt1ueEkWYKnE7wKxwJn9cHFj+Z4wAHQW6Khij+X/BTK+PqIS8tsRWSlL/KxN4XbLIjem/pTf7/PsvcVwbwjnaFqJ0dKt3SopO0I53dZv5uo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; 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=YX/I3mUmQGFqIWBNdSZz7bX8P22zZSPX7Udc+zmooUBOPy8vsbUQuLKk6xvZZw2yE7VUI1WmXQuVjFLVOjw5W7DEo4oJ2oko1DGPRbq1mFs4CAHeYeVwazHR5bZbig1a4cdXZP0S/ngYw6xJcpLIpcVRqI0YfQdlW6zpr/1Gqx4=; X-YMail-OSG: toElbd0VM1mBCfoRMXWwG8XGU5OhJJqncfwOCtWgUStSytR pTStFDUnnuM1m.GKF.JE8lURbNn8zFedUJzMaHnT7LOF84TurvjopyVDzgL7 Dhye50bFzjFis4rwKMXUA66dgDx1FBKK5EIfKq6_WwtOXciXsH.GfiFpoeAe FBsquXKAK69FQVdYIlW1kk.UMw5_YqK2a2mufk38ngOgvp3YZt0sBwuKKb4W VfMaANpV34T7fLvNYiXcaWwP2UY9yu7ZKN8pINsGUBqsAtno2n_BUMAOzwzv Q4oyPao3hQh0LnmWXUNodt_A1xtNFItTQbaIJMcijtaT9JgE9kO9nyyJvqzz no8E3y0IkDwfaPju9UXVcl1sUH50J7_DuzC3REmSaN0m9rU4Do0XPPLrRtNl zYqsy7_.RFpmM.BJ7DVMv7zyf5r4Y1J3IAzzWeObD2Qg44N1mQQ-- Received: from [209.131.62.115] by web31809.mail.mud.yahoo.com via HTTP; Thu, 16 Feb 2012 10:32:59 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340031 References: <4E1F6AAD24975D4BA5B1680429673943663A7EA2@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <1329417179.41387.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Thu, 16 Feb 2012 10:32:59 -0800 (PST) From: William Mills To: Mike Jones , "oauth@ietf.org" In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663A7EA2@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-1932656056-1329417179=:41387" Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:33:09 -0000 ---1395015409-1932656056-1329417179=:41387 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable No, this is required for forward compatibility.=A0 Implementations that sen= d extended parameters like capability advertisements (i.e. CAPTCHA support = or something) shoudl not be broken hitting older implementations.=0A=0A=0A= =0A________________________________=0A From: Mike Jones =0ATo: "oauth@ietf.org" =0ASent: Thursday, Febru= ary 16, 2012 10:16 AM=0ASubject: [OAUTH-WG] Ignoring unrecognized request p= arameters=0A =0A=0A =0AIn core -23, the last paragraph of section 3.1 now s= ays:=0A=A0=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The authorizatio= n server MUST ignore unrecognized request parameters.=0A=A0=0AIn -22, this = said:=0A=A0=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The authorizati= on server SHOULD ignore unrecognized request parameters.=0A=A0=0AIn a secur= ity protocol, it seems unreasonable to require that information be ignored.= =A0 As I see it, it SHOULD be legal to return an error if unrecognized info= rmation is received.=0A=A0=0AWhy the change?=A0 And can we please have it c= hanged back to SHOULD in -24?=0A=A0=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Thanks,=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike=0A=A0=0A____= ___________________________________________=0AOAuth mailing list=0AOAuth@ie= tf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth ---1395015409-1932656056-1329417179=:41387 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
No, this is required for forward compatibility.  Implementations tha= t send extended parameters like capability advertisements (i.e. CAPTCHA sup= port or something) shoudl not be broken hitting older implementations.
<= /span>

From: Mike Jones <Michael.Jones@micros= oft.com>
To: "oauth= @ietf.org" <oauth@ietf.org>
Subject: [OAUTH-WG] Ignoring unrecognized request parame= ters

=0A
=0A=0A =0A =0A=0A=0A
=0A
=0AIn core -23, the last paragraph of =0Asection 3.1 now says:
=0A
 
=0A
           &n= bsp;    The authorization server MUST ignore unrecognized re= quest parameters.
=0A
  =0A
In -22, this said:
=0A  
=0A
          &nb= sp;     The authorization server SHOULD ignore unrecogn= ized request parameters.
=0A
&nb= sp;
=0A
In a security protocol, i= t seems unreasonable to require that information be ignored.  As I see= it, it SHOULD be legal to return an error if unrecognized information is r= eceived.
=0A
 
=0AWhy the change?  And can we please h= ave it changed back to SHOULD in -24?
=0A
 
=0A
  =             &nb= sp;            =             &nb= sp;            =             Thanks,<= /div> =0A
     = ;            &n= bsp;            = ;            &n= bsp;            = ;         -- Mike
=0A
 
=0A
=0A
=0A=0A
_______________________________________________
OAuth mailing list
= OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth


<= /div>
---1395015409-1932656056-1329417179=:41387-- From mscurtescu@google.com Thu Feb 16 10:45:26 2012 Return-Path: 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 36A7D11E8074 for ; Thu, 16 Feb 2012 10:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 MPWD2fnQqyUE for ; Thu, 16 Feb 2012 10:45:22 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D66ED11E8087 for ; Thu, 16 Feb 2012 10:45:21 -0800 (PST) Received: by yenm3 with SMTP id m3so1651875yen.31 for ; Thu, 16 Feb 2012 10:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=/kv3cBPqccqDWd3vGf0N6MuIC7Q9E0bUR/GxJmmfBT4=; b=pG7YZkw6zZV4CAuRmQG1yGRZyaf3pKujDDeJrcV6tvTE8vRApKGL/eOm5fJ1eH2XEJ ZVQdsSfXnMDrCE9M7fEAF7ob2DLkGLPmT3qY6i/ceW8ngY8+Rpr11UjQZ9zGZDTwNAa5 Qiqpnq40S3LLucqzMGmGjN6p9aocEQsYIDHJI= Received: by 10.236.201.230 with SMTP id b66mr5112775yho.82.1329417921377; Thu, 16 Feb 2012 10:45:21 -0800 (PST) Received: by 10.236.201.230 with SMTP id b66mr5112755yho.82.1329417921290; Thu, 16 Feb 2012 10:45:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.55.23 with HTTP; Thu, 16 Feb 2012 10:45:01 -0800 (PST) In-Reply-To: <1329417179.41387.YahooMailNeo@web31809.mail.mud.yahoo.com> References: <4E1F6AAD24975D4BA5B1680429673943663A7EA2@TK5EX14MBXC284.redmond.corp.microsoft.com> <1329417179.41387.YahooMailNeo@web31809.mail.mud.yahoo.com> From: Marius Scurtescu Date: Thu, 16 Feb 2012 10:45:01 -0800 Message-ID: To: William Mills Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlbtQr1WPfhfkoZXgNT1rw0wrgn0AUBcTIkezvsNpTB0KQiq0KBUKK2IIqi0LevE6v2/gOyvxl35XXm31lD5WKz0z8LXAmgeZ1V0kB/38R+8uCXwYr3c08nAOPlY0MW7HCSf+va Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:45:26 -0000 +1 Yes, forward compatibility and extensions will be broken if unrecognized params are not allowed. Marius On Thu, Feb 16, 2012 at 10:32 AM, William Mills wrot= e: > No, this is required for forward compatibility.=A0 Implementations that s= end > extended parameters like capability advertisements (i.e. CAPTCHA support = or > something) shoudl not be broken hitting older implementations. > > ________________________________ > From: Mike Jones > To: "oauth@ietf.org" > Sent: Thursday, February 16, 2012 10:16 AM > Subject: [OAUTH-WG] Ignoring unrecognized request parameters > > In core -23, the last paragraph of section 3.1 now says: > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The authorization server MU= ST ignore unrecognized request > parameters. > > In -22, this said: > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The authorization server SH= OULD ignore unrecognized request > parameters. > > In a security protocol, it seems unreasonable to require that information= be > ignored.=A0 As I see it, it SHOULD be legal to return an error if unrecog= nized > information is received. > > Why the change?=A0 And can we please have it changed back to SHOULD in -2= 4? > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From mike@mtcc.com Thu Feb 16 10:48:11 2012 Return-Path: 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 910DB11E80A2 for ; Thu, 16 Feb 2012 10:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] 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 RuYW3RFfyk4E for ; Thu, 16 Feb 2012 10:48:06 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 9F61D21F87D7 for ; Thu, 16 Feb 2012 10:48:06 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q1GIm0U1008322 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 10:48:00 -0800 Message-ID: <4F3D4F60.4010101@mtcc.com> Date: Thu, 16 Feb 2012 10:48:00 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Marius Scurtescu References: <4E1F6AAD24975D4BA5B1680429673943663A7EA2@TK5EX14MBXC284.redmond.corp.microsoft.com> <1329417179.41387.YahooMailNeo@web31809.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1913; t=1329418085; x=1330282085; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20Ignoring=20unrecognized=20 request=20parameters |Sender:=20 |To:=20Marius=20Scurtescu=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=OqP3hFgSO/YEZX1KOMjfa3dg5H2malyOXQB58CG73yQ=; b=UVT7MWabPPbsA3LmFaWsi5RCb4T6QXCkMyqIFTPXOJAG9gfX8dyIeSLR3m zF3GkE2EeqgBrN60u2qJs8WJxaTJ3910STOgrw2d435pgIUSk86lOGgiSN0e j9ddlWjP8EaYSiSXcgt14MsQ/KxjZao8LJGnEtll7dj80DYtZ4Oj8=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:48:11 -0000 +1 On 02/16/2012 10:45 AM, Marius Scurtescu wrote: > +1 > > Yes, forward compatibility and extensions will be broken if > unrecognized params are not allowed. > > Marius > > > > On Thu, Feb 16, 2012 at 10:32 AM, William Mills wrote: >> No, this is required for forward compatibility. Implementations that send >> extended parameters like capability advertisements (i.e. CAPTCHA support or >> something) shoudl not be broken hitting older implementations. >> >> ________________________________ >> From: Mike Jones >> To: "oauth@ietf.org" >> Sent: Thursday, February 16, 2012 10:16 AM >> Subject: [OAUTH-WG] Ignoring unrecognized request parameters >> >> In core -23, the last paragraph of section 3.1 now says: >> >> The authorization server MUST ignore unrecognized request >> parameters. >> >> In -22, this said: >> >> The authorization server SHOULD ignore unrecognized request >> parameters. >> >> In a security protocol, it seems unreasonable to require that information be >> ignored. As I see it, it SHOULD be legal to return an error if unrecognized >> information is received. >> >> Why the change? And can we please have it changed back to SHOULD in -24? >> >> Thanks, >> -- Mike >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Thu Feb 16 10:55:30 2012 Return-Path: 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 815B521E801F for ; Thu, 16 Feb 2012 10:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 m0sSZ0LOeVpa for ; Thu, 16 Feb 2012 10:55:26 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C83121E8018 for ; Thu, 16 Feb 2012 10:55:26 -0800 (PST) Received: by yhkk25 with SMTP id k25so1649449yhk.31 for ; Thu, 16 Feb 2012 10:55:25 -0800 (PST) Received: by 10.236.9.33 with SMTP id 21mr5164065yhs.39.1329418525746; Thu, 16 Feb 2012 10:55:25 -0800 (PST) Received: from [192.168.1.213] (186-107-144-162.baf.movistar.cl. [186.107.144.162]) by mx.google.com with ESMTPS id h29sm11063948ann.16.2012.02.16.10.55.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Feb 2012 10:55:24 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_5E29FD83-6240-4E6F-8234-1B2EE6D2ADEA"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <1329417179.41387.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Thu, 16 Feb 2012 15:55:21 -0300 Message-Id: <95549D89-B2AB-4A40-96CE-C689DB07BF88@ve7jtb.com> References: <4E1F6AAD24975D4BA5B1680429673943663A7EA2@TK5EX14MBXC284.redmond.corp.microsoft.com> <1329417179.41387.YahooMailNeo@web31809.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkWgNxiGIf8jKk1K623oCiDy3A6H6xDozx3HkmqMCI3DFEcW1iInqc3qxffrzo136+/ncsm Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:55:30 -0000 --Apple-Mail=_5E29FD83-6240-4E6F-8234-1B2EE6D2ADEA Content-Type: multipart/alternative; boundary="Apple-Mail=_9591F660-CF2A-4645-9864-0EBAE9BE6EB1" --Apple-Mail=_9591F660-CF2A-4645-9864-0EBAE9BE6EB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 If you have a generic client that works across multiple Authorization = endpoints some that have extension X and others not, I can see that = having the Authorization servers ignore unknown parameters is desirable. However there are some endpoints that are not going to be able to allow = unknown parameters due to there security policy. They are often a = indication of an attack. If this remains a MUST then some endpoints will have to ignore it, and = be non compliant. I would be OK with something like "MUST ignore unknown parameters unless = the endpoint is required to return an error due to local security = policy." There is probably no perfect compromise on this one. John B. On 2012-02-16, at 3:32 PM, William Mills wrote: > No, this is required for forward compatibility. Implementations that = send extended parameters like capability advertisements (i.e. CAPTCHA = support or something) shoudl not be broken hitting older = implementations. >=20 > From: Mike Jones > To: "oauth@ietf.org" =20 > Sent: Thursday, February 16, 2012 10:16 AM > Subject: [OAUTH-WG] Ignoring unrecognized request parameters >=20 > In core -23, the last paragraph of section 3.1 now says: > =20 > The authorization server MUST ignore unrecognized = request parameters. > =20 > In -22, this said: > =20 > The authorization server SHOULD ignore unrecognized = request parameters. > =20 > In a security protocol, it seems unreasonable to require that = information be ignored. As I see it, it SHOULD be legal to return an = error if unrecognized information is received. > =20 > Why the change? And can we please have it changed back to SHOULD in = -24? > =20 > = Thanks, > -- = Mike > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_9591F660-CF2A-4645-9864-0EBAE9BE6EB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 If = you have a generic client that works across multiple Authorization = endpoints some that have extension X and others not, I can see that = having the Authorization servers ignore unknown parameters is = desirable.

However there are some endpoints that are = not going to be able to allow unknown parameters due to there security = policy.   They are often a indication of an = attack.

If this remains a MUST then some = endpoints will have to ignore it, and be non = compliant.

I would be OK with something like = "MUST ignore unknown parameters unless the endpoint is required to = return an error due to local security = policy."

There is probably no perfect = compromise on this one.

John = B.


On 2012-02-16, at = 3:32 PM, William Mills wrote:

No, = this is required for forward compatibility.  Implementations that = send extended parameters like capability advertisements (i.e. CAPTCHA = support or something) shoudl not be broken hitting older = implementations.

=
From: Mike Jones <Michael.Jones@microsoft.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, February 16, = 2012 10:16 AM
Subject: [OAUTH-WG] Ignoring unrecognized request = parameters

=20 =20
In core -23, the last paragraph of = section 3.1 now says:
=20
 
=20
       =          The authorization = server MUST ignore unrecognized request parameters.
=20
 
=20
In -22, this said:
=20
 
=20
       =          The authorization = server SHOULD ignore unrecognized request parameters.
=20
 
=20
In a security protocol, it seems = unreasonable to require that information be ignored.  As I see it, = it SHOULD be legal to return an error if unrecognized information is = received.
=20
 
=20
Why the change?  And can we = please have it changed back to SHOULD in -24?
=20
 
=20
       =             &n= bsp;           &nbs= p;            =             &n= bsp;       Thanks,
=20
       =             &n= bsp;           &nbs= p;            =             &n= bsp;       -- Mike
=20
 
=20

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
=
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_9591F660-CF2A-4645-9864-0EBAE9BE6EB1-- --Apple-Mail=_5E29FD83-6240-4E6F-8234-1B2EE6D2ADEA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MTYxODU1MjFaMCMGCSqGSIb3DQEJBDEWBBQo5DwPtRv7ccjBlWp4xCkwpLfAsTCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQAmbIMzO22OQB1NsITswGwd+c+vCHd2pl0EVb8a+ij1FzAg4v5UVQWusXUXfEyqZWCuA2b3SMQ/ LcMhxZTh7GQ3e9VRiHI4PNk0TvnI2Y0mKqIAcsameUoN836iAdIsOufM1nUzNNO/VYPid3bNaMoV ADBtoJZi7SsPsIGv2G7FvcKqndvfSzLBE3X6nPmY/4gdHr7tcbzKUn3ewThnykb612oG+LKJXlTC YImM7hMa5QVxqhbEH0f8OOLWG8piiqxjqkL9g7j2xxV1hRfit0CYjT2GPRhsxKlzIwgEjdbcM/sb 6CPvwOdGdPpEQN2a+SgeXJi+KnW1uWnZVLmjtGkbAAAAAAAA --Apple-Mail=_5E29FD83-6240-4E6F-8234-1B2EE6D2ADEA-- From eran@hueniverse.com Thu Feb 16 15:01:43 2012 Return-Path: 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 3811821E8042 for ; Thu, 16 Feb 2012 15:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 3MKGegBmNkmF for ; Thu, 16 Feb 2012 15:01:39 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 0DB7521F87E4 for ; Thu, 16 Feb 2012 15:01:38 -0800 (PST) Received: (qmail 14975 invoked from network); 16 Feb 2012 23:01:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Feb 2012 23:01:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 16 Feb 2012 16:01:24 -0700 From: Eran Hammer To: John Bradley , William Mills Date: Thu, 16 Feb 2012 16:01:46 -0700 Thread-Topic: [OAUTH-WG] Ignoring unrecognized request parameters Thread-Index: Aczs/ueneCWSoMuBQtahNOsUaDEsOA== Message-ID: In-Reply-To: <95549D89-B2AB-4A40-96CE-C689DB07BF88@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB62CAAF12FF3eranhueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 23:01:43 -0000 --_000_CB62CAAF12FF3eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can you give an example where an unknown parameter being ignored can lead t= o security issues? EH From: John Bradley > Date: Thu, 16 Feb 2012 11:55:21 -0700 To: William Mills > Cc: "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters If you have a generic client that works across multiple Authorization endpo= ints some that have extension X and others not, I can see that having the A= uthorization servers ignore unknown parameters is desirable. However there are some endpoints that are not going to be able to allow unk= nown parameters due to there security policy. They are often a indication= of an attack. If this remains a MUST then some endpoints will have to ignore it, and be n= on compliant. I would be OK with something like "MUST ignore unknown parameters unless th= e endpoint is required to return an error due to local security policy." There is probably no perfect compromise on this one. John B. On 2012-02-16, at 3:32 PM, William Mills wrote: No, this is required for forward compatibility. Implementations that send = extended parameters like capability advertisements (i.e. CAPTCHA support or= something) shoudl not be broken hitting older implementations. ________________________________ From: Mike Jones > To: "oauth@ietf.org" > Sent: Thursday, February 16, 2012 10:16 AM Subject: [OAUTH-WG] Ignoring unrecognized request parameters In core -23, the last paragraph of section 3.1 now says: The authorization server MUST ignore unrecognized request p= arameters. In -22, this said: The authorization server SHOULD ignore unrecognized request= parameters. In a security protocol, it seems unreasonable to require that information b= e ignored. As I see it, it SHOULD be legal to return an error if unrecogni= zed information is received. Why the change? And can we please have it changed back to SHOULD in -24? Thanks, -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CB62CAAF12FF3eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Can you give an example = where an unknown parameter being ignored can lead to security issues?
=

EH


From: John Bradley <ve7jtb@ve7jtb.com>
Date: Thu, 16 Feb 2012 11:55:21 -0700
To: William Mills <wmills@yahoo-inc.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Ignoring unrecognized request param= eters

If you have= a generic client that works across multiple Authorization endpoints some t= hat have extension X and others not, I can see that having the Authorizatio= n servers ignore unknown parameters is desirable.

Howeve= r there are some endpoints that are not going to be able to allow unknown p= arameters due to there security policy.   They are often a indication = of an attack.

If this remains a MUST then some end= points will have to ignore it, and be non compliant.

I would be OK with something like "MUST ignore unknown parameters unless= the endpoint is required to return an error due to local security policy."=

There is probably no perfect compromise on this o= ne.

John B.


On 2012-02-16, at 3:32 PM, William Mills wrote:

No, this is required fo= r forward compatibility.  Implementations that send extended parameter= s like capability advertisements (i.e. CAPTCHA support or something) shoudl= not be broken hitting older implementations.

From:= Mike Jones <M= ichael.Jones@microsoft.com>
oauth@ietf.org" <= ;oauth@ietf.org>
Sent: Thursday, February 16, 2012 10:1= 6 AM
Subject: [OAUTH-WG] Ignoring unrecognized request parame= ters

=20 =20
In core -23, the last paragraph of section 3.1 now says:
=20
 
=20
      &n= bsp;         The authorization serv= er MUST ignore unrecognized request parameters.
=20
 
=20
In -22, this said:
=20
 
=20
      &n= bsp;         The authorization serv= er SHOULD ignore unrecognized request parameters.
=20
 
=20
In a security protocol, it seems unrea= sonable to require that information be ignored.  As I see it, it SHOUL= D be legal to return an error if unrecognized information is received.=20
 
=20
Why the change?  And can we pleas= e have it changed back to SHOULD in -24?
=20
 
=20
      &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       Thanks,
=20
      &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       -- Mike
=20
 
=20

_______________________________________________
OA= uth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th


_____________________________= __________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_CB62CAAF12FF3eranhueniversecom_-- From eran@hueniverse.com Thu Feb 16 15:09:02 2012 Return-Path: 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 2A78221E8029 for ; Thu, 16 Feb 2012 15:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 xMw01lxC9UxX for ; Thu, 16 Feb 2012 15:08:58 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A086E21E8051 for ; Thu, 16 Feb 2012 15:08:57 -0800 (PST) Received: (qmail 5197 invoked from network); 16 Feb 2012 23:08:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Feb 2012 23:08:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 16 Feb 2012 16:08:51 -0700 From: Eran Hammer To: Mike Jones , "oauth@ietf.org" Date: Thu, 16 Feb 2012 16:09:08 -0700 Thread-Topic: [OAUTH-WG] Ignoring unrecognized request parameters Thread-Index: Aczs//EtdmyQc80jSnWWdPtNtKkeyw== Message-ID: In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663A7EA2@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB62CBC612FF9eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 23:09:02 -0000 --_000_CB62CBC612FF9eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The change came from multiple feedback provided from AD and other reviews. = MUST is required to guarantee forward compatibility with future extensions.= This was a known issue in 1.0 when some clients added body_hash support an= d caused servers to fail for no reason. A server that is unaware of a new extension will remain at the same securit= y level if ignoring unknown extensions. The server can require new extensio= ns. Please demonstrate how this can lead to a less secure implementation. EH From: Mike Jones > Date: Thu, 16 Feb 2012 11:16:04 -0700 To: "oauth@ietf.org" > Subject: [OAUTH-WG] Ignoring unrecognized request parameters In core -23, the last paragraph of section 3.1 now says: The authorization server MUST ignore unrecognized request p= arameters. In -22, this said: The authorization server SHOULD ignore unrecognized request= parameters. In a security protocol, it seems unreasonable to require that information b= e ignored. As I see it, it SHOULD be legal to return an error if unrecogni= zed information is received. Why the change? And can we please have it changed back to SHOULD in -24? Thanks, -- Mike --_000_CB62CBC612FF9eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The change came from mul= tiple feedback provided from AD and other reviews. MUST is required to guar= antee forward compatibility with future extensions. This was a known issue = in 1.0 when some clients added body_hash support and caused servers to fail= for no reason.

A server that is unaware of a new = extension will remain at the same security level if ignoring unknown extens= ions. The server can require new extensions. Please demonstrate how this ca= n lead to a less secure implementation.

EH

From: Mike Jones= <Michael.Jones@microsoft= .com>
Date: Thu, 16 Feb = 2012 11:16:04 -0700
To: "oauth@ietf.org" <oauth@ietf.org>
Subje= ct: [OAUTH-WG] Ignoring unrecognized request parameters

In core -23,= the last paragraph of section 3.1 now says:

 <= /o:p>

       &= nbsp;        The authorization server MU= ST ignore unrecognized request parameters.

 

In -22, this said:

 

&= nbsp;           &nbs= p;   The authorization server SHOULD ignore unrecognized request = parameters.

 

In a security protocol, it seems unreasonable to require = that information be ignored.  As I see it, it SHOULD be legal to retur= n an error if unrecognized information is received.

 

Why the change?&= nbsp; And can we please have it changed back to SHOULD in -24?

 

 =             &nb= sp;            =             &nb= sp;            =              Th= anks,

     &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        -- Mike

 

 --_000_CB62CBC612FF9eranhueniversecom_-- From eran@hueniverse.com Thu Feb 16 15:14:27 2012 Return-Path: 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 F350121E8078 for ; Thu, 16 Feb 2012 15:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] 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 VV51AegEGvxi for ; Thu, 16 Feb 2012 15:14:22 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 4477C21E8051 for ; Thu, 16 Feb 2012 15:14:17 -0800 (PST) Received: (qmail 32196 invoked from network); 16 Feb 2012 23:14:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Feb 2012 23:14:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 16 Feb 2012 16:14:07 -0700 From: Eran Hammer To: "Manger, James H" , "oauth@ietf.org" Date: Thu, 16 Feb 2012 16:14:30 -0700 Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt Thread-Index: AcztAK75xHpFVOIFQtiRwRX/fm/qow== Message-ID: In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114EBBDE0DD@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 23:14:27 -0000 I haven't seen much feedback so I assume this is almost ready for LC. I will apply the suggestions below and will request a WGLC for -02. EH On 2/8/12 10:51 PM, "Manger, James H" wrote: >Eran, a couple of comments on the new MAC spec: > >The example (=A71.1) does not seem to be correct. That is, I calculate >mac=3D"6T3zZzy2Emppni6bzL7kdRxUWL4=3D" instead of the given value. > >The example in =A73.2.1 has a typo. It says "using timestamp >"264095:7d8f3e4a"", but should say "using timestamp "264095"". > >Timestamp verification (=A74.1) is described as preventing replay attacks. >However, the 3 dot points that server MUST do only ensure that requests >(other than the first) are approximately fresh (assuming the first was >fresh). Of course, it is fairly obvious that the service can keep a copy >of {ts,nonce,id} tuples (while the ts is still approximately fresh) to >detect replays. > >When the ts field is defined (=A73.1) it is probably worth mentioning that >the fixed point in time (epoch) chosen to calculate ts MUST remain the >same for the lifetime of the key. That is, a client app cannot pick a new >epoch each time it starts if it is using the same key across restarts. > >Personally, I would almost prefer it to say: ts is seconds since 1970 >were possible; clients without a real-time clock can choose an arbitrary >epoch, but it must remain the same for the lifetime of the key; servers >SHOULD NOT assume client clocks are well synchronized to their own. It is >RECOMMENDED that a server assumes the 1st request with a given key is >fresh, and use the ts value in that request to determine the offset >between the client & servers clocks. That offset (assumed to remain >constant) can be used to determine if subsequent requests are fresh. > >-- >James Manger > >-----Original Message----- >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of >Eran Hammer >Sent: Thursday, 9 February 2012 4:55 AM >To: oauth@ietf.org >Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt > >Main changes: > >Removed cookies support >Removed body hash >Clarified timestamp verification > >I still have more comments to process but wanted to get a new draft out >first as the current one expired. > >Please review the new timestamp prose and let me know what you think. I'm >trying to allow the client to use any timestamp it can easily produce, >and move the verification logic to the server as much as possible. > >EH > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of internet-drafts@ietf.org >> Sent: Wednesday, February 08, 2012 9:52 AM >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt >>=20 >>=20 >> 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. >>=20 >> Title : HTTP Authentication: MAC Access Authentication >> Author(s) : Eran Hammer-Lahav >> Filename : draft-ietf-oauth-v2-http-mac-01.txt >> Pages : 20 >> Date : 2012-02-08 >>=20 >> This document specifies the HTTP MAC access authentication scheme, an >> HTTP authentication method using a message authentication code (MAC) >> algorithm to provide cryptographic verification of portions of HTTP >> requests. The document also defines an OAuth 2.0 binding for use as >> an access-token type. >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-http-mac-01.txt From julian.reschke@gmx.de Fri Feb 17 00:17:04 2012 Return-Path: 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 DBAEE21E8017 for ; Fri, 17 Feb 2012 00:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.188 X-Spam-Level: X-Spam-Status: No, score=-104.188 tagged_above=-999 required=5 tests=[AWL=-1.589, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 M7EYhM5V-jcO for ; Fri, 17 Feb 2012 00:17:03 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 153B721E8015 for ; Fri, 17 Feb 2012 00:17:01 -0800 (PST) Received: (qmail invoked by alias); 17 Feb 2012 08:17:00 -0000 Received: from p5DCC2AA5.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.42.165] by mail.gmx.net (mp016) with SMTP; 17 Feb 2012 09:17:00 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX194Xo5EC2Z4lue1JZC+o5d4wvAUcn28HeIZYfJ4f9 3jPx6BdPs54oWb Message-ID: <4F3E0CF9.6030905@gmx.de> Date: Fri, 17 Feb 2012 09:16:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Eran Hammer References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 08:17:04 -0000 On 2012-02-17 00:14, Eran Hammer wrote: > I haven't seen much feedback so I assume this is almost ready for LC. I > will apply the suggestions below and will request a WGLC for -02. > > EH You should align with the Bearer spec on referencing httpbis P7, and apply some of the changes we discussed for that spec (challenge/credentials ABNF etc). Best regards, Julian From haibin.song@huawei.com Fri Feb 17 00:52:18 2012 Return-Path: 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 4497021F889A; Fri, 17 Feb 2012 00:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 cpe8JcCPUESW; Fri, 17 Feb 2012 00:52:17 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 14DDA21F8894; Fri, 17 Feb 2012 00:52:17 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZJ00EX24M0LO@szxga04-in.huawei.com>; Fri, 17 Feb 2012 16:51:36 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZJ008GI4LY34@szxga04-in.huawei.com>; Fri, 17 Feb 2012 16:51:36 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX41702; Fri, 17 Feb 2012 16:51:28 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 16:51:17 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.222]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Fri, 17 Feb 2012 16:51:26 +0800 Date: Fri, 17 Feb 2012 08:52:52 +0000 From: Songhaibin In-reply-to: <4F3BB6B8.1030501@mitre.org> X-Originating-IP: [10.138.41.129] To: Justin Richer Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 Thread-index: AczrxK1m0Cmrx5G1TqO2SHCpS5Hjof//wGMA//yqX4A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3BB6B8.1030501@mitre.org> Cc: "draft-ietf-oauth-v2@tools.ietf.org" , "tsv-ads@tools.ietf.org" , "tsv-dir@ietf.org" , "oauth@ietf.org" , Martin Stiemerling Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 08:52:18 -0000 Hi Justin, Thank you for the clarification. See in line. > -----Original Message----- > From: Justin Richer [mailto:jricher@mitre.org] > Sent: Wednesday, February 15, 2012 9:44 PM > To: Songhaibin > Cc: tsv-ads@tools.ietf.org; draft-ietf-oauth-v2@tools.ietf.org; Martin Stiemerling; > oauth@ietf.org; tsv-dir@ietf.org > Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 > > On 02/15/2012 04:33 AM, Songhaibin wrote: > > I've reviewed this document as part of the transport area directorate's ongoing > effort to review key IETF documents. These comments were written primarily for > the transport area directors, but are copied to the document's authors for their > information and to allow them to address any issues raised. The authors should > consider this review together with any other last-call comments they receive. > Please always CC tsv-dir@ietf.org if you reply to or forward this review. > > > > First, I should apologize for the delay in this review, I should have finished it two > days ago. I have some common security knowledge but not an expert. > > > > Summary > > > > This draft is basically ready for publication, but has nits that should be fixed > before publication. > > > > General issues need discussion: > > > > 1. Section 1.3.3 and 1.3.4 discuss two authorization grant type: resource owner > password credentials, and client credentials. These two have the same flow and > many in common, and they are significantly different than the authorization code > grant type and implicit grant type described in previous sections. And in section > 1.3.4, it also says " Client credentials are used as an authorization grant typically > when the client is acting on its own behalf (the client is also the resource > owner),...". Is it better to combine these two grant types as one "client > credentials" grant type where the client can be the resource owner? > > No, they are quite distinct -- It all comes down to what you're > authenticating. The Resource Owner Password Credentials flow *also* > includes client credentials which are distinct from the resource owner's > own credentials. The client's credentials are going to be the same for a > given client across many different users, while the Resource Owner's > credentials are going to be different across different users, but the > same across different clients (for the same resource owner). In most > flows, the client's credentials identify just the client, and the > resource owner is identified through some other means (a direct > password, a redirected login to the authz endpoint). In the Client > Credentials flow, the client's credentials are the only ones that you have. > Okay, in the Resource Owner Password Credentials flow, it adds client credentials, but any client who was issued credentials from the authorization server can pass. How much security does the client credential in this flow add? > > 2. Two concepts confused me in section 2.4, I don't know if I am the only person > who is confusing here. One is user-agent-based application and another is native > application, why are they executed on the device used by the resource owner? I > think they can run on any device used by resource consumer instead of resource > owner. Resource owner is only used to grant access to resources. > > OAuth's main 3-legged pattern allows what's called "Alice-to-Alice > sharing", in that the Client is consuming on behalf of the resource > owner. In cases where you have an in-user-agent app or a native app, the > end user (resource owner) is going to be the one running it, and the one > authorizing it. > Yes, I understand that. But the document seems like resource owner is the "only" one who can run the UA app or native app? Or I missed something? Thanks, -Haibin > > Thanks for your feedback, and I hope this can help clear up the intent > of the working group here. If you can suggest language that will > solidify these points further, it can help make sure this doesn't > further confuse people. > > -- Justin From internet-drafts@ietf.org Fri Feb 17 16:12:47 2012 Return-Path: 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 6158A11E80BC; Fri, 17 Feb 2012 16:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 yfolWQyKKt66; Fri, 17 Feb 2012 16:12:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6023011E80B4; Fri, 17 Feb 2012 16:12:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120218001246.4301.55806.idtracker@ietfa.amsl.com> Date: Fri, 17 Feb 2012 16:12:46 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-17.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 00:12:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Authorization Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-17.txt Pages : 22 Date : 2012-02-17 This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-17.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-17.txt From Michael.Jones@microsoft.com Fri Feb 17 16:19:51 2012 Return-Path: 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 D85C411E80AE for ; Fri, 17 Feb 2012 16:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.784 X-Spam-Level: X-Spam-Status: No, score=-3.784 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ZOxWfPa-UfEq for ; Fri, 17 Feb 2012 16:19:51 -0800 (PST) Received: from DB3EHSOBE005.bigfish.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7179111E809F for ; Fri, 17 Feb 2012 16:19:50 -0800 (PST) Received: from mail30-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Sat, 18 Feb 2012 00:19:49 +0000 Received: from mail30-db3 (localhost [127.0.0.1]) by mail30-db3-R.bigfish.com (Postfix) with ESMTP id 684411E0319 for ; Sat, 18 Feb 2012 00:19:49 +0000 (UTC) X-SpamScore: -19 X-BigFish: VS-19(zzc85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail30-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail30-db3 (localhost.localdomain [127.0.0.1]) by mail30-db3 (MessageSwitch) id 1329524387988202_27208; Sat, 18 Feb 2012 00:19:47 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.254]) by mail30-db3.bigfish.com (Postfix) with ESMTP id EC42020004A for ; Sat, 18 Feb 2012 00:19:47 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 18 Feb 2012 00:19:47 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0247.005; Fri, 17 Feb 2012 16:19:44 -0800 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Bearer Token Specification Draft -17 Thread-Index: Aczt0v/Ld5jNP7/gRVOp2UhqhBWJKg== Date: Sat, 18 Feb 2012 00:19:43 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943663AB2D4@TK5EX14MBXC284.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.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943663AB2D4TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -17 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 00:19:52 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943663AB2D4TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft 17 of the OAuth 2.0 Bearer Token Specification has been published. This version changes = the RFCs referenced for certificate chain verification. The wording was pr= oposed by Alexey Melnikov as part of the Gen-ART review. It contains the following changes: * Restore RFC 2818 reference for server identity verification and add R= FC 5280 reference for certificate revocation lists, per Gen-ART review comm= ents. The draft is available at: * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17 A HTML-formatted version is available at: * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-17.html -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943663AB2D4TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft 17 of the OAuth 2.0 Bearer Token Specification has been published.  This ver= sion changes the RFCs referenced for certificate chain verification.  = The wording was proposed by Alexey Melnikov as part of the Gen-ART review.<= o:p>

 

It contains the following changes:

  • Restore RFC 2818 reference for server identity ver= ification and add RFC 5280 reference for certificate revocation lists, per = Gen-ART review comments.

 

The draft is available at:

·         http://tools.ietf.org/html/draft-ietf-oauth-v2-bea= rer-17

A HTML-formatted version is available at:=

·         http://self-issued.info/docs/draft-ietf-oau= th-v2-bearer-17.html

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B1680429673943663AB2D4TK5EX14MBXC284r_-- From wenjielin.bupt@gmail.com Fri Feb 17 18:07:38 2012 Return-Path: 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 EC3CD11E80C5 for ; Fri, 17 Feb 2012 18:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 wMkWbU9JuWKh for ; Fri, 17 Feb 2012 18:07:37 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A32CE11E80B7 for ; Fri, 17 Feb 2012 18:07:37 -0800 (PST) Received: by iagf6 with SMTP id f6so6200188iag.31 for ; Fri, 17 Feb 2012 18:07:37 -0800 (PST) Received-SPF: pass (google.com: domain of wenjielin.bupt@gmail.com designates 10.50.34.164 as permitted sender) client-ip=10.50.34.164; Authentication-Results: mr.google.com; spf=pass (google.com: domain of wenjielin.bupt@gmail.com designates 10.50.34.164 as permitted sender) smtp.mail=wenjielin.bupt@gmail.com; dkim=pass header.i=wenjielin.bupt@gmail.com Received: from mr.google.com ([10.50.34.164]) by 10.50.34.164 with SMTP id a4mr439613igj.14.1329530857399 (num_hops = 1); Fri, 17 Feb 2012 18:07:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=H/50Oda3YVDjvpz6dHdsOBV7Sf5f39qRmEtraN6xGjk=; b=ev7RI0BbnCPAzKDsdNP5NNGz0YPXJSd0uxz0utMdjUebpnoCh+WYN++mVoHc9IeP/n F4gNNAZmtlSp7tng/hHJlFpCCFxOFbGjlCHFvCXbkGxvwnq1eVfBM0EloPX4RRFhZLP0 XEDYonn0G25QaZBC+fSWQdP2pk9kFiNKdvIz0= Received: by 10.50.34.164 with SMTP id a4mr361887igj.14.1329530857328; Fri, 17 Feb 2012 18:07:37 -0800 (PST) MIME-Version: 1.0 Sender: wenjielin.bupt@gmail.com Received: by 10.42.139.138 with HTTP; Fri, 17 Feb 2012 18:07:17 -0800 (PST) From: Wenjie Lin Date: Fri, 17 Feb 2012 18:07:17 -0800 X-Google-Sender-Auth: kLkN58LzsmISi4Gz49ehvBPDBYo Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=14dae934050f78105c04b9338619 Subject: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 02:07:39 -0000 --14dae934050f78105c04b9338619 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called *scope attack*, provide a live-demo of the attack on Facebook, and propose a fix with discussions. *Scope Attack* OAuth authorization of services is associated with service agreement scope. For instance, Client provides an online game to User with a service agreement scope* A:* *User authorizes Client to access his profile information and to post messages on his behalf*. A malicious User can request for online game with service agreement scope* A*, manipulate the scope field, and change it to scope* B*: *User authorizes Client to access his profile information*. User can still play the games, yet Client can=92= t post messages on User=92s behalf, as originally agreed. OAuth 2.0 authorization code grant and implicit grant are vulnerable to the scope attack. *A Scope Attack Scenario* (1) Authorization Server: Facebook (authorization code grant) (2) Client: Online gaming company Game. It allows User to play the games with the service agreement scope* A: User authorizes Game to access his profile information and post messages on his behalf*. (3) User: malicious User with an account at Facebook. He attempts to play the games yet without authorizing Game to post messages on his behalf, that is, he changes the scope from *A* to *B: authorization of Client to access his profile information *only. *Attack Workflow* (1) User requests Game (Client) for permission to play games, instantiating OAuth 2.0 with scope* A*. (2) Game generates an authorization request with a scope specification *A*, and redirects User to Facebook with the request. (3) User manipulates the scope field and changes it to scope* B*. The modified request is then sent to Facebook. (4) User grants the modified request. (5) Facebook redirects User back to Game with the authorization code. (6) Game exchanges the authorization code for an access token. However it has no knowledge that the scope* A* has been changed to scope* B*. (7) Game provides online gaming service to User. However, Game can=92t post messages on User=92s Facebook page. *A Live-Demo: Facebook and CastleVille* (IE and Safari tested) Step 1: Login Facebook and visit Facebook Apps and Game page https://www.facebook.com/games Step 2: Click CastleVille. Step 3: When you see the Request for Permission page, instead of clicking =93Allow=94, change the scope field in the URL from your browser from =93scope=3Demail%2Cpublish_stream%2Cpublish_actions=94 to =93scope=3Demail%2Cpublish_stream=94. Step 4: After the modification, press ENTER to send the modified request to Facebook. Now you will see the modified Request of Permission page. Step 5: Click on =93Allow=94 button and enjoy the game. (video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w) *Impact* Client provides services to malicious User yet with the modified service agreement scope by User=92s design. *Manipulating Scope Field* The scope field in access token response is required ONLY IF Authorization Server observes that the User authorized scope is different than the original scope. Consequently, User can manipulate the scope field so that Authorization Server cannot detect the change of the scope. As a result Client provides the services yet can=92t obtain the information that is specified in the scope of the original service agreement. * *Client can verify the service agreement scope by checking all the fields against the original User request before providing the requested services to User. For instance, Client can verify the granted permissions if Authorization Server (e.g. Facebook) provides an API. However, this is out of the scope of OAuth 2.0, and Client may not check it. We observe: all top five games recommended by Facebook are vulnerable to the scope attack. *Proposed Fix* Draft-ietf-oauth-v2-23 Section 5.1: *Change from* =93scope OPTIONAL, if identical to the scope requested by the client, otherwise REQUIRED.=94 *to * =93scope REQUIRED=94 /* scope: User authorized scope */ *Remarks* (1) The proof of the correctness of OAuth with our proposed fix will be published in an article: =93*OAuth 2.0 =96 Attacks, Fixes, Correctness, and Generalizations*, Wenjie Lin, David Lee and Steve Lai, to appear=94.** (2) The implicit grant is also vulnerable to the scope attack. However it cannot be fixed by enforcing scope field in access token response as above; User can change the scope in response before being redirected to Client.** * * Wenjie Lin, The Ohio State University David Lee, HP Labs and The Ohio State University Steve Lai, The Ohio State University --14dae934050f78105c04b9338619 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

We describe an attack on OAuth 2.0 (draft-ietf-oauth= -v2-23), called scope attack, provide a live-demo of the attack on Facebook, and propose a fix with discussions.

=A0

Scope Attack

OAuth authorization of se= rvices is associated with service agreement scope. For instance, Client provides an online game to User with a service agreement scope A: User authorizes Client to access his profile information and to post messages on his behalf. A malicious User can request for online game with service agreement scope A, manipulate the scope field, and change it to scope B: User authorizes Client to access his p= rofile information. User can still play the games, =A0yet Client can=92t post messages on User=92s behalf, as originally agreed.

OAuth 2.0 authorization c= ode grant and implicit grant are vulnerable to the scope attack.

=A0

A Scope Attack Scenario

(1) Authorization Server:= Facebook (authorization code grant)

(2) Client: Online gaming= company Game. It allows User to play the games with the service agreement scope = A: User authorizes Game to access his profile information and post messages on his behalf.

(3) User: malicious User = with an account at Facebook. He attempts to play the games yet without authorizing = Game to post messages on his behalf, that is, he changes the scope from A to B: authorization of Client to access his profile information only.

=A0

Attack Workflow

(1)= User requests Game (Client) for permission to play games, instantiating OAuth 2.= 0 with scope A.

(2) Game generates an authorization request with a scope specification A, and redirects User to Facebook with the request.

(3) User manipulates the scope field and changes it to scope B. The mod= ified request is then sent to Facebook.

(4) User grants the modified request.

(5) Facebook redirects User back to Game with the authorization code.

(6) Game exchanges the authorization code for an access token. However it has no knowledge that the scope A has been changed to scope B.

(7) = Game provides online gaming service to User. However, Game can=92t post messages= on User=92s Facebook page.

=A0

A Live-Demo: Facebook and CastleVille (IE and Safari tested)

Step 1: Login Facebook an= d visit Facebook Apps and Game page

https://www.facebook.com/games

Step 2: Click CastleVille= .

Step 3: When you see the = Request for Permission page, instead of

clicking =93Allow=94, ch= ange the scope field in the URL from your browser from=A0 =93scope=3Demail%2Cpublish_stream%2Cpublish_actions=94 to =93scope= =3Demail%2Cpublish_stream=94.

Step 4: After the modific= ation, press ENTER to send the modified

request to Facebook. Now= you will see the modified Request of Permission page.

Step 5: Click on =93Allow= =94 button and enjoy the game.

(video: http://www.youtube.com/watch?v=3Dzk= mjLa3VU9w)

=A0

Impact

Client provides services = to malicious User yet with the modified service agreement scope by User=92s de= sign.

=A0

Manipulating Scope Field

The scope field in access= token response is required ONLY IF Authorization Server observes that the User au= thorized scope is different than the original scope. Consequently, User can manipula= te the scope field so that Authorization Server cannot detect the change of th= e scope. As a result Client provides the services yet can=92t obtain the information= that is specified in the scope of the original service agreement.

Client can verify t= he service agreement scope by checking all the fields against the original User request before providi= ng the requested services to User. =A0For instance, Client can verify the granted permissions if Authorization Server (e.g. Facebook)=A0 provides an API. However, this is out of the scope of OAuth 2.0, and Client may not check it. We obse= rve: all top five games recommended by Facebook are vulnerable to the scope atta= ck.

=A0

Proposed Fix

Draft-ietf-oauth-v2-23 Se= ction 5.1:

Change from

=93scope

=A0=A0=A0=A0= =A0=A0=A0=A0 OPTIONAL, if identical to the scope requested by the client,

=A0=A0=A0=A0= =A0=A0=A0=A0 otherwise REQUIRED.=94

to

=93scope REQUIRED=94 /* scope: User authorized scope */

=A0

Remarks

(1) T= he proof of the correctness of OAuth with our proposed fix will be published i= n an article: =93OAuth 2.0 =96 Attacks, Fixes, Correctness, and Generalizations, Wenjie Lin, David Lee and Steve Lai, = to appear=94.

(2) Th= e implicit grant is also vulnerable to the scope attack. However it cannot be fixed by enforcing scope field in access token response as above; User can = change the scope in response before being redirected to Client.

=A0

Wenjie Lin, The Ohio State University

David Lee, HP Labs and The Ohio State University

Steve Lai, The Ohio State University

--14dae934050f78105c04b9338619-- From wmills@yahoo-inc.com Fri Feb 17 18:40:20 2012 Return-Path: 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 BEE2E21E8013 for ; Fri, 17 Feb 2012 18:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.182 X-Spam-Level: X-Spam-Status: No, score=-17.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 wRA5zeJks3km for ; Fri, 17 Feb 2012 18:40:19 -0800 (PST) Received: from nm22.bullet.mail.bf1.yahoo.com (nm22.bullet.mail.bf1.yahoo.com [98.139.212.181]) by ietfa.amsl.com (Postfix) with SMTP id 1D64C21E800C for ; Fri, 17 Feb 2012 18:40:19 -0800 (PST) Received: from [98.139.212.147] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 18 Feb 2012 02:40:14 -0000 Received: from [98.139.212.227] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 18 Feb 2012 02:40:14 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 18 Feb 2012 02:40:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 422780.81929.bm@omp1036.mail.bf1.yahoo.com Received: (qmail 5120 invoked by uid 60001); 18 Feb 2012 02:40:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1329532813; bh=ARXPztYVMmxnyw8w51ISgtTsrxQ+P7hlnWg04mr6id8=; 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=fdSlq8Prq5wsgWnlxPqxUvHjkIpC3ILjYLiQFzMvy2bwnTITtEYChOrgTUvhoh4X3GcwNN0o4yq5ObkVRQSu9xBORBb3KIoSf12q6wE4ERtIKbYg92luuh17hPefcPr6bZwvs9fVuDm0CONf1betkBFlEokvsLnezfbJVSum4Lk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; 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=XucK1m70sEmmulO15Kv6yIwBxvB3bfULv6I3SK1mia444xOPnYppp9k7sqh58rwEBs1aPmlCazjaHGjmLMdXxpTYu9AEwnMnmlH33E0pPjDid/3u7gadNh70RpX7PMTv0TZjKI6xEgjyj07GTEgVsjoFC86eDr+BBj+awOey21c=; X-YMail-OSG: rIwgEl8VM1lVHt0u3J3AQoFeNO_OFzilXbQPDy1mIq1C8qW WvS8cDwmxBHFdeRhk17sHLQfM17wzopQzY5xKq4tFxLNf0frk0S3SQe7zG5Z ZRuSppkb395bAsa.y2d1KtVgniPzScBRfSbixl6rMDbE63OTR7kHwgiKEufC KlmM.M9YnsDpVEOEAEkdJP7oG2ohU2mH0AQF4scl8JNZuGoE7HS5eBHzOxhp uvwbaDsdJIl1fxh8CNo9eRqam3nzI28M7ceSnoG3AdxOMTwIuqzlqQhoTlxj LOYBBqhrasnW85t5w3fYTv.HiE1ylIvnm17vSxEWX3H43bzunrR_dT7jTvxQ tEZw6udK4ilD1_LSSLNJH2STy_srsifKDxkGrbWcvbo2gjHdMoob7DFjl8bn MBaNtgf_tXxq.QjX3vSa7xU0KtJJ4q73g3SKVGkFf6GwJQkwdKP0vVDEZHd_ esUamCBAHCB.4c.NNxpl6ZGAWiAaJTe6JVLtLe7DoG5RJdygkgmF0S4ujGCW ZxKqmPje4FXzWJNNKFD44FsJsqHkt1ZX8lgBkfLbKW0XctVkDXAArZQSmdmx YDHveMxPHC4_2IVkORQ-- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Fri, 17 Feb 2012 18:40:13 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340031 References: Message-ID: <1329532813.89091.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Fri, 17 Feb 2012 18:40:13 -0800 (PST) From: William Mills To: Wenjie Lin , "oauth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-1100079058-1329532813=:89091" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 02:40:20 -0000 --258328648-1100079058-1329532813=:89091 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don't think the problem as described is an attack per se, the user is abl= e to modify the rights being granted.=C2=A0 The user is after all in contro= l of what they want to allow.=C2=A0 In this case it looks like FBs implemen= tation is pretty loose with the games apps and there's no guarantee you'll = get the rights you want as a game developer.=0A=0A=0AWhat this scenario mea= n is that the integrity of the request from the game company to FB via the = user's context does not have sufficient integrity guarantee.=C2=A0 It is ce= rtainly possible for the auth server to have a registry of known clients an= d expected scopes, and in fact the auth server is expected to communicate t= o the user what they are approving.=0A=0A=0ACan an attacker cause a user to= approve a token with an unexpected scope?=C2=A0 That would be a big proble= m.=0A=0A=0A=0A________________________________=0A From: Wenjie Lin =0ATo: oauth@ietf.org =0ASent: Friday, February 17, 2012 6:07 PM= =0ASubject: [OAUTH-WG] A Scope Attack against OAuth 2.0=0A =0A=0AWe describ= e an attack on OAuth 2.0 (draft-ietf-oauth-v2-23),=0Acalled scope attack, p= rovide a=0Alive-demo of the attack on Facebook, and propose a fix with disc= ussions.=0A=C2=A0=0AScope Attack=0AOAuth authorization of services is=0Aass= ociated with service agreement scope. For instance, Client provides an=0Aon= line game to User with a service agreement scopeA: User authorizes Client t= o=0Aaccess his profile information and to post messages on his behalf. A=0A= malicious User can request for online game with service agreement scopeA, m= anipulate the scope field, and change=0Ait to scopeB: User authorizes Clien= t to access his profile information. User can=0Astill play the games, =C2= =A0yet Client=0Acan=E2=80=99t post messages on User=E2=80=99s behalf, as or= iginally agreed.=0AOAuth 2.0 authorization code grant=0Aand implicit grant = are vulnerable to the scope attack. =0A=C2=A0=0AA Scope Attack Scenario=0A(= 1) Authorization Server: Facebook=0A(authorization code grant)=0A(2) Client= : Online gaming company Game.=0AIt allows User to play the games with the s= ervice agreement scopeA: User authorizes Game to access his=0Aprofile infor= mation and post messages on his behalf.=0A(3) User: malicious User with an= =0Aaccount at Facebook. He attempts to play the games yet without authorizi= ng Game=0Ato post messages on his behalf, that is, he changes the scope fro= m A to B:=0Aauthorization of Client to access his profile information only.= =0A=C2=A0=0AAttack Workflow=0A(1)User=0Arequests Game (Client) for permissi= on to play games, instantiating OAuth 2.0=0Awith scopeA.=0A(2)Game=0Agenera= tes an authorization request with a scope specification A, and redirects Us= er to Facebook with=0Athe request.=0A(3)User=0Amanipulates the scope field = and changes it to scopeB. The modified request is then sent to Facebook.=0A= (4)User=0Agrants the modified request.=0A(5)Facebook=0Aredirects User back = to Game with the authorization code.=0A(6)Game=0Aexchanges the authorizatio= n code for an access token. However it has no=0Aknowledge that the scopeA h= as been=0Achanged to scopeB. =0A(7)Game=0Aprovides online gaming service to= User. However, Game can=E2=80=99t post messages on=0AUser=E2=80=99s Facebo= ok page.=0A=C2=A0=0AA Live-Demo: Facebook=0Aand CastleVille (IE and Safari = tested)=0AStep 1: Login Facebook and visit Facebook=0AApps and Game page = =0Ahttps://www.facebook.com/games=0AStep 2: Click CastleVille.=0AStep 3: Wh= en you see the Request=0Afor Permission page, instead of =0Aclicking =E2=80= =9CAllow=E2=80=9D, change the scope=0Afield in the URL from your browser fr= om=C2=A0 =E2=80=9Cscope=3Demail%2Cpublish_stream%2Cpublish_actions=E2=80=9D= to =E2=80=9Cscope=3Demail%2Cpublish_stream=E2=80=9D.=0AStep 4: After the m= odification,=0Apress ENTER to send the modified =0Arequest to Facebook. Now= you will=0Asee the modified Request of Permission page.=0AStep 5: Click on= =E2=80=9CAllow=E2=80=9D button and=0Aenjoy the game.=0A(video: http://www.= youtube.com/watch?v=3DzkmjLa3VU9w)=0A=C2=A0=0AImpact=0AClient provides serv= ices to=0Amalicious User yet with the modified service agreement scope by U= ser=E2=80=99s design. =0A=C2=A0=0AManipulating Scope=0AField=0AThe scope fi= eld in access token=0Aresponse is required ONLY IF Authorization Server obs= erves that the User authorized=0Ascope is different than the original scope= . Consequently, User can manipulate=0Athe scope field so that Authorization= Server cannot detect the change of the scope.=0AAs a result Client provide= s the services yet can=E2=80=99t obtain the information that=0Ais specified= in the scope of the original service agreement.=0AClient can verify the se= rvice agreement scope=0Aby checking all the fields against the original Use= r request before providing=0Athe requested services to User. =C2=A0For=0Ain= stance, Client can verify the granted permissions if Authorization Server= =0A(e.g. Facebook)=C2=A0 provides an API. However,=0Athis is out of the sco= pe of OAuth 2.0, and Client may not check it. We observe:=0Aall top five ga= mes recommended by Facebook are vulnerable to the scope attack. =0A=C2=A0= =0AProposed Fix=0ADraft-ietf-oauth-v2-23 Section 5.1:=0AChange from=0A=E2= =80=9Cscope=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL, if= =0Aidentical to the scope requested by the client,=0A=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 otherwise REQUIRED.=E2=80=9D=0Ato =0A=E2=80=9Cs= cope REQUIRED=E2=80=9D /* scope: User authorized scope */=0A=C2=A0=0ARemark= s=0A(1)The=0Aproof of the correctness of OAuth with our proposed fix will b= e published in an=0Aarticle: =E2=80=9COAuth 2.0 =E2=80=93 Attacks, Fixes,= =0ACorrectness, and Generalizations, Wenjie Lin, David Lee and Steve Lai, t= o=0Aappear=E2=80=9D.=0A(2)The=0Aimplicit grant is also vulnerable to the sc= ope attack. However it cannot be=0Afixed by enforcing scope field in access= token response as above; User can change=0Athe scope in response before be= ing redirected to Client.=0A=C2=A0=0AWenjie Lin, The Ohio State University = =0ADavid=0ALee, HP Labs and The Ohio State University=0ASteve Lai, The Ohio= State University=0A_______________________________________________=0AOAuth= mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oaut= h --258328648-1100079058-1329532813=:89091 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I don't think the problem as described is an attack per se, the user is a= ble to modify the rights being granted.  The user is after all in cont= rol of what they want to allow.  In this case it looks like FBs implem= entation is pretty loose with the games apps and there's no guarantee you'l= l get the rights you want as a game developer.
<= br>
What this scenario mean is that the integrity of= the request from the game company to FB via the user's context does not ha= ve sufficient integrity guarantee.  It is certainly possible for the a= uth server to have a registry of known clients and expected scopes, and in = fact the auth server is expected to communicate to the user what they are a= pproving.

Can an attacker cause a user to approve a token with an unexpected scope? = ; That would be a big problem.

From: We= njie Lin <lin.820@osu.edu>
= To: oauth@ietf.org
Se= nt: Friday, February 17, 2012 6:07 PM
Subject: [OAUTH-WG] A Scope Attack against OAuth= 2.0

=0A
=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A
We describ= e an attack on OAuth 2.0 (draft-ietf-oauth-v2-23),=0Acalled s= cope attack, provide a=0Alive-demo of the attack on Facebook, and propo= se a fix with discussions.
=0A=0A
 
=0A=0A
Scop= e Attack
=0A=0A
OAuth authorization of services is=0Aassociated with service= agreement scope. For instance, Client provides an=0Aonline game to User wi= th a service agreement scope A: User author= izes Client to=0Aaccess his profile information and to post messages on his= behalf. A=0Amalicious User can request for online game with service ag= reement scope A, manipulate the scope field, and change= =0Ait to scope B: User authorizes Client to= access his profile information. User can=0Astill play the games,  yet Client=0Acan=E2=80=99t post messages on User= =E2=80=99s behalf, as originally agreed.
=0A=0A
OAuth 2.0 authorization code gra= nt=0Aand implicit grant are vulnerable to the scope attack.
=0A=0A 
=0A=0A
A Scope Attack Scenario
=0A=0A
(1) Authorizati= on Server: Facebook=0A(authorization code grant)
=0A=0A
(2) Client: Online gamin= g company Game.=0AIt allows User to play the games with the service agreeme= nt scope A: User authorizes Game to access his=0Aprofile info= rmation and post messages on his behalf.
=0A=0A
(3) User: malicious User wit= h an=0Aaccount at Facebook. He attempts to play the games yet without autho= rizing Game=0Ato post messages on his behalf, that is, he changes the scope= from A to B:=0Aauthorization of Client to = access his profile information only.
=0A=0A
 
=0A=0A
Attack Workflow
=0A=0A
(1) User=0Arequests Game (Client) for permission to play games, = instantiating OAuth 2.0=0Awith scope A.
=0A=0A
(2) Game=0Agenerates an authorization request with a scope spec= ification A, and redirects User to Facebook with=0Athe re= quest.
=0A=0A
(3) User=0Amanipulates the scope field = and changes it to scope B. The modified request is then s= ent to Facebook.
=0A=0A
(4)= User=0Agrants the modifie= d request.
=0A=0A
(5) Facebook=0Aredirects User back = to Game with the authorization code.
=0A=0A
= (6) Game= =0Aexchanges the authorization code for an access token. However it has no= =0Aknowledge that the scope A has been=0Achanged to scope= B.
=0A=0A
(7) Game=0Aprovides onlin= e gaming service to User. However, Game can=E2=80=99t post messages on=0AUs= er=E2=80=99s Facebook page.
=0A=0A
 
=0A=0A
A L= ive-Demo: Facebook=0Aand CastleVille (IE and Safari tested)
=0A=0A
Step 1: Login Facebook and visit Faceboo= k=0AApps and Game page
=0A=0A
https://www.facebook.com/game= s
=0A=0A
Step 2: Click CastleVille.
=0A=0A
Step 3: When you see the Request=0Afor= Permission page, instead of
=0A=0A
clicking =E2=80=9CAllow=E2=80=9D, change t= he scope=0Afield in the URL from your browser from = =0A=E2=80=9Cscope=3Demail%2Cpublish_stream%2Cpublish_actions=E2=80= =9D to =E2=80=9Cscope=3Demail%2Cpublish_stream=E2=80=9D.
=0A=0A
Step 4: After th= e modification,=0Apress ENTER to send the modified
=0A=0A
request to Faceboo= k. Now you will=0Asee the modified Request of Permission page.
=0A=0A<= div class=3D"yiv1189279453MsoNormal" style=3D"text-indent:.5in;">Step 5: Cl= ick on =E2=80=9CAllow=E2=80=9D button and=0Aenjoy the game.
=0A=0A(video: http:= //www.youtube.com/watch?v=3DzkmjLa3VU9w)
=0A=0A
 
=0A=0A
Impact
=0A=0A
Client provides services to=0Amalicious User yet wit= h the modified service agreement scope by User=E2=80=99s design.
=0A= =0A
 
=0A=0A
Manipulating Scope=0AField
=0A= =0A
The sc= ope field in access token=0Aresponse is required ONLY IF Authorization Serv= er observes that the User authorized=0Ascope is different than the original= scope. Consequently, User can manipulate=0Athe scope field so that Authori= zation Server cannot detect the change of the scope.=0AAs a result Client p= rovides the services yet can=E2=80=99t obtain the information that=0Ais spe= cified in the scope of the original service agreement.
=0A=0A
Cli= ent can verify the service agreement scope=0Aby checking all the fields aga= inst the original User request before providing=0Athe requested services to= User.  For=0Ainstance, Client can verify the = granted permissions if Authorization Server=0A(e.g. Facebook)  provides an API. However,=0Athis is out of the scope of OA= uth 2.0, and Client may not check it. We observe:=0Aall top five games reco= mmended by Facebook are vulnerable to the scope attack.
=0A=0A
 
=0A=0A
Proposed Fix
=0A=0A
Draft-ietf-oauth-v2-23 Section= 5.1:
=0A=0A
Change= from
=0A=0A
=E2=80=9Cscope
=0A=0A
     = ;    OPTIONAL, if=0Aidentical to the scope requested = by the client,
=0A=0A
       = ;  otherwise REQUIRED.=E2=80=9D
=0A=0A
to
=0A=0A
=E2=80=9Cscope <= /span> REQUIRED=E2=80=9D /* scope: User authorized scope */
=0A=0A 
=0A=0A
Remarks
=0A=0A
(1) The=0Aproof of the co= rrectness of OAuth with our proposed fix will be published in an=0Aarticle:= =E2=80=9COAuth 2.0 =E2=80=93 Attacks, Fixes,=0ACorrectness, = and Generalizations, Wenjie Lin, David Lee and Steve Lai, to=0Aappear= =E2=80=9D.
=0A=0A
(2) The=0Aimplicit grant is also vulne= rable to the scope attack. However it cannot be=0Afixed by enforcing scope = field in access token response as above; User can change=0Athe scope in res= ponse before being redirected to Client.
=0A=0A
 
=0A=0A
Wenjie Lin, Th= e Ohio State University
=0A=0A
David=0ALee, HP Labs and The Ohio State University
=0A=0ASteve Lai, The Ohio State University=0A=0A=0A
_______________________________________________
OAu= th mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h


--258328648-1100079058-1329532813=:89091-- From dick.hardt@gmail.com Fri Feb 17 19:08:31 2012 Return-Path: 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 B628721F84D4 for ; Fri, 17 Feb 2012 19:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 3CJuzBb5L-8a for ; Fri, 17 Feb 2012 19:08:30 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1699221F84D1 for ; Fri, 17 Feb 2012 19:08:30 -0800 (PST) Received: by iagf6 with SMTP id f6so6251256iag.31 for ; Fri, 17 Feb 2012 19:08:29 -0800 (PST) Received-SPF: pass (google.com: domain of dick.hardt@gmail.com designates 10.43.53.1 as permitted sender) client-ip=10.43.53.1; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dick.hardt@gmail.com designates 10.43.53.1 as permitted sender) smtp.mail=dick.hardt@gmail.com; dkim=pass header.i=dick.hardt@gmail.com Received: from mr.google.com ([10.43.53.1]) by 10.43.53.1 with SMTP id vo1mr14314213icb.2.1329534509816 (num_hops = 1); Fri, 17 Feb 2012 19:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=ooYWt10jC/O2HCSqbBh37OloJOZj3Xa/XAJcWCDBmu8=; b=bn4PQOhy+i2DCD6abRWDKIATHsdskL4BnfH8UwofMKEmC8wWf60m6lfAlwbKWTGlny 8FkunuEF2218UsxqKapBnly7nGSiph+01wY+f9SSTenjUY3wlAGieJaTwtGDgdejJWOf jbIYPfLtzCPv1NeLZ7jiPSjraafpNppD0F0jg= Received: by 10.43.53.1 with SMTP id vo1mr11430321icb.2.1329534508570; Fri, 17 Feb 2012 19:08:28 -0800 (PST) Received: from [192.168.0.42] (S0106602ad0767c15.nb.shawcable.net. [70.74.90.92]) by mx.google.com with ESMTPS id ko6sm525757igc.2.2012.02.17.19.08.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Feb 2012 19:08:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_61DF1C3B-5234-4857-BBDE-5BB5522FBF53" From: Dick Hardt In-Reply-To: <1329532813.89091.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Fri, 17 Feb 2012 20:08:24 -0700 Message-Id: <8A103AC5-B662-416C-97D6-D43D2A56ED3A@gmail.com> References: <1329532813.89091.YahooMailNeo@web31808.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1257) Cc: Wenjie Lin , "oauth@ietf.org" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 03:08:31 -0000 --Apple-Mail=_61DF1C3B-5234-4857-BBDE-5BB5522FBF53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Some of the more interesting capabilities that an app can ask for are = revokable by the user later on. Facebook has an API call /me/permissions That lets an app determine what permissions the user has granted the = app. If need be the app can then ask (or re-ask) for additional scopes.=20= Additionally, Facebook could decide an app should have fewer scopes and = take away privileges from the app. A good app would be able to deal with = no longer being authorized to perform an action. I fail to see the security issue here. -- Dick On Feb 17, 2012, at 7:40 PM, William Mills wrote: > I don't think the problem as described is an attack per se, the user = is able to modify the rights being granted. The user is after all in = control of what they want to allow. In this case it looks like FBs = implementation is pretty loose with the games apps and there's no = guarantee you'll get the rights you want as a game developer. >=20 > What this scenario mean is that the integrity of the request from the = game company to FB via the user's context does not have sufficient = integrity guarantee. It is certainly possible for the auth server to = have a registry of known clients and expected scopes, and in fact the = auth server is expected to communicate to the user what they are = approving. >=20 > Can an attacker cause a user to approve a token with an unexpected = scope? That would be a big problem. >=20 > From: Wenjie Lin > To: oauth@ietf.org=20 > Sent: Friday, February 17, 2012 6:07 PM > Subject: [OAUTH-WG] A Scope Attack against OAuth 2.0 >=20 > We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called = scope attack, provide a live-demo of the attack on Facebook, and propose = a fix with discussions. > =20 > Scope Attack > OAuth authorization of services is associated with service agreement = scope. For instance, Client provides an online game to User with a = service agreement scope A: User authorizes Client to access his profile = information and to post messages on his behalf. A malicious User can = request for online game with service agreement scope A, manipulate the = scope field, and change it to scope B: User authorizes Client to access = his profile information. User can still play the games, yet Client = can=92t post messages on User=92s behalf, as originally agreed. > OAuth 2.0 authorization code grant and implicit grant are vulnerable = to the scope attack. > =20 > A Scope Attack Scenario > (1) Authorization Server: Facebook (authorization code grant) > (2) Client: Online gaming company Game. It allows User to play the = games with the service agreement scope A: User authorizes Game to access = his profile information and post messages on his behalf. > (3) User: malicious User with an account at Facebook. He attempts to = play the games yet without authorizing Game to post messages on his = behalf, that is, he changes the scope from A to B: authorization of = Client to access his profile information only. > =20 > Attack Workflow > (1) User requests Game (Client) for permission to play games, = instantiating OAuth 2.0 with scope A. > (2) Game generates an authorization request with a scope specification = A, and redirects User to Facebook with the request. > (3) User manipulates the scope field and changes it to scope B. The = modified request is then sent to Facebook. > (4) User grants the modified request. > (5) Facebook redirects User back to Game with the authorization code. > (6) Game exchanges the authorization code for an access token. However = it has no knowledge that the scope A has been changed to scope B. > (7) Game provides online gaming service to User. However, Game can=92t = post messages on User=92s Facebook page. > =20 > A Live-Demo: Facebook and CastleVille (IE and Safari tested) > Step 1: Login Facebook and visit Facebook Apps and Game page > https://www.facebook.com/games > Step 2: Click CastleVille. > Step 3: When you see the Request for Permission page, instead of > clicking =93Allow=94, change the scope field in the URL from your = browser from =93scope=3Demail%2Cpublish_stream%2Cpublish_actions=94 to = =93scope=3Demail%2Cpublish_stream=94. > Step 4: After the modification, press ENTER to send the modified > request to Facebook. Now you will see the modified Request of = Permission page. > Step 5: Click on =93Allow=94 button and enjoy the game. > (video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w) > =20 > Impact > Client provides services to malicious User yet with the modified = service agreement scope by User=92s design. > =20 > Manipulating Scope Field > The scope field in access token response is required ONLY IF = Authorization Server observes that the User authorized scope is = different than the original scope. Consequently, User can manipulate the = scope field so that Authorization Server cannot detect the change of the = scope. As a result Client provides the services yet can=92t obtain the = information that is specified in the scope of the original service = agreement. > Client can verify the service agreement scope by checking all the = fields against the original User request before providing the requested = services to User. For instance, Client can verify the granted = permissions if Authorization Server (e.g. Facebook) provides an API. = However, this is out of the scope of OAuth 2.0, and Client may not check = it. We observe: all top five games recommended by Facebook are = vulnerable to the scope attack. > =20 > Proposed Fix > Draft-ietf-oauth-v2-23 Section 5.1: > Change from > =93scope > OPTIONAL, if identical to the scope requested by the client, > otherwise REQUIRED.=94 > to > =93scope REQUIRED=94 /* scope: User authorized scope */ > =20 > Remarks > (1) The proof of the correctness of OAuth with our proposed fix will = be published in an article: =93OAuth 2.0 =96 Attacks, Fixes, = Correctness, and Generalizations, Wenjie Lin, David Lee and Steve Lai, = to appear=94. > (2) The implicit grant is also vulnerable to the scope attack. However = it cannot be fixed by enforcing scope field in access token response as = above; User can change the scope in response before being redirected to = Client. > =20 > Wenjie Lin, The Ohio State University > David Lee, HP Labs and The Ohio State University > Steve Lai, The Ohio State University >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_61DF1C3B-5234-4857-BBDE-5BB5522FBF53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Some = of the more interesting capabilities that an app can ask for are = revokable by the user later on.

Facebook has an API = call

/me/permissions
That lets an app = determine what permissions the user has granted the app. If need be the = app can then ask (or re-ask) for additional = scopes. 

Additionally, Facebook could = decide an app should have fewer scopes and take away privileges from the = app. A good app would be able to deal with no longer being authorized to = perform an action.

I fail to see the security = issue here.

-- = Dick

On Feb 17, 2012, at 7:40 PM, William = Mills wrote:

I don't think the problem as = described is an attack per se, the user is able to modify the rights = being granted.  The user is after all in control of what they want = to allow.  In this case it looks like FBs implementation is pretty = loose with the games apps and there's no guarantee you'll get the rights = you want as a game = developer.

What = this scenario mean is that the integrity of the request from the game = company to FB via the user's context does not have sufficient integrity = guarantee.  It is certainly possible for the auth server to have a = registry of known clients and expected scopes, and in fact the auth = server is expected to communicate to the user what they are = approving.

Can an attacker cause a user to approve a token with an unexpected = scope?  That would be a big = problem.

=
=
From: = Wenjie Lin <lin.820@osu.edu>
To: oauth@ietf.org
Sent: Friday, February 17, 2012 = 6:07 PM
Subject: = [OAUTH-WG] A Scope Attack against OAuth 2.0

We describe an attack on OAuth 2.0 = (draft-ietf-oauth-v2-23), called scope attack, provide a live-demo of the attack on Facebook, and propose a fix with = discussions.
 
Scope = Attack
OAuth = authorization of services is associated with service agreement scope. For instance, Client provides = an online game to User with a service agreement scope A: = User authorizes Client to access his profile information and to post messages on his behalf. A malicious User can request for online game with service agreement = scope A, manipulate the scope field, and change it to scope B: User authorizes Client to = access his profile information. User can still play the games,  yet Client can=92t post messages on User=92s behalf, as originally agreed.
OAuth = 2.0 authorization code grant and implicit grant are vulnerable to the scope attack.
 
A Scope Attack = Scenario
(1) = Authorization Server: Facebook (authorization code grant)
(2) = Client: Online gaming company Game. It allows User to play the games with the service agreement scope A: User authorizes Game to access his profile information and post messages on his behalf.
(3) = User: malicious User with an account at Facebook. He attempts to play the games yet without = authorizing Game to post messages on his behalf, that is, he changes the scope from A to B: authorization of Client to access his profile information = only.
 
Attack = Workflow
(1) User requests Game (Client) for permission to play games, instantiating OAuth = 2.0 with scope A.
(2) Game generates an authorization request with a scope specification A, and redirects User to Facebook with the request.
(3) User manipulates the scope field and changes it to scope B. = The modified request is then sent to Facebook.
(4) User grants the modified request.
(5) Facebook redirects User back to Game with the authorization code.
(6) Game exchanges the authorization code for an access token. However it has no knowledge that the scope A has been changed to scope B.
(7) Game provides online gaming service to User. However, Game can=92t post = messages on User=92s Facebook page.
 
A Live-Demo: = Facebook and CastleVille (IE and = Safari tested)
Step = 1: Login Facebook and visit Facebook Apps and Game page
https://www.facebook.com/games=
Step = 2: Click CastleVille.
Step = 3: When you see the Request for Permission page, instead of
clicking =93Allow=94, change the scope field in the URL from your browser from  =93scope=3Demail%2Cpublish_stream%2Cpublish_actions=94 to = =93scope=3Demail%2Cpublish_stream=94.
Step = 4: After the modification, press ENTER to send the modified
request= to Facebook. Now you will see the modified Request of Permission page.
Step = 5: Click on =93Allow=94 button and enjoy the game.
(video: = http://www.youtube.c= om/watch?v=3DzkmjLa3VU9w)
 
Impact
Client = provides services to malicious User yet with the modified service agreement scope by User=92s = design.
 
Manipulating Scope Field
The = scope field in access token response is required ONLY IF Authorization Server observes that the User = authorized scope is different than the original scope. Consequently, User can = manipulate the scope field so that Authorization Server cannot detect the change of = the scope. As a result Client provides the services yet can=92t obtain the = information that is specified in the scope of the original service agreement.
= Client can verify the service agreement scope by checking all the fields against the original User request before = providing the requested services to User.  For instance, Client can verify the granted permissions if Authorization = Server (e.g. Facebook)  provides an API. However, this is out of the scope of OAuth 2.0, and Client may not check it. We = observe: all top five games recommended by Facebook are vulnerable to the scope = attack.
 
Proposed = Fix
Draft-ietf-oauth-v2-23 Section 5.1:
Change = from
=93scope
         = OPTIONAL, if identical to the scope requested by the client,
         = otherwise REQUIRED.=94
to
=93scope REQUIRED=94 = /* scope: User authorized scope */
 
Remarks
(1) = The proof of the correctness of OAuth with our proposed fix will be = published in an article: =93OAuth 2.0 =96 Attacks, Fixes, Correctness, and Generalizations, Wenjie Lin, David Lee and Steve = Lai, to appear=94.
(2) = The implicit grant is also vulnerable to the scope attack. However it cannot = be fixed by enforcing scope field in access token response as above; User = can change the scope in response before being redirected to Client.
 
Wenjie Lin, The Ohio State = University
David Lee, HP Labs and The Ohio State University
Steve Lai, The Ohio State = University

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
=
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_61DF1C3B-5234-4857-BBDE-5BB5522FBF53-- From andredemarre@gmail.com Sat Feb 18 00:20:57 2012 Return-Path: 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 1CEB421F86A7 for ; Sat, 18 Feb 2012 00:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 nGXuaeRjopPT for ; Sat, 18 Feb 2012 00:20:55 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9A8F21F86A3 for ; Sat, 18 Feb 2012 00:20:55 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so4752363pbc.31 for ; Sat, 18 Feb 2012 00:20:55 -0800 (PST) Received-SPF: pass (google.com: domain of andredemarre@gmail.com designates 10.68.212.73 as permitted sender) client-ip=10.68.212.73; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andredemarre@gmail.com designates 10.68.212.73 as permitted sender) smtp.mail=andredemarre@gmail.com; dkim=pass header.i=andredemarre@gmail.com Received: from mr.google.com ([10.68.212.73]) by 10.68.212.73 with SMTP id ni9mr38980505pbc.56.1329553255576 (num_hops = 1); Sat, 18 Feb 2012 00:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OFmyAWVduGPwAYMKzsEzb3ucKA3BE5epeaxwYCzCpzU=; b=Xbuxzrdf5fbM7QQ/aTYAOgKw+RSmZX782UHmO9A0AZSLI7/k0RtGgf5SELRJ1MkBCA zL7wga93UMJsCzDu6EnnBVEe0zWPnZVodlG7zCvvIo+jbiHaTecROcLuFMcUKgKkALVe 3XY8GHqOau7LP8A+FL5/Go0rvUVWLhdiWff/k= MIME-Version: 1.0 Received: by 10.68.212.73 with SMTP id ni9mr31606200pbc.56.1329553255487; Sat, 18 Feb 2012 00:20:55 -0800 (PST) Received: by 10.68.25.193 with HTTP; Sat, 18 Feb 2012 00:20:55 -0800 (PST) In-Reply-To: <8A103AC5-B662-416C-97D6-D43D2A56ED3A@gmail.com> References: <1329532813.89091.YahooMailNeo@web31808.mail.mud.yahoo.com> <8A103AC5-B662-416C-97D6-D43D2A56ED3A@gmail.com> Date: Sat, 18 Feb 2012 00:20:55 -0800 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: Dick Hardt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Wenjie Lin , "oauth@ietf.org" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 08:20:57 -0000 Agreed. In fact, Facebook's auth dialog allows the user to deny certain permissions the client has requested at the time of authorization, which makes tampering with the scope field unnecessary. The user is the resource owner after all. draft-ietf-oauth-v2-23 Section 3.3: The authorization server MAY fully or partially ignore the scope requested by the client based on the authorization server policy or the resource owner's instructions. If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted. Regards, Andre DeMarre On Fri, Feb 17, 2012 at 7:08 PM, Dick Hardt wrote: > Some of the more interesting capabilities that an app can ask for are > revokable by the user later on. > > Facebook has an API call > > /me/permissions > > That lets an app determine what permissions the user has granted the app.= If > need be the app can then ask (or re-ask) for additional scopes. > > Additionally, Facebook could decide an app should have fewer scopes and t= ake > away privileges from the app. A good app would be able to deal with no > longer being authorized to perform an action. > > I fail to see the security issue here. > > -- Dick > > On Feb 17, 2012, at 7:40 PM, William Mills wrote: > > I don't think the problem as described is an attack per se, the user is a= ble > to modify the rights being granted.=A0 The user is after all in control o= f > what they want to allow.=A0 In this case it looks like FBs implementation= is > pretty loose with the games apps and there's no guarantee you'll get the > rights you want as a game developer. > > What this scenario mean is that the integrity of the request from the gam= e > company to FB via the user's context does not have sufficient integrity > guarantee.=A0 It is certainly possible for the auth server to have a regi= stry > of known clients and expected scopes, and in fact the auth server is > expected to communicate to the user what they are approving. > > Can an attacker cause a user to approve a token with an unexpected scope? > That would be a big problem. > > ________________________________ > From: Wenjie Lin > To: oauth@ietf.org > Sent: Friday, February 17, 2012 6:07 PM > Subject: [OAUTH-WG] A Scope Attack against OAuth 2.0 > > We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called scope > attack, provide a live-demo of the attack on Facebook, and propose a fix > with discussions. > > Scope Attack > OAuth authorization of services is associated with service agreement scop= e. > For instance, Client provides an online game to User with a service > agreement scope A: User authorizes Client to access his profile informati= on > and to post messages on his behalf. A malicious User can request for onli= ne > game with service agreement scope A, manipulate the scope field, and chan= ge > it to scope B: User authorizes Client to access his profile information. > User can still play the games, =A0yet Client can=92t post messages on Use= r=92s > behalf, as originally agreed. > OAuth 2.0 authorization code grant and implicit grant are vulnerable to t= he > scope attack. > > A Scope Attack Scenario > (1) Authorization Server: Facebook (authorization code grant) > (2) Client: Online gaming company Game. It allows User to play the games > with the service agreement scope A: User authorizes Game to access his > profile information and post messages on his behalf. > (3) User: malicious User with an account at Facebook. He attempts to play > the games yet without authorizing Game to post messages on his behalf, th= at > is, he changes the scope from A to B: authorization of Client to access h= is > profile information only. > > Attack Workflow > (1) User requests Game (Client) for permission to play games, instantiati= ng > OAuth 2.0 with scope A. > (2) Game generates an authorization request with a scope specification A, > and redirects User to Facebook with the request. > (3) User manipulates the scope field and changes it to scope B. The modif= ied > request is then sent to Facebook. > (4) User grants the modified request. > (5) Facebook redirects User back to Game with the authorization code. > (6) Game exchanges the authorization code for an access token. However it > has no knowledge that the scope A has been changed to scope B. > (7) Game provides online gaming service to User. However, Game can=92t po= st > messages on User=92s Facebook page. > > A Live-Demo: Facebook and CastleVille (IE and Safari tested) > Step 1: Login Facebook and visit Facebook Apps and Game page > https://www.facebook.com/games > Step 2: Click CastleVille. > Step 3: When you see the Request for Permission page, instead of > clicking =93Allow=94, change the scope field in the URL from your browser= from > =93scope=3Demail%2Cpublish_stream%2Cpublish_actions=94 to > =93scope=3Demail%2Cpublish_stream=94. > Step 4: After the modification, press ENTER to send the modified > request to Facebook. Now you will see the modified Request of Permission > page. > Step 5: Click on =93Allow=94 button and enjoy the game. > (video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w) > > Impact > Client provides services to malicious User yet with the modified service > agreement scope by User=92s design. > > Manipulating Scope Field > The scope field in access token response is required ONLY IF Authorizatio= n > Server observes that the User authorized scope is different than the > original scope. Consequently, User can manipulate the scope field so that > Authorization Server cannot detect the change of the scope. As a result > Client provides the services yet can=92t obtain the information that is > specified in the scope of the original service agreement. > Client can verify the service agreement scope by checking all the fields > against the original User request before providing the requested services= to > User. =A0For instance, Client can verify the granted permissions if > Authorization Server (e.g. Facebook)=A0 provides an API. However, this is= out > of the scope of OAuth 2.0, and Client may not check it. We observe: all t= op > five games recommended by Facebook are vulnerable to the scope attack. > > Proposed Fix > Draft-ietf-oauth-v2-23 Section 5.1: > Change from > =93scope > =A0=A0=A0=A0=A0=A0=A0=A0 OPTIONAL, if identical to the scope requested by= the client, > =A0=A0=A0=A0=A0=A0=A0=A0 otherwise REQUIRED.=94 > to > =93scope REQUIRED=94 /* scope: User authorized scope */ > > Remarks > (1) The proof of the correctness of OAuth with our proposed fix will be > published in an article: =93OAuth 2.0 =96 Attacks, Fixes, Correctness, an= d > Generalizations, Wenjie Lin, David Lee and Steve Lai, to appear=94. > (2) The implicit grant is also vulnerable to the scope attack. However it > cannot be fixed by enforcing scope field in access token response as abov= e; > User can change the scope in response before being redirected to Client. > > Wenjie Lin, The Ohio State University > David Lee, HP Labs and The Ohio State University > Steve Lai, The Ohio State University > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From peter.wolanin@acquia.com Sat Feb 18 12:53:21 2012 Return-Path: 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 9CD1E21E8025 for ; Sat, 18 Feb 2012 12:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] 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 9tlY1x8bufCQ for ; Sat, 18 Feb 2012 12:53:20 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with SMTP id 9A62621E8026 for ; Sat, 18 Feb 2012 12:53:20 -0800 (PST) Received: from mail-iy0-f174.google.com ([209.85.210.174]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT0APv0CTFvAUNaqcv6BQqf2x2ZKaMv+6@postini.com; Sat, 18 Feb 2012 12:53:20 PST Received: by iacb35 with SMTP id b35so5871659iac.19 for ; Sat, 18 Feb 2012 12:53:19 -0800 (PST) Received-SPF: pass (google.com: domain of peter.wolanin@acquia.com designates 10.50.203.66 as permitted sender) client-ip=10.50.203.66; Authentication-Results: mr.google.com; spf=pass (google.com: domain of peter.wolanin@acquia.com designates 10.50.203.66 as permitted sender) smtp.mail=peter.wolanin@acquia.com Received: from mr.google.com ([10.50.203.66]) by 10.50.203.66 with SMTP id ko2mr4389675igc.7.1329598399294 (num_hops = 1); Sat, 18 Feb 2012 12:53:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.203.66 with SMTP id ko2mr3561868igc.7.1329598399216; Sat, 18 Feb 2012 12:53:19 -0800 (PST) Received: by 10.231.20.12 with HTTP; Sat, 18 Feb 2012 12:53:19 -0800 (PST) Date: Sat, 18 Feb 2012 15:53:19 -0500 Message-ID: From: Peter Wolanin To: Eran Hammer Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkVKqop6HM4qTqCc5+Zzy2DAuKDH80FRkeWbd0kWjA7/AnR/KMiQoH5RNLqApYAoi+hUgMm Cc: "OAuth@ietf.org" Subject: [OAUTH-WG] MAC - body hash and response body hash and cache-control headers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 20:53:21 -0000 Dear Eran, I'm still hoping you will consider adding back the MAC spec a requirement for a body hash covered by the MAC. I still also feel that the lack of a hash covered by the MAC that protects the value of the response and response body makes this proposed spec quite a bit weaker than it should ideally be. You mentioned in arguing that there can be operational issues with verifying the body hash that intermediaries may transform the body. However, the HTTP 1.1 spec at least includes a header that seems designed specifically to mitigate at least the concerns about transformation of the body: Cache-Control: no-transform http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.5 This header should be respected by well-behaved proxies. e.g. see: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/#sec-request-no-transform It would seem that by including this header in the Oauth2 MAC spec for the request and the response there should not be operational issues with verifying a hash of the content? Thanks, Peter On Wed, Feb 8, 2012 at 5:59 PM, Eran Hammer wrote: > New draft: > > > > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 > > > > EH > > From sweeden@au1.ibm.com Sat Feb 18 13:18:33 2012 Return-Path: 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 B846721F8512 for ; Sat, 18 Feb 2012 13:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4] 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 DuofUnMmGh8k for ; Sat, 18 Feb 2012 13:18:32 -0800 (PST) Received: from e23smtp02.au.ibm.com (e23smtp02.au.ibm.com [202.81.31.144]) by ietfa.amsl.com (Postfix) with ESMTP id CCC4521F8508 for ; Sat, 18 Feb 2012 13:18:30 -0800 (PST) Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 18 Feb 2012 21:02:18 +1000 Received: from d23relay05.au.ibm.com (202.81.31.247) by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sat, 18 Feb 2012 21:01:34 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1ILCJbs3264622; Sun, 19 Feb 2012 08:12:19 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1ILHZYG010887; Sun, 19 Feb 2012 08:17:35 +1100 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1ILHYT6010878; Sun, 19 Feb 2012 08:17:34 +1100 In-Reply-To: References: X-KeepSent: 7789D618:84BDC5CF-4A2579A8:0023CB58; type=4; name=$KeepSent To: Wenjie Lin X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Shane B Weeden Date: Sat, 18 Feb 2012 16:34:54 +1000 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.2FP1HF437 | June 7, 2011) at 19/02/2012 08:21:44 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 x-cbid: 12021811-5490-0000-0000-000000C39648 Cc: oauth@ietf.org, oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 21:18:33 -0000 SSBhZ3JlZSB3aXRoIG90aGVycyAtIHRoaXMgaXMgbm90IGFuIGF0dGFjayBvbiB0aGUgcHJvdG9j b2wuIFRoZSB1c2VyIGhhcw0KdGhlIGNob2ljZSBhYm91dCB3aGljaCBzY29wZSB0byBncmFudCBh bmQgdGhlIGNsaWVudCdzIHJlZGlyZWN0IHRvIHRoZQ0KYXV0aG9yaXphdGlvbiBlbmRwb2ludCBp cyBvbmx5IGEgcmVxdWVzdCBmb3IgYSBwYXJ0aWN1bGFyIHNldCBvZg0KcGVybWlzc2lvbnMsIG5v dCBhIGd1YXJhbnRlZSB0aGF0IGl0IHdpbGwgZ2V0IHRoZW0uIFRoZSB1c2VyK2F1dGhvcml6YXRp b24NCnNlcnZlciBkZWNpZGUgd2hpY2ggc2NvcGUgaXMgYWN0dWFsbHkgZ3JhbnRlZC4gVGhlIGNs aWVudCBuZWVkcyB0byBoYW5kbGUNCmNhc2VzIHdoZXJlIHRoYXQgZGlmZmVycyBmcm9tIHdoYXQg aXQgb3JpZ2luYWxseSB3YW50ZWQuDQoNCg0KDQoNCkZyb206CVdlbmppZSBMaW4gPGxpbi44MjBA b3N1LmVkdT4NClRvOglvYXV0aEBpZXRmLm9yZw0KRGF0ZToJMTgvMDIvMjAxMiAxMjoxMiBQTQ0K U3ViamVjdDoJW09BVVRILVdHXSBBIFNjb3BlIEF0dGFjayBhZ2FpbnN0IE9BdXRoIDIuMA0KU2Vu dCBieToJb2F1dGgtYm91bmNlc0BpZXRmLm9yZw0KDQoNCg0KV2UgZGVzY3JpYmUgYW4gYXR0YWNr IG9uIE9BdXRoIDIuMCAoZHJhZnQtaWV0Zi1vYXV0aC12Mi0yMyksIGNhbGxlZCBzY29wZQ0KYXR0 YWNrLCBwcm92aWRlIGEgbGl2ZS1kZW1vIG9mIHRoZSBhdHRhY2sgb24gRmFjZWJvb2ssIGFuZCBw cm9wb3NlIGEgZml4DQp3aXRoIGRpc2N1c3Npb25zLg0KDQoNCg0KDQoNClNjb3BlIEF0dGFjaw0K DQoNCk9BdXRoIGF1dGhvcml6YXRpb24gb2Ygc2VydmljZXMgaXMgYXNzb2NpYXRlZCB3aXRoIHNl cnZpY2UgYWdyZWVtZW50IHNjb3BlLg0KRm9yIGluc3RhbmNlLCBDbGllbnQgcHJvdmlkZXMgYW4g b25saW5lIGdhbWUgdG8gVXNlciB3aXRoIGEgc2VydmljZQ0KYWdyZWVtZW50IHNjb3BlIEE6IFVz ZXIgYXV0aG9yaXplcyBDbGllbnQgdG8gYWNjZXNzIGhpcyBwcm9maWxlIGluZm9ybWF0aW9uDQph bmQgdG8gcG9zdCBtZXNzYWdlcyBvbiBoaXMgYmVoYWxmLiBBIG1hbGljaW91cyBVc2VyIGNhbiBy ZXF1ZXN0IGZvciBvbmxpbmUNCmdhbWUgd2l0aCBzZXJ2aWNlIGFncmVlbWVudCBzY29wZSBBLCBt YW5pcHVsYXRlIHRoZSBzY29wZSBmaWVsZCwgYW5kIGNoYW5nZQ0KaXQgdG8gc2NvcGUgQjogVXNl ciBhdXRob3JpemVzIENsaWVudCB0byBhY2Nlc3MgaGlzIHByb2ZpbGUgaW5mb3JtYXRpb24uDQpV c2VyIGNhbiBzdGlsbCBwbGF5IHRoZSBnYW1lcywgwqB5ZXQgQ2xpZW50IGNhbuKAmXQgcG9zdCBt ZXNzYWdlcyBvbiBVc2Vy4oCZcw0KYmVoYWxmLCBhcyBvcmlnaW5hbGx5IGFncmVlZC4NCg0KDQpP QXV0aCAyLjAgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IGFuZCBpbXBsaWNpdCBncmFudCBhcmUg dnVsbmVyYWJsZSB0byB0aGUNCnNjb3BlIGF0dGFjay4NCg0KDQoNCg0KDQpBIFNjb3BlIEF0dGFj ayBTY2VuYXJpbw0KDQoNCigxKSBBdXRob3JpemF0aW9uIFNlcnZlcjogRmFjZWJvb2sgKGF1dGhv cml6YXRpb24gY29kZSBncmFudCkNCg0KDQogICAgICAoMikgQ2xpZW50OiBPbmxpbmUgZ2FtaW5n IGNvbXBhbnkgR2FtZS4gSXQgYWxsb3dzIFVzZXIgdG8gcGxheSB0aGUNCiAgICAgIGdhbWVzIHdp dGggdGhlIHNlcnZpY2UgYWdyZWVtZW50IHNjb3BlIEE6IFVzZXIgYXV0aG9yaXplcyBHYW1lIHRv DQogICAgICBhY2Nlc3MgaGlzIHByb2ZpbGUgaW5mb3JtYXRpb24gYW5kIHBvc3QgbWVzc2FnZXMg b24gaGlzIGJlaGFsZi4NCg0KDQogICAgICAoMykgVXNlcjogbWFsaWNpb3VzIFVzZXIgd2l0aCBh biBhY2NvdW50IGF0IEZhY2Vib29rLiBIZSBhdHRlbXB0cyB0bw0KICAgICAgcGxheSB0aGUgZ2Ft ZXMgeWV0IHdpdGhvdXQgYXV0aG9yaXppbmcgR2FtZSB0byBwb3N0IG1lc3NhZ2VzIG9uIGhpcw0K ICAgICAgYmVoYWxmLCB0aGF0IGlzLCBoZSBjaGFuZ2VzIHRoZSBzY29wZSBmcm9tIEEgdG8gQjog YXV0aG9yaXphdGlvbiBvZg0KICAgICAgQ2xpZW50IHRvIGFjY2VzcyBoaXMgcHJvZmlsZSBpbmZv cm1hdGlvbiBvbmx5Lg0KDQoNCg0KDQoNCkF0dGFjayBXb3JrZmxvdw0KDQoNCiAgICAgICAgKDEp IFVzZXIgcmVxdWVzdHMgR2FtZSAoQ2xpZW50KSBmb3IgcGVybWlzc2lvbiB0byBwbGF5IGdhbWVz LA0KICAgICAgICBpbnN0YW50aWF0aW5nIE9BdXRoIDIuMCB3aXRoIHNjb3BlIEEuDQoNCg0KICAg ICAgICAoMikgR2FtZSBnZW5lcmF0ZXMgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0IHdpdGggYSBz Y29wZQ0KICAgICAgICBzcGVjaWZpY2F0aW9uIEEsIGFuZCByZWRpcmVjdHMgVXNlciB0byBGYWNl Ym9vayB3aXRoIHRoZSByZXF1ZXN0Lg0KDQoNCiAgICAgICAgKDMpIFVzZXIgbWFuaXB1bGF0ZXMg dGhlIHNjb3BlIGZpZWxkIGFuZCBjaGFuZ2VzIGl0IHRvIHNjb3BlIEIuIFRoZQ0KICAgICAgICBt b2RpZmllZCByZXF1ZXN0IGlzIHRoZW4gc2VudCB0byBGYWNlYm9vay4NCg0KDQogICAgICAgICg0 KSBVc2VyIGdyYW50cyB0aGUgbW9kaWZpZWQgcmVxdWVzdC4NCg0KDQogICAgICAgICg1KSBGYWNl Ym9vayByZWRpcmVjdHMgVXNlciBiYWNrIHRvIEdhbWUgd2l0aCB0aGUgYXV0aG9yaXphdGlvbg0K ICAgICAgICBjb2RlLg0KDQoNCiAgICAgICAgKDYpIEdhbWUgZXhjaGFuZ2VzIHRoZSBhdXRob3Jp emF0aW9uIGNvZGUgZm9yIGFuIGFjY2VzcyB0b2tlbi4NCiAgICAgICAgSG93ZXZlciBpdCBoYXMg bm8ga25vd2xlZGdlIHRoYXQgdGhlIHNjb3BlIEEgaGFzIGJlZW4gY2hhbmdlZCB0bw0KICAgICAg ICBzY29wZSBCLg0KDQoNCiAgICAgICAgKDcpIEdhbWUgcHJvdmlkZXMgb25saW5lIGdhbWluZyBz ZXJ2aWNlIHRvIFVzZXIuIEhvd2V2ZXIsIEdhbWUNCiAgICAgICAgY2Fu4oCZdCBwb3N0IG1lc3Nh Z2VzIG9uIFVzZXLigJlzIEZhY2Vib29rIHBhZ2UuDQoNCg0KDQoNCg0KQSBMaXZlLURlbW86IEZh Y2Vib29rIGFuZCBDYXN0bGVWaWxsZSAoSUUgYW5kIFNhZmFyaSB0ZXN0ZWQpDQoNCg0KICAgICAg U3RlcCAxOiBMb2dpbiBGYWNlYm9vayBhbmQgdmlzaXQgRmFjZWJvb2sgQXBwcyBhbmQgR2FtZSBw YWdlDQoNCg0KICAgICAgaHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL2dhbWVzDQoNCg0KU3RlcCAy OiBDbGljayBDYXN0bGVWaWxsZS4NCg0KDQogICAgICBTdGVwIDM6IFdoZW4geW91IHNlZSB0aGUg UmVxdWVzdCBmb3IgUGVybWlzc2lvbiBwYWdlLCBpbnN0ZWFkIG9mDQoNCg0KICAgICAgICAgICAg Y2xpY2tpbmcg4oCcQWxsb3figJ0sIGNoYW5nZSB0aGUgc2NvcGUgZmllbGQgaW4gdGhlIFVSTCBm cm9tIHlvdXINCiAgICAgICAgICAgIGJyb3dzZXIgZnJvbcKgIOKAnHNjb3BlPWVtYWlsJTJDcHVi bGlzaF9zdHJlYW0lMkNwdWJsaXNoX2FjdGlvbnPigJ0NCiAgICAgICAgICAgIHRvIOKAnHNjb3Bl PWVtYWlsJTJDcHVibGlzaF9zdHJlYW3igJ0uDQoNCg0KICAgICAgU3RlcCA0OiBBZnRlciB0aGUg bW9kaWZpY2F0aW9uLCBwcmVzcyBFTlRFUiB0byBzZW5kIHRoZSBtb2RpZmllZA0KDQoNCiAgICAg ICAgICAgIHJlcXVlc3QgdG8gRmFjZWJvb2suIE5vdyB5b3Ugd2lsbCBzZWUgdGhlIG1vZGlmaWVk IFJlcXVlc3Qgb2YNCiAgICAgICAgICAgIFBlcm1pc3Npb24gcGFnZS4NCg0KDQpTdGVwIDU6IENs aWNrIG9uIOKAnEFsbG934oCdIGJ1dHRvbiBhbmQgZW5qb3kgdGhlIGdhbWUuDQoNCg0KKHZpZGVv OiBodHRwOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9emttakxhM1ZVOXcpDQoNCg0KDQoNCg0K SW1wYWN0DQoNCg0KQ2xpZW50IHByb3ZpZGVzIHNlcnZpY2VzIHRvIG1hbGljaW91cyBVc2VyIHll dCB3aXRoIHRoZSBtb2RpZmllZCBzZXJ2aWNlDQphZ3JlZW1lbnQgc2NvcGUgYnkgVXNlcuKAmXMg ZGVzaWduLg0KDQoNCg0KDQoNCk1hbmlwdWxhdGluZyBTY29wZSBGaWVsZA0KDQoNClRoZSBzY29w ZSBmaWVsZCBpbiBhY2Nlc3MgdG9rZW4gcmVzcG9uc2UgaXMgcmVxdWlyZWQgT05MWSBJRiBBdXRo b3JpemF0aW9uDQpTZXJ2ZXIgb2JzZXJ2ZXMgdGhhdCB0aGUgVXNlciBhdXRob3JpemVkIHNjb3Bl IGlzIGRpZmZlcmVudCB0aGFuIHRoZQ0Kb3JpZ2luYWwgc2NvcGUuIENvbnNlcXVlbnRseSwgVXNl ciBjYW4gbWFuaXB1bGF0ZSB0aGUgc2NvcGUgZmllbGQgc28gdGhhdA0KQXV0aG9yaXphdGlvbiBT ZXJ2ZXIgY2Fubm90IGRldGVjdCB0aGUgY2hhbmdlIG9mIHRoZSBzY29wZS4gQXMgYSByZXN1bHQN CkNsaWVudCBwcm92aWRlcyB0aGUgc2VydmljZXMgeWV0IGNhbuKAmXQgb2J0YWluIHRoZSBpbmZv cm1hdGlvbiB0aGF0IGlzDQpzcGVjaWZpZWQgaW4gdGhlIHNjb3BlIG9mIHRoZSBvcmlnaW5hbCBz ZXJ2aWNlIGFncmVlbWVudC4NCg0KDQpDbGllbnQgY2FuIHZlcmlmeSB0aGUgc2VydmljZSBhZ3Jl ZW1lbnQgc2NvcGUgYnkgY2hlY2tpbmcgYWxsIHRoZSBmaWVsZHMNCmFnYWluc3QgdGhlIG9yaWdp bmFsIFVzZXIgcmVxdWVzdCBiZWZvcmUgcHJvdmlkaW5nIHRoZSByZXF1ZXN0ZWQgc2VydmljZXMN CnRvIFVzZXIuIMKgRm9yIGluc3RhbmNlLCBDbGllbnQgY2FuIHZlcmlmeSB0aGUgZ3JhbnRlZCBw ZXJtaXNzaW9ucyBpZg0KQXV0aG9yaXphdGlvbiBTZXJ2ZXIgKGUuZy4gRmFjZWJvb2spwqAgcHJv dmlkZXMgYW4gQVBJLiBIb3dldmVyLCB0aGlzIGlzIG91dA0Kb2YgdGhlIHNjb3BlIG9mIE9BdXRo IDIuMCwgYW5kIENsaWVudCBtYXkgbm90IGNoZWNrIGl0LiBXZSBvYnNlcnZlOiBhbGwgdG9wDQpm aXZlIGdhbWVzIHJlY29tbWVuZGVkIGJ5IEZhY2Vib29rIGFyZSB2dWxuZXJhYmxlIHRvIHRoZSBz Y29wZSBhdHRhY2suDQoNCg0KDQoNCg0KUHJvcG9zZWQgRml4DQoNCg0KRHJhZnQtaWV0Zi1vYXV0 aC12Mi0yMyBTZWN0aW9uIDUuMToNCg0KDQpDaGFuZ2UgZnJvbQ0KDQoNCiAgICAgIOKAnHNjb3Bl DQoNCg0KICAgICAgwqDCoMKgwqDCoMKgwqDCoCBPUFRJT05BTCwgaWYgaWRlbnRpY2FsIHRvIHRo ZSBzY29wZSByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCwNCg0KDQogICAgICDCoMKgwqDCoMKgwqDC oMKgIG90aGVyd2lzZSBSRVFVSVJFRC7igJ0NCg0KDQp0bw0KDQoNCuKAnHNjb3BlIFJFUVVJUkVE 4oCdIC8qIHNjb3BlOiBVc2VyIGF1dGhvcml6ZWQgc2NvcGUgKi8NCg0KDQoNCg0KDQpSZW1hcmtz DQoNCg0KKDEpIFRoZSBwcm9vZiBvZiB0aGUgY29ycmVjdG5lc3Mgb2YgT0F1dGggd2l0aCBvdXIg cHJvcG9zZWQgZml4IHdpbGwgYmUNCnB1Ymxpc2hlZCBpbiBhbiBhcnRpY2xlOiDigJxPQXV0aCAy LjAg4oCTIEF0dGFja3MsIEZpeGVzLCBDb3JyZWN0bmVzcywgYW5kDQpHZW5lcmFsaXphdGlvbnMs IFdlbmppZSBMaW4sIERhdmlkIExlZSBhbmQgU3RldmUgTGFpLCB0byBhcHBlYXLigJ0uDQoNCg0K KDIpIFRoZSBpbXBsaWNpdCBncmFudCBpcyBhbHNvIHZ1bG5lcmFibGUgdG8gdGhlIHNjb3BlIGF0 dGFjay4gSG93ZXZlciBpdA0KY2Fubm90IGJlIGZpeGVkIGJ5IGVuZm9yY2luZyBzY29wZSBmaWVs ZCBpbiBhY2Nlc3MgdG9rZW4gcmVzcG9uc2UgYXMgYWJvdmU7DQpVc2VyIGNhbiBjaGFuZ2UgdGhl IHNjb3BlIGluIHJlc3BvbnNlIGJlZm9yZSBiZWluZyByZWRpcmVjdGVkIHRvIENsaWVudC4NCg0K DQoNCg0KDQpXZW5qaWUgTGluLCBUaGUgT2hpbyBTdGF0ZSBVbml2ZXJzaXR5DQoNCg0KRGF2aWQg TGVlLCBIUCBMYWJzIGFuZCBUaGUgT2hpbyBTdGF0ZSBVbml2ZXJzaXR5DQoNCg0KU3RldmUgTGFp LCBUaGUgT2hpbyBTdGF0ZSBVbml2ZXJzaXR5DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg== From ve7jtb@ve7jtb.com Sat Feb 18 14:47:36 2012 Return-Path: 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 4168D21E8011 for ; Sat, 18 Feb 2012 14:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 QcPImuEYI7yH for ; Sat, 18 Feb 2012 14:47:35 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1195421E800F for ; Sat, 18 Feb 2012 14:47:34 -0800 (PST) Received: by yhkk25 with SMTP id k25so2576950yhk.31 for ; Sat, 18 Feb 2012 14:47:34 -0800 (PST) Received-SPF: pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.153.6 as permitted sender) client-ip=10.236.153.6; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.153.6 as permitted sender) smtp.mail=ve7jtb@ve7jtb.com Received: from mr.google.com ([10.236.153.6]) by 10.236.153.6 with SMTP id e6mr20754726yhk.113.1329605254616 (num_hops = 1); Sat, 18 Feb 2012 14:47:34 -0800 (PST) Received: by 10.236.153.6 with SMTP id e6mr15875493yhk.113.1329605253509; Sat, 18 Feb 2012 14:47:33 -0800 (PST) Received: from [192.168.1.213] ([190.22.86.242]) by mx.google.com with ESMTPS id g7sm33736796yhm.5.2012.02.18.14.47.30 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 18 Feb 2012 14:47:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_2C69CE81-EE50-49C0-B7BF-5332A0D2DB11"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Sat, 18 Feb 2012 19:47:24 -0300 Message-Id: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> References: To: Shane B Weeden X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmGdZk3OuVRAcJeX1zyqxeLvvFjtJ4YEIjfquaXcBoWzI4OA/IvlAU1Nwe37nC/hCPMvs+j Cc: Wenjie Lin , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 22:47:36 -0000 --Apple-Mail=_2C69CE81-EE50-49C0-B7BF-5332A0D2DB11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree that it is not a protocol problem. The problem is that some developers are not understanding the spec. One case I saw recently was a proposal to send a scope to the = Authorization endpoint that changed is authentication behaviour e.g. ask = for mlti-factor authentication. On a superficial reading of the spec they thought that not getting a = changed set of scopes back in the response that the Authorization server = was indicating that it had done what was asked. When I pointed out that the user agent can remove scopes because = requests are not signed, they had a similar solution of forcing all the = endpoints to always return the scopes granted. I hope I talked them out of that. The problem is getting people to use scopes to represent resources and = not other arbitrary configuration things, and to understand that even = if they do get a scope granted it could disappear before they get to use = the access token and they need to be prepared for that. The premise that users get access to y for access to x is something that = can be built with OAuth but is not something that can be inferred in the = way they are proposing. =46rom my perspective replying with granted scopes is a convince for the = client, but not something that can be depended upon. =20 I don't think we need any normative change. A don't make stupid assumptions about the persistence of scopes in = tokens note would be as far as I would go. John B. On 2012-02-18, at 3:34 AM, Shane B Weeden wrote: > I agree with others - this is not an attack on the protocol. The user = has > the choice about which scope to grant and the client's redirect to the > authorization endpoint is only a request for a particular set of > permissions, not a guarantee that it will get them. The = user+authorization > server decide which scope is actually granted. The client needs to = handle > cases where that differs from what it originally wanted. >=20 >=20 >=20 >=20 > From: Wenjie Lin > To: oauth@ietf.org > Date: 18/02/2012 12:12 PM > Subject: [OAUTH-WG] A Scope Attack against OAuth 2.0 > Sent by: oauth-bounces@ietf.org >=20 >=20 >=20 > We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called = scope > attack, provide a live-demo of the attack on Facebook, and propose a = fix > with discussions. >=20 >=20 >=20 >=20 >=20 > Scope Attack >=20 >=20 > OAuth authorization of services is associated with service agreement = scope. > For instance, Client provides an online game to User with a service > agreement scope A: User authorizes Client to access his profile = information > and to post messages on his behalf. A malicious User can request for = online > game with service agreement scope A, manipulate the scope field, and = change > it to scope B: User authorizes Client to access his profile = information. > User can still play the games, yet Client can=92t post messages on = User=92s > behalf, as originally agreed. >=20 >=20 > OAuth 2.0 authorization code grant and implicit grant are vulnerable = to the > scope attack. >=20 >=20 >=20 >=20 >=20 > A Scope Attack Scenario >=20 >=20 > (1) Authorization Server: Facebook (authorization code grant) >=20 >=20 > (2) Client: Online gaming company Game. It allows User to play = the > games with the service agreement scope A: User authorizes Game to > access his profile information and post messages on his behalf. >=20 >=20 > (3) User: malicious User with an account at Facebook. He attempts = to > play the games yet without authorizing Game to post messages on = his > behalf, that is, he changes the scope from A to B: authorization = of > Client to access his profile information only. >=20 >=20 >=20 >=20 >=20 > Attack Workflow >=20 >=20 > (1) User requests Game (Client) for permission to play games, > instantiating OAuth 2.0 with scope A. >=20 >=20 > (2) Game generates an authorization request with a scope > specification A, and redirects User to Facebook with the = request. >=20 >=20 > (3) User manipulates the scope field and changes it to scope B. = The > modified request is then sent to Facebook. >=20 >=20 > (4) User grants the modified request. >=20 >=20 > (5) Facebook redirects User back to Game with the authorization > code. >=20 >=20 > (6) Game exchanges the authorization code for an access token. > However it has no knowledge that the scope A has been changed = to > scope B. >=20 >=20 > (7) Game provides online gaming service to User. However, Game > can=92t post messages on User=92s Facebook page. >=20 >=20 >=20 >=20 >=20 > A Live-Demo: Facebook and CastleVille (IE and Safari tested) >=20 >=20 > Step 1: Login Facebook and visit Facebook Apps and Game page >=20 >=20 > https://www.facebook.com/games >=20 >=20 > Step 2: Click CastleVille. >=20 >=20 > Step 3: When you see the Request for Permission page, instead of >=20 >=20 > clicking =93Allow=94, change the scope field in the URL = from your > browser from = =93scope=3Demail%2Cpublish_stream%2Cpublish_actions=94 > to =93scope=3Demail%2Cpublish_stream=94. >=20 >=20 > Step 4: After the modification, press ENTER to send the modified >=20 >=20 > request to Facebook. Now you will see the modified Request = of > Permission page. >=20 >=20 > Step 5: Click on =93Allow=94 button and enjoy the game. >=20 >=20 > (video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w) >=20 >=20 >=20 >=20 >=20 > Impact >=20 >=20 > Client provides services to malicious User yet with the modified = service > agreement scope by User=92s design. >=20 >=20 >=20 >=20 >=20 > Manipulating Scope Field >=20 >=20 > The scope field in access token response is required ONLY IF = Authorization > Server observes that the User authorized scope is different than the > original scope. Consequently, User can manipulate the scope field so = that > Authorization Server cannot detect the change of the scope. As a = result > Client provides the services yet can=92t obtain the information that = is > specified in the scope of the original service agreement. >=20 >=20 > Client can verify the service agreement scope by checking all the = fields > against the original User request before providing the requested = services > to User. For instance, Client can verify the granted permissions if > Authorization Server (e.g. Facebook) provides an API. However, this = is out > of the scope of OAuth 2.0, and Client may not check it. We observe: = all top > five games recommended by Facebook are vulnerable to the scope attack. >=20 >=20 >=20 >=20 >=20 > Proposed Fix >=20 >=20 > Draft-ietf-oauth-v2-23 Section 5.1: >=20 >=20 > Change from >=20 >=20 > =93scope >=20 >=20 > OPTIONAL, if identical to the scope requested by the = client, >=20 >=20 > otherwise REQUIRED.=94 >=20 >=20 > to >=20 >=20 > =93scope REQUIRED=94 /* scope: User authorized scope */ >=20 >=20 >=20 >=20 >=20 > Remarks >=20 >=20 > (1) The proof of the correctness of OAuth with our proposed fix will = be > published in an article: =93OAuth 2.0 =96 Attacks, Fixes, Correctness, = and > Generalizations, Wenjie Lin, David Lee and Steve Lai, to appear=94. >=20 >=20 > (2) The implicit grant is also vulnerable to the scope attack. However = it > cannot be fixed by enforcing scope field in access token response as = above; > User can change the scope in response before being redirected to = Client. >=20 >=20 >=20 >=20 >=20 > Wenjie Lin, The Ohio State University >=20 >=20 > David Lee, HP Labs and The Ohio State University >=20 >=20 > Steve Lai, The Ohio State University > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2C69CE81-EE50-49C0-B7BF-5332A0D2DB11 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MTgyMjQ3MjVaMCMGCSqGSIb3DQEJBDEWBBRaQgD3cgAi+xl0YERI/JzwTEO4DzCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQBPlF1K9o4J65keJxUPI5gsQc0Wpy2jGMzc4WW9KlcOcWwaXonhwnAaQ90WqCFLYW9OQpZT2p6h 14Oj+GNactGHMYfoiPw+auhenk9IXO0vgkU9522FI/puOThujbGkye4uJWFGAaNS2NYbqO7yNebP Ele5KZQsx4Znin7HWeLBtJAjeMQGZXizpVrzXUYaghoYR2FqMwTecttpKMeLy8I5heLmfXIrJuDV kRIwm0qKFK09fTKM2H5XZRWWzNHFOsr58pXtQTKfM5mKNCke6oPcbcNeYcpCxquG4KiqS9L2SNSf ZvIpQ/OZ5q/FozQLoA5BRjGvA8Ru6mUDBFSKJrNzAAAAAAAA --Apple-Mail=_2C69CE81-EE50-49C0-B7BF-5332A0D2DB11-- From ve7jtb@ve7jtb.com Sat Feb 18 15:41:09 2012 Return-Path: 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 BA5AA21E800F for ; Sat, 18 Feb 2012 15:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 YXkHx2P-zwCp for ; Sat, 18 Feb 2012 15:41:08 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93D5F21F8591 for ; Sat, 18 Feb 2012 15:41:08 -0800 (PST) Received: by yhkk25 with SMTP id k25so2583686yhk.31 for ; Sat, 18 Feb 2012 15:41:08 -0800 (PST) Received-SPF: pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.100.245.4 as permitted sender) client-ip=10.100.245.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.100.245.4 as permitted sender) smtp.mail=ve7jtb@ve7jtb.com Received: from mr.google.com ([10.100.245.4]) by 10.100.245.4 with SMTP id s4mr320250anh.8.1329608468240 (num_hops = 1); Sat, 18 Feb 2012 15:41:08 -0800 (PST) Received: by 10.100.245.4 with SMTP id s4mr243447anh.8.1329608466437; Sat, 18 Feb 2012 15:41:06 -0800 (PST) Received: from [192.168.1.213] (186-107-131-167.baf.movistar.cl. [186.107.131.167]) by mx.google.com with ESMTPS id h20sm21287270ang.7.2012.02.18.15.41.03 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 18 Feb 2012 15:41:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_91152047-461F-4912-9A67-291EA3B6FDCD"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Sat, 18 Feb 2012 20:41:01 -0300 Message-Id: References: To: Eran Hammer X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkAesydXWWHTEIyj/el0IHzifvjT9+k+acOHw2FaqA1T82F3wpSPtVuBvQzMkN74YMI9By/ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 23:41:09 -0000 --Apple-Mail=_91152047-461F-4912-9A67-291EA3B6FDCD Content-Type: multipart/alternative; boundary="Apple-Mail=_4AD787A3-64F1-4571-8293-F7AD8BE0758B" --Apple-Mail=_4AD787A3-64F1-4571-8293-F7AD8BE0758B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It is a general problem with security protocols like SOAP, SAML, X.509. Sometimes when you define an extension you want to be certain that the = Authorization server understands it, or you want an error. As an example if someone did a authentication context extension (Not = proposing it just an example). They would perhaps rather have an error = if the Authorization server did not understand the extension, they = could then retry without the extension if that worked for them. This is generally dealt with by marking something as mustUnderstand in = SOAP or critical in x.509. Without that functionality (I am not asking to add it) it may be = reasonable for some Authorization servers to return an error if they do = not completely understand what is being sent to them. One school of thought feels that anything you don't understand in a = message could be an indication of a problem or tampering. =20 I am sympathetic to the Forward compatibility argument, however without = some sort of mustUnderstand semantics it is not going to always work. One thing that might help is an error message to indicate that it is = being rejected due to unknown extensions so a client can retry. John B.=20 On 2012-02-16, at 8:01 PM, Eran Hammer wrote: > Can you give an example where an unknown parameter being ignored can = lead to security issues? >=20 > EH >=20 >=20 > From: John Bradley > Date: Thu, 16 Feb 2012 11:55:21 -0700 > To: William Mills > Cc: "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters >=20 > If you have a generic client that works across multiple Authorization = endpoints some that have extension X and others not, I can see that = having the Authorization servers ignore unknown parameters is desirable. >=20 > However there are some endpoints that are not going to be able to = allow unknown parameters due to there security policy. They are often = a indication of an attack. >=20 > If this remains a MUST then some endpoints will have to ignore it, and = be non compliant. >=20 > I would be OK with something like "MUST ignore unknown parameters = unless the endpoint is required to return an error due to local security = policy." >=20 > There is probably no perfect compromise on this one. >=20 > John B. >=20 >=20 > On 2012-02-16, at 3:32 PM, William Mills wrote: >=20 >> No, this is required for forward compatibility. Implementations that = send extended parameters like capability advertisements (i.e. CAPTCHA = support or something) shoudl not be broken hitting older = implementations. >>=20 >> From: Mike Jones >> To: "oauth@ietf.org" =20 >> Sent: Thursday, February 16, 2012 10:16 AM >> Subject: [OAUTH-WG] Ignoring unrecognized request parameters >>=20 >> In core -23, the last paragraph of section 3.1 now says: >> =20 >> The authorization server MUST ignore unrecognized = request parameters. >> =20 >> In -22, this said: >> =20 >> The authorization server SHOULD ignore unrecognized = request parameters. >> =20 >> In a security protocol, it seems unreasonable to require that = information be ignored. As I see it, it SHOULD be legal to return an = error if unrecognized information is received. >> =20 >> Why the change? And can we please have it changed back to SHOULD in = -24? >> =20 >> = Thanks, >> -- = Mike >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_4AD787A3-64F1-4571-8293-F7AD8BE0758B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It is = a general problem with security protocols like SOAP, SAML, = X.509.

Sometimes when you define an extension you = want to be certain that the Authorization server understands it, =  or you want an error.

As an example if = someone did a authentication context extension (Not proposing it just an = example).   They would perhaps rather have an error if the = Authorization server did not understand the extension,  they could = then retry without the extension if that worked for = them.

This is generally dealt with by marking = something as mustU= nderstand in SOAP or critical in = x.509.

Without that functionality (I am not = asking to add it) it may be reasonable for some Authorization servers to = return an error if they do not completely understand what is being sent = to them.

One school of thought feels that = anything you don't understand in a message could be an indication of a = problem or tampering.   

I am = sympathetic to the Forward compatibility argument,  however without = some sort of mustUnderstand semantics it is not going to always = work.

One thing that might help is an error = message to indicate that it is being rejected due to unknown extensions = so a client can retry.

John = B. 


On 2012-02-16, at 8:01 = PM, Eran Hammer wrote:

Can you give an example = where an unknown parameter being ignored can lead to security = issues?

EH


From: = John Bradley <ve7jtb@ve7jtb.com>
Date: Thu, 16 Feb 2012 11:55:21 = -0700
To: William Mills = <wmills@yahoo-inc.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Ignoring = unrecognized request parameters

If you have a generic client = that works across multiple Authorization endpoints some that have = extension X and others not, I can see that having the Authorization = servers ignore unknown parameters is = desirable.

However there are some endpoints that are = not going to be able to allow unknown parameters due to there security = policy.   They are often a indication of an = attack.

If this remains a MUST then some = endpoints will have to ignore it, and be non = compliant.

I would be OK with something like = "MUST ignore unknown parameters unless the endpoint is required to = return an error due to local security = policy."

There is probably no perfect = compromise on this one.

John = B.


On 2012-02-16, at = 3:32 PM, William Mills wrote:

No, = this is required for forward compatibility.  Implementations that = send extended parameters like capability advertisements (i.e. CAPTCHA = support or something) shoudl not be broken hitting older = implementations.

=
From: Mike Jones <Michael.Jones@microsoft.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, February 16, = 2012 10:16 AM
Subject: [OAUTH-WG] Ignoring unrecognized request = parameters

=20 =20
In core -23, the last paragraph of sec= tion 3.1 now says:
=20
 
=20
       =          The authorization = server MUST ignore unrecognized request parameters.
=20
 
=20
In -22, this said:
=20
 
=20
       =          The authorization = server SHOULD ignore unrecognized request parameters.
=20
 
=20
In a security protocol, it seems = unreasonable to require that information be ignored.  As I see it, = it SHOULD be legal to return an error if unrecognized information is = received.
=20
 
=20
Why the change?  And can we = please have it changed back to SHOULD in -24?
=20
 
=20
       =             &n= bsp;           &nbs= p;            =             &n= bsp;       Thanks,
=20
       =             &n= bsp;           &nbs= p;            =             &n= bsp;       -- Mike
=20
 
=20 =

_______________________________________________
O= Auth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
=
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


= --Apple-Mail=_4AD787A3-64F1-4571-8293-F7AD8BE0758B-- --Apple-Mail=_91152047-461F-4912-9A67-291EA3B6FDCD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MTgyMzQxMDFaMCMGCSqGSIb3DQEJBDEWBBQh/6QiLCtBaqdSmfOo7BaZ+GZFbTCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQBrhJFvQipaiJR08T1aCPJ7MFDZFuFYJGwe699w0Aq+5EfEzKvO3QWHvHny8UYNlK/2lCRfhi8t 6x/5TiiM2rgBiUL0E2rXPXvfWotHpjoauQmmRYXsmmoQxbJ7UjAeDYciMM20qeTpBHsnI4LiC4LH tcQWVpwCWE54VH7Ft9sstDydUiXUnIpJoSjJHW3VE6joLWZxDUxfMYztRcB7oZbUugBbYCr00sww 7gPveNWk6/eq92zC9Xg3KF6Zn9Vlk8GQS4ucWWqphqAum7s6PoBVSxehQ++AaMjqMR5sxlkHxdnV OXpR0Yoqsh0eK4aHj2QoqEEaqiXYVKTHQokmg/5dAAAAAAAA --Apple-Mail=_91152047-461F-4912-9A67-291EA3B6FDCD-- From wenjielin.bupt@gmail.com Sat Feb 18 20:19:08 2012 Return-Path: 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 D803211E8088 for ; Sat, 18 Feb 2012 20:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 A-GUI9Dc6s2W for ; Sat, 18 Feb 2012 20:19:07 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D77111E8075 for ; Sat, 18 Feb 2012 20:19:07 -0800 (PST) Received: by iagf6 with SMTP id f6so7425950iag.31 for ; Sat, 18 Feb 2012 20:19:05 -0800 (PST) Received-SPF: pass (google.com: domain of wenjielin.bupt@gmail.com designates 10.50.34.164 as permitted sender) client-ip=10.50.34.164; Authentication-Results: mr.google.com; spf=pass (google.com: domain of wenjielin.bupt@gmail.com designates 10.50.34.164 as permitted sender) smtp.mail=wenjielin.bupt@gmail.com; dkim=pass header.i=wenjielin.bupt@gmail.com Received: from mr.google.com ([10.50.34.164]) by 10.50.34.164 with SMTP id a4mr5563956igj.14.1329625145336 (num_hops = 1); Sat, 18 Feb 2012 20:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=UJ7QzhKi5q1FXDIHq2nRNRXbvyJKgHMe6MgWhY3JrnE=; b=Bi/OV5JMTRB0QdUDuUcXc3f6WvrQcIqBP/AaGWlwPs7WL0UdrrG5YdgZfFZ7mw2Ow9 +q/u0VcHAzTvvOb4K11lo1SIKmtmg/lgB+KBpxslQHW86TPYwolsNX93dVrGOTqxUDe6 r60PDRpLImzW55kmuyHRq9QKWbrdEbyDEgf88= Received: by 10.50.34.164 with SMTP id a4mr4513979igj.14.1329625145206; Sat, 18 Feb 2012 20:19:05 -0800 (PST) MIME-Version: 1.0 Sender: wenjielin.bupt@gmail.com Received: by 10.42.139.138 with HTTP; Sat, 18 Feb 2012 20:18:45 -0800 (PST) In-Reply-To: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> From: Wenjie Lin Date: Sat, 18 Feb 2012 20:18:45 -0800 X-Google-Sender-Auth: gHTpY0Q14zIxHgALa03zLe-CWvM Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=14dae934050f76e62804b9497a83 Cc: "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 04:19:09 -0000 --14dae934050f76e62804b9497a83 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We appreciate your attention and response to our report.**** ** ** Since Authorization Server obtains the scope information ONLY from User, it can=92t tell whether the issued access token scope is different from the o= ne requested by Client, so long as User is consistently sending the same altered scope information to Authorization Server. Consequently, as an Option, Authorization Server may choose not to include the scope response parameter to inform Client of the actual scope granted, and that results in the scope attack. This is a protocol issue and is not an implementation issue; one can come up with an implementation that is compliant with the protocol specification yet with a scope attack.**** ** ** One may argue that we only care about User protection and security. Consequently, scope attack is apparently not a protocol security issue. However, it would significantly limit the applicability of the protocol, if Client is knowingly exposed to attacks. We need Client protection and security as well in applications, for instance, cloud services.**** ** ** Scope attack can be easily fixed. One can simply make it Required that Authorization Server MUST include the scope response parameter to inform Client of the actual scope granted, as we have proposed for your consideration.**** ** ** OAuth 2.0 is a sound protocol design. We prove the security properties (for both User and Client) and scope attack is an issue we=92ve got stuck in the proof.**** ** ** - W. Lin and D. Lee On Sat, Feb 18, 2012 at 2:47 PM, John Bradley wrote: > I agree that it is not a protocol problem. > > The problem is that some developers are not understanding the spec. > > One case I saw recently was a proposal to send a scope to the > Authorization endpoint that changed is authentication behaviour e.g. ask > for mlti-factor authentication. > > On a superficial reading of the spec they thought that not getting a > changed set of scopes back in the response that the Authorization server > was indicating that it had done what was asked. > > When I pointed out that the user agent can remove scopes because requests > are not signed, they had a similar solution of forcing all the endpoints > to always return the scopes granted. > > I hope I talked them out of that. > > The problem is getting people to use scopes to represent resources and no= t > other arbitrary configuration things, and to understand that even if the= y > do get a scope granted it could disappear before they get to use the acce= ss > token and they need to be prepared for that. > > The premise that users get access to y for access to x is something that > can be built with OAuth but is not something that can be inferred in the > way they are proposing. > > From my perspective replying with granted scopes is a convince for the > client, but not something that can be depended upon. > I don't think we need any normative change. > > A don't make stupid assumptions about the persistence of scopes in tokens > note would be as far as I would go. > > John B. > > On 2012-02-18, at 3:34 AM, Shane B Weeden wrote: > > > I agree with others - this is not an attack on the protocol. The user h= as > > the choice about which scope to grant and the client's redirect to the > > authorization endpoint is only a request for a particular set of > > permissions, not a guarantee that it will get them. The > user+authorization > > server decide which scope is actually granted. The client needs to hand= le > > cases where that differs from what it originally wanted. > > > > > > > > > > From: Wenjie Lin > > To: oauth@ietf.org > > Date: 18/02/2012 12:12 PM > > Subject: [OAUTH-WG] A Scope Attack against OAuth 2.0 > > Sent by: oauth-bounces@ietf.org > > > > > > > > We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called sco= pe > > attack, provide a live-demo of the attack on Facebook, and propose a fi= x > > with discussions. > > > > > > > > > > > > Scope Attack > > > > > > OAuth authorization of services is associated with service agreement > scope. > > For instance, Client provides an online game to User with a service > > agreement scope A: User authorizes Client to access his profile > information > > and to post messages on his behalf. A malicious User can request for > online > > game with service agreement scope A, manipulate the scope field, and > change > > it to scope B: User authorizes Client to access his profile information= . > > User can still play the games, yet Client can=92t post messages on Use= r=92s > > behalf, as originally agreed. > > > > > > OAuth 2.0 authorization code grant and implicit grant are vulnerable to > the > > scope attack. > > > > > > > > > > > > A Scope Attack Scenario > > > > > > (1) Authorization Server: Facebook (authorization code grant) > > > > > > (2) Client: Online gaming company Game. It allows User to play the > > games with the service agreement scope A: User authorizes Game to > > access his profile information and post messages on his behalf. > > > > > > (3) User: malicious User with an account at Facebook. He attempts = to > > play the games yet without authorizing Game to post messages on hi= s > > behalf, that is, he changes the scope from A to B: authorization o= f > > Client to access his profile information only. > > > > > > > > > > > > Attack Workflow > > > > > > (1) User requests Game (Client) for permission to play games, > > instantiating OAuth 2.0 with scope A. > > > > > > (2) Game generates an authorization request with a scope > > specification A, and redirects User to Facebook with the request= . > > > > > > (3) User manipulates the scope field and changes it to scope B. > The > > modified request is then sent to Facebook. > > > > > > (4) User grants the modified request. > > > > > > (5) Facebook redirects User back to Game with the authorization > > code. > > > > > > (6) Game exchanges the authorization code for an access token. > > However it has no knowledge that the scope A has been changed to > > scope B. > > > > > > (7) Game provides online gaming service to User. However, Game > > can=92t post messages on User=92s Facebook page. > > > > > > > > > > > > A Live-Demo: Facebook and CastleVille (IE and Safari tested) > > > > > > Step 1: Login Facebook and visit Facebook Apps and Game page > > > > > > https://www.facebook.com/games > > > > > > Step 2: Click CastleVille. > > > > > > Step 3: When you see the Request for Permission page, instead of > > > > > > clicking =93Allow=94, change the scope field in the URL from= your > > browser from =93scope=3Demail%2Cpublish_stream%2Cpublish_ac= tions=94 > > to =93scope=3Demail%2Cpublish_stream=94. > > > > > > Step 4: After the modification, press ENTER to send the modified > > > > > > request to Facebook. Now you will see the modified Request o= f > > Permission page. > > > > > > Step 5: Click on =93Allow=94 button and enjoy the game. > > > > > > (video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w) > > > > > > > > > > > > Impact > > > > > > Client provides services to malicious User yet with the modified servic= e > > agreement scope by User=92s design. > > > > > > > > > > > > Manipulating Scope Field > > > > > > The scope field in access token response is required ONLY IF > Authorization > > Server observes that the User authorized scope is different than the > > original scope. Consequently, User can manipulate the scope field so th= at > > Authorization Server cannot detect the change of the scope. As a result > > Client provides the services yet can=92t obtain the information that is > > specified in the scope of the original service agreement. > > > > > > Client can verify the service agreement scope by checking all the field= s > > against the original User request before providing the requested servic= es > > to User. For instance, Client can verify the granted permissions if > > Authorization Server (e.g. Facebook) provides an API. However, this is > out > > of the scope of OAuth 2.0, and Client may not check it. We observe: all > top > > five games recommended by Facebook are vulnerable to the scope attack. > > > > > > > > > > > > Proposed Fix > > > > > > Draft-ietf-oauth-v2-23 Section 5.1: > > > > > > Change from > > > > > > =93scope > > > > > > OPTIONAL, if identical to the scope requested by the > client, > > > > > > otherwise REQUIRED.=94 > > > > > > to > > > > > > =93scope REQUIRED=94 /* scope: User authorized scope */ > > > > > > > > > > > > Remarks > > > > > > (1) The proof of the correctness of OAuth with our proposed fix will be > > published in an article: =93OAuth 2.0 =96 Attacks, Fixes, Correctness, = and > > Generalizations, Wenjie Lin, David Lee and Steve Lai, to appear=94. > > > > > > (2) The implicit grant is also vulnerable to the scope attack. However = it > > cannot be fixed by enforcing scope field in access token response as > above; > > User can change the scope in response before being redirected to Client= . > > > > > > > > > > > > Wenjie Lin, The Ohio State University > > > > > > David Lee, HP Labs and The Ohio State University > > > > > > Steve Lai, The Ohio State University > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --14dae934050f76e62804b9497a83 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

We appreciate your attention and response to our report.<= /u>

=A0

Since A= uthorization Server obtains the scope information ONLY from User, it can=92= t tell whether the issued access token scope=A0 is different from the one r= equested by Client, so long as User is consistently sending the same altere= d scope information to Authorization Server. Consequently, as an Option, Au= thorization Server may choose not to include the scope response parameter t= o inform Client of the actual scope granted, and that results in the scope = attack. This is a protocol issue and is not an implementation issue; one ca= n come up with an implementation that is compliant with the protocol specif= ication yet with a scope attack.

=A0

One may argue that we only care about User protection and security.= Consequently, scope attack is apparently not a protocol security issue. Ho= wever, it would significantly limit the applicability of the protocol, if C= lient is knowingly exposed to attacks. We need Client protection and securi= ty as well in applications, for instance, cloud services.

=A0

Scope attack can be easily fixed. One can simply make it Required t= hat Authorization Server MUST include the scope response parameter to infor= m Client of the actual scope granted, as we have proposed for your consider= ation.

=A0

OAuth 2.0 is a sound protocol design. We prove the security propert= ies (for both User and Client) and scope attack is an issue we=92ve got stu= ck in the proof.

=A0

- W. Lin and D. Lee


On Sat, Feb 18, 2012 at 2:47 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I agree that it is not a protocol problem.
The problem is that some developers are not understanding the spec.

One case I saw recently was a proposal to send a scope to the Authorization= endpoint that changed is authentication behaviour e.g. ask for mlti-factor= authentication.

On a superficial reading of the spec they thought that not getting a change= d set of scopes back in the response that the Authorization server was indi= cating that it had done what was asked.

When I pointed out that the user agent can remove scopes because requests a= re not signed, =A0they had a similar solution of forcing all the endpoints = to always return the scopes granted.

I hope I talked them out of that.

The problem is getting people to use scopes to represent resources and not = other arbitrary configuration things, =A0and to understand that even if the= y do get a scope granted it could disappear before they get to use the acce= ss token and they need to be prepared for that.

The premise that users get access to y for access to x is something that ca= n be built with OAuth but is not something that can be inferred in the way = they are proposing.

>From my perspective replying with granted scopes is a convince for the clie= nt, but not something that can be depended upon.
I don't think we need any normative change.

A don't make stupid assumptions about the persistence of scopes in toke= ns note would be as far as I would go.

John B.

On 2012-02-18, at 3:34 AM, Shane B Weeden wrote:

> I agree with others - this is not an attack on the protocol. The user = has
> the choice about which scope to grant and the client's redirect to= the
> authorization endpoint is only a request for a particular set of
> permissions, not a guarantee that it will get them. The user+authoriza= tion
> server decide which scope is actually granted. The client needs to han= dle
> cases where that differs from what it originally wanted.
>
>
>
>
> From: Wenjie Lin <lin.820@osu.ed= u>
> To: =A0 oauth@ietf.org
> Date: 18/02/2012 12:12 PM
> Subject: =A0 =A0 =A0[OAUTH-WG] A Scope Attack against OAuth 2.0
> Sent by: =A0 =A0 =A0oauth-bo= unces@ietf.org
>
>
>
> We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called sc= ope
> attack, provide a live-demo of the attack on Facebook, and propose a f= ix
> with discussions.
>
>
>
>
>
> Scope Attack
>
>
> OAuth authorization of services is associated with service agreement s= cope.
> For instance, Client provides an online game to User with a service > agreement scope A: User authorizes Client to access his profile inform= ation
> and to post messages on his behalf. A malicious User can request for o= nline
> game with service agreement scope A, manipulate the scope field, and c= hange
> it to scope B: User authorizes Client to access his profile informatio= n.
> User can still play the games, =A0yet Client can=92t post messages on = User=92s
> behalf, as originally agreed.
>
>
> OAuth 2.0 authorization code grant and implicit grant are vulnerable t= o the
> scope attack.
>
>
>
>
>
> A Scope Attack Scenario
>
>
> (1) Authorization Server: Facebook (authorization code grant)
>
>
> =A0 =A0 =A0(2) Client: Online gaming company Game. It allows User to p= lay the
> =A0 =A0 =A0games with the service agreement scope A: User authorizes G= ame to
> =A0 =A0 =A0access his profile information and post messages on his beh= alf.
>
>
> =A0 =A0 =A0(3) User: malicious User with an account at Facebook. He at= tempts to
> =A0 =A0 =A0play the games yet without authorizing Game to post message= s on his
> =A0 =A0 =A0behalf, that is, he changes the scope from A to B: authoriz= ation of
> =A0 =A0 =A0Client to access his profile information only.
>
>
>
>
>
> Attack Workflow
>
>
> =A0 =A0 =A0 =A0(1) User requests Game (Client) for permission to play = games,
> =A0 =A0 =A0 =A0instantiating OAuth 2.0 with scope A.
>
>
> =A0 =A0 =A0 =A0(2) Game generates an authorization request with a scop= e
> =A0 =A0 =A0 =A0specification A, and redirects User to Facebook with th= e request.
>
>
> =A0 =A0 =A0 =A0(3) User manipulates the scope field and changes it to = scope B. The
> =A0 =A0 =A0 =A0modified request is then sent to Facebook.
>
>
> =A0 =A0 =A0 =A0(4) User grants the modified request.
>
>
> =A0 =A0 =A0 =A0(5) Facebook redirects User back to Game with the autho= rization
> =A0 =A0 =A0 =A0code.
>
>
> =A0 =A0 =A0 =A0(6) Game exchanges the authorization code for an access= token.
> =A0 =A0 =A0 =A0However it has no knowledge that the scope A has been c= hanged to
> =A0 =A0 =A0 =A0scope B.
>
>
> =A0 =A0 =A0 =A0(7) Game provides online gaming service to User. Howeve= r, Game
> =A0 =A0 =A0 =A0can=92t post messages on User=92s Facebook page.
>
>
>
>
>
> A Live-Demo: Facebook and CastleVille (IE and Safari tested)
>
>
> =A0 =A0 =A0Step 1: Login Facebook and visit Facebook Apps and Game pag= e
>
>
> =A0 =A0 =A0https://www.facebook.com/games
>
>
> Step 2: Click CastleVille.
>
>
> =A0 =A0 =A0Step 3: When you see the Request for Permission page, inste= ad of
>
>
> =A0 =A0 =A0 =A0 =A0 =A0clicking =93Allow=94, change the scope field in= the URL from your
> =A0 =A0 =A0 =A0 =A0 =A0browser from =A0=93scope=3Demail%2Cpublish_stre= am%2Cpublish_actions=94
> =A0 =A0 =A0 =A0 =A0 =A0to =93scope=3Demail%2Cpublish_stream=94.
>
>
> =A0 =A0 =A0Step 4: After the modification, press ENTER to send the mod= ified
>
>
> =A0 =A0 =A0 =A0 =A0 =A0request to Facebook. Now you will see the modif= ied Request of
> =A0 =A0 =A0 =A0 =A0 =A0Permission page.
>
>
> Step 5: Click on =93Allow=94 button and enjoy the game.
>
>
> (video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w)
>
>
>
>
>
> Impact
>
>
> Client provides services to malicious User yet with the modified servi= ce
> agreement scope by User=92s design.
>
>
>
>
>
> Manipulating Scope Field
>
>
> The scope field in access token response is required ONLY IF Authoriza= tion
> Server observes that the User authorized scope is different than the > original scope. Consequently, User can manipulate the scope field so t= hat
> Authorization Server cannot detect the change of the scope. As a resul= t
> Client provides the services yet can=92t obtain the information that i= s
> specified in the scope of the original service agreement.
>
>
> Client can verify the service agreement scope by checking all the fiel= ds
> against the original User request before providing the requested servi= ces
> to User. =A0For instance, Client can verify the granted permissions if=
> Authorization Server (e.g. Facebook) =A0provides an API. However, this= is out
> of the scope of OAuth 2.0, and Client may not check it. We observe: al= l top
> five games recommended by Facebook are vulnerable to the scope attack.=
>
>
>
>
>
> Proposed Fix
>
>
> Draft-ietf-oauth-v2-23 Section 5.1:
>
>
> Change from
>
>
> =A0 =A0 =A0=93scope
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 OPTIONAL, if identical to the scope reques= ted by the client,
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 otherwise REQUIRED.=94
>
>
> to
>
>
> =93scope REQUIRED=94 /* scope: User authorized scope */
>
>
>
>
>
> Remarks
>
>
> (1) The proof of the correctness of OAuth with our proposed fix will b= e
> published in an article: =93OAuth 2.0 =96 Attacks, Fixes, Correctness,= and
> Generalizations, Wenjie Lin, David Lee and Steve Lai, to appear=94. >
>
> (2) The implicit grant is also vulnerable to the scope attack. However= it
> cannot be fixed by enforcing scope field in access token response as a= bove;
> User can change the scope in response before being redirected to Clien= t.
>
>
>
>
>
> Wenjie Lin, The Ohio State University
>
>
> David Lee, HP Labs and The Ohio State University
>
>
> Steve Lai, The Ohio State University
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth





--14dae934050f76e62804b9497a83-- From wmills@yahoo-inc.com Sat Feb 18 20:34:59 2012 Return-Path: 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 0ABC011E808D for ; Sat, 18 Feb 2012 20:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.398 X-Spam-Level: X-Spam-Status: No, score=-17.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 aWLstpam0IaR for ; Sat, 18 Feb 2012 20:34:57 -0800 (PST) Received: from nm25-vm0.bullet.mail.sp2.yahoo.com (nm25-vm0.bullet.mail.sp2.yahoo.com [98.139.91.228]) by ietfa.amsl.com (Postfix) with SMTP id 36C5911E808C for ; Sat, 18 Feb 2012 20:34:57 -0800 (PST) Received: from [98.139.91.64] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 19 Feb 2012 04:34:54 -0000 Received: from [98.139.91.22] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 19 Feb 2012 04:34:54 -0000 Received: from [127.0.0.1] by omp1022.mail.sp2.yahoo.com with NNFMP; 19 Feb 2012 04:34:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 519360.57225.bm@omp1022.mail.sp2.yahoo.com Received: (qmail 67396 invoked by uid 60001); 19 Feb 2012 04:34:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1329626093; bh=oH8FErEir6Mwqp1vmy+uHWKRHQDVso1nGYOD/wpJsYc=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SU51PdvBsi0nlBj+6CGuJkgfMIy9EvJf51I9Oae3mGBga0Ru4E180nn7CBv+CcbklxVGLLDoAkgKe3uS+UNm8tSxnv/e7RkcHLvxDwWBV/KXWy1yn/Vmt3l48XDv8RySfjTz+SjgIMEzS/pB7BAZaEFpqo3QMNgCOf+MOgieA0I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bYTKH9VJboZ4ahdRwezp27rKmfWFUAHWD+z/u3SZKYZdtYXy65Q9NSGtCC28u5HWnog5HoCaMIPwWoyPB/7y02la3fYvKT05ASy8x/MdqM9jPYjXxbUNba2msRNIq9t8CUeToBp4Kly8nyuGlJzmxazsQkyHe3az6PsQY0HaHh8=; X-YMail-OSG: yRRXVNgVM1lMRVznFYP_VtUuZagZKaG7noxAMA5PWgxgYcF FGYtq034H7Z9gaNoQJVmYHPvCkuM8VGbHX60mNSg5I.V06WvJMwZkpX21iEg zsaMMTkk0HdEOZ6.Vj8cfI0WdN7gAvhNbwMPlq9Zrg7LXqb0xdzcA1WMV13T LUU0WemD6ZHQ2Ns49.DqRL0G9lnH_Hb0WnmlVvYqambohtuz4I58xSaqDEWV X5dqgzH1Ws52wFWbm06jJPLzN4bIyzyi0PtiLEcVuMRZFkKKeY.4uRrRPItC _BQYwbUcs9L1PJYTtnBXZoPxhiGIpJQQqhe1gXRkFAD3VYE90Yw05.vsA3Gp 3bhGlRGObxEuEnkGkIv57LuTNQjsRkLUEQ0fn_y78q11tFEUytTGd_dnDl4h 7LbNScxU8eWCplwIn8.K.FGsmiBu5.6zuITA79v9ey9Juu8D5oB1FEoyTod6 7jz5_RNZgwYuQSkJPZ6aL2uW9LdvlyMpZuPZqEgJT6rR4rjdUZ067VwAp9Oi N1EcKZUUnjuPimOB._PmExRf5B9xx9P_i3.KHRpjFT05UWixMwN0KcJY- Received: from [99.31.212.42] by web31804.mail.mud.yahoo.com via HTTP; Sat, 18 Feb 2012 20:34:53 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340031 References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> Message-ID: <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Sat, 18 Feb 2012 20:34:53 -0800 (PST) From: William Mills To: Wenjie Lin , John Bradley In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-1479337183-1329626093=:59538" Cc: "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 04:34:59 -0000 --835683298-1479337183-1329626093=:59538 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So, I think what you are pointing out is an operability flaw rather than a = security one.=C2=A0 It is possible that the client will be issued a token t= hat does not have the permissions it expects, and the only way for the clie= nt to determine this in a guaranteed fashion is to do an operation and see = a failure.=0A=0AThe question then is, does this warrant a MUST rather than = SHOULD.=C2=A0 The server may issue a more privileged token for example.=C2= =A0 From the scope name there's no way for the client to actually resolve t= he scope name to privilege, so even if the server provides the scope we mig= ht have the same problem.=0A=0AThere are current usages in comaparable syst= ems where an unscoped token implies no restriction.=C2=A0 The semantics of = scope names here have intentionally been left fuzzy.=C2=A0 It's a significa= nt change to try to fix this problem, but the questionis whether it's worth= it?=C2=A0 I doubt that will get it right in a way that people will agree w= ith, I don't think you proposed change is sufficient to resolve the problem= .=0A=0AWould it be sifficient to call it out as an implementors note or a n= ota bene type editorial comment?=0A=0A-bill=0A=0A=0A=0A=0A_________________= _______________=0A From: Wenjie Lin =0ATo: John Bradley =0ACc: "oauth@ietf.org (oauth@ietf.org)" = =0ASent: Saturday, February 18, 2012 8:18 PM=0ASubject: Re: [OAUTH-WG] A S= cope Attack against OAuth 2.0=0A =0A=0AWe appreciate your attention and res= ponse to our report.=0A=C2=A0=0ASince Authorization Server obtains the scop= e information ONLY from User, it can=E2=80=99t tell whether the issued acce= ss token scope=C2=A0 is different from the one requested by Client, so long= as User is consistently sending the same altered scope information to Auth= orization Server. Consequently, as an Option, Authorization Server may choo= se not to include the scope response parameter to inform Client of the actu= al scope granted, and that results in the scope attack. This is a protocol = issue and is not an implementation issue; one can come up with an implement= ation that is compliant with the protocol specification yet with a scope at= tack.=0A=C2=A0=0AOne may argue that we only care about User protection and = security. Consequently, scope attack is apparently not a protocol security = issue. However, it would significantly limit the applicability of the proto= col, if Client is knowingly exposed to attacks. We need Client protection a= nd security as well in applications, for instance, cloud services.=0A=C2=A0= =0AScope attack can be easily fixed. One can simply make it Required that A= uthorization Server MUST include the scope response parameter to inform Cli= ent of the actual scope granted, as we have proposed for your consideration= .=0A=C2=A0=0AOAuth 2.0 is a sound protocol design. We prove the security pr= operties (for both User and Client) and scope attack is an issue we=E2=80= =99ve got stuck in the proof.=0A=C2=A0=0A- W. Lin and D. Lee=0A=0AOn Sat, F= eb 18, 2012 at 2:47 PM, John Bradley wrote:=0A=0AI agre= e that it is not a protocol problem.=0A>=0A>The problem is that some develo= pers are not understanding the spec.=0A>=0A>One case I saw recently was a p= roposal to send a scope to the Authorization endpoint that changed is authe= ntication behaviour e.g. ask for mlti-factor authentication.=0A>=0A>On a su= perficial reading of the spec they thought that not getting a changed set o= f scopes back in the response that the Authorization server was indicating = that it had done what was asked.=0A>=0A>When I pointed out that the user ag= ent can remove scopes because requests are not signed, =C2=A0they had a sim= ilar solution of forcing all the endpoints to always return the scopes gran= ted.=0A>=0A>I hope I talked them out of that.=0A>=0A>The problem is getting= people to use scopes to represent resources and not other arbitrary config= uration things, =C2=A0and to understand that even if they do get a scope gr= anted it could disappear before they get to use the access token and they n= eed to be prepared for that.=0A>=0A>The premise that users get access to y = for access to x is something that can be built with OAuth but is not someth= ing that can be inferred in the way they are proposing.=0A>=0A>From my pers= pective replying with granted scopes is a convince for the client, but not = something that can be depended upon.=0A>I don't think we need any normative= change.=0A>=0A>A don't make stupid assumptions about the persistence of sc= opes in tokens note would be as far as I would go.=0A>=0A>John B.=0A>=0A>= =0A>On 2012-02-18, at 3:34 AM, Shane B Weeden wrote:=0A>=0A>> I agree with = others - this is not an attack on the protocol. The user has=0A>> the choic= e about which scope to grant and the client's redirect to the=0A>> authoriz= ation endpoint is only a request for a particular set of=0A>> permissions, = not a guarantee that it will get them. The user+authorization=0A>> server d= ecide which scope is actually granted. The client needs to handle=0A>> case= s where that differs from what it originally wanted.=0A>>=0A>>=0A>>=0A>>=0A= >> From: Wenjie Lin =0A>> To: =C2=A0 oauth@ietf.org=0A>> D= ate: 18/02/2012 12:12 PM=0A>> Subject: =C2=A0 =C2=A0 =C2=A0[OAUTH-WG] A Sco= pe Attack against OAuth 2.0=0A>> Sent by: =C2=A0 =C2=A0 =C2=A0oauth-bounces= @ietf.org=0A>>=0A>>=0A>>=0A>> We describe an attack on OAuth 2.0 (draft-iet= f-oauth-v2-23), called scope=0A>> attack, provide a live-demo of the attack= on Facebook, and propose a fix=0A>> with discussions.=0A>>=0A>>=0A>>=0A>>= =0A>>=0A>> Scope Attack=0A>>=0A>>=0A>> OAuth authorization of services is a= ssociated with service agreement scope.=0A>> For instance, Client provides = an online game to User with a service=0A>> agreement scope A: User authoriz= es Client to access his profile information=0A>> and to post messages on hi= s behalf. A malicious User can request for online=0A>> game with service ag= reement scope A, manipulate the scope field, and change=0A>> it to scope B:= User authorizes Client to access his profile information.=0A>> User can st= ill play the games, =C2=A0yet Client can=E2=80=99t post messages on User=E2= =80=99s=0A>> behalf, as originally agreed.=0A>>=0A>>=0A>> OAuth 2.0 authori= zation code grant and implicit grant are vulnerable to the=0A>> scope attac= k.=0A>>=0A>>=0A>>=0A>>=0A>>=0A>> A Scope Attack Scenario=0A>>=0A>>=0A>> (1)= Authorization Server: Facebook (authorization code grant)=0A>>=0A>>=0A>> = =C2=A0 =C2=A0 =C2=A0(2) Client: Online gaming company Game. It allows User = to play the=0A>> =C2=A0 =C2=A0 =C2=A0games with the service agreement scope= A: User authorizes Game to=0A>> =C2=A0 =C2=A0 =C2=A0access his profile inf= ormation and post messages on his behalf.=0A>>=0A>>=0A>> =C2=A0 =C2=A0 =C2= =A0(3) User: malicious User with an account at Facebook. He attempts to=0A>= > =C2=A0 =C2=A0 =C2=A0play the games yet without authorizing Game to post m= essages on his=0A>> =C2=A0 =C2=A0 =C2=A0behalf, that is, he changes the sco= pe from A to B: authorization of=0A>> =C2=A0 =C2=A0 =C2=A0Client to access = his profile information only.=0A>>=0A>>=0A>>=0A>>=0A>>=0A>> Attack Workflow= =0A>>=0A>>=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0(1) User requests Game (Client) = for permission to play games,=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0instantiating= OAuth 2.0 with scope A.=0A>>=0A>>=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0(2) Game= generates an authorization request with a scope=0A>> =C2=A0 =C2=A0 =C2=A0 = =C2=A0specification A, and redirects User to Facebook with the request.=0A>= >=0A>>=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0(3) User manipulates the scope field= and changes it to scope B. The=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0modified re= quest is then sent to Facebook.=0A>>=0A>>=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0(= 4) User grants the modified request.=0A>>=0A>>=0A>> =C2=A0 =C2=A0 =C2=A0 = =C2=A0(5) Facebook redirects User back to Game with the authorization=0A>> = =C2=A0 =C2=A0 =C2=A0 =C2=A0code.=0A>>=0A>>=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0= (6) Game exchanges the authorization code for an access token.=0A>> =C2=A0 = =C2=A0 =C2=A0 =C2=A0However it has no knowledge that the scope A has been c= hanged to=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0scope B.=0A>>=0A>>=0A>> =C2=A0 = =C2=A0 =C2=A0 =C2=A0(7) Game provides online gaming service to User. Howeve= r, Game=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0can=E2=80=99t post messages on User= =E2=80=99s Facebook page.=0A>>=0A>>=0A>>=0A>>=0A>>=0A>> A Live-Demo: Facebo= ok and CastleVille (IE and Safari tested)=0A>>=0A>>=0A>> =C2=A0 =C2=A0 =C2= =A0Step 1: Login Facebook and visit Facebook Apps and Game page=0A>>=0A>>= =0A>> =C2=A0 =C2=A0 =C2=A0https://www.facebook.com/games=0A>>=0A>>=0A>> Ste= p 2: Click CastleVille.=0A>>=0A>>=0A>> =C2=A0 =C2=A0 =C2=A0Step 3: When you= see the Request for Permission page, instead of=0A>>=0A>>=0A>> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clicking =E2=80=9CAllow=E2=80=9D, change the= scope field in the URL from your=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0browser from =C2=A0=E2=80=9Cscope=3Demail%2Cpublish_stream%2Cpublish_= actions=E2=80=9D=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to =E2=80=9C= scope=3Demail%2Cpublish_stream=E2=80=9D.=0A>>=0A>>=0A>> =C2=A0 =C2=A0 =C2= =A0Step 4: After the modification, press ENTER to send the modified=0A>>=0A= >>=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0request to Facebook. Now y= ou will see the modified Request of=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Permission page.=0A>>=0A>>=0A>> Step 5: Click on =E2=80=9CAllow=E2= =80=9D button and enjoy the game.=0A>>=0A>>=0A>> (video: http://www.youtube= .com/watch?v=3DzkmjLa3VU9w)=0A>>=0A>>=0A>>=0A>>=0A>>=0A>> Impact=0A>>=0A>>= =0A>> Client provides services to malicious User yet with the modified serv= ice=0A>> agreement scope by User=E2=80=99s design.=0A>>=0A>>=0A>>=0A>>=0A>>= =0A>> Manipulating Scope Field=0A>>=0A>>=0A>> The scope field in access tok= en response is required ONLY IF Authorization=0A>> Server observes that the= User authorized scope is different than the=0A>> original scope. Consequen= tly, User can manipulate the scope field so that=0A>> Authorization Server = cannot detect the change of the scope. As a result=0A>> Client provides the= services yet can=E2=80=99t obtain the information that is=0A>> specified i= n the scope of the original service agreement.=0A>>=0A>>=0A>> Client can ve= rify the service agreement scope by checking all the fields=0A>> against th= e original User request before providing the requested services=0A>> to Use= r. =C2=A0For instance, Client can verify the granted permissions if=0A>> Au= thorization Server (e.g. Facebook) =C2=A0provides an API. However, this is = out=0A>> of the scope of OAuth 2.0, and Client may not check it. We observe= : all top=0A>> five games recommended by Facebook are vulnerable to the sco= pe attack.=0A>>=0A>>=0A>>=0A>>=0A>>=0A>> Proposed Fix=0A>>=0A>>=0A>> Draft-= ietf-oauth-v2-23 Section 5.1:=0A>>=0A>>=0A>> Change from=0A>>=0A>>=0A>> =C2= =A0 =C2=A0 =C2=A0=E2=80=9Cscope=0A>>=0A>>=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 OPTIONAL, if identical to the scope requested by the c= lient,=0A>>=0A>>=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 othe= rwise REQUIRED.=E2=80=9D=0A>>=0A>>=0A>> to=0A>>=0A>>=0A>> =E2=80=9Cscope RE= QUIRED=E2=80=9D /* scope: User authorized scope */=0A>>=0A>>=0A>>=0A>>=0A>>= =0A>> Remarks=0A>>=0A>>=0A>> (1) The proof of the correctness of OAuth with= our proposed fix will be=0A>> published in an article: =E2=80=9COAuth 2.0 = =E2=80=93 Attacks, Fixes, Correctness, and=0A>> Generalizations, Wenjie Lin= , David Lee and Steve Lai, to appear=E2=80=9D.=0A>>=0A>>=0A>> (2) The impli= cit grant is also vulnerable to the scope attack. However it=0A>> cannot be= fixed by enforcing scope field in access token response as above;=0A>> Use= r can change the scope in response before being redirected to Client.=0A>>= =0A>>=0A>>=0A>>=0A>>=0A>> Wenjie Lin, The Ohio State University=0A>>=0A>>= =0A>> David Lee, HP Labs and The Ohio State University=0A>>=0A>>=0A>> Steve= Lai, The Ohio State University=0A>> ______________________________________= _________=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://www.ietf= .org/mailman/listinfo/oauth=0A>>=0A>>=0A>> ________________________________= _______________=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://ww= w.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A=0A=0A=0A=0A___________________= ____________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps:= //www.ietf.org/mailman/listinfo/oauth --835683298-1479337183-1329626093=:59538 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


--
The Elite G= entleman
--f46d0447a0bd7d22c604b977ea6b-- From buhake@googlemail.com Tue Feb 21 07:16:52 2012 Return-Path: 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 1223C21F86D8 for ; Tue, 21 Feb 2012 07:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 WhW80G6yIMhn for ; Tue, 21 Feb 2012 07:16:48 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8959D21F8732 for ; Tue, 21 Feb 2012 07:16:43 -0800 (PST) Received: by obbwd15 with SMTP id wd15so10002888obb.31 for ; Tue, 21 Feb 2012 07:16:43 -0800 (PST) Received-SPF: pass (google.com: domain of buhake@googlemail.com designates 10.182.14.97 as permitted sender) client-ip=10.182.14.97; Authentication-Results: mr.google.com; spf=pass (google.com: domain of buhake@googlemail.com designates 10.182.14.97 as permitted sender) smtp.mail=buhake@googlemail.com; dkim=pass header.i=buhake@googlemail.com Received: from mr.google.com ([10.182.14.97]) by 10.182.14.97 with SMTP id o1mr15729377obc.57.1329837403228 (num_hops = 1); Tue, 21 Feb 2012 07:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2kliwslBChk4kSrU7/L6AgYbJjAzVGypEeyicCjAtiw=; b=u3WNgczApC50QmT3TvkkAQYCEAceS+1I6qYBhyE+ZCjmhpY+C9PijSgteojS+WH3eV /oqHx6OfBJsXr3OABQ/BFuePrjRJJ/+Is336JIqODw0ceP5ke5iwoPbXkQZ8FhGL5dDL AbTTrqC93xjVo5wU/fKOk3CEJKo6Mns1IEM0M= Received: by 10.182.14.97 with SMTP id o1mr13393219obc.57.1329837403179; Tue, 21 Feb 2012 07:16:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.62.231 with HTTP; Tue, 21 Feb 2012 07:16:23 -0800 (PST) In-Reply-To: References: From: Buhake Sindi Date: Tue, 21 Feb 2012 17:16:23 +0200 Message-ID: To: Peter Brindisi Content-Type: multipart/alternative; boundary=14dae93996cd068bb804b97ae653 X-Mailman-Approved-At: Tue, 21 Feb 2012 07:25:46 -0800 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] error response for invalid refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 15:16:52 -0000 --14dae93996cd068bb804b97ae653 Content-Type: text/plain; charset=UTF-8 Hi invalid_grant > > The provided authorization grant (e.g. authorization code, > resource owner credentials) is invalid, expired, revoked, does > not match the redirection URI used > I would think that the refresh_token is an authorization code that needs refreshing, so this would be valid. On 21 February 2012 15:33, Peter Brindisi wrote: > Hi all, > > I am currently implementing version 23 of the oauth2 spec, and I came > across a bit of ambiguity. What is the appropriate error code for an > invalid refresh token? I am unsure whether it should be 'invalid_grant' or > 'invalid_request'. Neither seems 100% clear. > > Thanks in advance! > > Best, > Peter > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --14dae93996cd068bb804b97ae653 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi

invalid_grant
=C2=A0
The provided authorization grant (e.g. authorization code,
resource= owner credentials) is invalid, expired, revoked, does
not match the redirection URI used

I would think that t= he refresh_token is an authorization code that needs refreshing, so this wo= uld be valid.



On 21 February 2012= 15:33, Peter Brindisi <peter.brindisi@gmail.com> wrote:
Hi all,

I am currently im= plementing version 23 of the oauth2 spec, and I came across a bit of ambigu= ity. What is the appropriate error code for an invalid refresh token? I am = unsure whether it should be 'invalid_grant' or 'invalid_request= '. Neither seems 100% clear.

Thanks in advance!

Best,
=
Peter

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--14dae93996cd068bb804b97ae653-- From ve7jtb@ve7jtb.com Tue Feb 21 07:45:42 2012 Return-Path: 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 A234121F8738 for ; Tue, 21 Feb 2012 07:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.08 X-Spam-Level: X-Spam-Status: No, score=-3.08 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 2WikuJF3RbKS for ; Tue, 21 Feb 2012 07:45:38 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E95721F867D for ; Tue, 21 Feb 2012 07:45:37 -0800 (PST) Received: by ggnq2 with SMTP id q2so3396296ggn.31 for ; Tue, 21 Feb 2012 07:45:35 -0800 (PST) Received-SPF: pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.79.202 as permitted sender) client-ip=10.236.79.202; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.79.202 as permitted sender) smtp.mail=ve7jtb@ve7jtb.com Received: from mr.google.com ([10.236.79.202]) by 10.236.79.202 with SMTP id i50mr36256479yhe.61.1329839135916 (num_hops = 1); Tue, 21 Feb 2012 07:45:35 -0800 (PST) Received: by 10.236.79.202 with SMTP id i50mr28066133yhe.61.1329839135823; Tue, 21 Feb 2012 07:45:35 -0800 (PST) Received: from [192.168.1.213] ([190.22.94.172]) by mx.google.com with ESMTPS id g49sm55045248yhk.20.2012.02.21.07.45.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 07:45:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_8D816D36-E2DF-4FBA-9E49-47377856BD63"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <5FC99886-A2D2-4AC0-93E1-4E07B803DDCD@gmail.com> Date: Tue, 21 Feb 2012 12:45:28 -0300 Message-Id: <48442479-4DC3-498C-A8C1-0358CB88F743@ve7jtb.com> References: <58932B8B-2DDE-41D6-A91B-5036CC762C00@matake.jp> <1329757027.28055.YahooMailNeo@web31808.mail.mud.yahoo.com> <4F4284DD.3030006@alcatel-lucent.com> <1329798149.78115.YahooMailNeo@web31804.mail.mud.yahoo.com> <56F7111A-B65E-459A-BB8A-ED87CDF1EB4A@gmail.com> <923A754A-100F-4534-BEBB-7EC5E6297B9E@ve7jtb.com> <5FC99886-A2D2-4AC0-93E1-4E07B803DDCD@gmail.com> To: "matake@gmail" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl76ltuKgK7any2Qnq0t4YkhEuQiy2gHAD/Ugj3vdF+kgL3oikApPicmUDysliBhmsGCYI5 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Quick question about error response for "response_type=unknown" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 15:45:42 -0000 --Apple-Mail=_8D816D36-E2DF-4FBA-9E49-47377856BD63 Content-Type: multipart/alternative; boundary="Apple-Mail=_87C1E170-43D5-46A4-A966-A13E54FCE437" --Apple-Mail=_87C1E170-43D5-46A4-A966-A13E54FCE437 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Assuming that the preconditions of client_id and redirect_uri being = correct are met, and only the response_type is unsupported but known, = you would reply to the client in the appropriate way. If the response_type is unknown then I think the only reasonable thing = is to report the error to the resource owner without a redirect.=20 This is only my interpretation of the spec. The OAuth spec is silent = on this particular case. John On 2012-02-21, at 12:11 PM, matake@gmail wrote: > So only when sever understand the response_type but doesn't support = it, it returns "unsupported_response_type" error. > It sounds reasonable for me. >=20 > It will make some servers return "unsupported_response_type" with a = redirect and some don't, though. >=20 > Thanks. >=20 > On 2012/02/21, at 23:07, John Bradley wrote: >=20 >> If the Authorization server, doesn't understand the response_type and = has no other way to determine what sort of flow the client is expecting, = I don't see any choice other than returning a error to the user/browser. >>=20 >> In the case of an unknown response_type the client could also be = expecting postMessage, or making a direct connection. You just don't = know. >>=20 >> There may be cases that the Authorization server could infer how to = reply based on the client_id, if the client perhaps doesn't have a = client secret issued to it, you could guess that it is using a fragment = encoded flow. >>=20 >> I however don't know that guessing is a good practice. Probably = best to always return an error response without a redirect. >>=20 >> John B. >> On 2012-02-21, at 8:34 AM, matake@gmail wrote: >>=20 >>> So the answer is "Show the error to the user without redirecting = back to the client", right? >>> I'm now developing OAuth2 and OpenID Connect ruby library, and both = of them return errors >>>=20 >>> case 1. redirect with error in query if response_type is "code" but = it's not supported >>> case 2. redirect with error in fragment if response_type is "token = code", "token id_token", "token code id_token" or "code id_token" but = it's not supported >>> case 3. otherwise show error to the user without redirect since = server cannot understand the response_type at all >>>=20 >>> But other server might not understand some of response_types listed = in case 2 at all and choose case 3 in such case. >>> (ie. OAuth servers which don't understand OpenID Connect won't = understand "id_token") >>>=20 >>> So I'm afraid that it reduces interoperability, a bit. >>>=20 >>> On 2012/02/21, at 13:22, William Mills wrote: >>>=20 >>>> I does allow some parts of your server config to be discovered. = More of a problem in error responses is usually echoing back the user = data, or allowing user enumeration for example. Care is required, but = you don't have a ton of options here. >>>>=20 >>>> From: Igor Faynberg >>>> To: oauth@ietf.org=20 >>>> Sent: Monday, February 20, 2012 9:37 AM >>>> Subject: Re: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown" >>>>=20 >>>> Could there be a potential security hole in providing an error = response? (Not that I see it, but many problems in the past had been = caused by helpful responese.) >>>>=20 >>>> Igor >>>>=20 >>>> On 2/20/2012 11:57 AM, William Mills wrote: >>>>>=20 >>>>> Respond with an error in protocol. Thta won't include a redirect, = and the client has to know what to do. >>>>>=20 >>>>> From: nov matake >>>>> To: oauth WG =20 >>>>> Sent: Monday, February 20, 2012 6:11 AM >>>>> Subject: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown" >>>>>=20 >>>>> Hi OAuthers, >>>>>=20 >>>>> My apologies if you already discussed this. >>>>>=20 >>>>> When OAuth server received unknown response_type, how should the = server handle the error? >>>>>=20 >>>>> 1. Show the error to the user without redirecting back to the = client >>>>> 2. Redirect back to the client including the error in query >>>>> 3. Redirect back to the client including the error in fragment >>>>>=20 >>>>> Since choosing 2 or 3 is impossible in this case, 1 seems = reasonable for me. >>>>>=20 >>>>>=20 >>>>> -- >>>>> nov >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail=_87C1E170-43D5-46A4-A966-A13E54FCE437 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
So only when sever = understand the response_type but doesn't support it, it returns = "unsupported_response_type" error.
It sounds reasonable for = me.

It will make some servers return = "unsupported_response_type" with a redirect and some don't, = though.

Thanks.

On = 2012/02/21, at 23:07, John Bradley wrote:

If the Authorization server, = doesn't understand the response_type and has no other way to determine = what sort of flow the client is expecting, I don't see any choice other = than returning a error to the user/browser.

In the = case of an unknown response_type the client could also be expecting = postMessage, or making a direct connection.  You just don't = know.

There may be cases that the Authorization = server could infer how to reply based on the client_id, if the client = perhaps doesn't have a client secret issued to it, you could guess that = it is using a fragment encoded flow.

I however = don't know that guessing is a good practice.   Probably best to = always return an error response without a = redirect.

John B.
On = 2012-02-21, at 8:34 AM, matake@gmail wrote:

So the answer is "Show the = error to the user without redirecting back to the client", = right?
I'm now developing OAuth2 and OpenID Connect ruby library, = and both of them return errors

case 1. redirect = with error in query if response_type is "code" but it's not = supported
case 2. redirect with error in fragment if = response_type is "token code", "token id_token", "token code id_token" = or "code id_token" but it's not supported
case 3. otherwise = show error to the user without redirect since server cannot understand = the response_type at all

But other server might = not understand some of response_types listed in case 2 at all and choose = case 3 in such case.
(ie. OAuth servers which don't understand = OpenID Connect won't understand "id_token")

So = I'm afraid that it reduces interoperability, a = bit.

On 2012/02/21, = at 13:22, William Mills wrote:

I does = allow some parts of your server config to be discovered.  More of a = problem in error responses is usually echoing back the user data, or = allowing user enumeration for example.  Care is required, but you = don't have a ton of options here.

=
From: Igor Faynberg <igor.faynberg@alcatel-luc= ent.com>
To: = oauth@ietf.org
Sent: Monday, February 20, 2012 = 9:37 AM
Subject: = Re: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown"

=20 =20 =20
Could there be a potential security hole in providing an error response?  (Not that I see it, but many problems in the past = had been caused by helpful responese.)

Igor

On 2/20/2012 11:57 AM, William Mills wrote:
Respond with an error in protocol.  Thta won't include a redirect, and the client has to know what to = do.

From: nov matake <nov@matake.jp>
To: = oauth WG <oauth@ietf.org>
Sent: Monday, February 20, 2012 6:11 AM
Subject: [OAUTH-WG] Quick question about error response for "response_type=3Dunknown"

Hi OAuthers,

My apologies if you already discussed this.

When OAuth server received unknown response_type, how should the server handle the error?

1. Show the error to the user without redirecting back to the client
2. Redirect back to the client including the error in = query
3. Redirect back to the client including the error in fragment

Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for me.


--
nov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
=
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth



<= /div>= --Apple-Mail=_87C1E170-43D5-46A4-A966-A13E54FCE437-- --Apple-Mail=_8D816D36-E2DF-4FBA-9E49-47377856BD63 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MjExNTQ1MjlaMCMGCSqGSIb3DQEJBDEWBBTcuzpaKmX7mXO9NbueYVFLBGPshDCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQAsoIjG9LIIvRQwwugYhck3YBClTRYZR8K42t8twB//DWTJvnxtze1AAEkl4O3TgqPnQ9Xf10vx voC3J99lCvWNyHQE1Y9+PfuqfWbDeNlUZmuU6eMid//3z1452spJwk8KPMQp6qJk/9S/Yvp9TYs3 J/Wej6uGr6/JUe+NtuCbgeFymuQw82yxKXhrYIKr3w+EqZgG294sqmOulDxsWA9SU7UN0wPFsjVS mJrBDa9ViywUP/75AyrBnUTk3CelMw4NSWTHkQHZamZ+lVJ4XDNhfPppbIBmUGtfANmHs8NQYv2E 5Km7MjwKBIAcjPQOPKwveRd5UgH61wh9FSS5rgB8AAAAAAAA --Apple-Mail=_8D816D36-E2DF-4FBA-9E49-47377856BD63-- From wenjielin.bupt@gmail.com Tue Feb 21 11:25:52 2012 Return-Path: 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 9536021E805B for ; Tue, 21 Feb 2012 11:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 xGLocgLYiAKt for ; Tue, 21 Feb 2012 11:25:47 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC67321F85F4 for ; Tue, 21 Feb 2012 11:25:47 -0800 (PST) Received: by iagf6 with SMTP id f6so11660799iag.31 for ; Tue, 21 Feb 2012 11:25:47 -0800 (PST) Received-SPF: pass (google.com: domain of wenjielin.bupt@gmail.com designates 10.50.154.200 as permitted sender) client-ip=10.50.154.200; Authentication-Results: mr.google.com; spf=pass (google.com: domain of wenjielin.bupt@gmail.com designates 10.50.154.200 as permitted sender) smtp.mail=wenjielin.bupt@gmail.com; dkim=pass header.i=wenjielin.bupt@gmail.com Received: from mr.google.com ([10.50.154.200]) by 10.50.154.200 with SMTP id vq8mr22026871igb.14.1329852347427 (num_hops = 1); Tue, 21 Feb 2012 11:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=2nDOAKCos9hJ8zqr/aUyfRi0QiQNa7pyN3GL7h+BG3Y=; b=HUdGar5MxMr7WTgqieXsYocedC7897dC06KKn2RDoswEDueZUPPK85HQCIhTuhybQr 830vwHliLEbMzGultv1BGRs4B7M5MvCd8dATdX8dF4cnCcpYMcGmpgfJ0NjlA3kOrTtp xSitpsATACZlzlvF9I8TIFG6/YXioTnJTf8uM= Received: by 10.50.154.200 with SMTP id vq8mr17774016igb.14.1329852347328; Tue, 21 Feb 2012 11:25:47 -0800 (PST) MIME-Version: 1.0 Sender: wenjielin.bupt@gmail.com Received: by 10.42.139.138 with HTTP; Tue, 21 Feb 2012 11:25:27 -0800 (PST) In-Reply-To: References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> From: Wenjie Lin Date: Tue, 21 Feb 2012 11:25:27 -0800 X-Google-Sender-Auth: a0vCyjOZWoxuoshBA0Eqy54BLr0 Message-ID: To: =?ISO-8859-1?Q?Andr=E9_DeMarre?= Content-Type: multipart/alternative; boundary=14dae9340821c4295804b97e60f7 Cc: "Lee, David" , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 19:25:52 -0000 --14dae9340821c4295804b97e60f7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sat, Feb 18, 2012 at 9:52 PM, Andr=E9 DeMarre wr= ote: > The spec already does what you ask... > > Wenjie Lin wrote: > > as an Option, Authorization Server may choose not to include the scope > > response parameter to inform Client of the actual scope granted, and > > that results in the scope attack. > > That's not true. Consider draft-ietf-oauth-v2-23 section 3.3: > The authorization server MAY fully or partially ignore the scope > requested by the client based on the authorization server policy or > the resource owner's instructions. *If the issued access token scope > * > * is different from the one requested by the client, the authorization > server MUST include the "scope" response parameter to inform the > client of the actual scope granted.* > > The problem is the underlined part above. The authorization server can never figure out whether *the issued access token scope is different from the one requested by the client, *since the authorization server only receives scope information from the user =96 never from the client. So long as the user sends to the authorization server a consistent scope, that can be different than the one requested by the client, the authorization server can never figure out the difference. Consequently, the authorization server MAY NOT *include the "scope" response parameter to inform the client of the actual scope granted, *resulting in a scope attack. > See also draft-ietf-oauth-v2-23 section 5.1 regarding issuing an access > token: > scope > OPTIONAL, if identical to the scope requested by the client, > otherwise REQUIRED. The scope of the access token as described > by Section 3.3. > > > Regards, > Andre DeMarre > > On Sat, Feb 18, 2012 at 8:18 PM, Wenjie Lin wrote: > > We appreciate your attention and response to our report. > > > > > > > > Since Authorization Server obtains the scope information ONLY from User= , > it > > can=92t tell whether the issued access token scope is different from t= he > one > > requested by Client, so long as User is consistently sending the same > > altered scope information to Authorization Server. Consequently, as an > > Option, Authorization Server may choose not to include the scope respon= se > > parameter to inform Client of the actual scope granted, and that result= s > in > > the scope attack. This is a protocol issue and is not an implementation > > issue; one can come up with an implementation that is compliant with th= e > > protocol specification yet with a scope attack. > > > > > > > > One may argue that we only care about User protection and security. > > Consequently, scope attack is apparently not a protocol security issue. > > However, it would significantly limit the applicability of the protocol= , > if > > Client is knowingly exposed to attacks. We need Client protection and > > security as well in applications, for instance, cloud services. > > > > > > > > Scope attack can be easily fixed. One can simply make it Required that > > Authorization Server MUST include the scope response parameter to infor= m > > Client of the actual scope granted, as we have proposed for your > > consideration. > > > > > > > > OAuth 2.0 is a sound protocol design. We prove the security properties > (for > > both User and Client) and scope attack is an issue we=92ve got stuck in= the > > proof. > > > > > > > > - W. Lin and D. Lee > > > > > > On Sat, Feb 18, 2012 at 2:47 PM, John Bradley wrote= : > >> > >> I agree that it is not a protocol problem. > >> > >> The problem is that some developers are not understanding the spec. > >> > >> One case I saw recently was a proposal to send a scope to the > >> Authorization endpoint that changed is authentication behaviour e.g. > ask for > >> mlti-factor authentication. > >> > >> On a superficial reading of the spec they thought that not getting a > >> changed set of scopes back in the response that the Authorization > server was > >> indicating that it had done what was asked. > >> > >> When I pointed out that the user agent can remove scopes because > requests > >> are not signed, they had a similar solution of forcing all the > endpoints to > >> always return the scopes granted. > >> > >> I hope I talked them out of that. > >> > >> The problem is getting people to use scopes to represent resources and > not > >> other arbitrary configuration things, and to understand that even if > they > >> do get a scope granted it could disappear before they get to use the > access > >> token and they need to be prepared for that. > >> > >> The premise that users get access to y for access to x is something th= at > >> can be built with OAuth but is not something that can be inferred in > the way > >> they are proposing. > >> > >> From my perspective replying with granted scopes is a convince for the > >> client, but not something that can be depended upon. > >> I don't think we need any normative change. > >> > >> A don't make stupid assumptions about the persistence of scopes in > tokens > >> note would be as far as I would go. > >> > >> John B. > >> > >> On 2012-02-18, at 3:34 AM, Shane B Weeden wrote: > >> > >> > I agree with others - this is not an attack on the protocol. The use= r > >> > has > >> > the choice about which scope to grant and the client's redirect to t= he > >> > authorization endpoint is only a request for a particular set of > >> > permissions, not a guarantee that it will get them. The > >> > user+authorization > >> > server decide which scope is actually granted. The client needs to > >> > handle > >> > cases where that differs from what it originally wanted. > >> > > >> > > >> > > >> > > >> > From: Wenjie Lin > >> > To: oauth@ietf.org > >> > Date: 18/02/2012 12:12 PM > >> > Subject: [OAUTH-WG] A Scope Attack against OAuth 2.0 > >> > Sent by: oauth-bounces@ietf.org > >> > > >> > > >> > > >> > We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called > >> > scope > >> > attack, provide a live-demo of the attack on Facebook, and propose a > fix > >> > with discussions. > >> > > >> > > >> > > >> > > >> > > >> > Scope Attack > >> > > >> > > >> > OAuth authorization of services is associated with service agreement > >> > scope. > >> > For instance, Client provides an online game to User with a service > >> > agreement scope A: User authorizes Client to access his profile > >> > information > >> > and to post messages on his behalf. A malicious User can request for > >> > online > >> > game with service agreement scope A, manipulate the scope field, and > >> > change > >> > it to scope B: User authorizes Client to access his profile > information. > >> > User can still play the games, yet Client can=92t post messages on > User=92s > >> > behalf, as originally agreed. > >> > > >> > > >> > OAuth 2.0 authorization code grant and implicit grant are vulnerable > to > >> > the > >> > scope attack. > >> > > >> > > >> > > >> > > >> > > >> > A Scope Attack Scenario > >> > > >> > > >> > (1) Authorization Server: Facebook (authorization code grant) > >> > > >> > > >> > (2) Client: Online gaming company Game. It allows User to play > the > >> > games with the service agreement scope A: User authorizes Game = to > >> > access his profile information and post messages on his behalf. > >> > > >> > > >> > (3) User: malicious User with an account at Facebook. He attemp= ts > >> > to > >> > play the games yet without authorizing Game to post messages on > his > >> > behalf, that is, he changes the scope from A to B: authorizatio= n > of > >> > Client to access his profile information only. > >> > > >> > > >> > > >> > > >> > > >> > Attack Workflow > >> > > >> > > >> > (1) User requests Game (Client) for permission to play games, > >> > instantiating OAuth 2.0 with scope A. > >> > > >> > > >> > (2) Game generates an authorization request with a scope > >> > specification A, and redirects User to Facebook with the > request. > >> > > >> > > >> > (3) User manipulates the scope field and changes it to scope = B. > >> > The > >> > modified request is then sent to Facebook. > >> > > >> > > >> > (4) User grants the modified request. > >> > > >> > > >> > (5) Facebook redirects User back to Game with the authorizati= on > >> > code. > >> > > >> > > >> > (6) Game exchanges the authorization code for an access token= . > >> > However it has no knowledge that the scope A has been changed > to > >> > scope B. > >> > > >> > > >> > (7) Game provides online gaming service to User. However, Gam= e > >> > can=92t post messages on User=92s Facebook page. > >> > > >> > > >> > > >> > > >> > > >> > A Live-Demo: Facebook and CastleVille (IE and Safari tested) > >> > > >> > > >> > Step 1: Login Facebook and visit Facebook Apps and Game page > >> > > >> > > >> > https://www.facebook.com/games > >> > > >> > > >> > Step 2: Click CastleVille. > >> > > >> > > >> > Step 3: When you see the Request for Permission page, instead o= f > >> > > >> > > >> > clicking =93Allow=94, change the scope field in the URL f= rom > your > >> > browser from > >> > =93scope=3Demail%2Cpublish_stream%2Cpublish_actions=94 > >> > to =93scope=3Demail%2Cpublish_stream=94. > >> > > >> > > >> > Step 4: After the modification, press ENTER to send the modifie= d > >> > > >> > > >> > request to Facebook. Now you will see the modified Reques= t > of > >> > Permission page. > >> > > >> > > >> > Step 5: Click on =93Allow=94 button and enjoy the game. > >> > > >> > > >> > (video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w) > >> > > >> > > >> > > >> > > >> > > >> > Impact > >> > > >> > > >> > Client provides services to malicious User yet with the modified > service > >> > agreement scope by User=92s design. > >> > > >> > > >> > > >> > > >> > > >> > Manipulating Scope Field > >> > > >> > > >> > The scope field in access token response is required ONLY IF > >> > Authorization > >> > Server observes that the User authorized scope is different than the > >> > original scope. Consequently, User can manipulate the scope field so > >> > that > >> > Authorization Server cannot detect the change of the scope. As a > result > >> > Client provides the services yet can=92t obtain the information that= is > >> > specified in the scope of the original service agreement. > >> > > >> > > >> > Client can verify the service agreement scope by checking all the > fields > >> > against the original User request before providing the requested > >> > services > >> > to User. For instance, Client can verify the granted permissions if > >> > Authorization Server (e.g. Facebook) provides an API. However, this > is > >> > out > >> > of the scope of OAuth 2.0, and Client may not check it. We observe: > all > >> > top > >> > five games recommended by Facebook are vulnerable to the scope attac= k. > >> > > >> > > >> > > >> > > >> > > >> > Proposed Fix > >> > > >> > > >> > Draft-ietf-oauth-v2-23 Section 5.1: > >> > > >> > > >> > Change from > >> > > >> > > >> > =93scope > >> > > >> > > >> > OPTIONAL, if identical to the scope requested by the > >> > client, > >> > > >> > > >> > otherwise REQUIRED.=94 > >> > > >> > > >> > to > >> > > >> > > >> > =93scope REQUIRED=94 /* scope: User authorized scope */ > >> > > >> > > >> > > >> > > >> > > >> > Remarks > >> > > >> > > >> > (1) The proof of the correctness of OAuth with our proposed fix will > be > >> > published in an article: =93OAuth 2.0 =96 Attacks, Fixes, Correctnes= s, and > >> > Generalizations, Wenjie Lin, David Lee and Steve Lai, to appear=94. > >> > > >> > > >> > (2) The implicit grant is also vulnerable to the scope attack. Howev= er > >> > it > >> > cannot be fixed by enforcing scope field in access token response as > >> > above; > >> > User can change the scope in response before being redirected to > Client. > >> > > >> > > >> > > >> > > >> > > >> > Wenjie Lin, The Ohio State University > >> > > >> > > >> > David Lee, HP Labs and The Ohio State University > >> > > >> > > >> > Steve Lai, The Ohio State University > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 Wenjie Lin --14dae9340821c4295804b97e60f7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 18, 2012 at 9:52 PM, Andr=E9 DeMa= rre <andrede= marre@gmail.com> wrote:

The spec al= ready does what you ask...

Wenjie Lin wrote:
> as an Option, Authorization Server may choose not to include the scope=
> response parameter to inform Client of the actual scope granted, and > that results in the scope attack.

That's not true. Consider draft-ietf-oauth-v2-23 section 3.3:
=A0 The authorization server MAY fully or partially igno= re the scope
=A0 requested by the client based on the authorization server policy or
=A0 the resource owner's instructions. =A0If the issued acces= s token scope
=A0 is different from the one requested by the cl= ient, the authorization
=A0 server MUST include the "scope" response parameter to inform= the
=A0 client of the actual scope granted.

=A0
The problem is the underlined part= above. The authorization server can never figure out whether=A0t= he issued access token scope=A0 is different from the one requested by the = client,=A0since the authorization = server only receives scope information from the user =96 never from the cli= ent. So long as the user sends to the authorization server a consistent sco= pe, that can be different than the one requested by the client, the authori= zation server can never figure out the difference. Consequently, the author= ization server MAY NOT=A0include the "scope" response p= arameter to inform the client of the actual scope granted,=A0res= ulting in a scope attack.


=A0
See also draft-ietf-oauth-v2-23 section 5.1 regarding issuing an acce= ss token:
=A0 scope
=A0 =A0 =A0 =A0 OPTIONAL, if identical to the scope requested by the clien= t,
=A0 =A0 =A0 =A0 otherwise REQUIRED. =A0The scope of the access token= as described
=A0 =A0 =A0 =A0 by Section 3.3.


Regards,
Andre DeMarre

On Sat, Feb 18, 2012 at 8:18 PM, Wenjie Lin <lin.820@osu.edu> wrote:
> We appreciate your attention and response to our report.
>
>
>
> Since Authorization Server obtains the scope information ONLY from Use= r, it
> can=92t tell whether the issued access token scope=A0 is different fro= m the one
> requested by Client, so long as User is consistently sending the same<= br> > altered scope information to Authorization Server. Consequently, as an=
> Option, Authorization Server may choose not to include the scope respo= nse
> parameter to inform Client of the actual scope granted, and that resul= ts in
> the scope attack. This is a protocol issue and is not an implementatio= n
> issue; one can come up with an implementation that is compliant with t= he
> protocol specification yet with a scope attack.
>
>
>
> One may argue that we only care about User protection and security. > Consequently, scope attack is apparently not a protocol security issue= .
> However, it would significantly limit the applicability of the protoco= l, if
> Client is knowingly exposed to attacks. We need Client protection and<= br> > security as well in applications, for instance, cloud services.
>
>
>
> Scope attack can be easily fixed. One can simply make it Required that=
> Authorization Server MUST include the scope response parameter to info= rm
> Client of the actual scope granted, as we have proposed for your
> consideration.
>
>
>
> OAuth 2.0 is a sound protocol design. We prove the security properties= (for
> both User and Client) and scope attack is an issue we=92ve got stuck i= n the
> proof.
>
>
>
> - W. Lin and D. Lee
>
>
> On Sat, Feb 18, 2012 at 2:47 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>
>> I agree that it is not a protocol problem.
>>
>> The problem is that some developers are not understanding the spec= .
>>
>> One case I saw recently was a proposal to send a scope to the
>> Authorization endpoint that changed is authentication behaviour e.= g. ask for
>> mlti-factor authentication.
>>
>> On a superficial reading of the spec they thought that not getting= a
>> changed set of scopes back in the response that the Authorization = server was
>> indicating that it had done what was asked.
>>
>> When I pointed out that the user agent can remove scopes because r= equests
>> are not signed, =A0they had a similar solution of forcing all the = endpoints to
>> always return the scopes granted.
>>
>> I hope I talked them out of that.
>>
>> The problem is getting people to use scopes to represent resources= and not
>> other arbitrary configuration things, =A0and to understand that ev= en if they
>> do get a scope granted it could disappear before they get to use t= he access
>> token and they need to be prepared for that.
>>
>> The premise that users get access to y for access to x is somethin= g that
>> can be built with OAuth but is not something that can be inferred = in the way
>> they are proposing.
>>
>> From my perspective replying with granted scopes is a convince for= the
>> client, but not something that can be depended upon.
>> I don't think we need any normative change.
>>
>> A don't make stupid assumptions about the persistence of scope= s in tokens
>> note would be as far as I would go.
>>
>> John B.
>>
>> On 2012-02-18, at 3:34 AM, Shane B Weeden wrote:
>>
>> > I agree with others - this is not an attack on the protocol. = The user
>> > has
>> > the choice about which scope to grant and the client's re= direct to the
>> > authorization endpoint is only a request for a particular set= of
>> > permissions, not a guarantee that it will get them. The
>> > user+authorization
>> > server decide which scope is actually granted. The client nee= ds to
>> > handle
>> > cases where that differs from what it originally wanted.
>> >
>> >
>> >
>> >
>> > From: Wenjie Lin <lin.8= 20@osu.edu>
>> > To: =A0 oauth@ietf.org<= br> >> > Date: 18/02/2012 12:12 PM
>> > Subject: =A0 =A0 =A0[OAUTH-WG] A Scope Attack against OAuth 2= .0
>> > Sent by: =A0 =A0 =A0oauth-bounces@ietf.org
>> >
>> >
>> >
>> > We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), = called
>> > scope
>> > attack, provide a live-demo of the attack on Facebook, and pr= opose a fix
>> > with discussions.
>> >
>> >
>> >
>> >
>> >
>> > Scope Attack
>> >
>> >
>> > OAuth authorization of services is associated with service ag= reement
>> > scope.
>> > For instance, Client provides an online game to User with a s= ervice
>> > agreement scope A: User authorizes Client to access his profi= le
>> > information
>> > and to post messages on his behalf. A malicious User can requ= est for
>> > online
>> > game with service agreement scope A, manipulate the scope fie= ld, and
>> > change
>> > it to scope B: User authorizes Client to access his profile i= nformation.
>> > User can still play the games, =A0yet Client can=92t post mes= sages on User=92s
>> > behalf, as originally agreed.
>> >
>> >
>> > OAuth 2.0 authorization code grant and implicit grant are vul= nerable to
>> > the
>> > scope attack.
>> >
>> >
>> >
>> >
>> >
>> > A Scope Attack Scenario
>> >
>> >
>> > (1) Authorization Server: Facebook (authorization code grant)=
>> >
>> >
>> > =A0 =A0 =A0(2) Client: Online gaming company Game. It allows = User to play the
>> > =A0 =A0 =A0games with the service agreement scope A: User aut= horizes Game to
>> > =A0 =A0 =A0access his profile information and post messages o= n his behalf.
>> >
>> >
>> > =A0 =A0 =A0(3) User: malicious User with an account at Facebo= ok. He attempts
>> > to
>> > =A0 =A0 =A0play the games yet without authorizing Game to pos= t messages on his
>> > =A0 =A0 =A0behalf, that is, he changes the scope from A to B:= authorization of
>> > =A0 =A0 =A0Client to access his profile information only.
>> >
>> >
>> >
>> >
>> >
>> > Attack Workflow
>> >
>> >
>> > =A0 =A0 =A0 =A0(1) User requests Game (Client) for permission= to play games,
>> > =A0 =A0 =A0 =A0instantiating OAuth 2.0 with scope A.
>> >
>> >
>> > =A0 =A0 =A0 =A0(2) Game generates an authorization request wi= th a scope
>> > =A0 =A0 =A0 =A0specification A, and redirects User to Faceboo= k with the request.
>> >
>> >
>> > =A0 =A0 =A0 =A0(3) User manipulates the scope field and chang= es it to scope B.
>> > The
>> > =A0 =A0 =A0 =A0modified request is then sent to Facebook.
>> >
>> >
>> > =A0 =A0 =A0 =A0(4) User grants the modified request.
>> >
>> >
>> > =A0 =A0 =A0 =A0(5) Facebook redirects User back to Game with = the authorization
>> > =A0 =A0 =A0 =A0code.
>> >
>> >
>> > =A0 =A0 =A0 =A0(6) Game exchanges the authorization code for = an access token.
>> > =A0 =A0 =A0 =A0However it has no knowledge that the scope A h= as been changed to
>> > =A0 =A0 =A0 =A0scope B.
>> >
>> >
>> > =A0 =A0 =A0 =A0(7) Game provides online gaming service to Use= r. However, Game
>> > =A0 =A0 =A0 =A0can=92t post messages on User=92s Facebook pag= e.
>> >
>> >
>> >
>> >
>> >
>> > A Live-Demo: Facebook and CastleVille (IE and Safari tested)<= br> >> >
>> >
>> > =A0 =A0 =A0Step 1: Login Facebook and visit Facebook Apps and= Game page
>> >
>> >
>> > =A0 =A0 =A0https://www.facebook.com/games
>> >
>> >
>> > Step 2: Click CastleVille.
>> >
>> >
>> > =A0 =A0 =A0Step 3: When you see the Request for Permission pa= ge, instead of
>> >
>> >
>> > =A0 =A0 =A0 =A0 =A0 =A0clicking =93Allow=94, change the scope= field in the URL from your
>> > =A0 =A0 =A0 =A0 =A0 =A0browser from
>> > =A0=93scope=3Demail%2Cpublish_stream%2Cpublish_actions=94
>> > =A0 =A0 =A0 =A0 =A0 =A0to =93scope=3Demail%2Cpublish_stream= =94.
>> >
>> >
>> > =A0 =A0 =A0Step 4: After the modification, press ENTER to sen= d the modified
>> >
>> >
>> > =A0 =A0 =A0 =A0 =A0 =A0request to Facebook. Now you will see = the modified Request of
>> > =A0 =A0 =A0 =A0 =A0 =A0Permission page.
>> >
>> >
>> > Step 5: Click on =93Allow=94 button and enjoy the game.
>> >
>> >
>> > (video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w)
>> >
>> >
>> >
>> >
>> >
>> > Impact
>> >
>> >
>> > Client provides services to malicious User yet with the modif= ied service
>> > agreement scope by User=92s design.
>> >
>> >
>> >
>> >
>> >
>> > Manipulating Scope Field
>> >
>> >
>> > The scope field in access token response is required ONLY IF<= br> >> > Authorization
>> > Server observes that the User authorized scope is different t= han the
>> > original scope. Consequently, User can manipulate the scope f= ield so
>> > that
>> > Authorization Server cannot detect the change of the scope. A= s a result
>> > Client provides the services yet can=92t obtain the informati= on that is
>> > specified in the scope of the original service agreement.
>> >
>> >
>> > Client can verify the service agreement scope by checking all= the fields
>> > against the original User request before providing the reques= ted
>> > services
>> > to User. =A0For instance, Client can verify the granted permi= ssions if
>> > Authorization Server (e.g. Facebook) =A0provides an API. Howe= ver, this is
>> > out
>> > of the scope of OAuth 2.0, and Client may not check it. We ob= serve: all
>> > top
>> > five games recommended by Facebook are vulnerable to the scop= e attack.
>> >
>> >
>> >
>> >
>> >
>> > Proposed Fix
>> >
>> >
>> > Draft-ietf-oauth-v2-23 Section 5.1:
>> >
>> >
>> > Change from
>> >
>> >
>> > =A0 =A0 =A0=93scope
>> >
>> >
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 OPTIONAL, if identical to the sco= pe requested by the
>> > client,
>> >
>> >
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 otherwise REQUIRED.=94
>> >
>> >
>> > to
>> >
>> >
>> > =93scope REQUIRED=94 /* scope: User authorized scope */
>> >
>> >
>> >
>> >
>> >
>> > Remarks
>> >
>> >
>> > (1) The proof of the correctness of OAuth with our proposed f= ix will be
>> > published in an article: =93OAuth 2.0 =96 Attacks, Fixes, Cor= rectness, and
>> > Generalizations, Wenjie Lin, David Lee and Steve Lai, to appe= ar=94.
>> >
>> >
>> > (2) The implicit grant is also vulnerable to the scope attack= . However
>> > it
>> > cannot be fixed by enforcing scope field in access token resp= onse as
>> > above;
>> > User can change the scope in response before being redirected= to Client.
>> >
>> >
>> >
>> >
>> >
>> > Wenjie Lin, The Ohio State University
>> >
>> >
>> > David Lee, HP Labs and The Ohio State University
>> >
>> >
>> > Steve Lai, The Ohio State University
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



--
= Wenjie Lin
--14dae9340821c4295804b97e60f7-- From wenjielin.bupt@gmail.com Tue Feb 21 12:08:20 2012 Return-Path: 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 D938821E806E for ; Tue, 21 Feb 2012 12:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 9qOXtW-hZ+3V for ; Tue, 21 Feb 2012 12:08:16 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC33921E8063 for ; Tue, 21 Feb 2012 12:08:15 -0800 (PST) Received: by iagf6 with SMTP id f6so11711842iag.31 for ; Tue, 21 Feb 2012 12:08:15 -0800 (PST) Received-SPF: pass (google.com: domain of wenjielin.bupt@gmail.com designates 10.50.15.129 as permitted sender) client-ip=10.50.15.129; Authentication-Results: mr.google.com; spf=pass (google.com: domain of wenjielin.bupt@gmail.com designates 10.50.15.129 as permitted sender) smtp.mail=wenjielin.bupt@gmail.com; dkim=pass header.i=wenjielin.bupt@gmail.com Received: from mr.google.com ([10.50.15.129]) by 10.50.15.129 with SMTP id x1mr22198251igc.14.1329854895508 (num_hops = 1); Tue, 21 Feb 2012 12:08:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=DQF/CyzWqLl+pwZPbLuSKHBbxNsMUdATytzinCAtGTM=; b=fyxZeRPWFV4J1p0NcsEtm19pIPRZkJUCRNzSesZtRvv/OJlYOPnQ2qDivWJQWJqzf7 jW4Pp3ym08HKZJb4F0/f7IfOroEey9xxS8lhhE4wsvtouxH2xWNCdnpHcM1gSFJm3+d/ /aaHJcSre/q7uDg9wgEGCTser9Sjt3DcpbgCs= Received: by 10.50.15.129 with SMTP id x1mr17919589igc.14.1329854895393; Tue, 21 Feb 2012 12:08:15 -0800 (PST) MIME-Version: 1.0 Sender: wenjielin.bupt@gmail.com Received: by 10.42.139.138 with HTTP; Tue, 21 Feb 2012 12:07:54 -0800 (PST) In-Reply-To: <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> From: Wenjie Lin Date: Tue, 21 Feb 2012 12:07:54 -0800 X-Google-Sender-Auth: vhaR9J7jpE_4OQ-W2RWT9TDQmjs Message-ID: To: William Mills Content-Type: multipart/alternative; boundary=14dae9341133a48c8804b97ef885 Cc: "Lee, David" , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 20:08:21 -0000 --14dae9341133a48c8804b97ef885 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Our understanding is that you agree this is indeed a scope attack, that is, the user may get services, which are different than the client has agreed.*= * ** If the protocol adopts the change we=92ve suggested, the client immediately figures out the difference between what he has agreed and what is in the access token. How does the client deal with it? Decline the service or take other actions? Indeed, as you rightly pointed out, it is an issue of operation =96 an excellent note for the implementer. However, this is no longer a protocol issue. -W. Lin and D. Lee On Sat, Feb 18, 2012 at 8:34 PM, William Mills wrote= : > So, I think what you are pointing out is an operability flaw rather than = a > security one. It is possible that the client will be issued a token that > does not have the permissions it expects, and the only way for the client > to determine this in a guaranteed fashion is to do an operation and see a > failure. > > The question then is, does this warrant a MUST rather than SHOULD. The > server may issue a more privileged token for example. From the scope nam= e > there's no way for the client to actually resolve the scope name to > privilege, so even if the server provides the scope we might have the sam= e > problem. > > There are current usages in comaparable systems where an unscoped token > implies no restriction. The semantics of scope names here have > intentionally been left fuzzy. It's a significant change to try to fix > this problem, but the questionis whether it's worth it? I doubt that wil= l > get it right in a way that people will agree with, I don't think you > proposed change is sufficient to resolve the problem. > > Would it be sifficient to call it out as an implementors note or a nota > bene type editorial comment? > > -bill > > > ------------------------------ > *From:* Wenjie Lin > *To:* John Bradley > *Cc:* "oauth@ietf.org (oauth@ietf.org)" > *Sent:* Saturday, February 18, 2012 8:18 PM > *Subject:* Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 > > We appreciate your attention and response to our report.**** > ** ** > Since Authorization Server obtains the scope information ONLY from User, > it can=92t tell whether the issued access token scope is different from = the > one requested by Client, so long as User is consistently sending the same > altered scope information to Authorization Server. Consequently, as an > Option, Authorization Server may choose not to include the scope response > parameter to inform Client of the actual scope granted, and that results = in > the scope attack. This is a protocol issue and is not an implementation > issue; one can come up with an implementation that is compliant with the > protocol specification yet with a scope attack.**** > ** ** > One may argue that we only care about User protection and security. > Consequently, scope attack is apparently not a protocol security issue. > However, it would significantly limit the applicability of the protocol, = if > Client is knowingly exposed to attacks. We need Client protection and > security as well in applications, for instance, cloud services.**** > ** ** > Scope attack can be easily fixed. One can simply make it Required that > Authorization Server MUST include the scope response parameter to inform > Client of the actual scope granted, as we have proposed for your > consideration.**** > ** ** > OAuth 2.0 is a sound protocol design. We prove the security properties > (for both User and Client) and scope attack is an issue we=92ve got stuck= in > the proof.**** > ** ** > - W. Lin and D. Lee > > On Sat, Feb 18, 2012 at 2:47 PM, John Bradley wrote: > > I agree that it is not a protocol problem. > > The problem is that some developers are not understanding the spec. > > One case I saw recently was a proposal to send a scope to the > Authorization endpoint that changed is authentication behaviour e.g. ask > for mlti-factor authentication. > > On a superficial reading of the spec they thought that not getting a > changed set of scopes back in the response that the Authorization server > was indicating that it had done what was asked. > > When I pointed out that the user agent can remove scopes because requests > are not signed, they had a similar solution of forcing all the endpoints > to always return the scopes granted. > > I hope I talked them out of that. > > The problem is getting people to use scopes to represent resources and no= t > other arbitrary configuration things, and to understand that even if the= y > do get a scope granted it could disappear before they get to use the acce= ss > token and they need to be prepared for that. > > The premise that users get access to y for access to x is something that > can be built with OAuth but is not something that can be inferred in the > way they are proposing. > > From my perspective replying with granted scopes is a convince for the > client, but not something that can be depended upon. > I don't think we need any normative change. > > A don't make stupid assumptions about the persistence of scopes in tokens > note would be as far as I would go. > > John B. > > On 2012-02-18, at 3:34 AM, Shane B Weeden wrote: > > > I agree with others - this is not an attack on the protocol. The user h= as > > the choice about which scope to grant and the client's redirect to the > > authorization endpoint is only a request for a particular set of > > permissions, not a guarantee that it will get them. The > user+authorization > > server decide which scope is actually granted. The client needs to hand= le > > cases where that differs from what it originally wanted. > > > > > > > > > > From: Wenjie Lin > > To: oauth@ietf.org > > Date: 18/02/2012 12:12 PM > > Subject: [OAUTH-WG] A Scope Attack against OAuth 2.0 > > Sent by: oauth-bounces@ietf.org > > > > > > > > We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called sco= pe > > attack, provide a live-demo of the attack on Facebook, and propose a fi= x > > with discussions. > > > > > > > > > > > > Scope Attack > > > > > > OAuth authorization of services is associated with service agreement > scope. > > For instance, Client provides an online game to User with a service > > agreement scope A: User authorizes Client to access his profile > information > > and to post messages on his behalf. A malicious User can request for > online > > game with service agreement scope A, manipulate the scope field, and > change > > it to scope B: User authorizes Client to access his profile information= . > > User can still play the games, yet Client can=92t post messages on Use= r=92s > > behalf, as originally agreed. > > > > > > OAuth 2.0 authorization code grant and implicit grant are vulnerable to > the > > scope attack. > > > > > > > > > > > > A Scope Attack Scenario > > > > > > (1) Authorization Server: Facebook (authorization code grant) > > > > > > (2) Client: Online gaming company Game. It allows User to play the > > games with the service agreement scope A: User authorizes Game to > > access his profile information and post messages on his behalf. > > > > > > (3) User: malicious User with an account at Facebook. He attempts = to > > play the games yet without authorizing Game to post messages on hi= s > > behalf, that is, he changes the scope from A to B: authorization o= f > > Client to access his profile information only. > > > > > > > > > > > > Attack Workflow > > > > > > (1) User requests Game (Client) for permission to play games, > > instantiating OAuth 2.0 with scope A. > > > > > > (2) Game generates an authorization request with a scope > > specification A, and redirects User to Facebook with the request= . > > > > > > (3) User manipulates the scope field and changes it to scope B. > The > > modified request is then sent to Facebook. > > > > > > (4) User grants the modified request. > > > > > > (5) Facebook redirects User back to Game with the authorization > > code. > > > > > > (6) Game exchanges the authorization code for an access token. > > However it has no knowledge that the scope A has been changed to > > scope B. > > > > > > (7) Game provides online gaming service to User. However, Game > > can=92t post messages on User=92s Facebook page. > > > > > > > > > > > > A Live-Demo: Facebook and CastleVille (IE and Safari tested) > > > > > > Step 1: Login Facebook and visit Facebook Apps and Game page > > > > > > https://www.facebook.com/games > > > > > > Step 2: Click CastleVille. > > > > > > Step 3: When you see the Request for Permission page, instead of > > > > > > clicking =93Allow=94, change the scope field in the URL from= your > > browser from =93scope=3Demail%2Cpublish_stream%2Cpublish_ac= tions=94 > > to =93scope=3Demail%2Cpublish_stream=94. > > > > > > Step 4: After the modification, press ENTER to send the modified > > > > > > request to Facebook. Now you will see the modified Request o= f > > Permission page. > > > > > > Step 5: Click on =93Allow=94 button and enjoy the game. > > > > > > (video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w) > > > > > > > > > > > > Impact > > > > > > Client provides services to malicious User yet with the modified servic= e > > agreement scope by User=92s design. > > > > > > > > > > > > Manipulating Scope Field > > > > > > The scope field in access token response is required ONLY IF > Authorization > > Server observes that the User authorized scope is different than the > > original scope. Consequently, User can manipulate the scope field so th= at > > Authorization Server cannot detect the change of the scope. As a result > > Client provides the services yet can=92t obtain the information that is > > specified in the scope of the original service agreement. > > > > > > Client can verify the service agreement scope by checking all the field= s > > against the original User request before providing the requested servic= es > > to User. For instance, Client can verify the granted permissions if > > Authorization Server (e.g. Facebook) provides an API. However, this is > out > > of the scope of OAuth 2.0, and Client may not check it. We observe: all > top > > five games recommended by Facebook are vulnerable to the scope attack. > > > > > > > > > > > > Proposed Fix > > > > > > Draft-ietf-oauth-v2-23 Section 5.1: > > > > > > Change from > > > > > > =93scope > > > > > > OPTIONAL, if identical to the scope requested by the > client, > > > > > > otherwise REQUIRED.=94 > > > > > > to > > > > > > =93scope REQUIRED=94 /* scope: User authorized scope */ > > > > > > > > > > > > Remarks > > > > > > (1) The proof of the correctness of OAuth with our proposed fix will be > > published in an article: =93OAuth 2.0 =96 Attacks, Fixes, Correctness, = and > > Generalizations, Wenjie Lin, David Lee and Steve Lai, to appear=94. > > > > > > (2) The implicit grant is also vulnerable to the scope attack. However = it > > cannot be fixed by enforcing scope field in access token response as > above; > > User can change the scope in response before being redirected to Client= . > > > > > > > > > > > > Wenjie Lin, The Ohio State University > > > > > > David Lee, HP Labs and The Ohio State University > > > > > > Steve Lai, The Ohio State University > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 Wenjie Lin --14dae9341133a48c8804b97ef885 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Our understanding is that you agree this is indeed a scope attack, = that is, the user may get services, which are different than the client has= agreed.

If the protocol adopts the change we=92ve suggested, = the client immediately figures out the difference between what he has agree= d and what is in the access token. How does the client deal with it? Declin= e the service or take other actions? Indeed, as you rightly pointed out, it= is an issue of operation =96 an excellent note for the implementer. Howeve= r, this is no longer a protocol issue.

-W. Lin and D. Lee


On Sat, Feb 18, 2012 at 8:34 PM, Will= iam Mills <wmi= lls@yahoo-inc.com> wrote:
So, I think what you are pointing out is an = operability flaw rather than a security one.=A0 It is possible that the cli= ent will be issued a token that does not have the permissions it expects, a= nd the only way for the client to determine this in a guaranteed fashion is= to do an operation and see a failure.

The question then is, does this warr= ant a MUST rather than SHOULD.=A0 The server may issue a more privileged to= ken for example.=A0 From the scope name there's no way for the client t= o actually resolve the scope name to privilege, so even if the server provi= des the scope we might have the same problem.

There are current usages in comaparable systems where a= n unscoped token implies no restriction.=A0 The semantics of scope names here have intentionally been left fuzzy.=A0 It's a sign= ificant change to try to fix this problem, but the questionis whether it= 9;s worth it?=A0 I doubt that will get it right in a way that people will a= gree with, I don't think you proposed change is sufficient to resolve t= he problem.

Would it be sifficient to call it out as an implementor= s note or a nota bene type editorial comment?

-bil= l


From: Wenjie Lin <lin.820@osu.edu>
To: John Bradley <ve7jtb@ve7jtb.com> =
Cc: "oauth@ietf.org (oauth@ietf.org)" <oauth@ietf.org>
Sent: Saturday, February 18= , 2012 8:18 PM
Subject: = Re: [OAUTH-WG] A Scope Attack against OAuth 2.0

We appreciate your attention and response to our report.<= /u>
=A0
Since Authorization Ser= ver obtains the scope information ONLY from User, it can=92t tell whether t= he issued access token scope=A0 is different from the one requested by Clie= nt, so long as User is consistently sending the same altered scope informat= ion to Authorization Server. Consequently, as an Option, Authorization Serv= er may choose not to include the scope response parameter to inform Client = of the actual scope granted, and that results in the scope attack. This is = a protocol issue and is not an implementation issue; one can come up with a= n implementation that is compliant with the protocol specification yet with= a scope attack.
=A0
One may argue that we only care about User protection and security.= Consequently, scope attack is apparently not a protocol security issue. Ho= wever, it would significantly limit the applicability of the protocol, if C= lient is knowingly exposed to attacks. We need Client protection and securi= ty as well in applications, for instance, cloud services.
=A0
Scope attack can be easily fixed. One can simply make it Required t= hat Authorization Server MUST include the scope response parameter to infor= m Client of the actual scope granted, as we have proposed for your consider= ation.
=A0
OAuth 2.0 is a sound protocol design. We prove the security propert= ies (for both User and Client) and scope attack is an issue we=92ve got stu= ck in the proof.
=A0
- W. Lin and D. Lee

On Sat, Feb 18, 201= 2 at 2:47 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I agree that it is not a protocol problem.

The problem is that some developers are not understanding the spec.

One case I saw recently was a proposal to send a scope to the Authorization= endpoint that changed is authentication behaviour e.g. ask for mlti-factor= authentication.

On a superficial reading of the spec they thought that not getting a change= d set of scopes back in the response that the Authorization server was indi= cating that it had done what was asked.

When I pointed out that the user agent can remove scopes because requests a= re not signed, =A0they had a similar solution of forcing all the endpoints = to always return the scopes granted.

I hope I talked them out of that.

The problem is getting people to use scopes to represent resources and not = other arbitrary configuration things, =A0and to understand that even if the= y do get a scope granted it could disappear before they get to use the acce= ss token and they need to be prepared for that.

The premise that users get access to y for access to x is something that ca= n be built with OAuth but is not something that can be inferred in the way = they are proposing.

>From my perspective replying with granted scopes is a convince for the clie= nt, but not something that can be depended upon.
I don't think we need any normative change.

A don't make stupid assumptions about the persistence of scopes in toke= ns note would be as far as I would go.

John B.

On 2012-02-18, at 3:34 AM, Shane B Weeden wrote:

> I agree with others - this is not an attack on the protocol. The user = has
> the choice about which scope to grant and the client's redirect to= the
> authorization endpoint is only a request for a particular set of
> permissions, not a guarantee that it will get them. The user+authoriza= tion
> server decide which scope is actually granted. The client needs to han= dle
> cases where that differs from what it originally wanted.
>
>
>
>
> From: Wenjie Lin <lin.820@osu.edu>
> To: =A0 oauth@ietf.org
> Date: 18/02/2012 12:12 PM
> Subject: =A0 =A0 =A0[OAUTH-WG] A Scope Attack against OAuth 2.0
> Sent by: =A0 =A0 =A0oauth-bounces@ietf.org
>
>
>
> We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called sc= ope
> attack, provide a live-demo of the attack on Facebook, and propose a f= ix
> with discussions.
>
>
>
>
>
> Scope Attack
>
>
> OAuth authorization of services is associated with service agreement s= cope.
> For instance, Client provides an online game to User with a service > agreement scope A: User authorizes Client to access his profile inform= ation
> and to post messages on his behalf. A malicious User can request for o= nline
> game with service agreement scope A, manipulate the scope field, and c= hange
> it to scope B: User authorizes Client to access his profile informatio= n.
> User can still play the games, =A0yet Client can=92t post messages on = User=92s
> behalf, as originally agreed.
>
>
> OAuth 2.0 authorization code grant and implicit grant are vulnerable t= o the
> scope attack.
>
>
>
>
>
> A Scope Attack Scenario
>
>
> (1) Authorization Server: Facebook (authorization code grant)
>
>
> =A0 =A0 =A0(2) Client: Online gaming company Game. It allows User to p= lay the
> =A0 =A0 =A0games with the service agreement scope A: User authorizes G= ame to
> =A0 =A0 =A0access his profile information and post messages on his beh= alf.
>
>
> =A0 =A0 =A0(3) User: malicious User with an account at Facebook. He at= tempts to
> =A0 =A0 =A0play the games yet without authorizing Game to post message= s on his
> =A0 =A0 =A0behalf, that is, he changes the scope from A to B: authoriz= ation of
> =A0 =A0 =A0Client to access his profile information only.
>
>
>
>
>
> Attack Workflow
>
>
> =A0 =A0 =A0 =A0(1) User requests Game (Client) for permission to play = games,
> =A0 =A0 =A0 =A0instantiating OAuth 2.0 with scope A.
>
>
> =A0 =A0 =A0 =A0(2) Game generates an authorization request with a scop= e
> =A0 =A0 =A0 =A0specification A, and redirects User to Facebook with th= e request.
>
>
> =A0 =A0 =A0 =A0(3) User manipulates the scope field and changes it to = scope B. The
> =A0 =A0 =A0 =A0modified request is then sent to Facebook.
>
>
> =A0 =A0 =A0 =A0(4) User grants the modified request.
>
>
> =A0 =A0 =A0 =A0(5) Facebook redirects User back to Game with the autho= rization
> =A0 =A0 =A0 =A0code.
>
>
> =A0 =A0 =A0 =A0(6) Game exchanges the authorization code for an access= token.
> =A0 =A0 =A0 =A0However it has no knowledge that the scope A has been c= hanged to
> =A0 =A0 =A0 =A0scope B.
>
>
> =A0 =A0 =A0 =A0(7) Game provides online gaming service to User. Howeve= r, Game
> =A0 =A0 =A0 =A0can=92t post messages on User=92s Facebook page.
>
>
>
>
>
> A Live-Demo: Facebook and CastleVille (IE and Safari tested)
>
>
> =A0 =A0 =A0Step 1: Login Facebook and visit Facebook Apps and Game pag= e
>
>
> =A0 =A0 =A0https://www.facebook.com/games
>
>
> Step 2: Click CastleVille.
>
>
> =A0 =A0 =A0Step 3: When you see the Request for Permission page, inste= ad of
>
>
> =A0 =A0 =A0 =A0 =A0 =A0clicking =93Allow=94, change the scope field in= the URL from your
> =A0 =A0 =A0 =A0 =A0 =A0browser from =A0=93scope=3Demail%2Cpublish_stre= am%2Cpublish_actions=94
> =A0 =A0 =A0 =A0 =A0 =A0to =93scope=3Demail%2Cpublish_stream=94.
>
>
> =A0 =A0 =A0Step 4: After the modification, press ENTER to send the mod= ified
>
>
> =A0 =A0 =A0 =A0 =A0 =A0request to Facebook. Now you will see the modif= ied Request of
> =A0 =A0 =A0 =A0 =A0 =A0Permission page.
>
>
> Step 5: Click on =93Allow=94 button and enjoy the game.
>
>
> (video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w<= /a>)
>
>
>
>
>
> Impact
>
>
> Client provides services to malicious User yet with the modified servi= ce
> agreement scope by User=92s design.
>
>
>
>
>
> Manipulating Scope Field
>
>
> The scope field in access token response is required ONLY IF Authoriza= tion
> Server observes that the User authorized scope is different than the > original scope. Consequently, User can manipulate the scope field so t= hat
> Authorization Server cannot detect the change of the scope. As a resul= t
> Client provides the services yet can=92t obtain the information that i= s
> specified in the scope of the original service agreement.
>
>
> Client can verify the service agreement scope by checking all the fiel= ds
> against the original User request before providing the requested servi= ces
> to User. =A0For instance, Client can verify the granted permissions if=
> Authorization Server (e.g. Facebook) =A0provides an API. However, this= is out
> of the scope of OAuth 2.0, and Client may not check it. We observe: al= l top
> five games recommended by Facebook are vulnerable to the scope attack.=
>
>
>
>
>
> Proposed Fix
>
>
> Draft-ietf-oauth-v2-23 Section 5.1:
>
>
> Change from
>
>
> =A0 =A0 =A0=93scope
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 OPTIONAL, if identical to the scope reques= ted by the client,
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 otherwise REQUIRED.=94
>
>
> to
>
>
> =93scope REQUIRED=94 /* scope: User authorized scope */
>
>
>
>
>
> Remarks
>
>
> (1) The proof of the correctness of OAuth with our proposed fix will b= e
> published in an article: =93OAuth 2.0 =96 Attacks, Fixes, Correctness,= and
> Generalizations, Wenjie Lin, David Lee and Steve Lai, to appear=94. >
>
> (2) The implicit grant is also vulnerable to the scope attack. However= it
> cannot be fixed by enforcing scope field in access token response as a= bove;
> User can change the scope in response before being redirected to Clien= t.
>
>
>
>
>
> Wenjie Lin, The Ohio State University
>
>
> David Lee, HP Labs and The Ohio State University
>
>
> Steve Lai, The Ohio State University
> _______________________________________________
> OAuth mailing list
> O= Auth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> O= Auth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth






_______________________________________________
OAuth mailing = list
OAuth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/oauth





--
Wenjie Lin
--14dae9341133a48c8804b97ef885-- From wmills@yahoo-inc.com Tue Feb 21 13:43:25 2012 Return-Path: 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 5BA5D21E80B6 for ; Tue, 21 Feb 2012 13:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.207 X-Spam-Level: X-Spam-Status: No, score=-17.207 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 Nv5poJIAbUAO for ; Tue, 21 Feb 2012 13:43:23 -0800 (PST) Received: from nm4.bullet.mail.ne1.yahoo.com (nm4.bullet.mail.ne1.yahoo.com [98.138.90.67]) by ietfa.amsl.com (Postfix) with SMTP id ABCE321E807D for ; Tue, 21 Feb 2012 13:43:22 -0800 (PST) Received: from [98.138.90.51] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 21 Feb 2012 21:43:22 -0000 Received: from [98.138.87.9] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 21 Feb 2012 21:43:22 -0000 Received: from [127.0.0.1] by omp1009.mail.ne1.yahoo.com with NNFMP; 21 Feb 2012 21:43:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 989687.91762.bm@omp1009.mail.ne1.yahoo.com Received: (qmail 45611 invoked by uid 60001); 21 Feb 2012 21:43:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1329860601; bh=uq0TOFnU1NZk+sBZUJ15QB/oIMkrFWzOKH62TbjeaQw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bGVWmEjar+H71OdnS2ADG8N40+8v1wLA2gFjp79AsllOBPvDJRDGaikSlfjS/Nu+S2YkAa8O9rowuIyg1ONefvhGjU9MjZz5hl0Yl0E6UvTLoVTG/S0UpbkGvJxnz0qPB4tq6Z86toVxnfB+OYzHcMgj8CrZcR30Hwpbi5TkfN4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=D+6i7Kw+Mq+0x/L3CAx+OK7cfCSROfWZzYMotxrZuRpxxhN5BxoN72OItOnZ9Oh80l+0I5svEYTj58dZh4/wX8BZd8J+UXuZI9tsRtDHAMOEgTRsxIbuHxkra9OGZVzErMF9bap/gybLBzpOG5kTMMoaSe0v9Mveao3R7GlyDi4=; X-YMail-OSG: sNUBFjQVM1mLpSzaFmhAxRRqM4a_j6x_pHmuCuFqWMZjqMe tWromB4Wd9BFlTMkUaxzSawia36Z1EwmWcYGtkrztpCAC2AqsAFZOpQ_IuM7 9ezlLU3zQ1.9bapIoLTMo1CkHkGlo_wolDBZeUgWJg.x__cjfPwZSsEgVUSb C1RIE_GzTG3BV7oTRiLDNz86MoevBr9plne1IUC0O3lKmnzng0FQ7uX5tQmg GGw9l2dn3I4cVNgSMKxpkfyaBN1wls2o2UrhlSnpYQBF2ypPAMlxfxgwftsk ZyGkMXAWzKCoRz4EBVvk9SjUmWp16UgjliFr0E_3EnT_wGLWPqlSohkWhFE4 hmfkn.gkbPn3.fzYR9Z5aLgu9y0sz9lD_Z7DJq9hvrZQeQ_VaEbQ6.s2TCn8 Q.hWpWxV6UZeFUNY7XhaKPaX1WmMxOYA5cdUBN4F7.9FLkojFEwR_RVeoPz0 3dfD9mgd.1YpPkmxymo5WWp5OPrbtFKhxKLLAYsEIgyUqqe6Y_vI35aSyEO1 Dfsu1s1E6eBEL4GeVjPCMhTV2e2yTuxQ5y2j_ZYBik4EkXIGWqO0nZPEtx1q T5rIrJ2pWxq8PScFq2xU- Received: from [209.131.62.113] by web31806.mail.mud.yahoo.com via HTTP; Tue, 21 Feb 2012 13:43:21 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340031 References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> Message-ID: <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Tue, 21 Feb 2012 13:43:21 -0800 (PST) From: William Mills To: Wenjie Lin In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-1843559-1329860601=:42679" Cc: "Lee, David" , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 21:43:25 -0000 ---1055047407-1843559-1329860601=:42679 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable No, I do not agree that this is an attack.=C2=A0 The resource owner has gra= nted different privs than the client expects, but that was done by the reso= urce owner.=C2=A0=C2=A0 The only "attack" is the resource owner against the= client, and the client is going to have to have a way to detect invalid to= kens anyway.=0A=0A=0AAs I said in the first paragraph below, this is alread= y (good or bad) part of the protocol, that the scope profile issued may dif= fer.=C2=A0 What *might* fix this is if the auth server must also return the= scopes requested if they are covered by the token; so if the client asks f= or scope A (we'll say this is a legacy client scope) which is a proper subs= et of B, and the auth server wants to issue B (the new scope for the new ve= rsion of a client) then the server would have to return "B A" as the scope = list indicating both scope.=0A=0AThe problem still lies in an unscoped resp= onse, which some implementations will want to use "" for.=C2=A0 If we force= the above we force global scopes to be named, which isn't horrible.=0A=0A= =0A=0A________________________________=0A From: Wenjie Lin =0ATo: William Mills =0ACc: John Bradley ; "oauth@ietf.org (oauth@ietf.org)" ; "Lee, David"= =0ASent: Tuesday, February 21, 2012 12:07 PM=0ASubjec= t: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0=0A =0A=0AOur understandi= ng is that you agree this is indeed a scope attack, that is, the user may g= et services, which are different than the client has agreed.=0AIf the proto= col adopts the change we=E2=80=99ve suggested, the client immediately figur= es out the difference between what he has agreed and what is in the access = token. How does the client deal with it? Decline the service or take other = actions? Indeed, as you rightly pointed out, it is an issue of operation = =E2=80=93 an excellent note for the implementer. However, this is no longer= a protocol issue.=0A-W. Lin and D. Lee=0A=0AOn Sat, Feb 18, 2012 at 8:34 P= M, William Mills wrote:=0A=0ASo, I think what you ar= e pointing out is an operability flaw rather than a security one.=C2=A0 It = is possible that the client will be issued a token that does not have the p= ermissions it expects, and the only way for the client to determine this in= a guaranteed fashion is to do an operation and see a failure.=0A>=0A>=0A>T= he question then is, does this warrant a MUST rather than SHOULD.=C2=A0 The= server may issue a more privileged token for example.=C2=A0 From the scope= name there's no way for the client to actually resolve the scope name to p= rivilege, so even if the server provides the scope we might have the same p= roblem.=0A>=0A>=0A>There are current usages in comaparable systems where an= unscoped token implies no restriction.=C2=A0 The semantics of scope names = here have intentionally been left fuzzy.=C2=A0 It's a significant change to= try to fix this problem, but the questionis whether it's worth it?=C2=A0 I= doubt that will get it right in a way that people will agree with, I don't= think you proposed change is sufficient to resolve the problem.=0A>=0A>=0A= >Would it be sifficient to call it out as an implementors note or a nota be= ne type editorial comment?=0A>=0A>=0A>-bill=0A>=0A>=0A>=0A>=0A>=0A>=0A>____= ____________________________=0A> From: Wenjie Lin =0A>To: = John Bradley =0A>Cc: "oauth@ietf.org (oauth@ietf.org)" = =0A>Sent: Saturday, February 18, 2012 8:18 PM=0A>Subject: = Re: [OAUTH-WG] A Scope Attack against OAuth 2.0=0A> =0A>=0A>=0A>We apprecia= te your attention and response to our report.=0A>=C2=A0=0A>Since Authorizat= ion Server obtains the scope information ONLY from User, it can=E2=80=99t t= ell whether the issued access token scope=C2=A0 is different from the one r= equested by Client, so long as User is consistently sending the same altere= d scope information to Authorization Server. Consequently, as an Option, Au= thorization Server may choose not to include the scope response parameter t= o inform Client of the actual scope granted, and that results in the scope = attack. This is a protocol issue and is not an implementation issue; one ca= n come up with an implementation that is compliant with the protocol specif= ication yet with a scope attack.=0A>=C2=A0=0A>One may argue that we only ca= re about User protection and security. Consequently, scope attack is appare= ntly not a protocol security issue. However, it would significantly limit t= he applicability of the protocol, if Client is knowingly exposed to attacks= . We need Client protection and security as well in applications, for insta= nce, cloud services.=0A>=C2=A0=0A>Scope attack can be easily fixed. One can= simply make it Required that Authorization Server MUST include the scope r= esponse parameter to inform Client of the actual scope granted, as we have = proposed for your consideration.=0A>=C2=A0=0A>OAuth 2.0 is a sound protocol= design. We prove the security properties (for both User and Client) and sc= ope attack is an issue we=E2=80=99ve got stuck in the proof.=0A>=C2=A0=0A>-= W. Lin and D. Lee=0A>=0A>On Sat, Feb 18, 2012 at 2:47 PM, John Bradley wrote:=0A>=0A>I agree that it is not a protocol problem.= =0A>>=0A>>The problem is that some developers are not understanding the spe= c.=0A>>=0A>>One case I saw recently was a proposal to send a scope to the A= uthorization endpoint that changed is authentication behaviour e.g. ask for= mlti-factor authentication.=0A>>=0A>>On a superficial reading of the spec = they thought that not getting a changed set of scopes back in the response = that the Authorization server was indicating that it had done what was aske= d.=0A>>=0A>>When I pointed out that the user agent can remove scopes becaus= e requests are not signed, =C2=A0they had a similar solution of forcing all= the endpoints to always return the scopes granted.=0A>>=0A>>I hope I talke= d them out of that.=0A>>=0A>>The problem is getting people to use scopes to= represent resources and not other arbitrary configuration things, =C2=A0an= d to understand that even if they do get a scope granted it could disappear= before they get to use the access token and they need to be prepared for t= hat.=0A>>=0A>>The premise that users get access to y for access to x is som= ething that can be built with OAuth but is not something that can be inferr= ed in the way they are proposing.=0A>>=0A>>From my perspective replying wit= h granted scopes is a convince for the client, but not something that can b= e depended upon.=0A>>I don't think we need any normative change.=0A>>=0A>>A= don't make stupid assumptions about the persistence of scopes in tokens no= te would be as far as I would go.=0A>>=0A>>John B.=0A>>=0A>>=0A>>On 2012-02= -18, at 3:34 AM, Shane B Weeden wrote:=0A>>=0A>>> I agree with others - thi= s is not an attack on the protocol. The user has=0A>>> the choice about whi= ch scope to grant and the client's redirect to the=0A>>> authorization endp= oint is only a request for a particular set of=0A>>> permissions, not a gua= rantee that it will get them. The user+authorization=0A>>> server decide wh= ich scope is actually granted. The client needs to handle=0A>>> cases where= that differs from what it originally wanted.=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>= From: Wenjie Lin =0A>>> To: =C2=A0 oauth@ietf.org=0A>>> D= ate: 18/02/2012 12:12 PM=0A>>> Subject: =C2=A0 =C2=A0 =C2=A0[OAUTH-WG] A Sc= ope Attack against OAuth 2.0=0A>>> Sent by: =C2=A0 =C2=A0 =C2=A0oauth-bounc= es@ietf.org=0A>>>=0A>>>=0A>>>=0A>>> We describe an attack on OAuth 2.0 (dra= ft-ietf-oauth-v2-23), called scope=0A>>> attack, provide a live-demo of the= attack on Facebook, and propose a fix=0A>>> with discussions.=0A>>>=0A>>>= =0A>>>=0A>>>=0A>>>=0A>>> Scope Attack=0A>>>=0A>>>=0A>>> OAuth authorization= of services is associated with service agreement scope.=0A>>> For instance= , Client provides an online game to User with a service=0A>>> agreement sco= pe A: User authorizes Client to access his profile information=0A>>> and to= post messages on his behalf. A malicious User can request for online=0A>>>= game with service agreement scope A, manipulate the scope field, and chang= e=0A>>> it to scope B: User authorizes Client to access his profile informa= tion.=0A>>> User can still play the games, =C2=A0yet Client can=E2=80=99t p= ost messages on User=E2=80=99s=0A>>> behalf, as originally agreed.=0A>>>=0A= >>>=0A>>> OAuth 2.0 authorization code grant and implicit grant are vulnera= ble to the=0A>>> scope attack.=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>> A Scope = Attack Scenario=0A>>>=0A>>>=0A>>> (1) Authorization Server: Facebook (autho= rization code grant)=0A>>>=0A>>>=0A>>> =C2=A0 =C2=A0 =C2=A0(2) Client: Onli= ne gaming company Game. It allows User to play the=0A>>> =C2=A0 =C2=A0 =C2= =A0games with the service agreement scope A: User authorizes Game to=0A>>> = =C2=A0 =C2=A0 =C2=A0access his profile information and post messages on his= behalf.=0A>>>=0A>>>=0A>>> =C2=A0 =C2=A0 =C2=A0(3) User: malicious User wit= h an account at Facebook. He attempts to=0A>>> =C2=A0 =C2=A0 =C2=A0play the= games yet without authorizing Game to post messages on his=0A>>> =C2=A0 = =C2=A0 =C2=A0behalf, that is, he changes the scope from A to B: authorizati= on of=0A>>> =C2=A0 =C2=A0 =C2=A0Client to access his profile information on= ly.=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>> Attack Workflow=0A>>>=0A>>>=0A>>> = =C2=A0 =C2=A0 =C2=A0 =C2=A0(1) User requests Game (Client) for permission t= o play games,=0A>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0instantiating OAuth 2.0 with= scope A.=0A>>>=0A>>>=0A>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0(2) Game generates a= n authorization request with a scope=0A>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0speci= fication A, and redirects User to Facebook with the request.=0A>>>=0A>>>=0A= >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0(3) User manipulates the scope field and cha= nges it to scope B. The=0A>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0modified request i= s then sent to Facebook.=0A>>>=0A>>>=0A>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0(4) U= ser grants the modified request.=0A>>>=0A>>>=0A>>> =C2=A0 =C2=A0 =C2=A0 =C2= =A0(5) Facebook redirects User back to Game with the authorization=0A>>> = =C2=A0 =C2=A0 =C2=A0 =C2=A0code.=0A>>>=0A>>>=0A>>> =C2=A0 =C2=A0 =C2=A0 =C2= =A0(6) Game exchanges the authorization code for an access token.=0A>>> =C2= =A0 =C2=A0 =C2=A0 =C2=A0However it has no knowledge that the scope A has be= en changed to=0A>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0scope B.=0A>>>=0A>>>=0A>>> = =C2=A0 =C2=A0 =C2=A0 =C2=A0(7) Game provides online gaming service to User.= However, Game=0A>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0can=E2=80=99t post messages= on User=E2=80=99s Facebook page.=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>> A Liv= e-Demo: Facebook and CastleVille (IE and Safari tested)=0A>>>=0A>>>=0A>>> = =C2=A0 =C2=A0 =C2=A0Step 1: Login Facebook and visit Facebook Apps and Game= page=0A>>>=0A>>>=0A>>> =C2=A0 =C2=A0 =C2=A0https://www.facebook.com/games= =0A>>>=0A>>>=0A>>> Step 2: Click CastleVille.=0A>>>=0A>>>=0A>>> =C2=A0 =C2= =A0 =C2=A0Step 3: When you see the Request for Permission page, instead of= =0A>>>=0A>>>=0A>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clicking =E2=80= =9CAllow=E2=80=9D, change the scope field in the URL from your=0A>>> =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0browser from =C2=A0=E2=80=9Cscope=3Demai= l%2Cpublish_stream%2Cpublish_actions=E2=80=9D=0A>>> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0to =E2=80=9Cscope=3Demail%2Cpublish_stream=E2=80=9D.=0A= >>>=0A>>>=0A>>> =C2=A0 =C2=A0 =C2=A0Step 4: After the modification, press E= NTER to send the modified=0A>>>=0A>>>=0A>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0request to Facebook. Now you will see the modified Request of=0A>= >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Permission page.=0A>>>=0A>>>=0A= >>> Step 5: Click on =E2=80=9CAllow=E2=80=9D button and enjoy the game.=0A>= >>=0A>>>=0A>>> (video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w)=0A>>>= =0A>>>=0A>>>=0A>>>=0A>>>=0A>>> Impact=0A>>>=0A>>>=0A>>> Client provides ser= vices to malicious User yet with the modified service=0A>>> agreement scope= by User=E2=80=99s design.=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>> Manipulating= Scope Field=0A>>>=0A>>>=0A>>> The scope field in access token response is = required ONLY IF Authorization=0A>>> Server observes that the User authoriz= ed scope is different than the=0A>>> original scope. Consequently, User can= manipulate the scope field so that=0A>>> Authorization Server cannot detec= t the change of the scope. As a result=0A>>> Client provides the services y= et can=E2=80=99t obtain the information that is=0A>>> specified in the scop= e of the original service agreement.=0A>>>=0A>>>=0A>>> Client can verify th= e service agreement scope by checking all the fields=0A>>> against the orig= inal User request before providing the requested services=0A>>> to User. = =C2=A0For instance, Client can verify the granted permissions if=0A>>> Auth= orization Server (e.g. Facebook) =C2=A0provides an API. However, this is ou= t=0A>>> of the scope of OAuth 2.0, and Client may not check it. We observe:= all top=0A>>> five games recommended by Facebook are vulnerable to the sco= pe attack.=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>> Proposed Fix=0A>>>=0A>>>=0A>= >> Draft-ietf-oauth-v2-23 Section 5.1:=0A>>>=0A>>>=0A>>> Change from=0A>>>= =0A>>>=0A>>> =C2=A0 =C2=A0 =C2=A0=E2=80=9Cscope=0A>>>=0A>>>=0A>>> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTIONAL, if identical to the sco= pe requested by the client,=0A>>>=0A>>>=0A>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 otherwise REQUIRED.=E2=80=9D=0A>>>=0A>>>=0A>>> to=0A>>= >=0A>>>=0A>>> =E2=80=9Cscope REQUIRED=E2=80=9D /* scope: User authorized sc= ope */=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>> Remarks=0A>>>=0A>>>=0A>>> (1) Th= e proof of the correctness of OAuth with our proposed fix will be=0A>>> pub= lished in an article: =E2=80=9COAuth 2.0 =E2=80=93 Attacks, Fixes, Correctn= ess, and=0A>>> Generalizations, Wenjie Lin, David Lee and Steve Lai, to app= ear=E2=80=9D.=0A>>>=0A>>>=0A>>> (2) The implicit grant is also vulnerable t= o the scope attack. However it=0A>>> cannot be fixed by enforcing scope fie= ld in access token response as above;=0A>>> User can change the scope in re= sponse before being redirected to Client.=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>= >> Wenjie Lin, The Ohio State University=0A>>>=0A>>>=0A>>> David Lee, HP La= bs and The Ohio State University=0A>>>=0A>>>=0A>>> Steve Lai, The Ohio Stat= e University=0A>>> _______________________________________________=0A>>> OA= uth mailing list=0A>>> OAuth@ietf.org=0A>>> https://www.ietf.org/mailman/li= stinfo/oauth=0A>>>=0A>>>=0A>>> ____________________________________________= ___=0A>>> OAuth mailing list=0A>>> OAuth@ietf.org=0A>>> https://www.ietf.or= g/mailman/listinfo/oauth=0A>>=0A>>=0A>=0A>=0A>=0A>=0A>=0A>_________________= ______________________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>h= ttps://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A>=0A=0A=0A-- =0AWenjie= Lin ---1055047407-1843559-1329860601=:42679 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
No, I do not agree that this is an attack.  The resource owner has g= ranted different privs than the client expects, but that was done by the re= source owner.   The only "attack" is the resource owner against t= he client, and the client is going to have to have a way to detect invalid = tokens anyway.

As I = said in the first paragraph below, this is already (good or bad) part of th= e protocol, that the scope profile issued may differ.  What *might* fi= x this is if the auth server must also return the scopes requested if they = are covered by the token; so if the client asks for scope A (we'll say this= is a legacy client scope) which is a proper subset of B, and the auth serv= er wants to issue B (the new scope for the new version of a client) then the server would have to return "B A" as the scope list indicating bo= th scope.

The problem st= ill lies in an unscoped response, which some implementations will want to u= se "" for.  If we force the above we force global scopes to be named, = which isn't horrible.

From: Wenjie Lin &= lt;lin.820@osu.edu>
To:= William Mills <wmills@yahoo-inc.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>; "oaut= h@ietf.org (oauth@ietf.org)" <oauth@ietf.org>; "Lee, David" <david.lee10@hp.com>
Sent= : Tuesday, February 21, 2012 12:07 PM
Subject: Re: [OAUTH-WG] A Scope Attack against O= Auth 2.0

=0A=0AOur understanding is that you agree this is = indeed a scope attack, that is, the user may get services, which are differ= ent than the client has agreed.
=0A=0A
If the protocol adopts the change we=E2=80=99v= e suggested, the client immediately figures out the difference between what= he has agreed and what is in the access token. How does the client deal wi= th it? Decline the service or take other actions? Indeed, as you rightly po= inted out, it is an issue of operation =E2=80=93 an excellent note for the = implementer. However, this is no longer a protocol issue.
=0A= =0A
-W. Lin and D. Lee
=0A=0A
On S= at, Feb 18, 2012 at 8:34 PM, William Mills <wmills@yahoo-inc.com> wrote:
=0A=0A
=
So, I think what you are pointing out is an operability flaw rat= her than a security one.  It is possible that the client will be issue= d a token that does not have the permissions it expects, and the only way f= or the client to determine this in a guaranteed fashion is to do an operati= on and see a failure.
=0A=0A

The question then is, does this warrant a MUST rather than SHOULD. = ; The server may issue a more privileged token for example.  From the = scope name there's no way for the client to actually resolve the scope name= to privilege, so even if the server provides the scope we might have the s= ame problem.
=0A=0A

There are current usages= in comaparable systems where an unscoped token implies no restriction.&nbs= p; The semantics=0A of scope names here have intentionally been left fuzzy.=   It's a significant change to try to fix this problem, but the questi= onis whether it's worth it?  I doubt that will get it right in a way t= hat people will agree with, I don't think you proposed change is sufficient= to resolve the problem.
=0A=0A

Would it be siffici= ent to call it out as an implementors note or a nota bene type editorial co= mment?

-bill


=0A=0A
From:= Wenjie Lin <lin.820@osu.edu>
=0A=0A To: John Br= adley <ve7jtb@ve7jtb.com> Cc: "oauth@ietf.org (oauth@ietf.org)"= <oauth@ietf.org>
=0A=0A Sent: Saturday, February 18, 2012 8= :18 PM
Subject: Re: [OA= UTH-WG] A Scope Attack against OAuth 2.0
=0A=0A
=0A
=0A=0AWe appreciate your attention and response to our report.<= u>
=0A=0A=0A=0A =
Since Authorization Server obtains the scope = information ONLY from User, it can=E2=80=99t tell whether the issued access= token scope  is different from the one requested by Client, so long a= s User is consistently sending the same altered scope information to Author= ization Server. Consequently, as an Option, Authorization Server may choose= not to include the scope response parameter to inform Client of the actual= scope granted, and that results in the scope attack. This is a protocol is= sue and is not an implementation issue; one can come up with an implementat= ion that is compliant with the protocol specification yet with a scope=0A a= ttack.
=0A=0A
 
=0A=0A=0A=0AOne may argue that we only care = about User protection and security. Consequently, scope attack is apparentl= y not a protocol security issue. However, it would significantly limit the = applicability of the protocol, if Client is knowingly exposed to attacks. W= e need Client protection and security as well in applications, for instance= , cloud services.
=0A=0A=0A=0A
<= u> 
=0A=0A=0A=0AScope attack c= an be easily fixed. One can simply make it Required that Authorization Serv= er MUST include the scope response parameter to inform Client of the actual= scope granted, as we have proposed for your consideration.
=0A=0A=0A=0A
 
=0A=0A=0A=0AOAuth 2.0 is a sound protocol design. We prove t= he security properties (for both User and Client) and scope attack is an is= sue we=E2=80=99ve got stuck in the proof.
=0A=0A= =0A=0A
 
=0A=0A=0A=0A= - W. Lin and D. Lee

On Sat, Feb 18, 2= 012 at 2:47 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
=0A=0A=0A=0A= I agree that it is not a protocol problem.
=0A
=0AThe problem is that= some developers are not understanding the spec.
=0A
=0AOne case I sa= w recently was a proposal to send a scope to the Authorization endpoint tha= t changed is authentication behaviour e.g. ask for mlti-factor authenticati= on.
=0A
=0AOn a superficial reading of the spec they thought that not= getting a changed set of scopes back in the response that the Authorizatio= n server was indicating that it had done what was asked.
=0A
=0AWhen = I pointed out that the user agent can remove scopes because requests are no= t signed,  they had a similar solution of forcing all the endpoints to= always return the scopes granted.
=0A
=0AI hope I talked them out of= that.
=0A
=0AThe problem is getting people to use scopes to represen= t resources and not other arbitrary configuration things,  and to unde= rstand that even if they do get a scope granted it could disappear before t= hey get to use the access token and they need to be prepared for that.
= =0A=0A=0A=0A=0A
=0AThe premise that users get access to y for access to = x is something that can be built with OAuth but is not something that can b= e inferred in the way they are proposing.
=0A
=0AFrom my perspective = replying with granted scopes is a convince for the client, but not somethin= g that can be depended upon.
=0AI don't think we need any normative chan= ge.
=0A
=0AA don't make stupid assumptions about the persistence of s= copes in tokens note would be as far as I would go.
=0A
=0AJohn B.=0A

=0AOn 2012-02-18, at 3:34 AM, Shane B Weeden wrote:
= =0A
=0A> I agree with others - this is not an attack on the protocol.= The user has
=0A> the choice about which scope to grant and the clie= nt's redirect to the
=0A> authorization endpoint is only a request fo= r a particular set of
=0A> permissions, not a guarantee that it will = get them. The user+authorization
=0A> server decide which scope is ac= tually granted. The client needs to handle
=0A> cases where that diff= ers from what it originally wanted.
=0A>
=0A>
=0A>
=0A= >
=0A> From: Wenjie Lin <lin.820@= osu.edu>
=0A> To:   oauth@iet= f.org
=0A> Date: 18/02/2012 12:12 PM
=0A> Subject:   &= nbsp;  [OAUTH-WG] A Scope Attack against OAuth 2.0
=0A> Sent by:=      oauth-boun= ces@ietf.org
=0A>
=0A>
=0A>
=0A> We describe an= attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called scope
=0A> atta= ck, provide a live-demo of the attack on Facebook, and propose a fix
=0A= > with discussions.
=0A>
=0A>
=0A>
=0A>
=0A&g= t;
=0A> Scope Attack
=0A>
=0A>
=0A> OAuth authoriza= tion of services is associated with service agreement scope.
=0A> For= instance, Client provides an online game to User with a service
=0A>= agreement scope A: User authorizes Client to access his profile informatio= n
=0A> and to post messages on his behalf. A malicious User can reque= st for online
=0A> game with service agreement scope A, manipulate th= e scope field, and change
=0A> it to scope B: User authorizes Client = to access his profile information.
=0A> User can still play the games= ,  yet Client can=E2=80=99t post messages on User=E2=80=99s
=0A>= behalf, as originally agreed.
=0A>
=0A>
=0A> OAuth 2.0 a= uthorization code grant and implicit grant are vulnerable to the
=0A>= scope attack.
=0A>
=0A>
=0A>
=0A>
=0A>
= =0A> A Scope Attack Scenario
=0A>
=0A>
=0A> (1) Author= ization Server: Facebook (authorization code grant)
=0A>
=0A>=0A>      (2) Client: Online gaming company Game. It al= lows User to play the
=0A>      games with the service= agreement scope A: User authorizes Game to
=0A>      = access his profile information and post messages on his behalf.
=0A><= br>=0A>
=0A>      (3) User: malicious User with an = account at Facebook. He attempts to
=0A>      play the= games yet without authorizing Game to post messages on his
=0A> &nbs= p;    behalf, that is, he changes the scope from A to B: authoriz= ation of
=0A>      Client to access his profile inform= ation only.
=0A>
=0A>
=0A>
=0A>
=0A>
=0A&g= t; Attack Workflow
=0A>
=0A>
=0A>       &n= bsp;(1) User requests Game (Client) for permission to play games,
=0A>= ;        instantiating OAuth 2.0 with scope A.
=0A&g= t;
=0A>
=0A>        (2) Game generates an a= uthorization request with a scope
=0A>        spe= cification A, and redirects User to Facebook with the request.
=0A>=0A>
=0A>        (3) User manipulates the sc= ope field and changes it to scope B. The
=0A>       &n= bsp;modified request is then sent to Facebook.
=0A>
=0A>
=0A= >        (4) User grants the modified request.
= =0A>
=0A>
=0A>        (5) Facebook redir= ects User back to Game with the authorization
=0A>     &nbs= p;  code.
=0A>
=0A>
=0A>        = (6) Game exchanges the authorization code for an access token.
=0A> &= nbsp;      However it has no knowledge that the scope A has = been changed to
=0A>        scope B.
=0A>=0A>
=0A>        (7) Game provides online ga= ming service to User. However, Game
=0A>        c= an=E2=80=99t post messages on User=E2=80=99s Facebook page.
=0A>
= =0A>
=0A>
=0A>
=0A>
=0A> A Live-Demo: Facebook a= nd CastleVille (IE and Safari tested)
=0A>
=0A>
=0A> &nbs= p;    Step 1: Login Facebook and visit Facebook Apps and Game pag= e
=0A>
=0A>
=0A>      https://www.faceb= ook.com/games
=0A>
=0A>
=0A> Step 2: Click CastleVill= e.
=0A>
=0A>
=0A>      Step 3: When you se= e the Request for Permission page, instead of
=0A>
=0A>
=0A&= gt;            clicking =E2=80=9CAllow=E2=80= =9D, change the scope field in the URL from your
=0A>     &= nbsp;      browser from  =E2=80=9Cscope=3Demail%2Cpubli= sh_stream%2Cpublish_actions=E2=80=9D
=0A>        =    to =E2=80=9Cscope=3Demail%2Cpublish_stream=E2=80=9D.
=0A&g= t;
=0A>
=0A>      Step 4: After the modification= , press ENTER to send the modified
=0A>
=0A>
=0A>   =          request to Facebook. Now you will see the= modified Request of
=0A>            Pe= rmission page.
=0A>
=0A>
=0A> Step 5: Click on =E2=80=9CA= llow=E2=80=9D button and enjoy the game.
=0A>
=0A>
=0A> (= video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w)=0A>
=0A>
=0A>
=0A>
=0A>
=0A> Impact
= =0A>
=0A>
=0A> Client provides services to malicious User ye= t with the modified service
=0A> agreement scope by User=E2=80=99s de= sign.
=0A>
=0A>
=0A>
=0A>
=0A>
=0A> Man= ipulating Scope Field
=0A>
=0A>
=0A> The scope field in a= ccess token response is required ONLY IF Authorization
=0A> Server ob= serves that the User authorized scope is different than the
=0A> orig= inal scope. Consequently, User can manipulate the scope field so that
= =0A> Authorization Server cannot detect the change of the scope. As a re= sult
=0A> Client provides the services yet can=E2=80=99t obtain the i= nformation that is
=0A> specified in the scope of the original servic= e agreement.
=0A>
=0A>
=0A> Client can verify the service= agreement scope by checking all the fields
=0A> against the original= User request before providing the requested services
=0A> to User. &= nbsp;For instance, Client can verify the granted permissions if
=0A> = Authorization Server (e.g. Facebook)  provides an API. However, this i= s out
=0A> of the scope of OAuth 2.0, and Client may not check it. We= observe: all top
=0A> five games recommended by Facebook are vulnera= ble to the scope attack.
=0A>
=0A>
=0A>
=0A>
=0A= >
=0A> Proposed Fix
=0A>
=0A>
=0A> Draft-ietf-oa= uth-v2-23 Section 5.1:
=0A>
=0A>
=0A> Change from
=0A&= gt;
=0A>
=0A>      =E2=80=9Cscope
=0A>
= =0A>
=0A>               OPTIONA= L, if identical to the scope requested by the client,
=0A>
=0A>=
=0A>               otherwise REQU= IRED.=E2=80=9D
=0A>
=0A>
=0A> to
=0A>
=0A>=0A> =E2=80=9Cscope REQUIRED=E2=80=9D /* scope: User authorized scope *= /
=0A>
=0A>
=0A>
=0A>
=0A>
=0A> Remarks=
=0A>
=0A>
=0A> (1) The proof of the correctness of OAuth= with our proposed fix will be
=0A> published in an article: =E2=80= =9COAuth 2.0 =E2=80=93 Attacks, Fixes, Correctness, and
=0A> Generali= zations, Wenjie Lin, David Lee and Steve Lai, to appear=E2=80=9D.
=0A>= ;
=0A>
=0A> (2) The implicit grant is also vulnerable to the sc= ope attack. However it
=0A> cannot be fixed by enforcing scope field = in access token response as above;
=0A> User can change the scope in = response before being redirected to Client.
=0A>
=0A>
=0A>= ;
=0A>
=0A>
=0A> Wenjie Lin, The Ohio State University=0A>
=0A>
=0A> David Lee, HP Labs and The Ohio State Univer= sity
=0A>
=0A>
=0A> Steve Lai, The Ohio State University<= br>=0A> _______________________________________________
=0A> OAuth= mailing list
=0A> OAuth@ietf.org
= =0A> https://www.ietf.org/mailman/listinfo/oauth
= =0A>
=0A>
=0A> _____________________________________________= __
=0A> OAuth mailing list
=0A> OAu= th@ietf.org
=0A> https://www.ietf.org/mailman/lis= tinfo/oauth
=0A
=0A




=0A

__________________________________= _____________
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org/mailman/listinfo/oauth
=0A=0A




--
Wenjie Lin
=0A
=
---1055047407-1843559-1329860601=:42679-- From ve7jtb@ve7jtb.com Tue Feb 21 14:00:00 2012 Return-Path: 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 1E76411E8081 for ; Tue, 21 Feb 2012 14:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 3v3JKM-ERsvu for ; Tue, 21 Feb 2012 13:59:58 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC59111E8074 for ; Tue, 21 Feb 2012 13:59:57 -0800 (PST) Received: by yhkk25 with SMTP id k25so3622064yhk.31 for ; Tue, 21 Feb 2012 13:59:57 -0800 (PST) Received-SPF: pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.170.163 as permitted sender) client-ip=10.236.170.163; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.170.163 as permitted sender) smtp.mail=ve7jtb@ve7jtb.com Received: from mr.google.com ([10.236.170.163]) by 10.236.170.163 with SMTP id p23mr37961763yhl.36.1329861597359 (num_hops = 1); Tue, 21 Feb 2012 13:59:57 -0800 (PST) Received: by 10.236.170.163 with SMTP id p23mr29531984yhl.36.1329861596195; Tue, 21 Feb 2012 13:59:56 -0800 (PST) Received: from [192.168.1.213] ([190.22.73.49]) by mx.google.com with ESMTPS id q68sm37101080yhb.3.2012.02.21.13.59.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 13:59:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_98B5B1B7-9061-496F-AC51-88B2C2E502EA"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Tue, 21 Feb 2012 18:59:44 -0300 Message-Id: <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnkhIz6CGEqI8weOYANZQjQB0rIe22x7/h61bx8G/VSGArnj90b+nhzdzBJN6tNsHKuDhpv Cc: "Lee, David" , Wenjie Lin , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 22:00:00 -0000 --Apple-Mail=_98B5B1B7-9061-496F-AC51-88B2C2E502EA Content-Type: multipart/alternative; boundary="Apple-Mail=_B3324809-1D0F-4211-93D4-CE87386B941F" --Apple-Mail=_B3324809-1D0F-4211-93D4-CE87386B941F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Removing the unstopped response solves nothing , because the resource = owner can revoke a scope at any time after granting it. =20 Nothing forces the Authorization server to revoke the refresh or access = token if a scope is revoked. That is a implementation choice of the = Authorization server. This 'attack' is one that only works with badly designed clients that = are making unwarranted assumptions about the behaviour of the = Authorization server. =20 The only way for a client to know if a token has a scope it to try it, = or use a introspection endpoint. End of story. John B. On 2012-02-21, at 6:43 PM, William Mills wrote: > No, I do not agree that this is an attack. The resource owner has = granted different privs than the client expects, but that was done by = the resource owner. The only "attack" is the resource owner against = the client, and the client is going to have to have a way to detect = invalid tokens anyway. >=20 > As I said in the first paragraph below, this is already (good or bad) = part of the protocol, that the scope profile issued may differ. What = *might* fix this is if the auth server must also return the scopes = requested if they are covered by the token; so if the client asks for = scope A (we'll say this is a legacy client scope) which is a proper = subset of B, and the auth server wants to issue B (the new scope for the = new version of a client) then the server would have to return "B A" as = the scope list indicating both scope. >=20 > The problem still lies in an unscoped response, which some = implementations will want to use "" for. If we force the above we force = global scopes to be named, which isn't horrible. >=20 > From: Wenjie Lin > To: William Mills =20 > Cc: John Bradley ; "oauth@ietf.org = (oauth@ietf.org)" ; "Lee, David" =20 > Sent: Tuesday, February 21, 2012 12:07 PM > Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 >=20 > Our understanding is that you agree this is indeed a scope attack, = that is, the user may get services, which are different than the client = has agreed. > If the protocol adopts the change we=92ve suggested, the client = immediately figures out the difference between what he has agreed and = what is in the access token. How does the client deal with it? Decline = the service or take other actions? Indeed, as you rightly pointed out, = it is an issue of operation =96 an excellent note for the implementer. = However, this is no longer a protocol issue. > -W. Lin and D. Lee >=20 > On Sat, Feb 18, 2012 at 8:34 PM, William Mills = wrote: > So, I think what you are pointing out is an operability flaw rather = than a security one. It is possible that the client will be issued a = token that does not have the permissions it expects, and the only way = for the client to determine this in a guaranteed fashion is to do an = operation and see a failure. >=20 > The question then is, does this warrant a MUST rather than SHOULD. = The server may issue a more privileged token for example. =46rom the = scope name there's no way for the client to actually resolve the scope = name to privilege, so even if the server provides the scope we might = have the same problem. >=20 > There are current usages in comaparable systems where an unscoped = token implies no restriction. The semantics of scope names here have = intentionally been left fuzzy. It's a significant change to try to fix = this problem, but the questionis whether it's worth it? I doubt that = will get it right in a way that people will agree with, I don't think = you proposed change is sufficient to resolve the problem. >=20 > Would it be sifficient to call it out as an implementors note or a = nota bene type editorial comment? >=20 > -bill >=20 >=20 > From: Wenjie Lin > To: John Bradley =20 > Cc: "oauth@ietf.org (oauth@ietf.org)" =20 > Sent: Saturday, February 18, 2012 8:18 PM > Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 >=20 > We appreciate your attention and response to our report. > =20 > Since Authorization Server obtains the scope information ONLY from = User, it can=92t tell whether the issued access token scope is = different from the one requested by Client, so long as User is = consistently sending the same altered scope information to Authorization = Server. Consequently, as an Option, Authorization Server may choose not = to include the scope response parameter to inform Client of the actual = scope granted, and that results in the scope attack. This is a protocol = issue and is not an implementation issue; one can come up with an = implementation that is compliant with the protocol specification yet = with a scope attack. > =20 > One may argue that we only care about User protection and security. = Consequently, scope attack is apparently not a protocol security issue. = However, it would significantly limit the applicability of the protocol, = if Client is knowingly exposed to attacks. We need Client protection and = security as well in applications, for instance, cloud services. > =20 > Scope attack can be easily fixed. One can simply make it Required that = Authorization Server MUST include the scope response parameter to inform = Client of the actual scope granted, as we have proposed for your = consideration. > =20 > OAuth 2.0 is a sound protocol design. We prove the security properties = (for both User and Client) and scope attack is an issue we=92ve got = stuck in the proof. > =20 > - W. Lin and D. Lee >=20 > On Sat, Feb 18, 2012 at 2:47 PM, John Bradley = wrote: > I agree that it is not a protocol problem. >=20 > The problem is that some developers are not understanding the spec. >=20 > One case I saw recently was a proposal to send a scope to the = Authorization endpoint that changed is authentication behaviour e.g. ask = for mlti-factor authentication. >=20 > On a superficial reading of the spec they thought that not getting a = changed set of scopes back in the response that the Authorization server = was indicating that it had done what was asked. >=20 > When I pointed out that the user agent can remove scopes because = requests are not signed, they had a similar solution of forcing all the = endpoints to always return the scopes granted. >=20 > I hope I talked them out of that. >=20 > The problem is getting people to use scopes to represent resources and = not other arbitrary configuration things, and to understand that even = if they do get a scope granted it could disappear before they get to use = the access token and they need to be prepared for that. >=20 > The premise that users get access to y for access to x is something = that can be built with OAuth but is not something that can be inferred = in the way they are proposing. >=20 > =46rom my perspective replying with granted scopes is a convince for = the client, but not something that can be depended upon. > I don't think we need any normative change. >=20 > A don't make stupid assumptions about the persistence of scopes in = tokens note would be as far as I would go. >=20 > John B. >=20 > On 2012-02-18, at 3:34 AM, Shane B Weeden wrote: >=20 > > I agree with others - this is not an attack on the protocol. The = user has > > the choice about which scope to grant and the client's redirect to = the > > authorization endpoint is only a request for a particular set of > > permissions, not a guarantee that it will get them. The = user+authorization > > server decide which scope is actually granted. The client needs to = handle > > cases where that differs from what it originally wanted. > > > > > > > > > > From: Wenjie Lin > > To: oauth@ietf.org > > Date: 18/02/2012 12:12 PM > > Subject: [OAUTH-WG] A Scope Attack against OAuth 2.0 > > Sent by: oauth-bounces@ietf.org > > > > > > > > We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called = scope > > attack, provide a live-demo of the attack on Facebook, and propose a = fix > > with discussions. > > > > > > > > > > > > Scope Attack > > > > > > OAuth authorization of services is associated with service agreement = scope. > > For instance, Client provides an online game to User with a service > > agreement scope A: User authorizes Client to access his profile = information > > and to post messages on his behalf. A malicious User can request for = online > > game with service agreement scope A, manipulate the scope field, and = change > > it to scope B: User authorizes Client to access his profile = information. > > User can still play the games, yet Client can=92t post messages on = User=92s > > behalf, as originally agreed. > > > > > > OAuth 2.0 authorization code grant and implicit grant are vulnerable = to the > > scope attack. > > > > > > > > > > > > A Scope Attack Scenario > > > > > > (1) Authorization Server: Facebook (authorization code grant) > > > > > > (2) Client: Online gaming company Game. It allows User to play = the > > games with the service agreement scope A: User authorizes Game = to > > access his profile information and post messages on his behalf. > > > > > > (3) User: malicious User with an account at Facebook. He = attempts to > > play the games yet without authorizing Game to post messages on = his > > behalf, that is, he changes the scope from A to B: = authorization of > > Client to access his profile information only. > > > > > > > > > > > > Attack Workflow > > > > > > (1) User requests Game (Client) for permission to play games, > > instantiating OAuth 2.0 with scope A. > > > > > > (2) Game generates an authorization request with a scope > > specification A, and redirects User to Facebook with the = request. > > > > > > (3) User manipulates the scope field and changes it to scope = B. The > > modified request is then sent to Facebook. > > > > > > (4) User grants the modified request. > > > > > > (5) Facebook redirects User back to Game with the = authorization > > code. > > > > > > (6) Game exchanges the authorization code for an access = token. > > However it has no knowledge that the scope A has been changed = to > > scope B. > > > > > > (7) Game provides online gaming service to User. However, = Game > > can=92t post messages on User=92s Facebook page. > > > > > > > > > > > > A Live-Demo: Facebook and CastleVille (IE and Safari tested) > > > > > > Step 1: Login Facebook and visit Facebook Apps and Game page > > > > > > https://www.facebook.com/games > > > > > > Step 2: Click CastleVille. > > > > > > Step 3: When you see the Request for Permission page, instead = of > > > > > > clicking =93Allow=94, change the scope field in the URL = from your > > browser from = =93scope=3Demail%2Cpublish_stream%2Cpublish_actions=94 > > to =93scope=3Demail%2Cpublish_stream=94. > > > > > > Step 4: After the modification, press ENTER to send the = modified > > > > > > request to Facebook. Now you will see the modified = Request of > > Permission page. > > > > > > Step 5: Click on =93Allow=94 button and enjoy the game. > > > > > > (video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w) > > > > > > > > > > > > Impact > > > > > > Client provides services to malicious User yet with the modified = service > > agreement scope by User=92s design. > > > > > > > > > > > > Manipulating Scope Field > > > > > > The scope field in access token response is required ONLY IF = Authorization > > Server observes that the User authorized scope is different than the > > original scope. Consequently, User can manipulate the scope field so = that > > Authorization Server cannot detect the change of the scope. As a = result > > Client provides the services yet can=92t obtain the information that = is > > specified in the scope of the original service agreement. > > > > > > Client can verify the service agreement scope by checking all the = fields > > against the original User request before providing the requested = services > > to User. For instance, Client can verify the granted permissions if > > Authorization Server (e.g. Facebook) provides an API. However, this = is out > > of the scope of OAuth 2.0, and Client may not check it. We observe: = all top > > five games recommended by Facebook are vulnerable to the scope = attack. > > > > > > > > > > > > Proposed Fix > > > > > > Draft-ietf-oauth-v2-23 Section 5.1: > > > > > > Change from > > > > > > =93scope > > > > > > OPTIONAL, if identical to the scope requested by the = client, > > > > > > otherwise REQUIRED.=94 > > > > > > to > > > > > > =93scope REQUIRED=94 /* scope: User authorized scope */ > > > > > > > > > > > > Remarks > > > > > > (1) The proof of the correctness of OAuth with our proposed fix will = be > > published in an article: =93OAuth 2.0 =96 Attacks, Fixes, = Correctness, and > > Generalizations, Wenjie Lin, David Lee and Steve Lai, to appear=94. > > > > > > (2) The implicit grant is also vulnerable to the scope attack. = However it > > cannot be fixed by enforcing scope field in access token response as = above; > > User can change the scope in response before being redirected to = Client. > > > > > > > > > > > > Wenjie Lin, The Ohio State University > > > > > > David Lee, HP Labs and The Ohio State University > > > > > > Steve Lai, The Ohio State University > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 >=20 > --=20 > Wenjie Lin >=20 >=20 --Apple-Mail=_B3324809-1D0F-4211-93D4-CE87386B941F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
No, I = do not agree that this is an attack.  The resource owner has = granted different privs than the client expects, but that was done by = the resource owner.   The only "attack" is the resource owner = against the client, and the client is going to have to have a way to = detect invalid tokens = anyway.

As I said = in the first paragraph below, this is already (good or bad) part of the = protocol, that the scope profile issued may differ.  What *might* = fix this is if the auth server must also return the scopes requested if = they are covered by the token; so if the client asks for scope A (we'll = say this is a legacy client scope) which is a proper subset of B, and = the auth server wants to issue B (the new scope for the new version of a = client) then the server would have to return "B A" as the scope list indicating = both scope.

The = problem still lies in an unscoped response, which some implementations = will want to use "" for.  If we force the above we force global = scopes to be named, which isn't = horrible.

=
=
From: = Wenjie Lin <lin.820@osu.edu>
To: William Mills <wmills@yahoo-inc.com> =
Cc: John Bradley = <ve7jtb@ve7jtb.com>; "oauth@ietf.org (oauth@ietf.org)" <oauth@ietf.org>; "Lee, David" <david.lee10@hp.com> =
Sent: Tuesday, = February 21, 2012 12:07 PM
Subject: Re: [OAUTH-WG] A Scope Attack against OAuth = 2.0

Our understanding is that you agree = this is indeed a scope attack, that is, the user may get services, which = are different than the client has agreed.
If the protocol adopts the change = we=92ve suggested, the client immediately figures out the difference = between what he has agreed and what is in the access token. How does the = client deal with it? Decline the service or take other actions? Indeed, = as you rightly pointed out, it is an issue of operation =96 an excellent = note for the implementer. However, this is no longer a protocol = issue.
-W. Lin and D. Lee

On Sat, Feb 18, 2012 at = 8:34 PM, William Mills <wmills@yahoo-inc.com> = wrote:
So, I think what you are = pointing out is an operability flaw rather than a security one.  It = is possible that the client will be issued a token that does not have = the permissions it expects, and the only way for the client to determine = this in a guaranteed fashion is to do an operation and see a = failure.

The question then is, does this = warrant a MUST rather than SHOULD.  The server may issue a more = privileged token for example.  =46rom the scope name there's no way = for the client to actually resolve the scope name to privilege, so even = if the server provides the scope we might have the same = problem.

There are current usages in comaparable systems = where an unscoped token implies no restriction.  The semantics of scope names here have intentionally been left fuzzy.  It's a = significant change to try to fix this problem, but the questionis = whether it's worth it?  I doubt that will get it right in a way = that people will agree with, I don't think you proposed change is = sufficient to resolve the problem.

Would it be sifficient to call it out as an = implementors note or a nota bene type editorial = comment?

-bill


<= span>
From: = Wenjie Lin <lin.820@osu.edu>
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: "oauth@ietf.org (oauth@ietf.org)" <oauth@ietf.org>
Sent: Saturday, = February 18, 2012 8:18 PM
Subject: Re: [OAUTH-WG] A Scope = Attack against OAuth 2.0

We appreciate your attention and = response to our report.
 
Since Authorization Server obtains the = scope information ONLY from User, it can=92t tell whether the issued = access token scope  is different from the one requested by Client, = so long as User is consistently sending the same altered scope = information to Authorization Server. Consequently, as an Option, = Authorization Server may choose not to include the scope response = parameter to inform Client of the actual scope granted, and that results = in the scope attack. This is a protocol issue and is not an = implementation issue; one can come up with an implementation that is = compliant with the protocol specification yet with a scope attack.
 
One may argue that we only care about = User protection and security. Consequently, scope attack is apparently = not a protocol security issue. However, it would significantly limit the = applicability of the protocol, if Client is knowingly exposed to = attacks. We need Client protection and security as well in applications, = for instance, cloud services.
 
Scope attack can be easily fixed. One = can simply make it Required that Authorization Server MUST include the = scope response parameter to inform Client of the actual scope granted, = as we have proposed for your consideration.
 
OAuth 2.0 is a sound protocol design. = We prove the security properties (for both User and Client) and scope = attack is an issue we=92ve got stuck in the = proof.
 
- W. Lin and D. = Lee

On Sat, Feb 18, 2012 at 2:47 PM, John = Bradley <ve7jtb@ve7jtb.com> = wrote:
I agree that it is not a protocol problem.

The problem is that some developers are not understanding the spec.

One case I saw recently was a proposal to send a scope to the = Authorization endpoint that changed is authentication behaviour e.g. ask = for mlti-factor authentication.

On a superficial reading of the spec they thought that not getting a = changed set of scopes back in the response that the Authorization server = was indicating that it had done what was asked.

When I pointed out that the user agent can remove scopes because = requests are not signed,  they had a similar solution of forcing = all the endpoints to always return the scopes granted.

I hope I talked them out of that.

The problem is getting people to use scopes to represent resources and = not other arbitrary configuration things,  and to understand that = even if they do get a scope granted it could disappear before they get = to use the access token and they need to be prepared for that.

The premise that users get access to y for access to x is something that = can be built with OAuth but is not something that can be inferred in the = way they are proposing.

=46rom my perspective replying with granted scopes is a convince for the = client, but not something that can be depended upon.
I don't think we need any normative change.

A don't make stupid assumptions about the persistence of scopes in = tokens note would be as far as I would go.

John B.

On 2012-02-18, at 3:34 AM, Shane B Weeden wrote:

> I agree with others - this is not an attack on the protocol. The = user has
> the choice about which scope to grant and the client's redirect to = the
> authorization endpoint is only a request for a particular set = of
> permissions, not a guarantee that it will get them. The = user+authorization
> server decide which scope is actually granted. The client needs to = handle
> cases where that differs from what it originally wanted.
>
>
>
>
> From: Wenjie Lin <lin.820@osu.edu>
> To:   oauth@ietf.org
> Date: 18/02/2012 12:12 PM
> Subject:      [OAUTH-WG] A Scope Attack against = OAuth 2.0
> Sent by:      oauth-bounces@ietf.org
>
>
>
> We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called = scope
> attack, provide a live-demo of the attack on Facebook, and propose = a fix
> with discussions.
>
>
>
>
>
> Scope Attack
>
>
> OAuth authorization of services is associated with service = agreement scope.
> For instance, Client provides an online game to User with a = service
> agreement scope A: User authorizes Client to access his profile = information
> and to post messages on his behalf. A malicious User can request = for online
> game with service agreement scope A, manipulate the scope field, = and change
> it to scope B: User authorizes Client to access his profile = information.
> User can still play the games,  yet Client can=92t post = messages on User=92s
> behalf, as originally agreed.
>
>
> OAuth 2.0 authorization code grant and implicit grant are = vulnerable to the
> scope attack.
>
>
>
>
>
> A Scope Attack Scenario
>
>
> (1) Authorization Server: Facebook (authorization code grant)
>
>
>      (2) Client: Online gaming company Game. It = allows User to play the
>      games with the service agreement scope A: User = authorizes Game to
>      access his profile information and post = messages on his behalf.
>
>
>      (3) User: malicious User with an account at = Facebook. He attempts to
>      play the games yet without authorizing Game to = post messages on his
>      behalf, that is, he changes the scope from A to = B: authorization of
>      Client to access his profile information = only.
>
>
>
>
>
> Attack Workflow
>
>
>        (1) User requests Game (Client) for = permission to play games,
>        instantiating OAuth 2.0 with scope = A.
>
>
>        (2) Game generates an authorization = request with a scope
>        specification A, and redirects User to = Facebook with the request.
>
>
>        (3) User manipulates the scope field and = changes it to scope B. The
>        modified request is then sent to = Facebook.
>
>
>        (4) User grants the modified = request.
>
>
>        (5) Facebook redirects User back to Game = with the authorization
>        code.
>
>
>        (6) Game exchanges the authorization = code for an access token.
>        However it has no knowledge that the = scope A has been changed to
>        scope B.
>
>
>        (7) Game provides online gaming service = to User. However, Game
>        can=92t post messages on User=92s = Facebook page.
>
>
>
>
>
> A Live-Demo: Facebook and CastleVille (IE and Safari tested)
>
>
>      Step 1: Login Facebook and visit Facebook Apps = and Game page
>
>
>      https://www.facebook.com/games=
>
>
> Step 2: Click CastleVille.
>
>
>      Step 3: When you see the Request for Permission = page, instead of
>
>
>            clicking =93Allow=94, = change the scope field in the URL from your
>            browser from =  =93scope=3Demail%2Cpublish_stream%2Cpublish_actions=94
>            to = =93scope=3Demail%2Cpublish_stream=94.
>
>
>      Step 4: After the modification, press ENTER to = send the modified
>
>
>            request to Facebook. Now = you will see the modified Request of
>            Permission page.
>
>
> Step 5: Click on =93Allow=94 button and enjoy the game.
>
>
> (video: http://www.youtube.c= om/watch?v=3DzkmjLa3VU9w)
>
>
>
>
>
> Impact
>
>
> Client provides services to malicious User yet with the modified = service
> agreement scope by User=92s design.
>
>
>
>
>
> Manipulating Scope Field
>
>
> The scope field in access token response is required ONLY IF = Authorization
> Server observes that the User authorized scope is different than = the
> original scope. Consequently, User can manipulate the scope field = so that
> Authorization Server cannot detect the change of the scope. As a = result
> Client provides the services yet can=92t obtain the information = that is
> specified in the scope of the original service agreement.
>
>
> Client can verify the service agreement scope by checking all the = fields
> against the original User request before providing the requested = services
> to User.  For instance, Client can verify the granted = permissions if
> Authorization Server (e.g. Facebook)  provides an API. = However, this is out
> of the scope of OAuth 2.0, and Client may not check it. We observe: = all top
> five games recommended by Facebook are vulnerable to the scope = attack.
>
>
>
>
>
> Proposed Fix
>
>
> Draft-ietf-oauth-v2-23 Section 5.1:
>
>
> Change from
>
>
>      =93scope
>
>
>               OPTIONAL, if = identical to the scope requested by the client,
>
>
>               otherwise = REQUIRED.=94
>
>
> to
>
>
> =93scope REQUIRED=94 /* scope: User authorized scope */
>
>
>
>
>
> Remarks
>
>
> (1) The proof of the correctness of OAuth with our proposed fix = will be
> published in an article: =93OAuth 2.0 =96 Attacks, Fixes, = Correctness, and
> Generalizations, Wenjie Lin, David Lee and Steve Lai, to = appear=94.
>
>
> (2) The implicit grant is also vulnerable to the scope attack. = However it
> cannot be fixed by enforcing scope field in access token response = as above;
> User can change the scope in response before being redirected to = Client.
>
>
>
>
>
> Wenjie Lin, The Ohio State University
>
>
> David Lee, HP Labs and The Ohio State University
>
>
> Steve Lai, The Ohio State University
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/= mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/= mailman/listinfo/oauth






_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


=



-- =
Wenjie Lin


=

= --Apple-Mail=_B3324809-1D0F-4211-93D4-CE87386B941F-- --Apple-Mail=_98B5B1B7-9061-496F-AC51-88B2C2E502EA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MjEyMTU5NDVaMCMGCSqGSIb3DQEJBDEWBBQTMxUCFkzMgFCrj9FxB6vIal2FgDCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQC+WwJySbtb7jaaFyHXEDhfHeK/sr015oyFlv8jT5KoD/RcTuOBsekNdAkYHwnw51a1dbqVFIkb 5B9puLQBfoi3eWzt3B432chrBpxMASrFnB7uzoxDD/A+s9faIq4T9y3ozEUhZPiclq+79aFKrDlb XIvLiTrHyztpU5ADgwudQRbTt9khfbEYEr6Oqez6AVvX1sjfoWLZTmWWjZLdB0WDWQYdO9Zt0YoN xFEWfQAXJ1Yi8I6t3t43TAVVrLkiASsSXT4c3ZrXJkiDg/mqFOYaO0en+r6CZNKz7o93p0W2N34r D4Aw2urWp+SQus0FxWmmdnbBnbvJXP5bsFP3QVl1AAAAAAAA --Apple-Mail=_98B5B1B7-9061-496F-AC51-88B2C2E502EA-- From misnomer@gmail.com Tue Feb 21 14:32:08 2012 Return-Path: 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 522D511E80AA for ; Tue, 21 Feb 2012 14:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 VH2wx38rrdF2 for ; Tue, 21 Feb 2012 14:32:07 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0584411E807F for ; Tue, 21 Feb 2012 14:32:06 -0800 (PST) Received: by werg1 with SMTP id g1so4243070wer.31 for ; Tue, 21 Feb 2012 14:32:06 -0800 (PST) Received-SPF: pass (google.com: domain of misnomer@gmail.com designates 10.180.24.202 as permitted sender) client-ip=10.180.24.202; Authentication-Results: mr.google.com; spf=pass (google.com: domain of misnomer@gmail.com designates 10.180.24.202 as permitted sender) smtp.mail=misnomer@gmail.com; dkim=pass header.i=misnomer@gmail.com Received: from mr.google.com ([10.180.24.202]) by 10.180.24.202 with SMTP id w10mr29490469wif.9.1329863526320 (num_hops = 1); Tue, 21 Feb 2012 14:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=xoqf0NLZB+MUYb1EfTwWjuG3f97Y1Otq0Jc+ZYL2yH0=; b=w8CNazldXCry+X1jOkuRNE6xWHA0VdJZha1V3xomYeoKAjgHB504GmHXG32ocxAFq3 sqs7GooKK3esUmxAVD3KVqfwwGAm74m92R+hkcLSJ87qIxH/Jf24ty7QwXPfYcG9TK7e hdydl177WEMigiJ8hcZiUrTuljWNNAxxK6oKc= Received: by 10.180.24.202 with SMTP id w10mr24551770wif.9.1329863526208; Tue, 21 Feb 2012 14:32:06 -0800 (PST) Received: from [192.168.0.2] (94-193-236-71.zone7.bethere.co.uk. [94.193.236.71]) by mx.google.com with ESMTPS id p10sm25917502wic.0.2012.02.21.14.32.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 14:32:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_3927AAEB-3EA0-4F81-8722-383A14BB9A45"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Nicholas Devenish In-Reply-To: <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> Date: Tue, 21 Feb 2012 22:32:00 +0000 Message-Id: <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1257) Cc: "Lee, David" , Wenjie Lin , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 22:32:08 -0000 --Apple-Mail=_3927AAEB-3EA0-4F81-8722-383A14BB9A45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 21 Feb 2012, at 21:59, John Bradley wrote: > This 'attack' is one that only works with badly designed clients that = are making unwarranted assumptions about the behaviour of the = Authorization server. =20 Unwarranted assumptions? The spec in 3.3 says: "If the issued access token scope is different from the one requested by = the client, the authorization server MUST include the "scope" response = parameter to inform the client of the actual scope granted." - It says MUST; therefore any server that doesn't do this is = non-compliant? - It says scope different from the one requested by the *client*. The = possibility that the resource owner intercepts this request and changes = it doesn't seem to be considered here (it is not strictly the clients = request if that happens) - The purpose seems to be that the client should be told if the scope = changes; this would be important if the client requires a certain scope = level to work (though this could be solved more generally in many other = ways that wouldn't be in the scope of the oauth spec) Thus, assuming that the server is stating compliance, isn't the = assumption completely warranted? > The only way for a client to know if a token has a scope it to try it, = or use a introspection endpoint. End of story. An introspection endpoint obviously isn't part of the specification, so = isn't relevant to the discussion (though it solves the discussed = facebook issue). You are right though, that the only way for a client to know for sure is = to try to use it; Even if the spec mandated always returning the scope = to the client, the user could always intercept the return redirection = (assuming a non-confidential client) and change the scope there. Perhaps MUST should change to SHOULD, given that this essentially seems = unenforceable?= --Apple-Mail=_3927AAEB-3EA0-4F81-8722-383A14BB9A45 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJPRBthAAoJEB3emUU2Pi+ANr4P/AmLQcbB9Sl6+3lWIwtvhAj6 dGICwg9sEu8NwqXwirQIcteYs09oQDH8+NVfLOnlRcZ3NmesJbVb97lybHdY5PrJ v+jFGAedrafKLAoPaWtQnTibmCbFjofHkam0td1qV6lTiqn+8aKvTMP+Jdo3HnVG xA2rIEDiWIBGUqC8GhSRPFh/WtG2M0ExASx7EQyM0qpqK3z1qRUjXfYW2Q5eBqrF F7VLMocWueFkrWsQgUCx0602nImQACA4uK24iUSSk22RMhQ8faKMNsmkQhSR0HDT IoxfI5Pr9bs4YMvji/1Sug12/LmYyq2nH/Hs6H5nvtTCLsnpWMAxh6w8vcrnTvNe 0nHRaLLWeGpJwI1g8DQLA6P6sQ5gkzzuxo1P7WMGz4bccnqB7XiP/PFPvIbU/1Va OYS+iUbVsKmroAiKlxfVD5Nqh2DbVl3WtycVempmz0sxKG/r9W29McLnJ/jpMhnX sW34CsAtotOsD1oOWexvPTVZjpoOnWfN+CFcdKCY6m5LJw3+XUyQ8KMKG5CKGq1W Xriki5Bv6W1Puvd3rgs2T5N/1ZlaRs0ne20FRgBnwUlCyIz2NJuvlbY+wjzKRYzR qVLiTexdy+Age4faHECrN/hDGasDC+1n9PVRFAP5hCGJTC7eATgJlMFuChQcgI4t Zz6j9z7f5+6ZwIqDUgTZ =uXR8 -----END PGP SIGNATURE----- --Apple-Mail=_3927AAEB-3EA0-4F81-8722-383A14BB9A45-- From ve7jtb@ve7jtb.com Tue Feb 21 15:02:05 2012 Return-Path: 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 296D611E8116 for ; Tue, 21 Feb 2012 15:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 eAXlQtVqEgjt for ; Tue, 21 Feb 2012 15:02:04 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5148921F86A6 for ; Tue, 21 Feb 2012 15:02:04 -0800 (PST) Received: by yhkk25 with SMTP id k25so3646570yhk.31 for ; Tue, 21 Feb 2012 15:02:03 -0800 (PST) Received-SPF: pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.92.201 as permitted sender) client-ip=10.236.92.201; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.92.201 as permitted sender) smtp.mail=ve7jtb@ve7jtb.com Received: from mr.google.com ([10.236.92.201]) by 10.236.92.201 with SMTP id j49mr39307912yhf.60.1329865323971 (num_hops = 1); Tue, 21 Feb 2012 15:02:03 -0800 (PST) Received: by 10.236.92.201 with SMTP id j49mr30565578yhf.60.1329865323811; Tue, 21 Feb 2012 15:02:03 -0800 (PST) Received: from [192.168.1.213] ([190.22.73.49]) by mx.google.com with ESMTPS id y12sm34085123ang.21.2012.02.21.15.02.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 15:02:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_7185D2B1-09AE-435E-9442-F7F0E94AF6E4"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> Date: Tue, 21 Feb 2012 20:01:42 -0300 Message-Id: <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.com> References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> To: Nicholas Devenish X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkVvvQYMBsDAQshmdNLqAXEI/TtjJlRgDMUthGr4DVy98gDKGLA/IsgdgxhsXwI5unT2w4u Cc: "Lee, David" , Wenjie Lin , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 23:02:05 -0000 --Apple-Mail=_7185D2B1-09AE-435E-9442-F7F0E94AF6E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote: >=20 > On 21 Feb 2012, at 21:59, John Bradley wrote: >> This 'attack' is one that only works with badly designed clients = that are making unwarranted assumptions about the behaviour of the = Authorization server. =20 >=20 > Unwarranted assumptions? The spec in 3.3 says: >=20 > "If the issued access token scope is different from the one requested = by the client, the authorization server MUST include the "scope" = response parameter to inform the client of the actual scope granted." >=20 > - It says MUST; therefore any server that doesn't do this is = non-compliant? > - It says scope different from the one requested by the *client*. The = possibility that the resource owner intercepts this request and changes = it doesn't seem to be considered here (it is not strictly the clients = request if that happens) > - The purpose seems to be that the client should be told if the scope = changes; this would be important if the client requires a certain scope = level to work (though this could be solved more generally in many other = ways that wouldn't be in the scope of the oauth spec) >=20 > Thus, assuming that the server is stating compliance, isn't the = assumption completely warranted? No the authorization server may at any time for any reason remove a = scope from a granted access_token or refresh_token. =20 Reporting back changes in scopes granted along with the access_token is = a convenience not a security feature. =20 Assuming it is a security feature and those scopes will continue to be = valid for the token after granting is a bad design given the OAuth 2 = spec. >=20 >> The only way for a client to know if a token has a scope it to try = it, or use a introspection endpoint. End of story. >=20 > An introspection endpoint obviously isn't part of the specification, = so isn't relevant to the discussion (though it solves the discussed = facebook issue). >=20 > You are right though, that the only way for a client to know for sure = is to try to use it; Even if the spec mandated always returning the = scope to the client, the user could always intercept the return = redirection (assuming a non-confidential client) and change the scope = there. >=20 > Perhaps MUST should change to SHOULD, given that this essentially = seems unenforceable? A SHOULD may lead people to the conclusion that it is secure. I am = happy with saying it is not secure the only want to know is to have the = client be prepared to deal with tokens that do not contain the desired = scope when used. That is the only 100% solution. John B. --Apple-Mail=_7185D2B1-09AE-435E-9442-F7F0E94AF6E4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MjEyMzAxNDJaMCMGCSqGSIb3DQEJBDEWBBR4z1b02JF1LZN3mG2sdTSXWi/H1jCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQDBcDpFKXmFwTARxCJMa7OzeXwpUQmqGNiaUxuOU51bicbXrQTu1jYvz/v7zDmNYlRShlYOv0TH bJv6WE1Gi/DJwVuK7a0NDKHXtFKHmNJnStd9Hm2iX1DAIvHvMDn0cky1oa6u5fGkGqrCCQpK4ces zQAJF3U1G3Jx2W5vtEaj3yyWpAO52/lET93FYE4SE+wWTK7KFvTuTjAR6uj/IeA7HeuGLBkzJTEj DhcHwPuHrHrSzEixSwYBXxuQ7F8V9X0oxQl/H2viSIbfUQqF/6ADfgwCN7KY96GibMBt+xevcuxy /bOm/HHfK+ver25U4lufRsk4N7K3gp0WuJyn6n8HAAAAAAAA --Apple-Mail=_7185D2B1-09AE-435E-9442-F7F0E94AF6E4-- From andredemarre@gmail.com Tue Feb 21 16:38:47 2012 Return-Path: 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 5F56721F86F2 for ; Tue, 21 Feb 2012 16:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.883 X-Spam-Level: X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 0N88zBUVE2IQ for ; Tue, 21 Feb 2012 16:38:46 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94DD221F8645 for ; Tue, 21 Feb 2012 16:38:46 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so8291380pbc.31 for ; Tue, 21 Feb 2012 16:38:46 -0800 (PST) Received-SPF: pass (google.com: domain of andredemarre@gmail.com designates 10.68.233.74 as permitted sender) client-ip=10.68.233.74; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andredemarre@gmail.com designates 10.68.233.74 as permitted sender) smtp.mail=andredemarre@gmail.com; dkim=pass header.i=andredemarre@gmail.com Received: from mr.google.com ([10.68.233.74]) by 10.68.233.74 with SMTP id tu10mr81133016pbc.98.1329871126481 (num_hops = 1); Tue, 21 Feb 2012 16:38:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DFKv/vqHfg+fQgNB771WT76Nmiu76Yb5BKAC3cpT7dA=; b=H9SwRbwkMYIEPKf20LSlVkfyJXIYglM60Ir01+do4ueJt4OhOF7h9FdgGDN3pfpkAa VBOK+lC0rMv6O3UCI2Tky6yREO8VU4vof9pkG6caeTSySYw0+B+RVaJFenM2cLkSmf8Y on9oNOse4QPSgjEgU6Vsf2Y0/EMT9RMd8rqm4= MIME-Version: 1.0 Received: by 10.68.233.74 with SMTP id tu10mr66710703pbc.98.1329871126415; Tue, 21 Feb 2012 16:38:46 -0800 (PST) Received: by 10.68.25.193 with HTTP; Tue, 21 Feb 2012 16:38:46 -0800 (PST) In-Reply-To: <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.com> References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.com> Date: Tue, 21 Feb 2012 16:38:46 -0800 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Lee, David" , Wenjie Lin , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 00:38:47 -0000 The consensus seems to be, and I agree, that this shouldn't be considered an "attack," but that's really just nomenclature. I do concede that there is a spec issue here that I failed to appreciate at first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the issued access token scope is different from the one requested by the client," it suggests that the authorization server knows what was requested by the client. That isn't strictly true; it only knows what was in the authorization request, not who put it there. For the client to truly know what the auth server wants, (1) it would need to communicate directly with the client, (2) the client would need to preregister its desired scope, or (3) the client would need to sign a message that the user passes to the authorization endpoint. 1 and 3 are clearly not compatible with the spec, 2 might be; but that's not the point. A more correct statement in section 3.3 would be "If the issued access token scope is different from the one in the authorization request..." Regards, Andre DeMarre On Tue, Feb 21, 2012 at 3:01 PM, John Bradley wrote: > > On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote: > >> >> On 21 Feb 2012, at 21:59, John Bradley wrote: >>> This 'attack' =A0is one that only works with badly designed clients tha= t are making unwarranted assumptions about the behaviour of the Authorizati= on server. >> >> Unwarranted assumptions? The spec in 3.3 says: >> >> "If the issued access token scope is different from the one requested by= the client, the authorization server MUST include the "scope" response par= ameter to inform the client of the actual scope granted." >> >> - It says MUST; therefore any server that doesn't do this is non-complia= nt? >> - It says scope different from the one requested by the *client*. The po= ssibility that the resource owner intercepts this request and changes it do= esn't seem to be considered here (it is not strictly the clients request if= that happens) >> - The purpose seems to be that the client should be told if the scope ch= anges; this would be important if the client requires a certain scope level= to work (though this could be solved more generally in many other ways tha= t wouldn't be in the scope of the oauth spec) >> >> Thus, assuming that the server is stating compliance, isn't the assumpti= on completely warranted? > > No the authorization server may at any time for any reason remove a scope= from a granted access_token or refresh_token. > > Reporting back changes in scopes granted along with the access_token is a= convenience not a security feature. > > Assuming it is a security feature and those scopes will continue to be va= lid for the token after granting is a bad design given the OAuth 2 spec. >> >>> The only way for a client to know if a token has a scope it to try it, = or use a introspection endpoint. =A0End of story. >> >> An introspection endpoint obviously isn't part of the specification, so = isn't relevant to the discussion (though it solves the discussed facebook i= ssue). >> >> You are right though, that the only way for a client to know for sure is= to try to use it; Even if the spec mandated always returning the scope to = the client, the user could always intercept the return redirection (assumin= g a non-confidential client) and change the scope there. >> >> Perhaps MUST should change to SHOULD, given that this essentially seems = unenforceable? > > A SHOULD may lead people to the conclusion that it is secure. =A0 I am ha= ppy with saying it is not secure the only want to know is to have the clien= t be prepared to deal with tokens that do not contain the desired scope whe= n used. =A0 That is the only 100% solution. > > John B. > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From andredemarre@gmail.com Tue Feb 21 16:50:07 2012 Return-Path: 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 E642821E8048 for ; Tue, 21 Feb 2012 16:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 Zue4lpuK-rtQ for ; Tue, 21 Feb 2012 16:50:07 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 37DBE21E801E for ; Tue, 21 Feb 2012 16:50:07 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so8300506pbc.31 for ; Tue, 21 Feb 2012 16:50:07 -0800 (PST) Received-SPF: pass (google.com: domain of andredemarre@gmail.com designates 10.68.136.201 as permitted sender) client-ip=10.68.136.201; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andredemarre@gmail.com designates 10.68.136.201 as permitted sender) smtp.mail=andredemarre@gmail.com; dkim=pass header.i=andredemarre@gmail.com Received: from mr.google.com ([10.68.136.201]) by 10.68.136.201 with SMTP id qc9mr73958314pbb.161.1329871807118 (num_hops = 1); Tue, 21 Feb 2012 16:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=NGKGchsa3cY1yW2HD47wFz4YcPXjeGn2+mx//SoTUpg=; b=W358oKG34LvZy9pxUjUfxFzeGD1+boxHGMRCEUnDWZ1fVLJU1zhpi6G2wmpmoC1Sc0 BKz0ZBEILtlghO2KkxnAdS2JaUk52Ja2qwakyCULmoMr2b6RdJOR9BPEin/cympdQwb4 nEaIlCyqzyoKsdW0qygmHHo4WVhe9ZaBVBU9U= MIME-Version: 1.0 Received: by 10.68.136.201 with SMTP id qc9mr61284076pbb.161.1329871806983; Tue, 21 Feb 2012 16:50:06 -0800 (PST) Received: by 10.68.25.193 with HTTP; Tue, 21 Feb 2012 16:50:06 -0800 (PST) In-Reply-To: References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.com> Date: Tue, 21 Feb 2012 16:50:06 -0800 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: John Bradley , Nicholas Devenish , "Lee, David" , Wenjie Lin , "oauth@ietf.org (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 00:50:08 -0000 FWIW, it could be that the authorization request was authored by neither the client nor the user. An unrelated fourth party can construct an authorization endpoint URL using a client_id that isn't his own and send a user there. This wasn't possible in OAuth 1 because of how it used request tokens. Regards, Andre DeMarre On Tue, Feb 21, 2012 at 4:38 PM, Andr=E9 DeMarre w= rote: > The consensus seems to be, and I agree, that this shouldn't be > considered an "attack," but that's really just nomenclature. I do > concede that there is a spec issue here that I failed to appreciate at > first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the issued > access token scope is different from the one requested by the client," > it suggests that the authorization server knows what was requested by > the client. That isn't strictly true; it only knows what was in the > authorization request, not who put it there. For the client to truly > know what the auth server wants, (1) it would need to communicate > directly with the client, (2) the client would need to preregister its > desired scope, or (3) the client would need to sign a message that the > user passes to the authorization endpoint. 1 and 3 are clearly not > compatible with the spec, 2 might be; but that's not the point. > > A more correct statement in section 3.3 would be "If the issued access > token scope is different from the one in the authorization request..." > > Regards, > Andre DeMarre > > On Tue, Feb 21, 2012 at 3:01 PM, John Bradley wrote: >> >> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote: >> >>> >>> On 21 Feb 2012, at 21:59, John Bradley wrote: >>>> This 'attack' =A0is one that only works with badly designed clients th= at are making unwarranted assumptions about the behaviour of the Authorizat= ion server. >>> >>> Unwarranted assumptions? The spec in 3.3 says: >>> >>> "If the issued access token scope is different from the one requested b= y the client, the authorization server MUST include the "scope" response pa= rameter to inform the client of the actual scope granted." >>> >>> - It says MUST; therefore any server that doesn't do this is non-compli= ant? >>> - It says scope different from the one requested by the *client*. The p= ossibility that the resource owner intercepts this request and changes it d= oesn't seem to be considered here (it is not strictly the clients request i= f that happens) >>> - The purpose seems to be that the client should be told if the scope c= hanges; this would be important if the client requires a certain scope leve= l to work (though this could be solved more generally in many other ways th= at wouldn't be in the scope of the oauth spec) >>> >>> Thus, assuming that the server is stating compliance, isn't the assumpt= ion completely warranted? >> >> No the authorization server may at any time for any reason remove a scop= e from a granted access_token or refresh_token. >> >> Reporting back changes in scopes granted along with the access_token is = a convenience not a security feature. >> >> Assuming it is a security feature and those scopes will continue to be v= alid for the token after granting is a bad design given the OAuth 2 spec. >>> >>>> The only way for a client to know if a token has a scope it to try it,= or use a introspection endpoint. =A0End of story. >>> >>> An introspection endpoint obviously isn't part of the specification, so= isn't relevant to the discussion (though it solves the discussed facebook = issue). >>> >>> You are right though, that the only way for a client to know for sure i= s to try to use it; Even if the spec mandated always returning the scope to= the client, the user could always intercept the return redirection (assumi= ng a non-confidential client) and change the scope there. >>> >>> Perhaps MUST should change to SHOULD, given that this essentially seems= unenforceable? >> >> A SHOULD may lead people to the conclusion that it is secure. =A0 I am h= appy with saying it is not secure the only want to know is to have the clie= nt be prepared to deal with tokens that do not contain the desired scope wh= en used. =A0 That is the only 100% solution. >> >> John B. >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> From ve7jtb@ve7jtb.com Tue Feb 21 16:59:41 2012 Return-Path: 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 0F1A521E801E for ; Tue, 21 Feb 2012 16:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.361 X-Spam-Level: X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 ncD3LK6K3L0a for ; Tue, 21 Feb 2012 16:59:36 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 944C521E804F for ; Tue, 21 Feb 2012 16:59:34 -0800 (PST) Received: by yhkk25 with SMTP id k25so3675748yhk.31 for ; Tue, 21 Feb 2012 16:59:34 -0800 (PST) Received-SPF: pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.175.162 as permitted sender) client-ip=10.236.175.162; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.175.162 as permitted sender) smtp.mail=ve7jtb@ve7jtb.com Received: from mr.google.com ([10.236.175.162]) by 10.236.175.162 with SMTP id z22mr40533635yhl.119.1329872374029 (num_hops = 1); Tue, 21 Feb 2012 16:59:34 -0800 (PST) Received: by 10.236.175.162 with SMTP id z22mr31669798yhl.119.1329872373939; Tue, 21 Feb 2012 16:59:33 -0800 (PST) Received: from [192.168.1.213] ([190.22.73.49]) by mx.google.com with ESMTPS id h21sm22079492ann.1.2012.02.21.16.59.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 16:59:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_B832CB48-6EAA-468D-A5E5-70C09872120F"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Tue, 21 Feb 2012 21:59:25 -0300 Message-Id: References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.com> To: =?iso-8859-1?Q?Andr=E9_DeMarre?= X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlefwcngjtPRIPRpJRLjnQKtzq6nFBkVs1ucBuk7wzWhPRQaigSHoquEcQzXOyXjGai7Dac Cc: "Lee, David" , Wenjie Lin , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 00:59:41 -0000 --Apple-Mail=_B832CB48-6EAA-468D-A5E5-70C09872120F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yes, OpenID Connect deals with the issue by using a signed request = extension in the cases where the client needs to be certain the request = is only from the legitimate client and not tampered with. As you observe anyone can send a request the client_id and redirect_uri = are not secret in any way. =20 Though a well behaved client should be using state to check for XSRF = attacks. (that is a real attack) Signed requests have uses, but are not core to OAuth.=20 John B. On 2012-02-21, at 9:38 PM, Andr=E9 DeMarre wrote: > The consensus seems to be, and I agree, that this shouldn't be > considered an "attack," but that's really just nomenclature. I do > concede that there is a spec issue here that I failed to appreciate at > first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the issued > access token scope is different from the one requested by the client," > it suggests that the authorization server knows what was requested by > the client. That isn't strictly true; it only knows what was in the > authorization request, not who put it there. For the client to truly > know what the auth server wants, (1) it would need to communicate > directly with the client, (2) the client would need to preregister its > desired scope, or (3) the client would need to sign a message that the > user passes to the authorization endpoint. 1 and 3 are clearly not > compatible with the spec, 2 might be; but that's not the point. >=20 > A more correct statement in section 3.3 would be "If the issued access > token scope is different from the one in the authorization request..." >=20 > Regards, > Andre DeMarre >=20 > On Tue, Feb 21, 2012 at 3:01 PM, John Bradley = wrote: >>=20 >> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote: >>=20 >>>=20 >>> On 21 Feb 2012, at 21:59, John Bradley wrote: >>>> This 'attack' is one that only works with badly designed clients = that are making unwarranted assumptions about the behaviour of the = Authorization server. >>>=20 >>> Unwarranted assumptions? The spec in 3.3 says: >>>=20 >>> "If the issued access token scope is different from the one = requested by the client, the authorization server MUST include the = "scope" response parameter to inform the client of the actual scope = granted." >>>=20 >>> - It says MUST; therefore any server that doesn't do this is = non-compliant? >>> - It says scope different from the one requested by the *client*. = The possibility that the resource owner intercepts this request and = changes it doesn't seem to be considered here (it is not strictly the = clients request if that happens) >>> - The purpose seems to be that the client should be told if the = scope changes; this would be important if the client requires a certain = scope level to work (though this could be solved more generally in many = other ways that wouldn't be in the scope of the oauth spec) >>>=20 >>> Thus, assuming that the server is stating compliance, isn't the = assumption completely warranted? >>=20 >> No the authorization server may at any time for any reason remove a = scope from a granted access_token or refresh_token. >>=20 >> Reporting back changes in scopes granted along with the access_token = is a convenience not a security feature. >>=20 >> Assuming it is a security feature and those scopes will continue to = be valid for the token after granting is a bad design given the OAuth 2 = spec. >>>=20 >>>> The only way for a client to know if a token has a scope it to try = it, or use a introspection endpoint. End of story. >>>=20 >>> An introspection endpoint obviously isn't part of the specification, = so isn't relevant to the discussion (though it solves the discussed = facebook issue). >>>=20 >>> You are right though, that the only way for a client to know for = sure is to try to use it; Even if the spec mandated always returning the = scope to the client, the user could always intercept the return = redirection (assuming a non-confidential client) and change the scope = there. >>>=20 >>> Perhaps MUST should change to SHOULD, given that this essentially = seems unenforceable? >>=20 >> A SHOULD may lead people to the conclusion that it is secure. I am = happy with saying it is not secure the only want to know is to have the = client be prepared to deal with tokens that do not contain the desired = scope when used. That is the only 100% solution. >>=20 >> John B. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 --Apple-Mail=_B832CB48-6EAA-468D-A5E5-70C09872120F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MjIwMDU5MjZaMCMGCSqGSIb3DQEJBDEWBBRvaeJXsr0yyxLdDCYfeCSieskpFTCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQA9I4HKYSEi4gk40aR9Xuq9iDaVR5HCrBe9DLwUCroTCr/zyH1LXVc2IZZ8K/KyprvZB3HrjPpJ kBWsXoK0lSe27qKw4cjgO2Jqd+oMRvIs2xinKTPuIqVpZahuxTtEGjIb/LmzEmLzldtQ81nezcsa ucNvyNkbkGmTRlKp1vm0jPoA0qzL07Y5m0EntD0Hp1VrGNI28C0pDdOblfR057u2+s3l2t0d+uTI ODRIRsC5dTX4YPLpbX2eRMV8QpZmqeK5eLx8FF5Z0iW5PHqiyDtdTA5bM5agPLygaQnIpP+76gJl OK+i2y9Imsps1s2//hvmS4EcTjUyhrwpARafwtIQAAAAAAAA --Apple-Mail=_B832CB48-6EAA-468D-A5E5-70C09872120F-- From peter.wolanin@acquia.com Tue Feb 21 17:34:20 2012 Return-Path: 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 7E9BD21E8016 for ; Tue, 21 Feb 2012 17:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.827 X-Spam-Level: X-Spam-Status: No, score=-4.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] 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 X7Xvq5imY0Tb for ; Tue, 21 Feb 2012 17:34:20 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with SMTP id 0BC5C21E800C for ; Tue, 21 Feb 2012 17:34:10 -0800 (PST) Received: from mail-lpp01m010-f43.google.com ([209.85.215.43]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT0RGEvZGTxeYGoXpdOgkwAFAfNJjzLFf@postini.com; Tue, 21 Feb 2012 17:34:11 PST Received: by lagp5 with SMTP id p5so15368218lag.16 for ; Tue, 21 Feb 2012 17:34:09 -0800 (PST) Received-SPF: pass (google.com: domain of peter.wolanin@acquia.com designates 10.152.134.200 as permitted sender) client-ip=10.152.134.200; Authentication-Results: mr.google.com; spf=pass (google.com: domain of peter.wolanin@acquia.com designates 10.152.134.200 as permitted sender) smtp.mail=peter.wolanin@acquia.com Received: from mr.google.com ([10.152.134.200]) by 10.152.134.200 with SMTP id pm8mr21138740lab.34.1329874448998 (num_hops = 1); Tue, 21 Feb 2012 17:34:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.134.200 with SMTP id pm8mr17696933lab.34.1329874448840; Tue, 21 Feb 2012 17:34:08 -0800 (PST) Received: by 10.152.8.229 with HTTP; Tue, 21 Feb 2012 17:34:08 -0800 (PST) In-Reply-To: <4F412E76.6080408@lodderstedt.net> References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> <4F412E76.6080408@lodderstedt.net> Date: Tue, 21 Feb 2012 20:34:08 -0500 Message-ID: From: Peter Wolanin To: Torsten Lodderstedt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk5RYMFuMcCHbRseMDSv0N/1o1ro7udBF+xGLfUQyrKXbuzw2RZ8A7b4lwnMEUKvJ7sYCeY Cc: Tim Bray , S Moonesamy , apps-discuss@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 01:34:20 -0000 Looking at this document, I don't see much discussion of the risk due to a tampered response except possibly 5.1.2. For example, injection of spam or phishing links into search results. Given the known issues with CA issuers, and the fact that some transactions may be carried out over non-SSL channels, can you include some discussion of the use of HMAC signing of the response body or other tactics for assuring the client that they received the genuine response from the server? -Peter On Sun, Feb 19, 2012 at 12:16 PM, Torsten Lodderstedt wrote: > > Hi Tim, > > I just submitted the revised version of the OAuth 2.0 security document (= http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-02). This revisi= on should address the issues you raised in your AppsDir review. We especial= ly removed all normative language from the document. > > We took the liberty to leave the back references in Section 5. We conside= r this back references to section 4 a valuable information for implementors= since they justify the particular countermeasure. All to often security co= nsiderations are given without the corresponding rationales. And without a = justification, the "unconvinced" implementor may tend to ignore or underest= imate the respective controls. > > > regards, > Torsten. > > Am 23.01.2012 22:47, schrieb S Moonesamy: >> >> The following is the AppsDir review performed by Tim Bray. =C2=A0It woul= d be appreciated if a reply is sent to Tim Bray with a copy to the apps-dis= cuss mailing list. >> >> >> I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on appsdir, please see >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorat= e). >> >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-oauth-v2-threatmodel-01 >> Title: =C2=A0OAuth 2.0 Threat Model and Security Considerations >> Reviewer: Tim Bray >> Review Date: =C2=A0Jan 23, 2012 >> >> Summary: This needs some more editorial work, but is basically sound. >> It's not clear, though, whether it wants to be an Informational RFC or >> not; the use of RFC2119 language needs special attention. =C2=A0I think = a >> few of the "minor issues" are worthy of a little bit more work in >> another draft. >> >> Major Issues: >> >> The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. =C2= =A0I >> normally wouldn't expect a "threat model" to include normative text. >> The basic idea would be to say "Here is an enumeration of the threats, >> and here are the tools available to OAUTH2 implementors to meet them." >> =C2=A0I was impressed by the enumeration, which seemed very complete and >> well thought through. But the usage of 2119, which makes statements >> normative, seems inconsistent. =C2=A0I can think of 2 ways to address th= is: >> >> 1. Remove all the 2119 words, so this document isn't normative, and >> publish it as an Informational RFC >> 2. Go through and clean up the 2119 language so it's used >> consistently; then this becomes a normative document. >> >> This is going to affect the references to this document from other >> I-Ds in the OAuth suite, which are currently in last call. >> >> Here are all the section-numbered notes enumerating my issues around >> 2119, as I encountered them: >> >> Section 2.3, I'm a little confused about the use of RFC2119 MAY in a >> threat analysis. =C2=A0When you say "The following data elements MAY be >> stored or accessible...", Is this saying that "The OAuth2 RFC says >> that the following data elements MAY be..." or is it saying something >> else. I don't think there's anything seriously wrong here, but a bit >> more explanation might be in order. =C2=A0I note a comparative absence o= f >> 2119-ese in section 5 describing countermeasures, where one would >> expect to find it. >> Also in 4.3.1, first bullet point, there's "Authorization servers MUST..= ." >> Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 >> Related: "SHALL"?! in 4.6.3 >> Adding to the concern, there is use of lower-case "must"; note 2nd & >> 3rd bullet points in 4.4.3, which use "MUST" and "must" respectively. >> >> Minor Issues: >> >> 4.1.2 first attack: It says "An attack may obtain the refresh tokens >> issued to a web server client." This needs to be clearer... a "Web >> server client" can be a browser or a native app. =C2=A0Do you mean, "the >> refresh tokens issued by the web server to multiple clients?" >> >> 4.1.2 last attack. =C2=A0In the case where a device is cloned, wouldn't >> "Utilize device lock to prevent unauthorized device access" still be a >> countermeasure? =C2=A0In many devices, such cloning would carry along th= e >> user's device-lock settings. >> >> 4.4.1.4 2nd bullet. =C2=A0The explanation of why this wouldn't work for >> native clients wasn't comprehensible to me. =C2=A0I'm suspicious of any >> such claims because I can emulate most things a browser can do in a >> mobile client. =C2=A0Perhaps this would be obvious to someone who is an >> OAuth2 implementor. >> >> 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a >> Web Browser control embedded in the native app. =C2=A0If that's not what= it >> means, I don't understand what it's saying. =C2=A0If this is true, then = the >> second bullet point is probably wrong. >> >> 4.6.6 1st bullet. =C2=A0I'm not convinced that the Cache-Control header >> will *ensure* that a client protects information properly. =C2=A0Should = say >> something like "minimize the risk that authenticated content is not >> protected" >> >> 5.* The enumeration, for some but not all of the countermeasures in >> this section, of the threats against which this is a countermeasure, >> reduces readability and, unless it's generated automatically from the >> underlying source, is redundant information, which is unlikely to be >> consistent between sections 4 and 5, and adds difficulty to >> maintenance of this document without adding much value. =C2=A0I'd just w= ipe >> all these bullet lists out. =C2=A0If it's generated automatically it's l= ess >> damaging, but still reduces readability. =C2=A0In the current draft, thi= s >> is there for some countermeasures but absent for others. =C2=A0Another g= ood >> reason to just take it out. >> >> 5.2.2.5 Device identifiers are very tricky. =C2=A0It's correct that IMEI= is >> not adequate, but there are ways to do it without SMS. =C2=A0For more, s= ee >> http://android-developers.blogspot.com/2011/03/identifying-app-installat= ions.html >> >> 5.3.4 Surely a little more could be said about device lock. =C2=A0On a >> typical modern phone, "device lock" options include PINs, passwords, >> "face recognition" and so on. =C2=A0These are *not* equal in their level= of >> security they provide. >> >> Nits: >> >> Formatting is lousy. =C2=A0There are notations, including ** and _whatev= er_ >> that I'm not familiar with in the RFC context. >> >> Section 1.0: s/in-built into/built into/ >> 2.1, last bullet point: "An example could by a..." s/by/be/ >> 2.2, 1st bullet point s/eaves drop/eavesdrop/ >> 2.3, 1st para, s/treat/threat/ >> 2.3.1, last bullet, "per authorization process". =C2=A0Adjectival phrase= s >> should be hyphenated: "per-authorization process" >> 2.3.3, last bullet, ditto >> 3.1, 1st para, "all kinds of tokens" should be "many kinds of tokens" >> 3.1, 2nd para, should be ; not , after "within the authorization server" >> =C2=A0 =C2=A0 =C2=A0s/protected/protect/ >> =C2=A0 =C2=A0 =C2=A0s/different system/different systems/ >> 3.4 1st para, s/intermediary/intermediate/ >> =C2=A0 =C2=A0 =C2=A0list item 1. s/short-living/short-lived/ >> 3.5 s/malicious client/malicious clients/ >> 3.7 top of page 12, what is the underscore notation _client_id_ mean? >> I'm not familiar with this in the RFC context. >> =C2=A01st bullet point: s/token/token's/ >> =C2=A02nd bullet point, multiple issues, 1st sentence should be " the >> initial authorization and issuance of a token by an end-user >> =C2=A0 =C2=A0 to a particular client, and subsequent requests by this cl= ient to >> =C2=A0 =C2=A0 obtain tokens without user consent (automatic processing o= f repeated >> =C2=A0 =C2=A0 authorization) >> =C2=A0halfway down page 13, s/insures/ensures/ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s/validates the clients/valida= tes the client's/ >> 4. first sentence, s/this sections/this section/ >> 4.1.2 first para, the last sentence is confusing. How about: "Before >> enumerating the threats, here are some generally applicable >> countermeasures:" >> 4.2.4 2nd bullet s/could not be/can not be/ >> 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests" - I >> assume that's supposed to be a hyperlink to one of the 5.* sections? >> 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that the >> referrer header may contain an Authorization code in a ?a=3Db style >> argument >> 4.4.1.2 first bullet, "can be employed" is inconsistent with style of >> rest of doc >> 4.4.1.3 first 2 bullets have un-labeled links. >> 4.4.1.4 1st bullet s/authentication/authenticate/ >> 4.4.1.4 2nd bullet s/mean/means/ >> 4.4.1.7 2nd bullet s/tokens/token's/ >> 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ >> 4.4.1.10, 3rd bullet, s/aibility/ability/ >> 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ >> 4.4.1.12 I think the href to semicomplete.com needs to be turned into >> an IETF-style reference >> 4.4.2 " since HTTP user agents do not send fragments server requests." >> What you mean to say is "Since HTTP user agents do not send the >> fragment part of URIs to HTTP servers." >> 4.4.2.2 s/browser/browser's/ >> 5.1.4.1.3 s/consider to not store/refrain from storing/ >> 5.* s/may consider to $(verb)/may consider $(verb)ing/ >> 5.1.6 Needs some sort of sentence structure >> 5.3.2 Needs some sort of sentence structure; or is this intended just >> to be a title, with 5.3.3 etc nested under it? >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Peter M. Wolanin, Ph.D. =C2=A0 =C2=A0 =C2=A0: Momentum Specialist,=C2=A0 Ac= quia. Inc. peter.wolanin@acquia.com : 781-313-8322 "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com" From mark.mcgloin@ie.ibm.com Wed Feb 22 07:07:55 2012 Return-Path: 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 AD85521F8811 for ; Wed, 22 Feb 2012 07:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.138 X-Spam-Level: X-Spam-Status: No, score=-1.138 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, MANGLED_LIST=2.3] 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 kzOw+2L9w4EN for ; Wed, 22 Feb 2012 07:07:51 -0800 (PST) Received: from e06smtp16.uk.ibm.com (e06smtp16.uk.ibm.com [195.75.94.112]) by ietfa.amsl.com (Postfix) with ESMTP id 24F2721F8829 for ; Wed, 22 Feb 2012 07:07:45 -0800 (PST) Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 22 Feb 2012 14:57:34 -0000 Received: from d06nrmr1806.portsmouth.uk.ibm.com (9.149.39.193) by e06smtp16.uk.ibm.com (192.168.101.146) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 22 Feb 2012 14:57:03 -0000 Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1MEv2Sw2093300; Wed, 22 Feb 2012 14:57:02 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1MEv26V016565; Wed, 22 Feb 2012 07:57:02 -0700 Received: from d06ml091.portsmouth.uk.ibm.com (d06ml091.portsmouth.uk.ibm.com [9.149.104.170]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1MEv2gJ016561; Wed, 22 Feb 2012 07:57:02 -0700 In-Reply-To: References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> <4F412E76.6080408@lodderstedt.net> X-KeepSent: FE613B8D:4E554796-802579AC:00506D73; type=4; name=$KeepSent To: Peter Wolanin X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Wed, 22 Feb 2012 14:56:56 +0000 X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 22/02/2012 14:56:56 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable x-cbid: 12022214-3548-0000-0000-0000011EAAA2 Cc: oauth-bounces@ietf.org, apps-discuss@ietf.org, S Moonesamy , Tim Bray , oauth@ietf.org Subject: Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 15:07:55 -0000 Hi Peter The core oauth spec states that TLS MUST be used wherever tokens or passwords are being transmitted, except for the redirection_url but it = does recommend it use TLS in section 3.1.2.1 and explicitly states why. Regards Mark oauth-bounces@ietf.org wrote on 22/02/2012 01:34:08: > From: > > Peter Wolanin > > To: > > Torsten Lodderstedt > > Cc: > > Tim Bray , S Moonesamy , > apps-discuss@ietf.org, oauth@ietf.org > > Date: > > 22/02/2012 01:34 > > Subject: > > Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth- > v2-threatmodel-01 > > Sent by: > > oauth-bounces@ietf.org > > Looking at this document, I don't see much discussion of the risk due= > to a tampered response except possibly 5.1.2. For example, injection= > of spam or phishing links into search results. > > Given the known issues with CA issuers, and the fact that some > transactions may be carried out over non-SSL channels, can you includ= e > some discussion of the use of HMAC signing of the response body or > other tactics for assuring the client that they received the genuine > response from the server? > > -Peter > > > On Sun, Feb 19, 2012 at 12:16 PM, Torsten Lodderstedt > wrote: > > > > Hi Tim, > > > > I just submitted the revised version of the OAuth 2.0 security docu= ment ( > http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-02). This > revision should address the issues you raised in your AppsDir > review. We especially removed all normative language from the documen= t. > > > > We took the liberty to leave the back references in Section 5. We > consider this back references to section 4 a valuable information > for implementors since they justify the particular countermeasure. > All to often security considerations are given without the > corresponding rationales. And without a justification, the > "unconvinced" implementor may tend to ignore or underestimate the > respective controls. > > > > > > regards, > > Torsten. > > > > Am 23.01.2012 22:47, schrieb S Moonesamy: > >> > >> The following is the AppsDir review performed by Tim Bray. =A0It > would be appreciated if a reply is sent to Tim Bray with a copy to > the apps-discuss mailing list. > >> > >> > >> I have been selected as the Applications Area Directorate reviewer= for > >> this draft (for background on appsdir, please see > >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectora= te). > >> > >> Please resolve these comments along with any other Last Call comme= nts > >> you may receive. Please wait for direction from your document shep= herd > >> or AD before posting a new version of the draft. > >> > >> Document: draft-ietf-oauth-v2-threatmodel-01 > >> Title: =A0OAuth 2.0 Threat Model and Security Considerations > >> Reviewer: Tim Bray > >> Review Date: =A0Jan 23, 2012 > >> > >> Summary: This needs some more editorial work, but is basically sou= nd. > >> It's not clear, though, whether it wants to be an Informational RF= C or > >> not; the use of RFC2119 language needs special attention. =A0I thi= nk a > >> few of the "minor issues" are worthy of a little bit more work in > >> another draft. > >> > >> Major Issues: > >> > >> The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through= . =A0I > >> normally wouldn't expect a "threat model" to include normative tex= t. > >> The basic idea would be to say "Here is an enumeration of the thre= ats, > >> and here are the tools available to OAUTH2 implementors to meet th= em." > >> =A0I was impressed by the enumeration, which seemed very complete = and > >> well thought through. But the usage of 2119, which makes statement= s > >> normative, seems inconsistent. =A0I can think of 2 ways to address= this: > >> > >> 1. Remove all the 2119 words, so this document isn't normative, an= d > >> publish it as an Informational RFC > >> 2. Go through and clean up the 2119 language so it's used > >> consistently; then this becomes a normative document. > >> > >> This is going to affect the references to this document from other= > >> I-Ds in the OAuth suite, which are currently in last call. > >> > >> Here are all the section-numbered notes enumerating my issues arou= nd > >> 2119, as I encountered them: > >> > >> Section 2.3, I'm a little confused about the use of RFC2119 MAY in= a > >> threat analysis. =A0When you say "The following data elements MAY = be > >> stored or accessible...", Is this saying that "The OAuth2 RFC says= > >> that the following data elements MAY be..." or is it saying someth= ing > >> else. I don't think there's anything seriously wrong here, but a b= it > >> more explanation might be in order. =A0I note a comparative absenc= e of > >> 2119-ese in section 5 describing countermeasures, where one would > >> expect to find it. > >> Also in 4.3.1, first bullet point, there's "Authorization servers MUST..." > >> Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 > >> Related: "SHALL"?! in 4.6.3 > >> Adding to the concern, there is use of lower-case "must"; note 2nd= & > >> 3rd bullet points in 4.4.3, which use "MUST" and "must" respective= ly. > >> > >> Minor Issues: > >> > >> 4.1.2 first attack: It says "An attack may obtain the refresh toke= ns > >> issued to a web server client." This needs to be clearer... a "Web= > >> server client" can be a browser or a native app. =A0Do you mean, "= the > >> refresh tokens issued by the web server to multiple clients?" > >> > >> 4.1.2 last attack. =A0In the case where a device is cloned, wouldn= 't > >> "Utilize device lock to prevent unauthorized device access" still = be a > >> countermeasure? =A0In many devices, such cloning would carry along= the > >> user's device-lock settings. > >> > >> 4.4.1.4 2nd bullet. =A0The explanation of why this wouldn't work f= or > >> native clients wasn't comprehensible to me. =A0I'm suspicious of a= ny > >> such claims because I can emulate most things a browser can do in = a > >> mobile client. =A0Perhaps this would be obvious to someone who is = an > >> OAuth2 implementor. > >> > >> 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.= e. a > >> Web Browser control embedded in the native app. =A0If that's not w= hat it > >> means, I don't understand what it's saying. =A0If this is true, th= en the > >> second bullet point is probably wrong. > >> > >> 4.6.6 1st bullet. =A0I'm not convinced that the Cache-Control head= er > >> will *ensure* that a client protects information properly. =A0Shou= ld say > >> something like "minimize the risk that authenticated content is no= t > >> protected" > >> > >> 5.* The enumeration, for some but not all of the countermeasures i= n > >> this section, of the threats against which this is a countermeasur= e, > >> reduces readability and, unless it's generated automatically from = the > >> underlying source, is redundant information, which is unlikely to = be > >> consistent between sections 4 and 5, and adds difficulty to > >> maintenance of this document without adding much value. =A0I'd jus= t wipe > >> all these bullet lists out. =A0If it's generated automatically it'= s less > >> damaging, but still reduces readability. =A0In the current draft, = this > >> is there for some countermeasures but absent for others. =A0Anothe= r good > >> reason to just take it out. > >> > >> 5.2.2.5 Device identifiers are very tricky. =A0It's correct that I= MEI is > >> not adequate, but there are ways to do it without SMS. =A0For more= , see > >> http://android-developers.blogspot.com/2011/03/identifying-app- > installations.html > >> > >> 5.3.4 Surely a little more could be said about device lock. =A0On = a > >> typical modern phone, "device lock" options include PINs, password= s, > >> "face recognition" and so on. =A0These are *not* equal in their le= vel of > >> security they provide. > >> > >> Nits: > >> > >> Formatting is lousy. =A0There are notations, including ** and _wha= tever_ > >> that I'm not familiar with in the RFC context. > >> > >> Section 1.0: s/in-built into/built into/ > >> 2.1, last bullet point: "An example could by a..." s/by/be/ > >> 2.2, 1st bullet point s/eaves drop/eavesdrop/ > >> 2.3, 1st para, s/treat/threat/ > >> 2.3.1, last bullet, "per authorization process". =A0Adjectival phr= ases > >> should be hyphenated: "per-authorization process" > >> 2.3.3, last bullet, ditto > >> 3.1, 1st para, "all kinds of tokens" should be "many kinds of toke= ns" > >> 3.1, 2nd para, should be ; not , after "within the authorization server" > >> =A0 =A0 =A0s/protected/protect/ > >> =A0 =A0 =A0s/different system/different systems/ > >> 3.4 1st para, s/intermediary/intermediate/ > >> =A0 =A0 =A0list item 1. s/short-living/short-lived/ > >> 3.5 s/malicious client/malicious clients/ > >> 3.7 top of page 12, what is the underscore notation _client_id_ me= an? > >> I'm not familiar with this in the RFC context. > >> =A01st bullet point: s/token/token's/ > >> =A02nd bullet point, multiple issues, 1st sentence should be " the= > >> initial authorization and issuance of a token by an end-user > >> =A0 =A0 to a particular client, and subsequent requests by this cl= ient to > >> =A0 =A0 obtain tokens without user consent (automatic processing o= f repeated > >> =A0 =A0 authorization) > >> =A0halfway down page 13, s/insures/ensures/ > >> =A0 =A0 =A0 =A0 =A0 =A0 s/validates the clients/validates the clie= nt's/ > >> 4. first sentence, s/this sections/this section/ > >> 4.1.2 first para, the last sentence is confusing. How about: "Befo= re > >> enumerating the threats, here are some generally applicable > >> countermeasures:" > >> 4.2.4 2nd bullet s/could not be/can not be/ > >> 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests"= - I > >> assume that's supposed to be a hyperlink to one of the 5.* section= s? > >> 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that = the > >> referrer header may contain an Authorization code in a ?a=3Db styl= e > >> argument > >> 4.4.1.2 first bullet, "can be employed" is inconsistent with style= of > >> rest of doc > >> 4.4.1.3 first 2 bullets have un-labeled links. > >> 4.4.1.4 1st bullet s/authentication/authenticate/ > >> 4.4.1.4 2nd bullet s/mean/means/ > >> 4.4.1.7 2nd bullet s/tokens/token's/ > >> 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ > >> 4.4.1.10, 3rd bullet, s/aibility/ability/ > >> 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ > >> 4.4.1.12 I think the href to semicomplete.com needs to be turned i= nto > >> an IETF-style reference > >> 4.4.2 " since HTTP user agents do not send fragments server reques= ts." > >> What you mean to say is "Since HTTP user agents do not send the > >> fragment part of URIs to HTTP servers." > >> 4.4.2.2 s/browser/browser's/ > >> 5.1.4.1.3 s/consider to not store/refrain from storing/ > >> 5.* s/may consider to $(verb)/may consider $(verb)ing/ > >> 5.1.6 Needs some sort of sentence structure > >> 5.3.2 Needs some sort of sentence structure; or is this intended j= ust > >> to be a title, with 5.3.3 etc nested under it? > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Peter M. Wolanin, Ph.D. =A0 =A0 =A0: Momentum Specialist,=A0 Acquia. = Inc. > peter.wolanin@acquia.com : 781-313-8322 > > "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com" > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth= From wenjielin.bupt@gmail.com Thu Feb 23 15:55:37 2012 Return-Path: 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 F1EFD21F885C for ; Thu, 23 Feb 2012 15:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.706 X-Spam-Level: X-Spam-Status: No, score=-2.706 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 bnuk1E8feBfF for ; Thu, 23 Feb 2012 15:55:35 -0800 (PST) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id A739B21F884A for ; Thu, 23 Feb 2012 15:55:35 -0800 (PST) Received: by iaeo4 with SMTP id o4so3728864iae.27 for ; Thu, 23 Feb 2012 15:55:35 -0800 (PST) Received-SPF: pass (google.com: domain of wenjielin.bupt@gmail.com designates 10.42.177.133 as permitted sender) client-ip=10.42.177.133; Authentication-Results: mr.google.com; spf=pass (google.com: domain of wenjielin.bupt@gmail.com designates 10.42.177.133 as permitted sender) smtp.mail=wenjielin.bupt@gmail.com; dkim=pass header.i=wenjielin.bupt@gmail.com Received: from mr.google.com ([10.42.177.133]) by 10.42.177.133 with SMTP id bi5mr4824373icb.40.1330041335397 (num_hops = 1); Thu, 23 Feb 2012 15:55:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=eyR/NU7SkDSTuEmSn8kxkIss02wPPW/mEcmjxNS35W8=; b=m+zO5Mf/rZ/+YFpsuSQbYNv+C3bzUz1l65zVbr6PvPK9KXuf9cHlbsyytcy6FkL8HK trOkeXtnqm0Jwot7TnKyLQempWE98Opn3rjrrU511j+JkPkw3cf43JJVIR4ISTlE/mPC 15/UGXJoyq95zT0C8YtZ8RCvgzKIWw/KpjZ7c= Received: by 10.42.177.133 with SMTP id bi5mr4041489icb.40.1330041335272; Thu, 23 Feb 2012 15:55:35 -0800 (PST) MIME-Version: 1.0 Sender: wenjielin.bupt@gmail.com Received: by 10.42.139.138 with HTTP; Thu, 23 Feb 2012 15:55:14 -0800 (PST) In-Reply-To: References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.com> From: Wenjie Lin Date: Thu, 23 Feb 2012 15:55:14 -0800 X-Google-Sender-Auth: qAC1Oh1K93qNwXK47eKnZgvDeKA Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=90e6ba6e86dc5356bd04b9aa6102 Cc: "Lee, David" , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 23:55:37 -0000 --90e6ba6e86dc5356bd04b9aa6102 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We assume that the authorization server is trustworthy and won=92t do anything that violates the spec. We want to prevent attacks by the client on the user, as well as the attacks by the user on the client.**** The scope attack is by the user on the client. From the point view of the user it is not an attack. However, the client takes it as an attack; the user violates the service agreement by the client who may have no knowledge about it, unless the authorization server always sends him the authorized scope information when granting an access token, as we've proposed, and the client can figure out the difference/violation and decide how to deal with it.**** ** ** When the client identifies the difference between his specified scope and that in the access token, he can choose to abort or continue the service, or take other actions. This is an implementation issue and is beyond the scope of OAuth. There are other possible anomalies from implementations, such as revocation of the scope by the user. However, they are not well specified in the current spec and we take them as an implementation rather than a protocol issue.**** ** ** There might be applications where the client would not perceive scope attack as an attack if he could allow any changes of the service agreement scope by the user. If OAuth were aimed for such clients only, it would significantly limit the applicability of the protocol. We appreciate the insightful discussions on how the client could check and handle the scope differences and beyond. They are extremely helpful for the implementers. -W. Lin and D. Lee On Tue, Feb 21, 2012 at 4:59 PM, John Bradley wrote: > Yes, OpenID Connect deals with the issue by using a signed request > extension in the cases where the client needs to be certain the request i= s > only from the legitimate client and not tampered with. > > As you observe anyone can send a request the client_id and redirect_uri > are not secret in any way. > > Though a well behaved client should be using state to check for XSRF > attacks. (that is a real attack) > > Signed requests have uses, but are not core to OAuth. > > John B. > On 2012-02-21, at 9:38 PM, Andr=E9 DeMarre wrote: > > > The consensus seems to be, and I agree, that this shouldn't be > > considered an "attack," but that's really just nomenclature. I do > > concede that there is a spec issue here that I failed to appreciate at > > first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the issued > > access token scope is different from the one requested by the client," > > it suggests that the authorization server knows what was requested by > > the client. That isn't strictly true; it only knows what was in the > > authorization request, not who put it there. For the client to truly > > know what the auth server wants, (1) it would need to communicate > > directly with the client, (2) the client would need to preregister its > > desired scope, or (3) the client would need to sign a message that the > > user passes to the authorization endpoint. 1 and 3 are clearly not > > compatible with the spec, 2 might be; but that's not the point. > > > > A more correct statement in section 3.3 would be "If the issued access > > token scope is different from the one in the authorization request..." > > > > Regards, > > Andre DeMarre > > > > On Tue, Feb 21, 2012 at 3:01 PM, John Bradley wrote= : > >> > >> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote: > >> > >>> > >>> On 21 Feb 2012, at 21:59, John Bradley wrote: > >>>> This 'attack' is one that only works with badly designed clients > that are making unwarranted assumptions about the behaviour of the > Authorization server. > >>> > >>> Unwarranted assumptions? The spec in 3.3 says: > >>> > >>> "If the issued access token scope is different from the one requested > by the client, the authorization server MUST include the "scope" response > parameter to inform the client of the actual scope granted." > >>> > >>> - It says MUST; therefore any server that doesn't do this is > non-compliant? > >>> - It says scope different from the one requested by the *client*. The > possibility that the resource owner intercepts this request and changes i= t > doesn't seem to be considered here (it is not strictly the clients reques= t > if that happens) > >>> - The purpose seems to be that the client should be told if the scope > changes; this would be important if the client requires a certain scope > level to work (though this could be solved more generally in many other > ways that wouldn't be in the scope of the oauth spec) > >>> > >>> Thus, assuming that the server is stating compliance, isn't the > assumption completely warranted? > >> > >> No the authorization server may at any time for any reason remove a > scope from a granted access_token or refresh_token. > >> > >> Reporting back changes in scopes granted along with the access_token i= s > a convenience not a security feature. > >> > >> Assuming it is a security feature and those scopes will continue to be > valid for the token after granting is a bad design given the OAuth 2 spec= . > >>> > >>>> The only way for a client to know if a token has a scope it to try > it, or use a introspection endpoint. End of story. > >>> > >>> An introspection endpoint obviously isn't part of the specification, > so isn't relevant to the discussion (though it solves the discussed > facebook issue). > >>> > >>> You are right though, that the only way for a client to know for sure > is to try to use it; Even if the spec mandated always returning the scope > to the client, the user could always intercept the return redirection > (assuming a non-confidential client) and change the scope there. > >>> > >>> Perhaps MUST should change to SHOULD, given that this essentially > seems unenforceable? > >> > >> A SHOULD may lead people to the conclusion that it is secure. I am > happy with saying it is not secure the only want to know is to have the > client be prepared to deal with tokens that do not contain the desired > scope when used. That is the only 100% solution. > >> > >> John B. > >> > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > --=20 Wenjie Lin --90e6ba6e86dc5356bd04b9aa6102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

We assume that the authorization server is trustworthy and won=92t do anyth= ing that violates the spec. We want to prevent attacks by the client on the= user, as well as the attacks by the user on the client.


The scope attack is by the user on the cli= ent. From the point view of the user it is not an attack. However, the clie= nt takes it as an attack; the user violates the service agreement by the cl= ient who may have no knowledge about it, unless the authorization server al= ways sends him the authorized scope information when granting an access tok= en, as we've proposed, and the client can figure out the difference/vio= lation and decide how to deal with it.

=A0

When the client identifies the difference between his specified scope and t= hat in the access token, he can choose to abort or continue the service, or= take other actions. This is an implementation issue and is beyond the scop= e of OAuth.=A0There are other possible anomalies from implementations, such as revocatio= n of the scope by the user. However, they are not well specified in the cur= rent spec and we take them as an implementation rather than a protocol issu= e.

=A0

Ther= e might be applications where the client would not perceive scope attack as= an attack if he could allow any changes of the service agreement scope by = the user. If OAuth were aimed for such clients only, it would significantly= limit the applicability of the protocol.=A0

We appreciate the insightful discussions on how the client could check = and handle the scope differences and beyond. They are extremely helpful for= the implementers.


-W. Lin and D. Lee


On Tue, Feb 21, 2012 at 4:59 PM, John Bradley <ve7j= tb@ve7jtb.com> wrote:
Yes, =A0OpenID Connect deals with the issue = by using a signed request extension in the cases where the client needs to = be certain the request is only from the legitimate client and not tampered = with.

As you observe anyone can send a request the client_id and redirect_uri are= not secret in any way.

Though a well behaved client should be using state to check for XSRF attack= s. (that is a real attack)

Signed requests have uses, =A0but are not core to OAuth.

John B.
On 2012-02-21, at 9:38 PM, Andr=E9 DeMarre wrote:

> The consensus seems to be, and I agree, that this shouldn't be
> considered an "attack," but that's really just nomenclat= ure. I do
> concede that there is a spec issue here that I failed to appreciate at=
> first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the issu= ed
> access token scope is different from the one requested by the client,&= quot;
> it suggests that the authorization server knows what was requested by<= br> > the client. That isn't strictly true; it only knows what was in th= e
> authorization request, not who put it there. For the client to truly > know what the auth server wants, (1) it would need to communicate
> directly with the client, (2) the client would need to preregister its=
> desired scope, or (3) the client would need to sign a message that the=
> user passes to the authorization endpoint. 1 and 3 are clearly not
> compatible with the spec, 2 might be; but that's not the point. >
> A more correct statement in section 3.3 would be "If the issued a= ccess
> token scope is different from the one in the authorization request...&= quot;
>
> Regards,
> Andre DeMarre
>
> On Tue, Feb 21, 2012 at 3:01 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>
>> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote:
>>
>>>
>>> On 21 Feb 2012, at 21:59, John Bradley wrote:
>>>> This 'attack' =A0is one that only works with badly= designed clients that are making unwarranted assumptions about the behavio= ur of the Authorization server.
>>>
>>> Unwarranted assumptions? The spec in 3.3 says:
>>>
>>> "If the issued access token scope is different from the o= ne requested by the client, the authorization server MUST include the "= ;scope" response parameter to inform the client of the actual scope gr= anted."
>>>
>>> - It says MUST; therefore any server that doesn't do this = is non-compliant?
>>> - It says scope different from the one requested by the *clien= t*. The possibility that the resource owner intercepts this request and cha= nges it doesn't seem to be considered here (it is not strictly the clie= nts request if that happens)
>>> - The purpose seems to be that the client should be told if th= e scope changes; this would be important if the client requires a certain s= cope level to work (though this could be solved more generally in many othe= r ways that wouldn't be in the scope of the oauth spec)
>>>
>>> Thus, assuming that the server is stating compliance, isn'= t the assumption completely warranted?
>>
>> No the authorization server may at any time for any reason remove = a scope from a granted access_token or refresh_token.
>>
>> Reporting back changes in scopes granted along with the access_tok= en is a convenience not a security feature.
>>
>> Assuming it is a security feature and those scopes will continue t= o be valid for the token after granting is a bad design given the OAuth 2 s= pec.
>>>
>>>> The only way for a client to know if a token has a scope i= t to try it, or use a introspection endpoint. =A0End of story.
>>>
>>> An introspection endpoint obviously isn't part of the spec= ification, so isn't relevant to the discussion (though it solves the di= scussed facebook issue).
>>>
>>> You are right though, that the only way for a client to know f= or sure is to try to use it; Even if the spec mandated always returning the= scope to the client, the user could always intercept the return redirectio= n (assuming a non-confidential client) and change the scope there.
>>>
>>> Perhaps MUST should change to SHOULD, given that this essentia= lly seems unenforceable?
>>
>> A SHOULD may lead people to the conclusion that it is secure. =A0 = I am happy with saying it is not secure the only want to know is to have th= e client be prepared to deal with tokens that do not contain the desired sc= ope when used. =A0 That is the only 100% solution.
>>
>> John B.
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>>




--
= Wenjie Lin
--90e6ba6e86dc5356bd04b9aa6102-- From phil.hunt@oracle.com Thu Feb 23 16:11:38 2012 Return-Path: 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 77D6A21F88E0 for ; Thu, 23 Feb 2012 16:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.423 X-Spam-Level: X-Spam-Status: No, score=-9.423 tagged_above=-999 required=5 tests=[AWL=1.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 nf+sr8xBOjh6 for ; Thu, 23 Feb 2012 16:11:04 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 95E4C21F88DB for ; Thu, 23 Feb 2012 16:11:00 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q1O0Ar5b020610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Feb 2012 00:10:54 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q1O0AqtF007533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2012 00:10:53 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q1O0Aqqq002109; Thu, 23 Feb 2012 18:10:52 -0600 Received: from dhcp-rmdc-twvpn-1-vpnpool-10-159-28-129.vpn.oracle.com (/10.159.28.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 23 Feb 2012 16:10:52 -0800 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_FE7AFCB3-05EF-45A7-BB8C-3A81CB5313DD" From: Phil Hunt In-Reply-To: Date: Thu, 23 Feb 2012 16:10:53 -0800 Message-Id: <6358D5C7-B8B3-4636-91CB-4685FC307EA1@oracle.com> References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.com> To: Wenjie Lin X-Mailer: Apple Mail (2.1251.1) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4F46D58E.005C,ss=1,re=-2.300,fgs=0 Cc: "Lee, David" , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 00:11:39 -0000 --Apple-Mail=_FE7AFCB3-05EF-45A7-BB8C-3A81CB5313DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I'm still not seeing how "user choice" can become an "attack" While a user might hack the request or a phishing attempt might generate = a link that requests an unusual scope combination, it shouldn't matter = since the authorization server should allow the user to decline specific = scopes if they want to / or the authorization server may choose to = override specific combinations of scope. The client has to be prepared to accept in all cases that it may not get = what it asks for. It may for example be entirely refused. If the client = doesn't get what it asked for then it can choose to generate an error to = the user. A common case is many apps will connect to social nets and request = "ReadProfile" and "UpdateStatus". Yet the user might not want to grant = "UpdateStatus". The client app has to handle this gracefully. Finally scope is a right granted to the client for access to a resource = -- not the other way around as your attack suggests. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-02-23, at 3:55 PM, Wenjie Lin wrote: > We assume that the authorization server is trustworthy and won=92t do = anything that violates the spec. We want to prevent attacks by the = client on the user, as well as the attacks by the user on the client. >=20 > The scope attack is by the user on the client. =46rom the point view = of the user it is not an attack. However, the client takes it as an = attack; the user violates the service agreement by the client who may = have no knowledge about it, unless the authorization server always sends = him the authorized scope information when granting an access token, as = we've proposed, and the client can figure out the difference/violation = and decide how to deal with it. > =20 > When the client identifies the difference between his specified scope = and that in the access token, he can choose to abort or continue the = service, or take other actions. This is an implementation issue and is = beyond the scope of OAuth. There are other possible anomalies from = implementations, such as revocation of the scope by the user. However, = they are not well specified in the current spec and we take them as an = implementation rather than a protocol issue. > =20 > There might be applications where the client would not perceive scope = attack as an attack if he could allow any changes of the service = agreement scope by the user. If OAuth were aimed for such clients only, = it would significantly limit the applicability of the protocol.=20 >=20 > We appreciate the insightful discussions on how the client could check = and handle the scope differences and beyond. They are extremely helpful = for the implementers. >=20 > -W. Lin and D. Lee >=20 > On Tue, Feb 21, 2012 at 4:59 PM, John Bradley = wrote: > Yes, OpenID Connect deals with the issue by using a signed request = extension in the cases where the client needs to be certain the request = is only from the legitimate client and not tampered with. >=20 > As you observe anyone can send a request the client_id and = redirect_uri are not secret in any way. >=20 > Though a well behaved client should be using state to check for XSRF = attacks. (that is a real attack) >=20 > Signed requests have uses, but are not core to OAuth. >=20 > John B. > On 2012-02-21, at 9:38 PM, Andr=E9 DeMarre wrote: >=20 > > The consensus seems to be, and I agree, that this shouldn't be > > considered an "attack," but that's really just nomenclature. I do > > concede that there is a spec issue here that I failed to appreciate = at > > first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the issued > > access token scope is different from the one requested by the = client," > > it suggests that the authorization server knows what was requested = by > > the client. That isn't strictly true; it only knows what was in the > > authorization request, not who put it there. For the client to truly > > know what the auth server wants, (1) it would need to communicate > > directly with the client, (2) the client would need to preregister = its > > desired scope, or (3) the client would need to sign a message that = the > > user passes to the authorization endpoint. 1 and 3 are clearly not > > compatible with the spec, 2 might be; but that's not the point. > > > > A more correct statement in section 3.3 would be "If the issued = access > > token scope is different from the one in the authorization = request..." > > > > Regards, > > Andre DeMarre > > > > On Tue, Feb 21, 2012 at 3:01 PM, John Bradley = wrote: > >> > >> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote: > >> > >>> > >>> On 21 Feb 2012, at 21:59, John Bradley wrote: > >>>> This 'attack' is one that only works with badly designed clients = that are making unwarranted assumptions about the behaviour of the = Authorization server. > >>> > >>> Unwarranted assumptions? The spec in 3.3 says: > >>> > >>> "If the issued access token scope is different from the one = requested by the client, the authorization server MUST include the = "scope" response parameter to inform the client of the actual scope = granted." > >>> > >>> - It says MUST; therefore any server that doesn't do this is = non-compliant? > >>> - It says scope different from the one requested by the *client*. = The possibility that the resource owner intercepts this request and = changes it doesn't seem to be considered here (it is not strictly the = clients request if that happens) > >>> - The purpose seems to be that the client should be told if the = scope changes; this would be important if the client requires a certain = scope level to work (though this could be solved more generally in many = other ways that wouldn't be in the scope of the oauth spec) > >>> > >>> Thus, assuming that the server is stating compliance, isn't the = assumption completely warranted? > >> > >> No the authorization server may at any time for any reason remove a = scope from a granted access_token or refresh_token. > >> > >> Reporting back changes in scopes granted along with the = access_token is a convenience not a security feature. > >> > >> Assuming it is a security feature and those scopes will continue to = be valid for the token after granting is a bad design given the OAuth 2 = spec. > >>> > >>>> The only way for a client to know if a token has a scope it to = try it, or use a introspection endpoint. End of story. > >>> > >>> An introspection endpoint obviously isn't part of the = specification, so isn't relevant to the discussion (though it solves the = discussed facebook issue). > >>> > >>> You are right though, that the only way for a client to know for = sure is to try to use it; Even if the spec mandated always returning the = scope to the client, the user could always intercept the return = redirection (assuming a non-confidential client) and change the scope = there. > >>> > >>> Perhaps MUST should change to SHOULD, given that this essentially = seems unenforceable? > >> > >> A SHOULD may lead people to the conclusion that it is secure. I = am happy with saying it is not secure the only want to know is to have = the client be prepared to deal with tokens that do not contain the = desired scope when used. That is the only 100% solution. > >> > >> John B. > >> > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> >=20 >=20 >=20 >=20 > --=20 > Wenjie Lin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_FE7AFCB3-05EF-45A7-BB8C-3A81CB5313DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I'm = still not seeing how "user choice" can become an = "attack"

While a user might hack the request or a = phishing attempt might generate a link that requests an unusual scope = combination, it shouldn't matter since the authorization server should = allow the user to decline specific scopes if they want to / or the = authorization server may choose to override specific combinations of = scope.

The client has to be prepared to accept = in all cases that it may not get what it asks for. It may for example be = entirely refused. If the client doesn't get what it asked for then it = can choose to generate an error to the user.

A = common case is many apps will connect to social nets and request = "ReadProfile" and "UpdateStatus". Yet the user might not want to grant = "UpdateStatus". The client app has to handle this = gracefully.

Finally scope is a right granted to = the client for access to a resource -- not the other way around as your = attack suggests.

Phil

On 2012-02-23, at 3:55 PM, Wenjie Lin wrote:

We assume that the authorization server is trustworthy and won=92t do = anything that violates the spec. We want to prevent attacks by the = client on the user, as well as the attacks by the user on the = client.

The scope attack is by the user on the = client. =46rom the point view of the user it is not an attack. However, = the client takes it as an attack; the user violates the service = agreement by the client who may have no knowledge about it, unless the = authorization server always sends him the authorized scope information = when granting an access token, as we've proposed, and the client can = figure out the difference/violation and decide how to deal with = it.
 
When the client identifies the difference between his specified scope = and that in the access token, he can choose to abort or continue the = service, or take other actions. This is an implementation issue and is = beyond the scope of OAuth. There are other = possible anomalies from implementations, such as revocation of the scope = by the user. However, they are not well specified in the current spec = and we take them as an implementation rather than a protocol = issue.
There might be applications = where the client would not perceive scope attack as an attack if he = could allow any changes of the service agreement scope by the user. If = OAuth were aimed for such clients only, it would significantly limit the = applicability of the protocol. 

We appreciate the insightful discussions on how the client could = check and handle the scope differences and beyond. They are extremely = helpful for the implementers.

-W. Lin and D. = Lee

On Tue, Feb 21, = 2012 at 4:59 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes,  OpenID = Connect deals with the issue by using a signed request extension in the = cases where the client needs to be certain the request is only from the = legitimate client and not tampered with.

As you observe anyone can send a request the client_id and redirect_uri = are not secret in any way.

Though a well behaved client should be using state to check for XSRF = attacks. (that is a real attack)

Signed requests have uses,  but are not core to OAuth.

John B.
On 2012-02-21, at 9:38 PM, Andr=E9 DeMarre wrote:

> The consensus seems to be, and I agree, that this shouldn't be
> considered an "attack," but that's really just nomenclature. I = do
> concede that there is a spec issue here that I failed to appreciate = at
> first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the = issued
> access token scope is different from the one requested by the = client,"
> it suggests that the authorization server knows what was requested = by
> the client. That isn't strictly true; it only knows what was in = the
> authorization request, not who put it there. For the client to = truly
> know what the auth server wants, (1) it would need to = communicate
> directly with the client, (2) the client would need to preregister = its
> desired scope, or (3) the client would need to sign a message that = the
> user passes to the authorization endpoint. 1 and 3 are clearly = not
> compatible with the spec, 2 might be; but that's not the point.
>
> A more correct statement in section 3.3 would be "If the issued = access
> token scope is different from the one in the authorization = request..."
>
> Regards,
> Andre DeMarre
>
> On Tue, Feb 21, 2012 at 3:01 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>
>> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote:
>>
>>>
>>> On 21 Feb 2012, at 21:59, John Bradley wrote:
>>>> This 'attack'  is one that only works with badly = designed clients that are making unwarranted assumptions about the = behaviour of the Authorization server.
>>>
>>> Unwarranted assumptions? The spec in 3.3 says:
>>>
>>> "If the issued access token scope is different from the one = requested by the client, the authorization server MUST include the = "scope" response parameter to inform the client of the actual scope = granted."
>>>
>>> - It says MUST; therefore any server that doesn't do this = is non-compliant?
>>> - It says scope different from the one requested by the = *client*. The possibility that the resource owner intercepts this = request and changes it doesn't seem to be considered here (it is not = strictly the clients request if that happens)
>>> - The purpose seems to be that the client should be told if = the scope changes; this would be important if the client requires a = certain scope level to work (though this could be solved more generally = in many other ways that wouldn't be in the scope of the oauth spec)
>>>
>>> Thus, assuming that the server is stating compliance, isn't = the assumption completely warranted?
>>
>> No the authorization server may at any time for any reason = remove a scope from a granted access_token or refresh_token.
>>
>> Reporting back changes in scopes granted along with the = access_token is a convenience not a security feature.
>>
>> Assuming it is a security feature and those scopes will = continue to be valid for the token after granting is a bad design given = the OAuth 2 spec.
>>>
>>>> The only way for a client to know if a token has a = scope it to try it, or use a introspection endpoint.  End of = story.
>>>
>>> An introspection endpoint obviously isn't part of the = specification, so isn't relevant to the discussion (though it solves the = discussed facebook issue).
>>>
>>> You are right though, that the only way for a client to = know for sure is to try to use it; Even if the spec mandated always = returning the scope to the client, the user could always intercept the = return redirection (assuming a non-confidential client) and change the = scope there.
>>>
>>> Perhaps MUST should change to SHOULD, given that this = essentially seems unenforceable?
>>
>> A SHOULD may lead people to the conclusion that it is secure. =   I am happy with saying it is not secure the only want to know is = to have the client be prepared to deal with tokens that do not contain = the desired scope when used.   That is the only 100% solution.
>>
>> John B.
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>




-- =
Wenjie Lin
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_FE7AFCB3-05EF-45A7-BB8C-3A81CB5313DD-- From kristoph@gmail.com Thu Feb 23 16:22:33 2012 Return-Path: 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 C9BBB21F88E2 for ; Thu, 23 Feb 2012 16:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 fzG33a2qK2XM for ; Thu, 23 Feb 2012 16:22:32 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0AF121F88E1 for ; Thu, 23 Feb 2012 16:22:32 -0800 (PST) Received: by dakl33 with SMTP id l33so1914652dak.31 for ; Thu, 23 Feb 2012 16:22:32 -0800 (PST) Received-SPF: pass (google.com: domain of kristoph@gmail.com designates 10.68.223.167 as permitted sender) client-ip=10.68.223.167; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kristoph@gmail.com designates 10.68.223.167 as permitted sender) smtp.mail=kristoph@gmail.com; dkim=pass header.i=kristoph@gmail.com Received: from mr.google.com ([10.68.223.167]) by 10.68.223.167 with SMTP id qv7mr645736pbc.139.1330042952653 (num_hops = 1); Thu, 23 Feb 2012 16:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=lyP70Qm7aryhDihUtdse7xtKeAH2psiVk27MMc5VwKM=; b=a3H9MfiPwn9LUdFvoQlk2cWbgrBn0p6YBuv1qg0hJuyl4S3ioM8uB0BMXuDUp++GOI FEyn0QaoRrRERhl461AVay4KjR3yxM1o4QQPsPq2U+dUAQ8+wnx0555ePHK2PU1ARPwJ bqgcUzviUqzGyL8tXCoHH0yhJxq4Y9LNgvPY0= Received: by 10.68.223.167 with SMTP id qv7mr539737pbc.139.1330042952583; Thu, 23 Feb 2012 16:22:32 -0800 (PST) Received: from [10.0.1.9] (c-50-132-71-89.hsd1.wa.comcast.net. [50.132.71.89]) by mx.google.com with ESMTPS id l1sm2770145pbs.34.2012.02.23.16.22.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Feb 2012 16:22:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Kristoph In-Reply-To: Date: Thu, 23 Feb 2012 16:22:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <34134676-9D51-4975-AD77-8AD34C3342B7@gmail.com> References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.com> To: Wenjie Lin X-Mailer: Apple Mail (2.1257) Cc: "Lee, David" , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 00:22:33 -0000 Privilege de-escalation is not an attack. Your argument comes down to "I = can change something and no error is shown so it's an attack" but you've = not actually shown any sort of negative consequence because, you know, = there isn't one.=20 ]{ On Feb 23, 2012, at 3:55 PM, Wenjie Lin wrote: > We assume that the authorization server is trustworthy and won=92t do = anything that violates the spec. We want to prevent attacks by the = client on the user, as well as the attacks by the user on the client. >=20 > The scope attack is by the user on the client. =46rom the point view = of the user it is not an attack. However, the client takes it as an = attack; the user violates the service agreement by the client who may = have no knowledge about it, unless the authorization server always sends = him the authorized scope information when granting an access token, as = we've proposed, and the client can figure out the difference/violation = and decide how to deal with it. > =20 > When the client identifies the difference between his specified scope = and that in the access token, he can choose to abort or continue the = service, or take other actions. This is an implementation issue and is = beyond the scope of OAuth. There are other possible anomalies from = implementations, such as revocation of the scope by the user. However, = they are not well specified in the current spec and we take them as an = implementation rather than a protocol issue. > =20 > There might be applications where the client would not perceive scope = attack as an attack if he could allow any changes of the service = agreement scope by the user. If OAuth were aimed for such clients only, = it would significantly limit the applicability of the protocol.=20 >=20 > We appreciate the insightful discussions on how the client could check = and handle the scope differences and beyond. They are extremely helpful = for the implementers. >=20 > -W. Lin and D. Lee >=20 > On Tue, Feb 21, 2012 at 4:59 PM, John Bradley = wrote: > Yes, OpenID Connect deals with the issue by using a signed request = extension in the cases where the client needs to be certain the request = is only from the legitimate client and not tampered with. >=20 > As you observe anyone can send a request the client_id and = redirect_uri are not secret in any way. >=20 > Though a well behaved client should be using state to check for XSRF = attacks. (that is a real attack) >=20 > Signed requests have uses, but are not core to OAuth. >=20 > John B. > On 2012-02-21, at 9:38 PM, Andr=E9 DeMarre wrote: >=20 > > The consensus seems to be, and I agree, that this shouldn't be > > considered an "attack," but that's really just nomenclature. I do > > concede that there is a spec issue here that I failed to appreciate = at > > first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the issued > > access token scope is different from the one requested by the = client," > > it suggests that the authorization server knows what was requested = by > > the client. That isn't strictly true; it only knows what was in the > > authorization request, not who put it there. For the client to truly > > know what the auth server wants, (1) it would need to communicate > > directly with the client, (2) the client would need to preregister = its > > desired scope, or (3) the client would need to sign a message that = the > > user passes to the authorization endpoint. 1 and 3 are clearly not > > compatible with the spec, 2 might be; but that's not the point. > > > > A more correct statement in section 3.3 would be "If the issued = access > > token scope is different from the one in the authorization = request..." > > > > Regards, > > Andre DeMarre > > > > On Tue, Feb 21, 2012 at 3:01 PM, John Bradley = wrote: > >> > >> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote: > >> > >>> > >>> On 21 Feb 2012, at 21:59, John Bradley wrote: > >>>> This 'attack' is one that only works with badly designed clients = that are making unwarranted assumptions about the behaviour of the = Authorization server. > >>> > >>> Unwarranted assumptions? The spec in 3.3 says: > >>> > >>> "If the issued access token scope is different from the one = requested by the client, the authorization server MUST include the = "scope" response parameter to inform the client of the actual scope = granted." > >>> > >>> - It says MUST; therefore any server that doesn't do this is = non-compliant? > >>> - It says scope different from the one requested by the *client*. = The possibility that the resource owner intercepts this request and = changes it doesn't seem to be considered here (it is not strictly the = clients request if that happens) > >>> - The purpose seems to be that the client should be told if the = scope changes; this would be important if the client requires a certain = scope level to work (though this could be solved more generally in many = other ways that wouldn't be in the scope of the oauth spec) > >>> > >>> Thus, assuming that the server is stating compliance, isn't the = assumption completely warranted? > >> > >> No the authorization server may at any time for any reason remove a = scope from a granted access_token or refresh_token. > >> > >> Reporting back changes in scopes granted along with the = access_token is a convenience not a security feature. > >> > >> Assuming it is a security feature and those scopes will continue to = be valid for the token after granting is a bad design given the OAuth 2 = spec. > >>> > >>>> The only way for a client to know if a token has a scope it to = try it, or use a introspection endpoint. End of story. > >>> > >>> An introspection endpoint obviously isn't part of the = specification, so isn't relevant to the discussion (though it solves the = discussed facebook issue). > >>> > >>> You are right though, that the only way for a client to know for = sure is to try to use it; Even if the spec mandated always returning the = scope to the client, the user could always intercept the return = redirection (assuming a non-confidential client) and change the scope = there. > >>> > >>> Perhaps MUST should change to SHOULD, given that this essentially = seems unenforceable? > >> > >> A SHOULD may lead people to the conclusion that it is secure. I = am happy with saying it is not secure the only want to know is to have = the client be prepared to deal with tokens that do not contain the = desired scope when used. That is the only 100% solution. > >> > >> John B. > >> > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> >=20 >=20 >=20 >=20 > --=20 > Wenjie Lin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wenjielin.bupt@gmail.com Thu Feb 23 17:02:54 2012 Return-Path: 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 6887D11E8096 for ; Thu, 23 Feb 2012 17:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 7rk-r7ER500X for ; Thu, 23 Feb 2012 17:02:52 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A931611E808E for ; Thu, 23 Feb 2012 17:02:52 -0800 (PST) Received: by iagf6 with SMTP id f6so2819239iag.31 for ; Thu, 23 Feb 2012 17:02:52 -0800 (PST) Received-SPF: pass (google.com: domain of wenjielin.bupt@gmail.com designates 10.50.154.200 as permitted sender) client-ip=10.50.154.200; Authentication-Results: mr.google.com; spf=pass (google.com: domain of wenjielin.bupt@gmail.com designates 10.50.154.200 as permitted sender) smtp.mail=wenjielin.bupt@gmail.com; dkim=pass header.i=wenjielin.bupt@gmail.com Received: from mr.google.com ([10.50.154.200]) by 10.50.154.200 with SMTP id vq8mr75805igb.14.1330045372461 (num_hops = 1); Thu, 23 Feb 2012 17:02:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=usYMtwRzgPhBE+QCP78egj75irXuyq1/+B/jmfzakdw=; b=eRJYRRLmQJTrtvIIg0uJe2dMQr52E+RGnSC7I9gcqxCjud9rdXLfTY3oGeEUEl3UG6 HoQejq4EG8MccPnoCeyCYzputA09N4cs0j+z5wDTMCMEaGL0ATHxBPScQOmZxSSjyrRW 5bUZu1PElxHviMQ8AhzyI8ndpt96JOaxR3dYs= Received: by 10.50.154.200 with SMTP id vq8mr64347igb.14.1330045372186; Thu, 23 Feb 2012 17:02:52 -0800 (PST) MIME-Version: 1.0 Sender: wenjielin.bupt@gmail.com Received: by 10.42.139.138 with HTTP; Thu, 23 Feb 2012 17:02:32 -0800 (PST) In-Reply-To: <34134676-9D51-4975-AD77-8AD34C3342B7@gmail.com> References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.com> <34134676-9D51-4975-AD77-8AD34C3342B7@gmail.com> From: Wenjie Lin Date: Thu, 23 Feb 2012 17:02:32 -0800 X-Google-Sender-Auth: 9dN_GF1_BJWOKek2LcWNuS-byDE Message-ID: To: Kristoph Content-Type: multipart/alternative; boundary=14dae9340821f1c0ac04b9ab5154 Cc: "Lee, David" , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 01:02:54 -0000 --14dae9340821f1c0ac04b9ab5154 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As we have shown in our Feb 17th email, the negative consequence is a violation by the user of the service agreement, that is, the user is able to play the game but the client cannot post messages on behalf of the user.= * *** *"Scope Attack* OAuth authorization of services is associated with service agreement scope. For instance, Client provides an online game to User with a service agreement scope* A:* *User authorizes Client to access his profile information and to post messages on his behalf*. A malicious User can request for online game with service agreement scope* A*, manipulate the scope field, and change it to scope* B*: *User authorizes Client to access his profile information*. User can still play the games, yet Client can=92= t post messages on User=92s behalf, as originally agreed." ** - W. Lin and D. Lee On Thu, Feb 23, 2012 at 4:22 PM, Kristoph wrote: > Privilege de-escalation is not an attack. Your argument comes down to "I > can change something and no error is shown so it's an attack" but you've > not actually shown any sort of negative consequence because, you know, > there isn't one. > > ]{ > > On Feb 23, 2012, at 3:55 PM, Wenjie Lin wrote: > > > We assume that the authorization server is trustworthy and won=92t do > anything that violates the spec. We want to prevent attacks by the client > on the user, as well as the attacks by the user on the client. > > > > The scope attack is by the user on the client. From the point view of > the user it is not an attack. However, the client takes it as an attack; > the user violates the service agreement by the client who may have no > knowledge about it, unless the authorization server always sends him the > authorized scope information when granting an access token, as we've > proposed, and the client can figure out the difference/violation and deci= de > how to deal with it. > > > > When the client identifies the difference between his specified scope > and that in the access token, he can choose to abort or continue the > service, or take other actions. This is an implementation issue and is > beyond the scope of OAuth. There are other possible anomalies from > implementations, such as revocation of the scope by the user. However, th= ey > are not well specified in the current spec and we take them as an > implementation rather than a protocol issue. > > > > There might be applications where the client would not perceive scope > attack as an attack if he could allow any changes of the service agreemen= t > scope by the user. If OAuth were aimed for such clients only, it would > significantly limit the applicability of the protocol. > > > > We appreciate the insightful discussions on how the client could check > and handle the scope differences and beyond. They are extremely helpful f= or > the implementers. > > > > -W. Lin and D. Lee > > > > On Tue, Feb 21, 2012 at 4:59 PM, John Bradley wrote= : > > Yes, OpenID Connect deals with the issue by using a signed request > extension in the cases where the client needs to be certain the request i= s > only from the legitimate client and not tampered with. > > > > As you observe anyone can send a request the client_id and redirect_uri > are not secret in any way. > > > > Though a well behaved client should be using state to check for XSRF > attacks. (that is a real attack) > > > > Signed requests have uses, but are not core to OAuth. > > > > John B. > > On 2012-02-21, at 9:38 PM, Andr=E9 DeMarre wrote: > > > > > The consensus seems to be, and I agree, that this shouldn't be > > > considered an "attack," but that's really just nomenclature. I do > > > concede that there is a spec issue here that I failed to appreciate a= t > > > first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the issued > > > access token scope is different from the one requested by the client,= " > > > it suggests that the authorization server knows what was requested by > > > the client. That isn't strictly true; it only knows what was in the > > > authorization request, not who put it there. For the client to truly > > > know what the auth server wants, (1) it would need to communicate > > > directly with the client, (2) the client would need to preregister it= s > > > desired scope, or (3) the client would need to sign a message that th= e > > > user passes to the authorization endpoint. 1 and 3 are clearly not > > > compatible with the spec, 2 might be; but that's not the point. > > > > > > A more correct statement in section 3.3 would be "If the issued acces= s > > > token scope is different from the one in the authorization request...= " > > > > > > Regards, > > > Andre DeMarre > > > > > > On Tue, Feb 21, 2012 at 3:01 PM, John Bradley > wrote: > > >> > > >> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote: > > >> > > >>> > > >>> On 21 Feb 2012, at 21:59, John Bradley wrote: > > >>>> This 'attack' is one that only works with badly designed clients > that are making unwarranted assumptions about the behaviour of the > Authorization server. > > >>> > > >>> Unwarranted assumptions? The spec in 3.3 says: > > >>> > > >>> "If the issued access token scope is different from the one > requested by the client, the authorization server MUST include the "scope= " > response parameter to inform the client of the actual scope granted." > > >>> > > >>> - It says MUST; therefore any server that doesn't do this is > non-compliant? > > >>> - It says scope different from the one requested by the *client*. > The possibility that the resource owner intercepts this request and chang= es > it doesn't seem to be considered here (it is not strictly the clients > request if that happens) > > >>> - The purpose seems to be that the client should be told if the > scope changes; this would be important if the client requires a certain > scope level to work (though this could be solved more generally in many > other ways that wouldn't be in the scope of the oauth spec) > > >>> > > >>> Thus, assuming that the server is stating compliance, isn't the > assumption completely warranted? > > >> > > >> No the authorization server may at any time for any reason remove a > scope from a granted access_token or refresh_token. > > >> > > >> Reporting back changes in scopes granted along with the access_token > is a convenience not a security feature. > > >> > > >> Assuming it is a security feature and those scopes will continue to > be valid for the token after granting is a bad design given the OAuth 2 > spec. > > >>> > > >>>> The only way for a client to know if a token has a scope it to try > it, or use a introspection endpoint. End of story. > > >>> > > >>> An introspection endpoint obviously isn't part of the specification= , > so isn't relevant to the discussion (though it solves the discussed > facebook issue). > > >>> > > >>> You are right though, that the only way for a client to know for > sure is to try to use it; Even if the spec mandated always returning the > scope to the client, the user could always intercept the return redirecti= on > (assuming a non-confidential client) and change the scope there. > > >>> > > >>> Perhaps MUST should change to SHOULD, given that this essentially > seems unenforceable? > > >> > > >> A SHOULD may lead people to the conclusion that it is secure. I am > happy with saying it is not secure the only want to know is to have the > client be prepared to deal with tokens that do not contain the desired > scope when used. That is the only 100% solution. > > >> > > >> John B. > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> OAuth mailing list > > >> OAuth@ietf.org > > >> https://www.ietf.org/mailman/listinfo/oauth > > >> > > > > > > > > > > -- > > Wenjie Lin > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Wenjie Lin --14dae9340821f1c0ac04b9ab5154 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

As we have shown in our Feb 17th email, the negative consequence is a viola= tion by the user of the service agreement, that is, the user is able to pla= y the game but the client cannot post messages on behalf of the user.


"Scope Attack

OAuth authorization of services is associated with service agreement scope.= For instance, Client provides an online game to User with a service agreem= ent scope=A0A:=A0User authorizes Client to access his profile inf= ormation and to post messages on his behalf. A malicious User can reque= st for online game with service agreement scope=A0A, manipulate the = scope field, and change it to scope=A0B:=A0User authorizes Client= to access his profile information. User can still play the games,=A0= =A0yet Client can=92t post messages on User=92s behalf, as originally agree= d."

=A0

- W. Lin and D. Lee


On Thu, Feb 23, 2012 at 4:22 PM, Kristoph <kristoph@gmail.com&g= t; wrote:
Privilege de-escalation is not an attack. Yo= ur argument comes down to "I can change something and no error is show= n so it's an attack" but you've not actually shown any sort of= negative consequence because, you know, there isn't one.

]{

On Feb 23, 2012, at 3:55 PM, Wenjie Lin wrote:

> We assume that the authorization server is trustworthy and won=92t do = anything that violates the spec. We want to prevent attacks by the client o= n the user, as well as the attacks by the user on the client.
>
> The scope attack is by the user on the client. From the point view of = the user it is not an attack. However, the client takes it as an attack; th= e user violates the service agreement by the client who may have no knowled= ge about it, unless the authorization server always sends him the authorize= d scope information when granting an access token, as we've proposed, a= nd the client can figure out the difference/violation and decide how to dea= l with it.
>
> When the client identifies the difference between his specified scope = and that in the access token, he can choose to abort or continue the servic= e, or take other actions. This is an implementation issue and is beyond the= scope of OAuth. There are other possible anomalies from implementations, s= uch as revocation of the scope by the user. However, they are not well spec= ified in the current spec and we take them as an implementation rather than= a protocol issue.
>
> There might be applications where the client would not perceive scope = attack as an attack if he could allow any changes of the service agreement = scope by the user. If OAuth were aimed for such clients only, it would sign= ificantly limit the applicability of the protocol.
>
> We appreciate the insightful discussions on how the client could check= and handle the scope differences and beyond. They are extremely helpful fo= r the implementers.
>
> -W. Lin and D. Lee
>
> On Tue, Feb 21, 2012 at 4:59 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> Yes, =A0OpenID Connect deals with the issue by using a signed request = extension in the cases where the client needs to be certain the request is = only from the legitimate client and not tampered with.
>
> As you observe anyone can send a request the client_id and redirect_ur= i are not secret in any way.
>
> Though a well behaved client should be using state to check for XSRF a= ttacks. (that is a real attack)
>
> Signed requests have uses, =A0but are not core to OAuth.
>
> John B.
> On 2012-02-21, at 9:38 PM, Andr=E9 DeMarre wrote:
>
> > The consensus seems to be, and I agree, that this shouldn't b= e
> > considered an "attack," but that's really just nome= nclature. I do
> > concede that there is a spec issue here that I failed to apprecia= te at
> > first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the= issued
> > access token scope is different from the one requested by the cli= ent,"
> > it suggests that the authorization server knows what was requeste= d by
> > the client. That isn't strictly true; it only knows what was = in the
> > authorization request, not who put it there. For the client to tr= uly
> > know what the auth server wants, (1) it would need to communicate=
> > directly with the client, (2) the client would need to preregiste= r its
> > desired scope, or (3) the client would need to sign a message tha= t the
> > user passes to the authorization endpoint. 1 and 3 are clearly no= t
> > compatible with the spec, 2 might be; but that's not the poin= t.
> >
> > A more correct statement in section 3.3 would be "If the iss= ued access
> > token scope is different from the one in the authorization reques= t..."
> >
> > Regards,
> > Andre DeMarre
> >
> > On Tue, Feb 21, 2012 at 3:01 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> >>
> >> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote:
> >>
> >>>
> >>> On 21 Feb 2012, at 21:59, John Bradley wrote:
> >>>> This 'attack' =A0is one that only works with = badly designed clients that are making unwarranted assumptions about the be= haviour of the Authorization server.
> >>>
> >>> Unwarranted assumptions? The spec in 3.3 says:
> >>>
> >>> "If the issued access token scope is different from = the one requested by the client, the authorization server MUST include the = "scope" response parameter to inform the client of the actual sco= pe granted."
> >>>
> >>> - It says MUST; therefore any server that doesn't do = this is non-compliant?
> >>> - It says scope different from the one requested by the *= client*. The possibility that the resource owner intercepts this request an= d changes it doesn't seem to be considered here (it is not strictly the= clients request if that happens)
> >>> - The purpose seems to be that the client should be told = if the scope changes; this would be important if the client requires a cert= ain scope level to work (though this could be solved more generally in many= other ways that wouldn't be in the scope of the oauth spec)
> >>>
> >>> Thus, assuming that the server is stating compliance, isn= 't the assumption completely warranted?
> >>
> >> No the authorization server may at any time for any reason re= move a scope from a granted access_token or refresh_token.
> >>
> >> Reporting back changes in scopes granted along with the acces= s_token is a convenience not a security feature.
> >>
> >> Assuming it is a security feature and those scopes will conti= nue to be valid for the token after granting is a bad design given the OAut= h 2 spec.
> >>>
> >>>> The only way for a client to know if a token has a sc= ope it to try it, or use a introspection endpoint. =A0End of story.
> >>>
> >>> An introspection endpoint obviously isn't part of the= specification, so isn't relevant to the discussion (though it solves t= he discussed facebook issue).
> >>>
> >>> You are right though, that the only way for a client to k= now for sure is to try to use it; Even if the spec mandated always returnin= g the scope to the client, the user could always intercept the return redir= ection (assuming a non-confidential client) and change the scope there.
> >>>
> >>> Perhaps MUST should change to SHOULD, given that this ess= entially seems unenforceable?
> >>
> >> A SHOULD may lead people to the conclusion that it is secure.= =A0 I am happy with saying it is not secure the only want to know is to ha= ve the client be prepared to deal with tokens that do not contain the desir= ed scope when used. =A0 That is the only 100% solution.
> >>
> >> John B.
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
>
>
>
>
> --
> Wenjie Lin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
= Wenjie Lin
--14dae9340821f1c0ac04b9ab5154-- From misnomer@gmail.com Thu Feb 23 17:12:33 2012 Return-Path: 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 C7E5911E808A for ; Thu, 23 Feb 2012 17:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 1W3ojnDwlYip for ; Thu, 23 Feb 2012 17:12:32 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D43BD11E80A2 for ; Thu, 23 Feb 2012 17:12:30 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so1152185wgb.13 for ; Thu, 23 Feb 2012 17:12:30 -0800 (PST) Received-SPF: pass (google.com: domain of misnomer@gmail.com designates 10.180.101.72 as permitted sender) client-ip=10.180.101.72; Authentication-Results: mr.google.com; spf=pass (google.com: domain of misnomer@gmail.com designates 10.180.101.72 as permitted sender) smtp.mail=misnomer@gmail.com; dkim=pass header.i=misnomer@gmail.com Received: from mr.google.com ([10.180.101.72]) by 10.180.101.72 with SMTP id fe8mr241990wib.4.1330045950100 (num_hops = 1); Thu, 23 Feb 2012 17:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=6fX/Fe7Ymra65zDE9nFlzTMyHFLiu9yDm+9vEqwlMGI=; b=nrFt5/Nl2TFhurRC9Yu8Np+ExHdyczvixQBSoXkRACIGKKt38BkAdJ5kzgR3dgFwok QYWEcTsdwYdGFNZ64UNncwlvlP1Uwa+qxnSHymgVH5Ss4Z2AJcNrRnBTbdz0V56920Z1 Szk09YGu7YjEjQ6QUyVP+1lxTLPuBM8CSXea8= Received: by 10.180.101.72 with SMTP id fe8mr199905wib.4.1330045950032; Thu, 23 Feb 2012 17:12:30 -0800 (PST) Received: from [192.168.0.2] (94-193-236-71.zone7.bethere.co.uk. [94.193.236.71]) by mx.google.com with ESMTPS id s8sm234309wiz.8.2012.02.23.17.12.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Feb 2012 17:12:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Nicholas Devenish In-Reply-To: Date: Fri, 24 Feb 2012 01:12:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1CA65248-D1AE-415D-85CD-E0E116D84A4B@gmail.com> References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.com> <34134676-9D51-4975-AD77-8AD34C3342B7@gmail.com> To: Wenjie Lin X-Mailer: Apple Mail (2.1257) Cc: "Lee, David" , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 01:12:33 -0000 On 24 Feb 2012, at 01:02, Wenjie Lin wrote: > As we have shown in our Feb 17th email, the negative consequence is a = violation by the user of the service agreement, that is, the user is = able to play the game but the client cannot post messages on behalf of = the user. That's not a negative within the context of the OAuth protocol, which = protects the users interests, not the clients. It looks as though with = the current wording, it's basically not possible to be compliant (very = mildly) in this scenario. But as John Bradley pointed out, it's completely legitimate for a client = to give the "game" full permissions, and then edit the scope afterwards = (though I can't find an explicit reference in the draft, I expect it to = be covered by one of the "This is out of scope" or revocation clauses). Implementations that want to allow clients to enforce the scope contract = with the user could always just implement a method to get the actual = scope back (like facebook), but it's not an attack against the protocol = or user..= From ve7jtb@ve7jtb.com Thu Feb 23 17:33:29 2012 Return-Path: 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 A6CD521E8026 for ; Thu, 23 Feb 2012 17:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 rOf74fVebiNH for ; Thu, 23 Feb 2012 17:33:29 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F95A21F85FB for ; Thu, 23 Feb 2012 17:33:28 -0800 (PST) Received: by ggnq2 with SMTP id q2so1058115ggn.31 for ; Thu, 23 Feb 2012 17:33:27 -0800 (PST) Received-SPF: pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.101.10.39 as permitted sender) client-ip=10.101.10.39; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.101.10.39 as permitted sender) smtp.mail=ve7jtb@ve7jtb.com Received: from mr.google.com ([10.101.10.39]) by 10.101.10.39 with SMTP id n39mr122415ani.3.1330047207802 (num_hops = 1); Thu, 23 Feb 2012 17:33:27 -0800 (PST) Received: by 10.101.10.39 with SMTP id n39mr94107ani.3.1330047207569; Thu, 23 Feb 2012 17:33:27 -0800 (PST) Received: from 201-188-70-237.bam.movistar.cl ([201.188.70.237]) by mx.google.com with ESMTPS id g49sm8129206yhk.20.2012.02.23.17.33.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Feb 2012 17:33:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_C11BD91A-475E-4150-B30C-13B395326051"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <1CA65248-D1AE-415D-85CD-E0E116D84A4B@gmail.com> Date: Thu, 23 Feb 2012 22:33:22 -0300 Message-Id: <2078F36D-6F53-4750-8136-144936C1A2FD@ve7jtb.com> References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.com> <34134676-9D51-4975-AD77-8AD34C3342B7@gmail.com> <1CA65248-D1AE-415D-85CD-E0E116D84A4B@gmail.com> To: Nicholas Devenish X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkWUiQ9zNFzi6oTVKbdWgSoc+4XPBziQTVgIUt+bysRdAIcUVQpL8w0fpbwdU3TXECQCjYQ Cc: "Lee, David" , Wenjie Lin , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 01:33:29 -0000 --Apple-Mail=_C11BD91A-475E-4150-B30C-13B395326051 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In that case the game is the client as it is using the access token to = get to the protected resource (FB graph API in this case). The resource = owner can revoke a granted scope at the authorization server after the = fact. That is how Facebook works now, as near as I can tell. Not that Facebook is a good example of how OAuth should work, They = issue long lived access tokens and not refresh tokens. A well behaved Authorization server would grant a refresh tokens with = all of the granted scopes, once the short lived access token expires it = would get a new one and see that it had been downs coped from the = original grant scope set. =20 The correct design is using a refresh token. that way if the user has = edited the scopes on the way to the Authorization server the client just = needs to use the refresh token with the scopes it believes were granted. If it gets back a downs coped response it knows something has changed. I have a hard time being sympathetic, because OAuth was not intended to = enforce service agreements on behalf of the Client, it is acting on = behalf of the resource owner. Enforcing multiparty service agreements should be a OAuth extension for = those that want it. John B. On 2012-02-23, at 10:12 PM, Nicholas Devenish wrote: >=20 > On 24 Feb 2012, at 01:02, Wenjie Lin wrote: >=20 >> As we have shown in our Feb 17th email, the negative consequence is a = violation by the user of the service agreement, that is, the user is = able to play the game but the client cannot post messages on behalf of = the user. >=20 > That's not a negative within the context of the OAuth protocol, which = protects the users interests, not the clients. It looks as though with = the current wording, it's basically not possible to be compliant (very = mildly) in this scenario. >=20 > But as John Bradley pointed out, it's completely legitimate for a = client to give the "game" full permissions, and then edit the scope = afterwards (though I can't find an explicit reference in the draft, I = expect it to be covered by one of the "This is out of scope" or = revocation clauses). >=20 > Implementations that want to allow clients to enforce the scope = contract with the user could always just implement a method to get the = actual scope back (like facebook), but it's not an attack against the = protocol or user.. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_C11BD91A-475E-4150-B30C-13B395326051 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MjQwMTMzMjNaMCMGCSqGSIb3DQEJBDEWBBT23Hdib18h7Wbp8AleFU9VtBEQqDCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQCmOwYeG9UZJL0aT5I6yI4pLmv6+HIGImESTQ89H/L/OwGhWqNigczkhve7VzdIPB0MWBR9yhUG 6yDAvBIdqOOxNgzgZ7oCgdlSpp59nHJki03HuPmmtWy/zTr940XD2xtk6soLy9PWionpa7nb0B2L hPuodxHl9n4OZnBPwJZ1H7F8TKaaph6jGw+TfyBsZWMBYDrmO8YCBBpXCmzFd0HGzyFoLcwA7ebF hQFDp6ltKLDCmfn1gfxsQh/54xAQHfe/2dF2MMWjy3DuIQzL/Eits2dQ8KPd6zGxNja1Kh59bEuD Z89r3jpYfi8Wbughg4LvS5hxfYmZJ0c6EVgqXhr+AAAAAAAA --Apple-Mail=_C11BD91A-475E-4150-B30C-13B395326051-- From dan.taflin@gettyimages.com Fri Feb 24 08:57:52 2012 Return-Path: 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 3A85B21F867F for ; Fri, 24 Feb 2012 08:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 M3qouorUyo0A for ; Fri, 24 Feb 2012 08:57:47 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6F221F8802 for ; Fri, 24 Feb 2012 08:57:46 -0800 (PST) Received: from mail203-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 Feb 2012 16:57:46 +0000 Received: from mail203-ch1 (localhost [127.0.0.1]) by mail203-ch1-R.bigfish.com (Postfix) with ESMTP id 514C34203B1; Fri, 24 Feb 2012 16:57:46 +0000 (UTC) X-SpamScore: -33 X-BigFish: VPS-33(zz9371Ic89bh936eKc85dh1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:216.169.250.56; KIP:(null); UIP:(null); IPV:NLI; H:SEAPXCH10CAHT02.amer.gettywan.com; RD:london.webmail.gettyimages.com; EFVD:NLI Received-SPF: pass (mail203-ch1: domain of gettyimages.com designates 216.169.250.56 as permitted sender) client-ip=216.169.250.56; envelope-from=dan.taflin@gettyimages.com; helo=SEAPXCH10CAHT02.amer.gettywan.com ; gettywan.com ; Received: from mail203-ch1 (localhost.localdomain [127.0.0.1]) by mail203-ch1 (MessageSwitch) id 1330102662458423_25703; Fri, 24 Feb 2012 16:57:42 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail203-ch1.bigfish.com (Postfix) with ESMTP id 6565AE004D; Fri, 24 Feb 2012 16:57:42 +0000 (UTC) Received: from SEAPXCH10CAHT02.amer.gettywan.com (216.169.250.56) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 Feb 2012 16:57:39 +0000 Received: from SEAPXCH10MBX01.amer.gettywan.com ([fe80::f054:280d:92db:5fff]) by SEAPXCH10CAHT02.amer.gettywan.com ([::1]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 08:55:38 -0800 From: Dan Taflin To: Wenjie Lin , Kristoph Thread-Topic: [OAUTH-WG] A Scope Attack against OAuth 2.0 Thread-Index: AQHM8pAQdzX7fHWCz0yt2jdPwxIvOJZMQrTQ Date: Fri, 24 Feb 2012 16:55:38 +0000 Message-ID: <429493818451304B84EC9A0797B5D8584506B4@SEAPXCH10MBX01.amer.gettywan.com> References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.com> <34134676-9D51-4975-AD77-8AD34C3342B7@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.68.44] Content-Type: multipart/alternative; boundary="_000_429493818451304B84EC9A0797B5D8584506B4SEAPXCH10MBX01ame_" MIME-Version: 1.0 X-OriginatorOrg: gettyimages.com Cc: "Lee, David" , "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:57:52 -0000 --_000_429493818451304B84EC9A0797B5D8584506B4SEAPXCH10MBX01ame_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thereby depriving the client of visibility on the social network. Yes, this= is a hack, by the user, against the client, and there is material harm. Th= e user is getting something without giving the client what was originally p= romised. Of course, the client will quickly discover the hack, and could take whatev= er action it deems appropriate, such as shutting itself down with an error = message. The question is, should the oauth protocol provide the client with= the information up front by providing scope information along with the acc= ess token? Dan From: Wenjie Lin [mailto:lin.820@osu.edu] Sent: Thursday, February 23, 2012 5:03 PM To: Kristoph Cc: Lee, David; oauth@ietf.org (oauth@ietf.org) Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 As we have shown in our Feb 17th email, the negative consequence is a viola= tion by the user of the service agreement, that is, the user is able to pla= y the game but the client cannot post messages on behalf of the user. "Scope Attack OAuth authorization of services is associated with service agreement scope.= For instance, Client provides an online game to User with a service agreem= ent scope A: User authorizes Client to access his profile information and t= o post messages on his behalf. A malicious User can request for online game= with service agreement scope A, manipulate the scope field, and change it = to scope B: User authorizes Client to access his profile information. User = can still play the games, yet Client can't post messages on User's behalf,= as originally agreed." - W. Lin and D. Lee On Thu, Feb 23, 2012 at 4:22 PM, Kristoph > wrote: Privilege de-escalation is not an attack. Your argument comes down to "I ca= n change something and no error is shown so it's an attack" but you've not = actually shown any sort of negative consequence because, you know, there is= n't one. ]{ On Feb 23, 2012, at 3:55 PM, Wenjie Lin wrote: > We assume that the authorization server is trustworthy and won't do anyth= ing that violates the spec. We want to prevent attacks by the client on the= user, as well as the attacks by the user on the client. > > The scope attack is by the user on the client. From the point view of the= user it is not an attack. However, the client takes it as an attack; the u= ser violates the service agreement by the client who may have no knowledge = about it, unless the authorization server always sends him the authorized s= cope information when granting an access token, as we've proposed, and the = client can figure out the difference/violation and decide how to deal with = it. > > When the client identifies the difference between his specified scope and= that in the access token, he can choose to abort or continue the service, = or take other actions. This is an implementation issue and is beyond the sc= ope of OAuth. There are other possible anomalies from implementations, such= as revocation of the scope by the user. However, they are not well specifi= ed in the current spec and we take them as an implementation rather than a = protocol issue. > > There might be applications where the client would not perceive scope att= ack as an attack if he could allow any changes of the service agreement sco= pe by the user. If OAuth were aimed for such clients only, it would signifi= cantly limit the applicability of the protocol. > > We appreciate the insightful discussions on how the client could check an= d handle the scope differences and beyond. They are extremely helpful for t= he implementers. > > -W. Lin and D. Lee > > On Tue, Feb 21, 2012 at 4:59 PM, John Bradley > wrote: > Yes, OpenID Connect deals with the issue by using a signed request exten= sion in the cases where the client needs to be certain the request is only = from the legitimate client and not tampered with. > > As you observe anyone can send a request the client_id and redirect_uri a= re not secret in any way. > > Though a well behaved client should be using state to check for XSRF atta= cks. (that is a real attack) > > Signed requests have uses, but are not core to OAuth. > > John B. > On 2012-02-21, at 9:38 PM, Andr=E9 DeMarre wrote: > > > The consensus seems to be, and I agree, that this shouldn't be > > considered an "attack," but that's really just nomenclature. I do > > concede that there is a spec issue here that I failed to appreciate at > > first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the issued > > access token scope is different from the one requested by the client," > > it suggests that the authorization server knows what was requested by > > the client. That isn't strictly true; it only knows what was in the > > authorization request, not who put it there. For the client to truly > > know what the auth server wants, (1) it would need to communicate > > directly with the client, (2) the client would need to preregister its > > desired scope, or (3) the client would need to sign a message that the > > user passes to the authorization endpoint. 1 and 3 are clearly not > > compatible with the spec, 2 might be; but that's not the point. > > > > A more correct statement in section 3.3 would be "If the issued access > > token scope is different from the one in the authorization request..." > > > > Regards, > > Andre DeMarre > > > > On Tue, Feb 21, 2012 at 3:01 PM, John Bradley > wrote: > >> > >> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote: > >> > >>> > >>> On 21 Feb 2012, at 21:59, John Bradley wrote: > >>>> This 'attack' is one that only works with badly designed clients th= at are making unwarranted assumptions about the behaviour of the Authorizat= ion server. > >>> > >>> Unwarranted assumptions? The spec in 3.3 says: > >>> > >>> "If the issued access token scope is different from the one requested= by the client, the authorization server MUST include the "scope" response = parameter to inform the client of the actual scope granted." > >>> > >>> - It says MUST; therefore any server that doesn't do this is non-comp= liant? > >>> - It says scope different from the one requested by the *client*. The= possibility that the resource owner intercepts this request and changes it= doesn't seem to be considered here (it is not strictly the clients request= if that happens) > >>> - The purpose seems to be that the client should be told if the scope= changes; this would be important if the client requires a certain scope le= vel to work (though this could be solved more generally in many other ways = that wouldn't be in the scope of the oauth spec) > >>> > >>> Thus, assuming that the server is stating compliance, isn't the assum= ption completely warranted? > >> > >> No the authorization server may at any time for any reason remove a sc= ope from a granted access_token or refresh_token. > >> > >> Reporting back changes in scopes granted along with the access_token i= s a convenience not a security feature. > >> > >> Assuming it is a security feature and those scopes will continue to be= valid for the token after granting is a bad design given the OAuth 2 spec. > >>> > >>>> The only way for a client to know if a token has a scope it to try i= t, or use a introspection endpoint. End of story. > >>> > >>> An introspection endpoint obviously isn't part of the specification, = so isn't relevant to the discussion (though it solves the discussed faceboo= k issue). > >>> > >>> You are right though, that the only way for a client to know for sure= is to try to use it; Even if the spec mandated always returning the scope = to the client, the user could always intercept the return redirection (assu= ming a non-confidential client) and change the scope there. > >>> > >>> Perhaps MUST should change to SHOULD, given that this essentially see= ms unenforceable? > >> > >> A SHOULD may lead people to the conclusion that it is secure. I am h= appy with saying it is not secure the only want to know is to have the clie= nt be prepared to deal with tokens that do not contain the desired scope wh= en used. That is the only 100% solution. > >> > >> John B. > >> > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > -- > Wenjie Lin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Wenjie Lin --_000_429493818451304B84EC9A0797B5D8584506B4SEAPXCH10MBX01ame_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thereby depriving the cli= ent of visibility on the social network. Yes, this is a hack, by the user, = against the client, and there is material harm. The user is getting something without giving the client what was originally promise= d.

 <= /p>

Of course, the client wil= l quickly discover the hack, and could take whatever action it deems approp= riate, such as shutting itself down with an error message. The question is, should the oauth protocol provide the client with the inf= ormation up front by providing scope information along with the access toke= n?

 <= /p>

Dan

 <= /p>

From: Wenjie L= in [mailto:lin.820@osu.edu]
Sent: Thursday, February 23, 2012 5:03 PM
To: Kristoph
Cc: Lee, David; oauth@ietf.org (oauth@ietf.org)
Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0<= /span>

 

As we = have shown in our Feb 17th email, the negative consequence is a violation b= y the user of the service agreement, that is, the user is able to play the = game but the client cannot post messages on behalf of the user.

&= nbsp;

"Scope Attack

OAuth autho= rization of services is associated with service agreement scope. For instan= ce, Client provides an online game to User with a service agreement scope A: User authorizes Client to access his profile information and to post messages on his behalf. A malicious User can r= equest for online game with service agreement scope A, manipula= te the scope field, and change it to scope B: User auth= orizes Client to access his profile information. User can still play the games,  yet Client can’t post mess= ages on User’s behalf, as originally agreed."<= /p>

 

- W. Lin and D. Lee

 

On Thu, Feb 23, 2012 at 4:22 PM, Kristoph <kristoph@gmail.com> wrote:

Privilege de-escalation is not an attack. Your argum= ent comes down to "I can change something and no error is shown so it'= s an attack" but you've not actually shown any sort of negative conseq= uence because, you know, there isn't one.

]{


On Feb 23, 2012, at 3:55 PM, Wenjie Lin wrote:

> We assume that the authorization server is trustworthy and won’t= do anything that violates the spec. We want to prevent attacks by the clie= nt on the user, as well as the attacks by the user on the client.
>
> The scope attack is by the user on the client. From the point view of = the user it is not an attack. However, the client takes it as an attack; th= e user violates the service agreement by the client who may have no knowled= ge about it, unless the authorization server always sends him the authorized scope information when granting an = access token, as we've proposed, and the client can figure out the differen= ce/violation and decide how to deal with it.
>
> When the client identifies the difference between his specified scope = and that in the access token, he can choose to abort or continue the servic= e, or take other actions. This is an implementation issue and is beyond the= scope of OAuth. There are other possible anomalies from implementations, such as revocation of the scope by the use= r. However, they are not well specified in the current spec and we take the= m as an implementation rather than a protocol issue.
>
> There might be applications where the client would not perceive scope = attack as an attack if he could allow any changes of the service agreement = scope by the user. If OAuth were aimed for such clients only, it would sign= ificantly limit the applicability of the protocol.
>
> We appreciate the insightful discussions on how the client could check= and handle the scope differences and beyond. They are extremely helpful fo= r the implementers.
>
> -W. Lin and D. Lee
>
> On Tue, Feb 21, 2012 at 4:59 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> Yes,  OpenID Connect deals with the issue by using a signed reque= st extension in the cases where the client needs to be certain the request = is only from the legitimate client and not tampered with.
>
> As you observe anyone can send a request the client_id and redirect_ur= i are not secret in any way.
>
> Though a well behaved client should be using state to check for XSRF a= ttacks. (that is a real attack)
>
> Signed requests have uses,  but are not core to OAuth.
>
> John B.
> On 2012-02-21, at 9:38 PM, Andr=E9 DeMarre wrote:
>
> > The consensus seems to be, and I agree, that this shouldn't be > > considered an "attack," but that's really just nomencla= ture. I do
> > concede that there is a spec issue here that I failed to apprecia= te at
> > first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the= issued
> > access token scope is different from the one requested by the cli= ent,"
> > it suggests that the authorization server knows what was requeste= d by
> > the client. That isn't strictly true; it only knows what was in t= he
> > authorization request, not who put it there. For the client to tr= uly
> > know what the auth server wants, (1) it would need to communicate=
> > directly with the client, (2) the client would need to preregiste= r its
> > desired scope, or (3) the client would need to sign a message tha= t the
> > user passes to the authorization endpoint. 1 and 3 are clearly no= t
> > compatible with the spec, 2 might be; but that's not the point. > >
> > A more correct statement in section 3.3 would be "If the iss= ued access
> > token scope is different from the one in the authorization reques= t..."
> >
> > Regards,
> > Andre DeMarre
> >
> > On Tue, Feb 21, 2012 at 3:01 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> >>
> >> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote:
> >>
> >>>
> >>> On 21 Feb 2012, at 21:59, John Bradley wrote:
> >>>> This 'attack'  is one that only works with badly= designed clients that are making unwarranted assumptions about the behavio= ur of the Authorization server.
> >>>
> >>> Unwarranted assumptions? The spec in 3.3 says:
> >>>
> >>> "If the issued access token scope is different from = the one requested by the client, the authorization server MUST include the = "scope" response parameter to inform the client of the actual sco= pe granted."
> >>>
> >>> - It says MUST; therefore any server that doesn't do this= is non-compliant?
> >>> - It says scope different from the one requested by the *= client*. The possibility that the resource owner intercepts this request an= d changes it doesn't seem to be considered here (it is not strictly the cli= ents request if that happens)
> >>> - The purpose seems to be that the client should be told = if the scope changes; this would be important if the client requires a cert= ain scope level to work (though this could be solved more generally in many= other ways that wouldn't be in the scope of the oauth spec)
> >>>
> >>> Thus, assuming that the server is stating compliance, isn= 't the assumption completely warranted?
> >>
> >> No the authorization server may at any time for any reason re= move a scope from a granted access_token or refresh_token.
> >>
> >> Reporting back changes in scopes granted along with the acces= s_token is a convenience not a security feature.
> >>
> >> Assuming it is a security feature and those scopes will conti= nue to be valid for the token after granting is a bad design given the OAut= h 2 spec.
> >>>
> >>>> The only way for a client to know if a token has a sc= ope it to try it, or use a introspection endpoint.  End of story.
> >>>
> >>> An introspection endpoint obviously isn't part of the spe= cification, so isn't relevant to the discussion (though it solves the discu= ssed facebook issue).
> >>>
> >>> You are right though, that the only way for a client to k= now for sure is to try to use it; Even if the spec mandated always returnin= g the scope to the client, the user could always intercept the return redir= ection (assuming a non-confidential client) and change the scope there.
> >>>
> >>> Perhaps MUST should change to SHOULD, given that this ess= entially seems unenforceable?
> >>
> >> A SHOULD may lead people to the conclusion that it is secure.=   I am happy with saying it is not secure the only want to know is to= have the client be prepared to deal with tokens that do not contain the de= sired scope when used.   That is the only 100% solution.
> >>
> >> John B.
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
>
>
>
>
> --
> Wenjie Lin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



 

--
Wenjie Lin

--_000_429493818451304B84EC9A0797B5D8584506B4SEAPXCH10MBX01ame_-- From bobbym@amazon.com Tue Feb 28 13:54:27 2012 Return-Path: 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 38BF421F858A for ; Tue, 28 Feb 2012 13:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 G8W6l3uwlqH5 for ; Tue, 28 Feb 2012 13:54:26 -0800 (PST) Received: from smtp-fw-31001.amazon.com (smtp-fw-31001.amazon.com [207.171.178.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5191E21F8578 for ; Tue, 28 Feb 2012 13:54:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,498,1325462400"; d="scan'208,217";a="181876138" Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32]) by smtp-border-fw-out-31001.sea31.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Feb 2012 21:54:12 +0000 Received: from ex-hub-0101.ant.amazon.com (ex-hub-0101.sea3.amazon.com [172.21.19.21]) by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id q1SLs4vv008015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 28 Feb 2012 21:54:12 GMT Received: from EX-SEA31-A.ant.amazon.com ([fe80::b450:6f2c:c0f9:1e85]) by ex-hub-0101.ant.amazon.com ([fe80::15a4:9d9a:bd65:89cf%14]) with mapi; Tue, 28 Feb 2012 13:54:01 -0800 From: "Martin, Bobby" To: "oauth@ietf.org" Date: Tue, 28 Feb 2012 13:54:00 -0800 Thread-Topic: Associating access_token with user-agent on client? Thread-Index: Acz2Y3p/Li3CjQWhQvm/Xc0tOGH/iw== Message-ID: <566590632924AD48B839AF6CD200554A02B24D2EBB@EX-SEA31-A.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_566590632924AD48B839AF6CD200554A02B24D2EBBEXSEA31Aantam_" MIME-Version: 1.0 Subject: [OAUTH-WG] Associating access_token with user-agent on client? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 21:55:45 -0000 --_000_566590632924AD48B839AF6CD200554A02B24D2EBBEXSEA31Aantam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth 2.0 spec specifically says not to return the access_token to the = user-agent (which I understand), but it does not indicate how to associate = the access_token with a particular client session. This seems like an important omission, since any way that spoofs how the cl= ient recognizes a user-agent request as belonging to a resource owner is a= s good as spoofing the access_token. I searched the list archives and in general googled around, but I don't see= any discussion of this. In our use case, we want to recognize the custome= r based on their authentication with the auth server, so ideally we do not = require a login in the client's domain. Can someone point me to discussions around this? Thanks, Bobby --_000_566590632924AD48B839AF6CD200554A02B24D2EBBEXSEA31Aantam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth 2.0 sp= ec specifically says not to return the access_token to the user-agent (whic= h I understand), but it does not indicate how to associate the access_token= with a particular client session.

=  

This seems like an important omission,= since any way that spoofs how the client recognizes a user-agent request a= s belonging to a resource owner  is as good as spoofing the access_tok= en.

 

I searched the list archives and in general googled around, but I don= ’t see any discussion of this.  In our use case, we want to reco= gnize the customer based on their authentication with the auth server, so i= deally we do not require a login in the client’s domain.

 

Can someon= e point me to discussions around this?

<= o:p> 

Thanks,

Bobby

= --_000_566590632924AD48B839AF6CD200554A02B24D2EBBEXSEA31Aantam_-- From andredemarre@gmail.com Tue Feb 28 16:13:42 2012 Return-Path: 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 569D921F85EC for ; Tue, 28 Feb 2012 16:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.002 X-Spam-Level: X-Spam-Status: No, score=-3.002 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 8zkw7eQgDtlD for ; Tue, 28 Feb 2012 16:13:37 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC57121F8545 for ; Tue, 28 Feb 2012 16:13:37 -0800 (PST) Received: by pbcwz17 with SMTP id wz17so2708327pbc.31 for ; Tue, 28 Feb 2012 16:13:37 -0800 (PST) Received-SPF: pass (google.com: domain of andredemarre@gmail.com designates 10.68.130.164 as permitted sender) client-ip=10.68.130.164; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andredemarre@gmail.com designates 10.68.130.164 as permitted sender) smtp.mail=andredemarre@gmail.com; dkim=pass header.i=andredemarre@gmail.com Received: from mr.google.com ([10.68.130.164]) by 10.68.130.164 with SMTP id of4mr16097003pbb.56.1330474417629 (num_hops = 1); Tue, 28 Feb 2012 16:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=zLRhXvOMZBAY0tNxbjIF8c9X8lSIDbb24WmqzZXOO+M=; b=shun4CvQWzIq7MkQx/yvgxurMVY+TeJGfwvFiHtQNBOLg77W3EKOjb+mp+KqXbzvuL kKxbk88H2KL/q2yqx8syOJ9H29uIUGFvoiOcTGqZ1Jdeg9PbrspzVXeR2G+N47yN3+2Z A7XJ6nrknHLH0tsyjHAtSTyr2xL1K5nTaGfok= MIME-Version: 1.0 Received: by 10.68.130.164 with SMTP id of4mr13370798pbb.56.1330474417439; Tue, 28 Feb 2012 16:13:37 -0800 (PST) Received: by 10.68.25.193 with HTTP; Tue, 28 Feb 2012 16:13:37 -0800 (PST) In-Reply-To: References: <566590632924AD48B839AF6CD200554A02B24D2EBB@EX-SEA31-A.ant.amazon.com> Date: Tue, 28 Feb 2012 16:13:37 -0800 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: OAuth WG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] Fwd: Associating access_token with user-agent on client? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 00:13:42 -0000 Neglected to copy the WG. ---------- Forwarded message ---------- From: Andr=E9 DeMarre Date: Tue, Feb 28, 2012 at 3:52 PM Subject: Re: [OAUTH-WG] Associating access_token with user-agent on client? To: "Martin, Bobby" I assume you're talking about the authorization code flow, and that your client is a server-side web application. How to persist state to maintain a session between a user agent and a web app client is beyond the scope of OAuth. The spec alludes to it in its explanation of the "state" parameter and CSRF, but that's not what you're asking. The client will usually use cookies to maintain a user session, and it's up to the client to decide how sessions are secured. This is no different when the client uses an OAuth server for user authentication; the client still needs to manage a session so it can identify the user as he interacts with the app. There is a difference between matching a user to a real identity (authentication), and recognizing the same user between stateless HTTP requests (sessions). You do bring up a very good point though, that being that if a user's client session is hijacked, then the attacker can use the client to access the user's protected resources. Session security at the client is beyond the scope of OAuth, and the spec only touches on it in its consideration of client redirection endpoint security. For example, see section 3.1.2.1 (http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-3.1.2.1). OAuth is not about securing web applications, but at the very least, perhaps the threat model document could explain that clients need to defend against session hijacking, not only at the redirection endpoint but throughout the application. In the case of cookie-based sessions, the session ID cookie should only be transmitted over TLS. If it's in the threat model already, I must have overlooked it. Regards, Andre DeMarre On Tue, Feb 28, 2012 at 1:54 PM, Martin, Bobby wrote: > The OAuth 2.0 spec specifically says not to return the access_token to th= e > user-agent (which I understand), but it does not indicate how to associat= e > the access_token with a particular client session. > > > > This seems like an important omission, since any way that spoofs how the > client recognizes a user-agent request as belonging to a resource owner = =A0is > as good as spoofing the access_token. > > > > I searched the list archives and in general googled around, but I don=92t= see > any discussion of this.=A0 In our use case, we want to recognize the cust= omer > based on their authentication with the auth server, so ideally we do not > require a login in the client=92s domain. > > > > Can someone point me to discussions around this? > > > > Thanks, > > Bobby > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From bobbym@amazon.com Tue Feb 28 16:19:00 2012 Return-Path: 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 C397E21F8526 for ; Tue, 28 Feb 2012 16:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 20IvCv233+WJ for ; Tue, 28 Feb 2012 16:19:00 -0800 (PST) Received: from smtp-fw-31001.amazon.com (smtp-fw-31001.amazon.com [207.171.178.25]) by ietfa.amsl.com (Postfix) with ESMTP id 06BCD21F851C for ; Tue, 28 Feb 2012 16:19:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,499,1325462400"; d="scan'208";a="182234112" Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32]) by smtp-border-fw-out-31001.sea31.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Feb 2012 00:18:54 +0000 Received: from ex-hub-31012.ant.amazon.com (ex-hub-31012.sea31.amazon.com [10.185.169.29]) by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id q1T0Inpc013957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 29 Feb 2012 00:18:49 GMT Received: from EX-SEA31-A.ant.amazon.com ([fe80::b450:6f2c:c0f9:1e85]) by ex-hub-31012.ant.amazon.com ([fe80::a489:929b:842e:1dbc%12]) with mapi; Tue, 28 Feb 2012 16:18:49 -0800 From: "Martin, Bobby" To: =?iso-8859-1?Q?Andr=E9_DeMarre?= , OAuth WG Date: Tue, 28 Feb 2012 16:18:47 -0800 Thread-Topic: [OAUTH-WG] Fwd: Associating access_token with user-agent on client? Thread-Index: Acz2dwhe6DHQJ1F7Rd+7cUQ8sTL6gwAABEcQ Message-ID: <566590632924AD48B839AF6CD200554A02B24D305A@EX-SEA31-A.ant.amazon.com> References: <566590632924AD48B839AF6CD200554A02B24D2EBB@EX-SEA31-A.ant.amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Fwd: Associating access_token with user-agent on client? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 00:19:00 -0000 You assume correctly :-) I do recognize that general authentication of a user on a web site is the p= roblem, and that it is to some degree outside the scope of OAuth. I waffle= d about including that in my original email; I felt that it watered down th= e argument. In our model the authentication of the user on the client (by the OAuth 2.0= spec's definition of client, in our case a web server) is mixed up somewha= t with the OAuth authentication process. Before the user authenticates wit= h the auth server, the user on the client has no identity, or at most has a= n anonymous session. It is the act of authenticating with the auth server = which gives the user a meaningful identity on the client. In our design so far we have elected to send back a cookie in the response = from the final 302 to the client redirect_uri. In fact, our whole client d= omain(s) are insecure, and securing all of them is essentially impossible. = So we need to do a balancing act in that we would like to limit the scope = of the breach if the client authentication is hijacked, but we know that fo= r many threats we simply have no recourse. (No recourse in that e.g. a MIT= M attack is always possible on an insecure domain). Which is acceptable be= cause the resources are relatively low value (user's real name, etc). To be more specific about limiting the scope of a breach - for example it i= s less impactful for a 3rd party to be able to snoop on the transactions th= at the user agent initiates than to be able to make arbitrary requests itse= lf, and less impactful for a 3rd party to be able to retrieve data about th= e user for a limited time than for them to be able to retrieve at any time = in the future. Does anyone have recommendations of specs to look at for the specifically m= anaging user authentication with an insecure server, which work well with t= he OAuth 2.0 model? Thanks! Bobby -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndr=E9 DeMarre Sent: Tuesday, February 28, 2012 4:14 PM To: OAuth WG Subject: [OAUTH-WG] Fwd: Associating access_token with user-agent on client= ? Neglected to copy the WG. ---------- Forwarded message ---------- From: Andr=E9 DeMarre Date: Tue, Feb 28, 2012 at 3:52 PM Subject: Re: [OAUTH-WG] Associating access_token with user-agent on client? To: "Martin, Bobby" I assume you're talking about the authorization code flow, and that your client is a server-side web application. How to persist state to maintain a session between a user agent and a web app client is beyond the scope of OAuth. The spec alludes to it in its explanation of the "state" parameter and CSRF, but that's not what you're asking. The client will usually use cookies to maintain a user session, and it's up to the client to decide how sessions are secured. This is no different when the client uses an OAuth server for user authentication; the client still needs to manage a session so it can identify the user as he interacts with the app. There is a difference between matching a user to a real identity (authentication), and recognizing the same user between stateless HTTP requests (sessions). You do bring up a very good point though, that being that if a user's client session is hijacked, then the attacker can use the client to access the user's protected resources. Session security at the client is beyond the scope of OAuth, and the spec only touches on it in its consideration of client redirection endpoint security. For example, see section 3.1.2.1 (http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-3.1.2.1). OAuth is not about securing web applications, but at the very least, perhaps the threat model document could explain that clients need to defend against session hijacking, not only at the redirection endpoint but throughout the application. In the case of cookie-based sessions, the session ID cookie should only be transmitted over TLS. If it's in the threat model already, I must have overlooked it. Regards, Andre DeMarre On Tue, Feb 28, 2012 at 1:54 PM, Martin, Bobby wrote: > The OAuth 2.0 spec specifically says not to return the access_token to th= e > user-agent (which I understand), but it does not indicate how to associat= e > the access_token with a particular client session. > > > > This seems like an important omission, since any way that spoofs how the > client recognizes a user-agent request as belonging to a resource owner = =A0is > as good as spoofing the access_token. > > > > I searched the list archives and in general googled around, but I don't s= ee > any discussion of this.=A0 In our use case, we want to recognize the cust= omer > based on their authentication with the auth server, so ideally we do not > require a login in the client's domain. > > > > Can someone point me to discussions around this? > > > > Thanks, > > Bobby > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From pete@appmuscle.com Wed Feb 29 18:44:56 2012 Return-Path: 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 843FC21F858E for ; Wed, 29 Feb 2012 18:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 0xw73C1QJRLe for ; Wed, 29 Feb 2012 18:44:56 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1510721F858D for ; Wed, 29 Feb 2012 18:44:55 -0800 (PST) Received: by ggmi1 with SMTP id i1so42967ggm.31 for ; Wed, 29 Feb 2012 18:44:55 -0800 (PST) Received-SPF: pass (google.com: domain of pete@appmuscle.com designates 10.101.129.7 as permitted sender) client-ip=10.101.129.7; Authentication-Results: mr.google.com; spf=pass (google.com: domain of pete@appmuscle.com designates 10.101.129.7 as permitted sender) smtp.mail=pete@appmuscle.com Received: from mr.google.com ([10.101.129.7]) by 10.101.129.7 with SMTP id g7mr1402628ann.12.1330569895746 (num_hops = 1); Wed, 29 Feb 2012 18:44:55 -0800 (PST) Received: by 10.101.129.7 with SMTP id g7mr1106654ann.12.1330569895679; Wed, 29 Feb 2012 18:44:55 -0800 (PST) Received: from [10.44.251.246] (mobile-198-228-233-243.mycingular.net. [198.228.233.243]) by mx.google.com with ESMTPS id n72sm1112222yhh.21.2012.02.29.18.44.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 18:44:55 -0800 (PST) From: Pete Clark Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9A405) Message-Id: Date: Wed, 29 Feb 2012 21:44:48 -0500 To: "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Gm-Message-State: ALoCoQmIeS06jDIMD4Oq7t75Y/zewq0+GsmzRWEswb9khbQD9PV7fFsMiEqzLmSuD5DBCuqaArOe Subject: [OAUTH-WG] Securing APIs with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 02:45:57 -0000 Hey all, I've joined the list because I'd like to use OAuth 2 to implement s= ecurity for a new set of REST APIs I'm developing for a client. I'm coding w= ith PHP, but my questions are more general. Right now, there will be only o= ne web site that uses the APIs, in a server-to-server fashion, and currently= we don't have a need for a third party application to gain access to user d= ata, such that a user would need to authorize that app. We do, however, wan= t to have that ability down the road. My question is, can I still use OAuth= 2 in some way to implement our first phase? =46rom what I've read, it seem= s like the "client credentials" flow is the one I want to use for now. Can s= omeone: 1) Confirm that that's what I should use for this first phase? 2) Point me to an implementation of this flow (in any language) that I could= use or port to PHP? I've found some libraries for php but can't really tel= l, being new, if they offer the "client credentials" flow 3) Answer one more question.. Will using the client credentials flow now all= ow me to move to one of the user-authorizes-external-app flows down the road= without having to reimplement or throw away the client credentials flow cod= e? I apologize for all the questions, but these would really help point me in t= he right direction.. Thank you for reading! Sincerely, Pete From sweeden@au1.ibm.com Wed Feb 29 19:00:06 2012 Return-Path: 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 A2C6C21E807B for ; Wed, 29 Feb 2012 19:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.578 X-Spam-Level: X-Spam-Status: No, score=-8.578 tagged_above=-999 required=5 tests=[AWL=2.021, BAYES_00=-2.599, 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 OhPUAIgrlxI2 for ; Wed, 29 Feb 2012 19:00:06 -0800 (PST) Received: from e23smtp06.au.ibm.com (e23smtp06.au.ibm.com [202.81.31.148]) by ietfa.amsl.com (Postfix) with ESMTP id 1721B21E801E for ; Wed, 29 Feb 2012 19:00:04 -0800 (PST) Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 1 Mar 2012 02:55:54 +1000 Received: from d23relay04.au.ibm.com (202.81.31.246) by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 1 Mar 2012 02:55:51 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q212sG7C3424370; Thu, 1 Mar 2012 13:54:19 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q212xjND029513; Thu, 1 Mar 2012 13:59:45 +1100 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q212xjh0029506; Thu, 1 Mar 2012 13:59:45 +1100 In-Reply-To: References: X-KeepSent: 00AD6E13:25AA51DD-4A2579B4:00101F47; type=4; name=$KeepSent To: Pete Clark X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Shane B Weeden Date: Wed, 29 Feb 2012 19:59:28 -0700 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.2FP1HF437 | June 7, 2011) at 01/03/2012 14:03:51 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII x-cbid: 12022916-7014-0000-0000-000000A8FE36 Cc: "oauth@ietf.org" , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 03:00:06 -0000 1. Yes, client credentials sounds right for what you described. Think of it as lightweight b2b authentication in that sense (but two steps - one to get a token, and another to use it). 2. Can't help you with source - but do have a product-based solution :) 3. Absolutely it should for the resource server, but the answer may depend have same dependency on the implementation you use. Regards, Shane. From: Pete Clark To: "oauth@ietf.org" Date: 29/02/2012 06:50 PM Subject: [OAUTH-WG] Securing APIs with OAuth 2.0 Sent by: oauth-bounces@ietf.org Hey all, I've joined the list because I'd like to use OAuth 2 to implement security for a new set of REST APIs I'm developing for a client. I'm coding with PHP, but my questions are more general. Right now, there will be only one web site that uses the APIs, in a server-to-server fashion, and currently we don't have a need for a third party application to gain access to user data, such that a user would need to authorize that app. We do, however, want to have that ability down the road. My question is, can I still use OAuth 2 in some way to implement our first phase? From what I've read, it seems like the "client credentials" flow is the one I want to use for now. Can someone: 1) Confirm that that's what I should use for this first phase? 2) Point me to an implementation of this flow (in any language) that I could use or port to PHP? I've found some libraries for php but can't really tell, being new, if they offer the "client credentials" flow 3) Answer one more question.. Will using the client credentials flow now allow me to move to one of the user-authorizes-external-app flows down the road without having to reimplement or throw away the client credentials flow code? I apologize for all the questions, but these would really help point me in the right direction.. Thank you for reading! Sincerely, Pete _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From pete@appmuscle.com Wed Feb 29 19:14:55 2012 Return-Path: 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 561F321E801E for ; Wed, 29 Feb 2012 19:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.023 X-Spam-Level: X-Spam-Status: No, score=-3.023 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Duqef8QS1Mnw for ; Wed, 29 Feb 2012 19:14:54 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01B6F21F85A4 for ; Wed, 29 Feb 2012 19:14:53 -0800 (PST) Received: by ggmi1 with SMTP id i1so49437ggm.31 for ; Wed, 29 Feb 2012 19:14:53 -0800 (PST) Received-SPF: pass (google.com: domain of pete@appmuscle.com designates 10.236.191.100 as permitted sender) client-ip=10.236.191.100; Authentication-Results: mr.google.com; spf=pass (google.com: domain of pete@appmuscle.com designates 10.236.191.100 as permitted sender) smtp.mail=pete@appmuscle.com Received: from mr.google.com ([10.236.191.100]) by 10.236.191.100 with SMTP id f64mr4387143yhn.57.1330571693693 (num_hops = 1); Wed, 29 Feb 2012 19:14:53 -0800 (PST) Received: by 10.236.191.100 with SMTP id f64mr3445042yhn.57.1330571693610; Wed, 29 Feb 2012 19:14:53 -0800 (PST) Received: from [10.44.251.246] (mobile-198-228-233-243.mycingular.net. [198.228.233.243]) by mx.google.com with ESMTPS id b33sm884781anb.4.2012.02.29.19.14.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 19:14:53 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <5727FEEF-AE93-46F3-813E-27DDD0DAF4F1@appmuscle.com> X-Mailer: iPhone Mail (9A405) From: Pete Clark Date: Wed, 29 Feb 2012 22:14:46 -0500 To: Shane B Weeden X-Gm-Message-State: ALoCoQk+oUoGIvTEp0GCsZQ6vACklbtYtymzAMsp4RLgJQZhUshPhWpvtaXnNJ9CdYVpspyuPfZU Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 03:14:55 -0000 Thanks Shane! Would love to check out your product.. Can you send a link? -- Message typed on a tiny keyboard. Forgive me for any typos! On Feb 29, 2012, at 9:59 PM, Shane B Weeden wrote: > 1. Yes, client credentials sounds right for what you described. Think of it > as lightweight b2b authentication in that sense (but two steps - one to get > a token, and another to use it). > 2. Can't help you with source - but do have a product-based solution :) > 3. Absolutely it should for the resource server, but the answer may depend > have same dependency on the implementation you use. > > Regards, > Shane. > > > > From: Pete Clark > To: "oauth@ietf.org" > Date: 29/02/2012 06:50 PM > Subject: [OAUTH-WG] Securing APIs with OAuth 2.0 > Sent by: oauth-bounces@ietf.org > > > > Hey all, I've joined the list because I'd like to use OAuth 2 to implement > security for a new set of REST APIs I'm developing for a client. I'm > coding with PHP, but my questions are more general. Right now, there will > be only one web site that uses the APIs, in a server-to-server fashion, and > currently we don't have a need for a third party application to gain access > to user data, such that a user would need to authorize that app. We do, > however, want to have that ability down the road. My question is, can I > still use OAuth 2 in some way to implement our first phase? From what I've > read, it seems like the "client credentials" flow is the one I want to use > for now. Can someone: > > 1) Confirm that that's what I should use for this first phase? > 2) Point me to an implementation of this flow (in any language) that I > could use or port to PHP? I've found some libraries for php but can't > really tell, being new, if they offer the "client credentials" flow > 3) Answer one more question.. Will using the client credentials flow now > allow me to move to one of the user-authorizes-external-app flows down the > road without having to reimplement or throw away the client credentials > flow code? > > I apologize for all the questions, but these would really help point me in > the right direction.. Thank you for reading! > > Sincerely, > Pete > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > >
So, I think what you are pointing out is an operability flaw rather than = a security one.  It is possible that the client will be issued a token= that does not have the permissions it expects, and the only way for the cl= ient to determine this in a guaranteed fashion is to do an operation and se= e a failure.

The questio= n then is, does this warrant a MUST rather than SHOULD.  The server ma= y issue a more privileged token for example.  From the scope name ther= e's no way for the client to actually resolve the scope name to privilege, = so even if the server provides the scope we might have the same problem.

There are current usages in comaparable syste= ms where an unscoped token implies no restriction.  The semantics of scope names here have intentionally been left fuzzy.  It's a signi= ficant change to try to fix this problem, but the questionis whether it's w= orth it?  I doubt that will get it right in a way that people will agr= ee with, I don't think you proposed change is sufficient to resolve the pro= blem.

Would it be sifficient to call it out as an = implementors note or a nota bene type editorial comment?

-bill


From: We= njie Lin <lin.820@osu.edu>
= To: John Bradley <ve7jtb@ve7jtb.com>
Cc: "oauth@ietf.org (oauth@ietf.or= g)" <oauth@ietf.org>
Sent:= Saturday, February 18, 2012 8:18 PM
Subject: Re: [OAUTH-WG] A Scope Attack against OA= uth 2.0

=0A
=0A=0AWe appreciate your attention and resp= onse to our report.
=0A=0A 
Since Authorization Server obtains the s= cope information ONLY from User, it can=E2=80=99t tell whether the issued a= ccess token scope  is different from the one requested by Client, so l= ong as User is consistently sending the same altered scope information to A= uthorization Server. Consequently, as an Option, Authorization Server may c= hoose not to include the scope response parameter to inform Client of the a= ctual scope granted, and that results in the scope attack. This is a protoc= ol issue and is not an implementation issue; one can come up with an implem= entation that is compliant with the protocol specification yet with a scope attack.
=0A=0A
 
=0A=0AOne may argue that we only care about User pr= otection and security. Consequently, scope attack is apparently not a proto= col security issue. However, it would significantly limit the applicability= of the protocol, if Client is knowingly exposed to attacks. We need Client= protection and security as well in applications, for instance, cloud servi= ces.
=0A=0A
 
=0A=0AScope attack can be easily fixed. One can simply = make it Required that Authorization Server MUST include the scope response = parameter to inform Client of the actual scope granted, as we have proposed= for your consideration.
=0A=0A
 
=0A=0AOAuth 2.0 is a sound protocol= design. We prove the security properties (for both User and Client) and sc= ope attack is an issue we=E2=80=99ve got stuck in the proof.<= /span>
=0A=0A
=  
=0A=0A- W. Lin and D. Lee

On Sat, Feb 18, 2012 at 2:47 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
=0A=0A
I agree that i= t is not a protocol problem.
=0A
=0AThe problem is that some develope= rs are not understanding the spec.
=0A
=0AOne case I saw recently was= a proposal to send a scope to the Authorization endpoint that changed is a= uthentication behaviour e.g. ask for mlti-factor authentication.
=0A
= =0AOn a superficial reading of the spec they thought that not getting a cha= nged set of scopes back in the response that the Authorization server was i= ndicating that it had done what was asked.
=0A
=0AWhen I pointed out = that the user agent can remove scopes because requests are not signed, &nbs= p;they had a similar solution of forcing all the endpoints to always return= the scopes granted.
=0A
=0AI hope I talked them out of that.
=0A<= br>=0AThe problem is getting people to use scopes to represent resources an= d not other arbitrary configuration things,  and to understand that ev= en if they do get a scope granted it could disappear before they get to use= the access token and they need to be prepared for that.
=0A=0A=0A
= =0AThe premise that users get access to y for access to x is something that= can be built with OAuth but is not something that can be inferred in the w= ay they are proposing.
=0A
=0AFrom my perspective replying with grant= ed scopes is a convince for the client, but not something that can be depen= ded upon.
=0AI don't think we need any normative change.
=0A
=0AA = don't make stupid assumptions about the persistence of scopes in tokens not= e would be as far as I would go.
=0A
=0AJohn B.
=0A

=0AOn 2012-02-18, at= 3:34 AM, Shane B Weeden wrote:
=0A
=0A> I agree with others - thi= s is not an attack on the protocol. The user has
=0A> the choice abou= t which scope to grant and the client's redirect to the
=0A> authoriz= ation endpoint is only a request for a particular set of
=0A> permiss= ions, not a guarantee that it will get them. The user+authorization
=0A&= gt; server decide which scope is actually granted. The client needs to hand= le
=0A> cases where that differs from what it originally wanted.
= =0A>
=0A>
=0A>
=0A>
=0A> From: Wenjie Lin <lin.820@osu.edu>
=0A> To:   <= a rel=3D"nofollow" ymailto=3D"mailto:oauth@ietf.org" target=3D"_blank" href= =3D"mailto:oauth@ietf.org">oauth@ietf.org
=0A> Date: 18/02/2012 1= 2:12 PM
=0A> Subject:      [OAUTH-WG] A Scope Attack a= gainst OAuth 2.0
=0A> Sent by:      oauth-bounces@ietf.org
=0A>
=0A><= br>=0A>
=0A> We describe an attack on OAuth 2.0 (draft-ietf-oauth-= v2-23), called scope
=0A> attack, provide a live-demo of the attack o= n Facebook, and propose a fix
=0A> with discussions.
=0A>
= =0A>
=0A>
=0A>
=0A>
=0A> Scope Attack
=0A>=
=0A>
=0A> OAuth authorization of services is associated with s= ervice agreement scope.
=0A> For instance, Client provides an online = game to User with a service
=0A> agreement scope A: User authorizes C= lient to access his profile information
=0A> and to post messages on = his behalf. A malicious User can request for online
=0A> game with se= rvice agreement scope A, manipulate the scope field, and change
=0A> = it to scope B: User authorizes Client to access his profile information.=0A> User can still play the games,  yet Client can=E2=80=99t post= messages on User=E2=80=99s
=0A> behalf, as originally agreed.
=0A= >
=0A>
=0A> OAuth 2.0 authorization code grant and implicit = grant are vulnerable to the
=0A> scope attack.
=0A>
=0A><= br>=0A>
=0A>
=0A>
=0A> A Scope Attack Scenario
=0A&= gt;
=0A>
=0A> (1) Authorization Server: Facebook (authorization= code grant)
=0A>
=0A>
=0A>      (2) Clien= t: Online gaming company Game. It allows User to play the
=0A>  =    games with the service agreement scope A: User authorizes Gam= e to
=0A>      access his profile information and post= messages on his behalf.
=0A>
=0A>
=0A>     &nb= sp;(3) User: malicious User with an account at Facebook. He attempts to
= =0A>      play the games yet without authorizing Game to = post messages on his
=0A>      behalf, that is, he cha= nges the scope from A to B: authorization of
=0A>      = ;Client to access his profile information only.
=0A>
=0A>
= =0A>
=0A>
=0A>
=0A> Attack Workflow
=0A>
=0A&= gt;
=0A>        (1) User requests Game (Client) f= or permission to play games,
=0A>        instanti= ating OAuth 2.0 with scope A.
=0A>
=0A>
=0A>    = ;    (2) Game generates an authorization request with a scope
= =0A>        specification A, and redirects User to F= acebook with the request.
=0A>
=0A>
=0A>     &n= bsp;  (3) User manipulates the scope field and changes it to scope B. = The
=0A>        modified request is then sent to = Facebook.
=0A>
=0A>
=0A>        (4) U= ser grants the modified request.
=0A>
=0A>
=0A>   &n= bsp;    (5) Facebook redirects User back to Game with the authori= zation
=0A>        code.
=0A>
=0A>=0A>        (6) Game exchanges the authorization co= de for an access token.
=0A>        However it ha= s no knowledge that the scope A has been changed to
=0A>    = ;    scope B.
=0A>
=0A>
=0A>     &nbs= p;  (7) Game provides online gaming service to User. However, Game
= =0A>        can=E2=80=99t post messages on User=E2= =80=99s Facebook page.
=0A>
=0A>
=0A>
=0A>
=0A&g= t;
=0A> A Live-Demo: Facebook and CastleVille (IE and Safari tested)<= br>=0A>
=0A>
=0A>      Step 1: Login Facebook= and visit Facebook Apps and Game page
=0A>
=0A>
=0A> &nb= sp;    https://www.facebook.com/games
=0A>
=0A>= ;
=0A> Step 2: Click CastleVille.
=0A>
=0A>
=0A> &n= bsp;    Step 3: When you see the Request for Permission page, ins= tead of
=0A>
=0A>
=0A>          =  clicking =E2=80=9CAllow=E2=80=9D, change the scope field in the URL = from your
=0A>            browser from =  =E2=80=9Cscope=3Demail%2Cpublish_stream%2Cpublish_actions=E2=80=9D=0A>            to =E2=80=9Cscope=3Demail= %2Cpublish_stream=E2=80=9D.
=0A>
=0A>
=0A>     =  Step 4: After the modification, press ENTER to send the modified
= =0A>
=0A>
=0A>            requ= est to Facebook. Now you will see the modified Request of
=0A>  =          Permission page.
=0A>
=0A>=0A> Step 5: Click on =E2=80=9CAllow=E2=80=9D button and enjoy the gam= e.
=0A>
=0A>
=0A> (video: http://www.you= tube.com/watch?v=3DzkmjLa3VU9w)
=0A>
=0A>
=0A>
=0A= >
=0A>
=0A> Impact
=0A>
=0A>
=0A> Client p= rovides services to malicious User yet with the modified service
=0A>= agreement scope by User=E2=80=99s design.
=0A>
=0A>
=0A>=
=0A>
=0A>
=0A> Manipulating Scope Field
=0A>
= =0A>
=0A> The scope field in access token response is required ONL= Y IF Authorization
=0A> Server observes that the User authorized scop= e is different than the
=0A> original scope. Consequently, User can m= anipulate the scope field so that
=0A> Authorization Server cannot de= tect the change of the scope. As a result
=0A> Client provides the se= rvices yet can=E2=80=99t obtain the information that is
=0A> specifie= d in the scope of the original service agreement.
=0A>
=0A>
= =0A> Client can verify the service agreement scope by checking all the f= ields
=0A> against the original User request before providing the req= uested services
=0A> to User.  For instance, Client can verify t= he granted permissions if
=0A> Authorization Server (e.g. Facebook) &= nbsp;provides an API. However, this is out
=0A> of the scope of OAuth= 2.0, and Client may not check it. We observe: all top
=0A> five game= s recommended by Facebook are vulnerable to the scope attack.
=0A>=0A>
=0A>
=0A>
=0A>
=0A> Proposed Fix
=0A>= ;
=0A>
=0A> Draft-ietf-oauth-v2-23 Section 5.1:
=0A>
= =0A>
=0A> Change from
=0A>
=0A>
=0A>   &nbs= p;  =E2=80=9Cscope
=0A>
=0A>
=0A>     &nbs= p;         OPTIONAL, if identical to the scope requeste= d by the client,
=0A>
=0A>
=0A>       &nbs= p;       otherwise REQUIRED.=E2=80=9D
=0A>
=0A><= br>=0A> to
=0A>
=0A>
=0A> =E2=80=9Cscope REQUIRED=E2= =80=9D /* scope: User authorized scope */
=0A>
=0A>
=0A><= br>=0A>
=0A>
=0A> Remarks
=0A>
=0A>
=0A> (= 1) The proof of the correctness of OAuth with our proposed fix will be
= =0A> published in an article: =E2=80=9COAuth 2.0 =E2=80=93 Attacks, Fixe= s, Correctness, and
=0A> Generalizations, Wenjie Lin, David Lee and S= teve Lai, to appear=E2=80=9D.
=0A>
=0A>
=0A> (2) The impl= icit grant is also vulnerable to the scope attack. However it
=0A> ca= nnot be fixed by enforcing scope field in access token response as above;=0A> User can change the scope in response before being redirected to = Client.
=0A>
=0A>
=0A>
=0A>
=0A>
=0A> W= enjie Lin, The Ohio State University
=0A>
=0A>
=0A> David= Lee, HP Labs and The Ohio State University
=0A>
=0A>
=0A>= ; Steve Lai, The Ohio State University
=0A> _________________________= ______________________
=0A> OAuth mailing list
=0A> OAuth@ietf.org
=0A> https://ww= w.ietf.org/mailman/listinfo/oauth
=0A>
=0A>
=0A> ____= ___________________________________________
=0A> OAuth mailing list=0A> OAuth@ietf.org
=0A> https://www.ietf.org/mailman/listinfo/oauth
=0A
=0A




=0A
_______________________________________________
OAuth mailing list=
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--835683298-1479337183-1329626093=:59538-- From andredemarre@gmail.com Sat Feb 18 21:52:54 2012 Return-Path: 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 8648F21F84E6 for ; Sat, 18 Feb 2012 21:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.989 X-Spam-Level: X-Spam-Status: No, score=-2.989 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 IBlsKA6BmfIR for ; Sat, 18 Feb 2012 21:52:53 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4097921F84E4 for ; Sat, 18 Feb 2012 21:52:53 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so5394525pbc.31 for ; Sat, 18 Feb 2012 21:52:52 -0800 (PST) Received-SPF: pass (google.com: domain of andredemarre@gmail.com designates 10.68.233.74 as permitted sender) client-ip=10.68.233.74; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andredemarre@gmail.com designates 10.68.233.74 as permitted sender) smtp.mail=andredemarre@gmail.com; dkim=pass header.i=andredemarre@gmail.com Received: from mr.google.com ([10.68.233.74]) by 10.68.233.74 with SMTP id tu10mr47772706pbc.98.1329630772982 (num_hops = 1); Sat, 18 Feb 2012 21:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QIxkmcYoZp6LbCE1eJ1TrG0Y21HlI6cLgN7QWbGSrbA=; b=Q9zgh2y+dde/hctZ6rwKUMp/SrZsVJYDEKzzlPiFMWoLtvCvK2ky7SUu6iGnukjAx6 5qzus1xB6xKlnVxa6Cig2FkB1/aPC5H4+CDXO5BNzTMA47AQQd5zH9mhMtjHCulc1suf YK/hFAsdDj6Gpd2qKhZOjvv7UaTpV4nMHfHYk= MIME-Version: 1.0 Received: by 10.68.233.74 with SMTP id tu10mr39182858pbc.98.1329630771775; Sat, 18 Feb 2012 21:52:51 -0800 (PST) Received: by 10.68.25.193 with HTTP; Sat, 18 Feb 2012 21:52:51 -0800 (PST) In-Reply-To: References: <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> Date: Sat, 18 Feb 2012 21:52:51 -0800 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: Wenjie Lin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 05:52:54 -0000 The spec already does what you ask... Wenjie Lin wrote: > as an Option, Authorization Server may choose not to include the scope > response parameter to inform Client of the actual scope granted, and > that results in the scope attack. That's not true. Consider draft-ietf-oauth-v2-23 section 3.3: The authorization server MAY fully or partially ignore the scope requested by the client based on the authorization server policy or the resource owner's instructions. If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted. See also draft-ietf-oauth-v2-23 section 5.1 regarding issuing an access tok= en: scope OPTIONAL, if identical to the scope requested by the client, otherwise REQUIRED. The scope of the access token as described by Section 3.3. Regards, Andre DeMarre On Sat, Feb 18, 2012 at 8:18 PM, Wenjie Lin wrote: > We appreciate your attention and response to our report. > > > > Since Authorization Server obtains the scope information ONLY from User, = it > can=92t tell whether the issued access token scope=A0 is different from t= he one > requested by Client, so long as User is consistently sending the same > altered scope information to Authorization Server. Consequently, as an > Option, Authorization Server may choose not to include the scope response > parameter to inform Client of the actual scope granted, and that results = in > the scope attack. This is a protocol issue and is not an implementation > issue; one can come up with an implementation that is compliant with the > protocol specification yet with a scope attack. > > > > One may argue that we only care about User protection and security. > Consequently, scope attack is apparently not a protocol security issue. > However, it would significantly limit the applicability of the protocol, = if > Client is knowingly exposed to attacks. We need Client protection and > security as well in applications, for instance, cloud services. > > > > Scope attack can be easily fixed. One can simply make it Required that > Authorization Server MUST include the scope response parameter to inform > Client of the actual scope granted, as we have proposed for your > consideration. > > > > OAuth 2.0 is a sound protocol design. We prove the security properties (f= or > both User and Client) and scope attack is an issue we=92ve got stuck in t= he > proof. > > > > - W. Lin and D. Lee > > > On Sat, Feb 18, 2012 at 2:47 PM, John Bradley wrote: >> >> I agree that it is not a protocol problem. >> >> The problem is that some developers are not understanding the spec. >> >> One case I saw recently was a proposal to send a scope to the >> Authorization endpoint that changed is authentication behaviour e.g. ask= for >> mlti-factor authentication. >> >> On a superficial reading of the spec they thought that not getting a >> changed set of scopes back in the response that the Authorization server= was >> indicating that it had done what was asked. >> >> When I pointed out that the user agent can remove scopes because request= s >> are not signed, =A0they had a similar solution of forcing all the endpoi= nts to >> always return the scopes granted. >> >> I hope I talked them out of that. >> >> The problem is getting people to use scopes to represent resources and n= ot >> other arbitrary configuration things, =A0and to understand that even if = they >> do get a scope granted it could disappear before they get to use the acc= ess >> token and they need to be prepared for that. >> >> The premise that users get access to y for access to x is something that >> can be built with OAuth but is not something that can be inferred in the= way >> they are proposing. >> >> From my perspective replying with granted scopes is a convince for the >> client, but not something that can be depended upon. >> I don't think we need any normative change. >> >> A don't make stupid assumptions about the persistence of scopes in token= s >> note would be as far as I would go. >> >> John B. >> >> On 2012-02-18, at 3:34 AM, Shane B Weeden wrote: >> >> > I agree with others - this is not an attack on the protocol. The user >> > has >> > the choice about which scope to grant and the client's redirect to the >> > authorization endpoint is only a request for a particular set of >> > permissions, not a guarantee that it will get them. The >> > user+authorization >> > server decide which scope is actually granted. The client needs to >> > handle >> > cases where that differs from what it originally wanted. >> > >> > >> > >> > >> > From: Wenjie Lin >> > To: =A0 oauth@ietf.org >> > Date: 18/02/2012 12:12 PM >> > Subject: =A0 =A0 =A0[OAUTH-WG] A Scope Attack against OAuth 2.0 >> > Sent by: =A0 =A0 =A0oauth-bounces@ietf.org >> > >> > >> > >> > We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called >> > scope >> > attack, provide a live-demo of the attack on Facebook, and propose a f= ix >> > with discussions. >> > >> > >> > >> > >> > >> > Scope Attack >> > >> > >> > OAuth authorization of services is associated with service agreement >> > scope. >> > For instance, Client provides an online game to User with a service >> > agreement scope A: User authorizes Client to access his profile >> > information >> > and to post messages on his behalf. A malicious User can request for >> > online >> > game with service agreement scope A, manipulate the scope field, and >> > change >> > it to scope B: User authorizes Client to access his profile informatio= n. >> > User can still play the games, =A0yet Client can=92t post messages on = User=92s >> > behalf, as originally agreed. >> > >> > >> > OAuth 2.0 authorization code grant and implicit grant are vulnerable t= o >> > the >> > scope attack. >> > >> > >> > >> > >> > >> > A Scope Attack Scenario >> > >> > >> > (1) Authorization Server: Facebook (authorization code grant) >> > >> > >> > =A0 =A0 =A0(2) Client: Online gaming company Game. It allows User to p= lay the >> > =A0 =A0 =A0games with the service agreement scope A: User authorizes G= ame to >> > =A0 =A0 =A0access his profile information and post messages on his beh= alf. >> > >> > >> > =A0 =A0 =A0(3) User: malicious User with an account at Facebook. He at= tempts >> > to >> > =A0 =A0 =A0play the games yet without authorizing Game to post message= s on his >> > =A0 =A0 =A0behalf, that is, he changes the scope from A to B: authoriz= ation of >> > =A0 =A0 =A0Client to access his profile information only. >> > >> > >> > >> > >> > >> > Attack Workflow >> > >> > >> > =A0 =A0 =A0 =A0(1) User requests Game (Client) for permission to play = games, >> > =A0 =A0 =A0 =A0instantiating OAuth 2.0 with scope A. >> > >> > >> > =A0 =A0 =A0 =A0(2) Game generates an authorization request with a scop= e >> > =A0 =A0 =A0 =A0specification A, and redirects User to Facebook with th= e request. >> > >> > >> > =A0 =A0 =A0 =A0(3) User manipulates the scope field and changes it to = scope B. >> > The >> > =A0 =A0 =A0 =A0modified request is then sent to Facebook. >> > >> > >> > =A0 =A0 =A0 =A0(4) User grants the modified request. >> > >> > >> > =A0 =A0 =A0 =A0(5) Facebook redirects User back to Game with the autho= rization >> > =A0 =A0 =A0 =A0code. >> > >> > >> > =A0 =A0 =A0 =A0(6) Game exchanges the authorization code for an access= token. >> > =A0 =A0 =A0 =A0However it has no knowledge that the scope A has been c= hanged to >> > =A0 =A0 =A0 =A0scope B. >> > >> > >> > =A0 =A0 =A0 =A0(7) Game provides online gaming service to User. Howeve= r, Game >> > =A0 =A0 =A0 =A0can=92t post messages on User=92s Facebook page. >> > >> > >> > >> > >> > >> > A Live-Demo: Facebook and CastleVille (IE and Safari tested) >> > >> > >> > =A0 =A0 =A0Step 1: Login Facebook and visit Facebook Apps and Game pag= e >> > >> > >> > =A0 =A0 =A0https://www.facebook.com/games >> > >> > >> > Step 2: Click CastleVille. >> > >> > >> > =A0 =A0 =A0Step 3: When you see the Request for Permission page, inste= ad of >> > >> > >> > =A0 =A0 =A0 =A0 =A0 =A0clicking =93Allow=94, change the scope field in= the URL from your >> > =A0 =A0 =A0 =A0 =A0 =A0browser from >> > =A0=93scope=3Demail%2Cpublish_stream%2Cpublish_actions=94 >> > =A0 =A0 =A0 =A0 =A0 =A0to =93scope=3Demail%2Cpublish_stream=94. >> > >> > >> > =A0 =A0 =A0Step 4: After the modification, press ENTER to send the mod= ified >> > >> > >> > =A0 =A0 =A0 =A0 =A0 =A0request to Facebook. Now you will see the modif= ied Request of >> > =A0 =A0 =A0 =A0 =A0 =A0Permission page. >> > >> > >> > Step 5: Click on =93Allow=94 button and enjoy the game. >> > >> > >> > (video: http://www.youtube.com/watch?v=3DzkmjLa3VU9w) >> > >> > >> > >> > >> > >> > Impact >> > >> > >> > Client provides services to malicious User yet with the modified servi= ce >> > agreement scope by User=92s design. >> > >> > >> > >> > >> > >> > Manipulating Scope Field >> > >> > >> > The scope field in access token response is required ONLY IF >> > Authorization >> > Server observes that the User authorized scope is different than the >> > original scope. Consequently, User can manipulate the scope field so >> > that >> > Authorization Server cannot detect the change of the scope. As a resul= t >> > Client provides the services yet can=92t obtain the information that i= s >> > specified in the scope of the original service agreement. >> > >> > >> > Client can verify the service agreement scope by checking all the fiel= ds >> > against the original User request before providing the requested >> > services >> > to User. =A0For instance, Client can verify the granted permissions if >> > Authorization Server (e.g. Facebook) =A0provides an API. However, this= is >> > out >> > of the scope of OAuth 2.0, and Client may not check it. We observe: al= l >> > top >> > five games recommended by Facebook are vulnerable to the scope attack. >> > >> > >> > >> > >> > >> > Proposed Fix >> > >> > >> > Draft-ietf-oauth-v2-23 Section 5.1: >> > >> > >> > Change from >> > >> > >> > =A0 =A0 =A0=93scope >> > >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 OPTIONAL, if identical to the scope reques= ted by the >> > client, >> > >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 otherwise REQUIRED.=94 >> > >> > >> > to >> > >> > >> > =93scope REQUIRED=94 /* scope: User authorized scope */ >> > >> > >> > >> > >> > >> > Remarks >> > >> > >> > (1) The proof of the correctness of OAuth with our proposed fix will b= e >> > published in an article: =93OAuth 2.0 =96 Attacks, Fixes, Correctness,= and >> > Generalizations, Wenjie Lin, David Lee and Steve Lai, to appear=94. >> > >> > >> > (2) The implicit grant is also vulnerable to the scope attack. However >> > it >> > cannot be fixed by enforcing scope field in access token response as >> > above; >> > User can change the scope in response before being redirected to Clien= t. >> > >> > >> > >> > >> > >> > Wenjie Lin, The Ohio State University >> > >> > >> > David Lee, HP Labs and The Ohio State University >> > >> > >> > Steve Lai, The Ohio State University >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From andrewarnott@gmail.com Sun Feb 19 07:08:52 2012 Return-Path: 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 6806521F847A for ; Sun, 19 Feb 2012 07:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 CRv6PSEgT-wu for ; Sun, 19 Feb 2012 07:08:51 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id AA96D21F8472 for ; Sun, 19 Feb 2012 07:08:51 -0800 (PST) Received: by qan41 with SMTP id 41so5115412qan.10 for ; Sun, 19 Feb 2012 07:08:51 -0800 (PST) Received-SPF: pass (google.com: domain of andrewarnott@gmail.com designates 10.229.106.221 as permitted sender) client-ip=10.229.106.221; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andrewarnott@gmail.com designates 10.229.106.221 as permitted sender) smtp.mail=andrewarnott@gmail.com; dkim=pass header.i=andrewarnott@gmail.com Received: from mr.google.com ([10.229.106.221]) by 10.229.106.221 with SMTP id y29mr12483070qco.88.1329664131307 (num_hops = 1); Sun, 19 Feb 2012 07:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=SkQcwOvCbi7+IQNQ8GRgRU7yg5QGqY/n+dpyNPGPEno=; b=BQp7Xw/8VjJORDSVD37tPId1HMhangd3yASJ8MV+2DpbfV2NQVUWQ6zprJo2LHjewX P4CgWAmFtAlE2vkHOkgVpwHhEIhVJJtBJ+VaTdhiLzQ96ExFrlADYbGzQzbQYc7uAMvp 0Z2j3VsxW/eZ0ZfowYyv3dcJL4mG9xqhtxqH8= Received: by 10.229.106.221 with SMTP id y29mr10611015qco.88.1329664131217; Sun, 19 Feb 2012 07:08:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.25.8 with HTTP; Sun, 19 Feb 2012 07:08:31 -0800 (PST) From: Andrew Arnott Date: Sun, 19 Feb 2012 07:08:31 -0800 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=002354470f6c36382a04b9528e68 Subject: [OAUTH-WG] Section 10.3 client advice inapplicable? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 15:08:52 -0000 --002354470f6c36382a04b9528e68 Content-Type: text/plain; charset=ISO-8859-1 >From draft 23, section 10.3: The client SHOULD request access tokens with the minimal scope and lifetimenecessary. The authorization server SHOULD take the client identity into account when choosing how to honor the requested scope and lifetime, and MAY issue an access token with a less rights than requested. I can't find the part in the spec where the client can request access tokens in such a way as to influence the lifetime. Why is the client then being advised in the above section to minimize the lifetime of the access tokens it asks for? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --002354470f6c36382a04b9528e68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
From draft 23, section 10.3:

The client SHOULD request acc= ess tokens with the minimal scope and lifetime necessary. The authorization server SHOULD take the client identi= ty into account when choosing how to honor the requested scope and lifetime= , and MAY issue an access token with a less rights than requested.

I can't find the part in the= spec where the client can request access tokens in such a way as to influe= nce the lifetime. =A0Why is the client then being advised in the above sect= ion to minimize the lifetime of the access tokens it asks for?

--
Andrew Arnott
"I [may] not agree with what = you have to say, but I'll defend to the death your right to say it.&quo= t; - S. G. Tallentyre
--002354470f6c36382a04b9528e68-- From ve7jtb@ve7jtb.com Sun Feb 19 07:31:49 2012 Return-Path: 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 1333E21F8549 for ; Sun, 19 Feb 2012 07:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 l7DJkExJhqge for ; Sun, 19 Feb 2012 07:31:48 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCF621F8545 for ; Sun, 19 Feb 2012 07:31:48 -0800 (PST) Received: by yenm3 with SMTP id m3so2698378yen.31 for ; Sun, 19 Feb 2012 07:31:47 -0800 (PST) Received-SPF: pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.79.138 as permitted sender) client-ip=10.236.79.138; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.79.138 as permitted sender) smtp.mail=ve7jtb@ve7jtb.com Received: from mr.google.com ([10.236.79.138]) by 10.236.79.138 with SMTP id i10mr17395891yhe.12.1329665507768 (num_hops = 1); Sun, 19 Feb 2012 07:31:47 -0800 (PST) Received: by 10.236.79.138 with SMTP id i10mr13360825yhe.12.1329665507690; Sun, 19 Feb 2012 07:31:47 -0800 (PST) Received: from [192.168.1.213] (186-107-131-167.baf.movistar.cl. [186.107.131.167]) by mx.google.com with ESMTPS id a24sm15038605ana.10.2012.02.19.07.31.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Feb 2012 07:31:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_3035A7A6-6D7F-4C7B-B4CF-12BB252492F0"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Sun, 19 Feb 2012 12:31:42 -0300 Message-Id: <61C6C5B6-A678-41A6-BC5B-4FE81D4E266C@ve7jtb.com> References: To: Andrew Arnott X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmwsFIQvB12N7OhGzR6yrpOjGFTlMDS6QrwrlDpn4+jCWQroJTBLC3nPtsxujEeP7CeE3oU Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Section 10.3 client advice inapplicable? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 15:31:49 -0000 --Apple-Mail=_3035A7A6-6D7F-4C7B-B4CF-12BB252492F0 Content-Type: multipart/alternative; boundary="Apple-Mail=_924C1E36-21F1-4C7A-9FDD-A48F08BA98A0" --Apple-Mail=_924C1E36-21F1-4C7A-9FDD-A48F08BA98A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 There is nothing explicit in draft 23 about requesting a scope lifetime. = It is as they say fuzzy. You know that some people have used additional scopes like = offline_access to request longer lifetimes. It may be reasonable to preconfigure something at the tAuthorization = server based on client_id, but there is also the question of how to = present the options to the user in an understandable way. Fortunately or unfortunately this has been punted to the specs using = OAuth to define. =20 How to deal with this question for openID Connect is on the agenda for = our F2F in San Francisco on Mar 2. John B.=20 On 2012-02-19, at 12:08 PM, Andrew Arnott wrote: > =46rom draft 23, section 10.3: > The client SHOULD request access tokens with the minimal scope and = lifetime necessary. The authorization server SHOULD take the client = identity into account when choosing how to honor the requested scope and = lifetime, and MAY issue an access token with a less rights than = requested. >=20 >=20 > I can't find the part in the spec where the client can request access = tokens in such a way as to influence the lifetime. Why is the client = then being advised in the above section to minimize the lifetime of the = access tokens it asks for? >=20 > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the = death your right to say it." - S. G. Tallentyre > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_924C1E36-21F1-4C7A-9FDD-A48F08BA98A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 There = is nothing explicit in draft 23 about requesting a scope lifetime. =   It is as they say fuzzy.

You know that some = people have used additional scopes like offline_access to request longer = lifetimes.

It may be reasonable to preconfigure = something at the tAuthorization server based on client_id,  but = there is also the question of how to present the options to the user in = an understandable way.

Fortunately or = unfortunately this has been punted to the specs using OAuth to define. =    

How to deal with this question = for openID Connect is on the agenda for our F2F in San Francisco on Mar = 2.

John B. 
On 2012-02-19, at = 12:08 PM, Andrew Arnott wrote:

=46rom = draft 23, section 10.3:

The client SHOULD request = access tokens with the minimal scope and lifetime necessary. The = authorization server SHOULD take the client identity into account when = choosing how to honor the requested scope and lifetime, and MAY issue an = access token with a less rights than requested.


I can't find the part in = the spec where the client can request access tokens in such a way as to = influence the lifetime.  Why is the client then being advised in = the above section to minimize the lifetime of the access tokens it asks = for?

--
Andrew Arnott
"I [may] not agree with what = you have to say, but I'll defend to the death your right to say it." - = S. G. Tallentyre
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_924C1E36-21F1-4C7A-9FDD-A48F08BA98A0-- --Apple-Mail=_3035A7A6-6D7F-4C7B-B4CF-12BB252492F0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MTkxNTMxNDJaMCMGCSqGSIb3DQEJBDEWBBS7cIxa7uZI0/fQsXjmbiznBVYcaDCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQAfDVekQ6LEFYH4t+rAS/VbmXNdRtRRyQn9k6485Cyjcj1YWOWfJ75bzoNjDupUwzPHfvvo9rmj 6D3FT9sHnLUinikRDQacq6Hq1V2RBdm5m2OmbmFg3HlERIWkxljJpk8X2Vn9RBjCgeiB0EKv5oSH eEX/JjvC9Bqt5kHTtbbMyDi/AIYDdu+Hc/kprdx9KaeV1ud/mDXx00o778l9ijAyGzjAUHOo1QE1 wOgMxjAW45v+pP9vIAzriWShzi7l8R3IjEiGXkhDI7elJxTyATTKwq8T0cTyUfHeqo785DRObew1 ODmDXOioqpxIPNAmUv1/XPlzAOEn/Iir8sQ6yjXKAAAAAAAA --Apple-Mail=_3035A7A6-6D7F-4C7B-B4CF-12BB252492F0-- From andrewarnott@gmail.com Sun Feb 19 07:36:13 2012 Return-Path: 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 4CF2121F8554 for ; Sun, 19 Feb 2012 07:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_LOW=-1] 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 aMt1FCct+P6C for ; Sun, 19 Feb 2012 07:36:12 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1B5121F8552 for ; Sun, 19 Feb 2012 07:36:12 -0800 (PST) Received: by qafi29 with SMTP id i29so2347187qaf.10 for ; Sun, 19 Feb 2012 07:36:12 -0800 (PST) Received-SPF: pass (google.com: domain of andrewarnott@gmail.com designates 10.229.135.201 as permitted sender) client-ip=10.229.135.201; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andrewarnott@gmail.com designates 10.229.135.201 as permitted sender) smtp.mail=andrewarnott@gmail.com; dkim=pass header.i=andrewarnott@gmail.com Received: from mr.google.com ([10.229.135.201]) by 10.229.135.201 with SMTP id o9mr12444292qct.148.1329665772296 (num_hops = 1); Sun, 19 Feb 2012 07:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=ranvJbWyYz+9/PkJ/n8idp4dLgavaS5NAyzHkUdg98E=; b=i8gLc+kZT3ugTT3OIPsGhQUqmm24uPlXrMsFI9KYZfkBdTipkDceMlpCQSZx3iMNGE lJ3VzF1OCREDh5mIXDRrShP+o7UFaMGv1EslXAD9Ro8dlTS9kOcBLxtsAYhKLnXCmbNh zw90C3tBeyGJvCzH7AZPVEveVSctWPvl3YwcE= Received: by 10.229.135.201 with SMTP id o9mr10588219qct.148.1329665772209; Sun, 19 Feb 2012 07:36:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.25.8 with HTTP; Sun, 19 Feb 2012 07:35:52 -0800 (PST) From: Andrew Arnott Date: Sun, 19 Feb 2012 07:35:52 -0800 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=00248c6a862e05c6df04b952f033 Subject: [OAUTH-WG] How an AS can validate the state parameter? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 15:36:13 -0000 --00248c6a862e05c6df04b952f033 Content-Type: text/plain; charset=ISO-8859-1 >From section 10.14: (draft 23) > > The Authorization server and client MUST validate and sanitize any value > received, and in particular, the value of the state and redirect_uri > parameters. Elsewhere in the spec the AS is instructed to exactly preserve the state and to consider it an opaque value. How then, can an AS validate and sanitize the state parameter? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --00248c6a862e05c6df04b952f033 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >From section 10.14: (draft 23)
The Authorization server and client MUST val= idate and sanitize any value received, and in particular, the value of the= =A0state=A0and=A0redirect_uri=A0parameters.

Elsewhere in the spec the AS is instructed= to exactly preserve the state and to consider it an opaque value. =A0How t= hen, can an AS validate and sanitize the state parameter?

--
Andrew Arnott
"I [may] not agree with what you have to= say, but I'll defend to the death your right to say it." - S. G. = Tallentyre
--00248c6a862e05c6df04b952f033-- From internet-drafts@ietf.org Sun Feb 19 09:00:48 2012 Return-Path: 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 90D9F21F84F4; Sun, 19 Feb 2012 09:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 wSPt7tyIQOAU; Sun, 19 Feb 2012 09:00:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB1B21F84B8; Sun, 19 Feb 2012 09:00:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120219170026.10410.2700.idtracker@ietfa.amsl.com> Date: Sun, 19 Feb 2012 09:00:26 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 17:00:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : OAuth 2.0 Threat Model and Security Considerations Author(s) : Torsten Lodderstedt Mark McGloin Phil Hunt Filename : draft-ietf-oauth-v2-threatmodel-02.txt Pages : 65 Date : 2012-02-19 This document gives security considerations based on a comprehensive threat model for the OAuth 2.0 Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-02.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-threatmodel-02.txt From torsten@lodderstedt.net Sun Feb 19 09:16:43 2012 Return-Path: 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 BBF3321F852A; Sun, 19 Feb 2012 09:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.568 X-Spam-Level: X-Spam-Status: No, score=0.568 tagged_above=-999 required=5 tests=[AWL=-1.897, BAYES_40=-0.185, HELO_EQ_DE=0.35, MANGLED_LIST=2.3] 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 ODVjYHo+ajCm; Sun, 19 Feb 2012 09:16:42 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3B36A21F8525; Sun, 19 Feb 2012 09:16:42 -0800 (PST) Received: from [79.253.29.122] (helo=[192.168.71.36]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1RzANL-0003Tq-Dk; Sun, 19 Feb 2012 18:16:39 +0100 Message-ID: <4F412E76.6080408@lodderstedt.net> Date: Sun, 19 Feb 2012 18:16:38 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Tim Bray References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> In-Reply-To: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: S Moonesamy , apps-discuss@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 17:16:43 -0000 Hi Tim, I just submitted the revised version of the OAuth 2.0 security document (http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-02). This revision should address the issues you raised in your AppsDir review. We especially removed all normative language from the document. We took the liberty to leave the back references in Section 5. We consider this back references to section 4 a valuable information for implementors since they justify the particular countermeasure. All to often security considerations are given without the corresponding rationales. And without a justification, the "unconvinced" implementor may tend to ignore or underestimate the respective controls. regards, Torsten. Am 23.01.2012 22:47, schrieb S Moonesamy: > The following is the AppsDir review performed by Tim Bray. It would > be appreciated if a reply is sent to Tim Bray with a copy to the > apps-discuss mailing list. > > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-oauth-v2-threatmodel-01 > Title: OAuth 2.0 Threat Model and Security Considerations > Reviewer: Tim Bray > Review Date: Jan 23, 2012 > > Summary: This needs some more editorial work, but is basically sound. > It's not clear, though, whether it wants to be an Informational RFC or > not; the use of RFC2119 language needs special attention. I think a > few of the "minor issues" are worthy of a little bit more work in > another draft. > > Major Issues: > > The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. I > normally wouldn't expect a "threat model" to include normative text. > The basic idea would be to say "Here is an enumeration of the threats, > and here are the tools available to OAUTH2 implementors to meet them." > I was impressed by the enumeration, which seemed very complete and > well thought through. But the usage of 2119, which makes statements > normative, seems inconsistent. I can think of 2 ways to address this: > > 1. Remove all the 2119 words, so this document isn't normative, and > publish it as an Informational RFC > 2. Go through and clean up the 2119 language so it's used > consistently; then this becomes a normative document. > > This is going to affect the references to this document from other > I-Ds in the OAuth suite, which are currently in last call. > > Here are all the section-numbered notes enumerating my issues around > 2119, as I encountered them: > > Section 2.3, I'm a little confused about the use of RFC2119 MAY in a > threat analysis. When you say "The following data elements MAY be > stored or accessible...", Is this saying that "The OAuth2 RFC says > that the following data elements MAY be..." or is it saying something > else. I don't think there's anything seriously wrong here, but a bit > more explanation might be in order. I note a comparative absence of > 2119-ese in section 5 describing countermeasures, where one would > expect to find it. > Also in 4.3.1, first bullet point, there's "Authorization servers > MUST..." > Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 > Related: "SHALL"?! in 4.6.3 > Adding to the concern, there is use of lower-case "must"; note 2nd & > 3rd bullet points in 4.4.3, which use "MUST" and "must" respectively. > > Minor Issues: > > 4.1.2 first attack: It says "An attack may obtain the refresh tokens > issued to a web server client." This needs to be clearer... a "Web > server client" can be a browser or a native app. Do you mean, "the > refresh tokens issued by the web server to multiple clients?" > > 4.1.2 last attack. In the case where a device is cloned, wouldn't > "Utilize device lock to prevent unauthorized device access" still be a > countermeasure? In many devices, such cloning would carry along the > user's device-lock settings. > > 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for > native clients wasn't comprehensible to me. I'm suspicious of any > such claims because I can emulate most things a browser can do in a > mobile client. Perhaps this would be obvious to someone who is an > OAuth2 implementor. > > 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a > Web Browser control embedded in the native app. If that's not what it > means, I don't understand what it's saying. If this is true, then the > second bullet point is probably wrong. > > 4.6.6 1st bullet. I'm not convinced that the Cache-Control header > will *ensure* that a client protects information properly. Should say > something like "minimize the risk that authenticated content is not > protected" > > 5.* The enumeration, for some but not all of the countermeasures in > this section, of the threats against which this is a countermeasure, > reduces readability and, unless it's generated automatically from the > underlying source, is redundant information, which is unlikely to be > consistent between sections 4 and 5, and adds difficulty to > maintenance of this document without adding much value. I'd just wipe > all these bullet lists out. If it's generated automatically it's less > damaging, but still reduces readability. In the current draft, this > is there for some countermeasures but absent for others. Another good > reason to just take it out. > > 5.2.2.5 Device identifiers are very tricky. It's correct that IMEI is > not adequate, but there are ways to do it without SMS. For more, see > http://android-developers.blogspot.com/2011/03/identifying-app-installations.html > > > 5.3.4 Surely a little more could be said about device lock. On a > typical modern phone, "device lock" options include PINs, passwords, > "face recognition" and so on. These are *not* equal in their level of > security they provide. > > Nits: > > Formatting is lousy. There are notations, including ** and _whatever_ > that I'm not familiar with in the RFC context. > > Section 1.0: s/in-built into/built into/ > 2.1, last bullet point: "An example could by a..." s/by/be/ > 2.2, 1st bullet point s/eaves drop/eavesdrop/ > 2.3, 1st para, s/treat/threat/ > 2.3.1, last bullet, "per authorization process". Adjectival phrases > should be hyphenated: "per-authorization process" > 2.3.3, last bullet, ditto > 3.1, 1st para, "all kinds of tokens" should be "many kinds of tokens" > 3.1, 2nd para, should be ; not , after "within the authorization server" > s/protected/protect/ > s/different system/different systems/ > 3.4 1st para, s/intermediary/intermediate/ > list item 1. s/short-living/short-lived/ > 3.5 s/malicious client/malicious clients/ > 3.7 top of page 12, what is the underscore notation _client_id_ mean? > I'm not familiar with this in the RFC context. > 1st bullet point: s/token/token's/ > 2nd bullet point, multiple issues, 1st sentence should be " the > initial authorization and issuance of a token by an end-user > to a particular client, and subsequent requests by this client to > obtain tokens without user consent (automatic processing of repeated > authorization) > halfway down page 13, s/insures/ensures/ > s/validates the clients/validates the client's/ > 4. first sentence, s/this sections/this section/ > 4.1.2 first para, the last sentence is confusing. How about: "Before > enumerating the threats, here are some generally applicable > countermeasures:" > 4.2.4 2nd bullet s/could not be/can not be/ > 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests" - I > assume that's supposed to be a hyperlink to one of the 5.* sections? > 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that the > referrer header may contain an Authorization code in a ?a=b style > argument > 4.4.1.2 first bullet, "can be employed" is inconsistent with style of > rest of doc > 4.4.1.3 first 2 bullets have un-labeled links. > 4.4.1.4 1st bullet s/authentication/authenticate/ > 4.4.1.4 2nd bullet s/mean/means/ > 4.4.1.7 2nd bullet s/tokens/token's/ > 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ > 4.4.1.10, 3rd bullet, s/aibility/ability/ > 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ > 4.4.1.12 I think the href to semicomplete.com needs to be turned into > an IETF-style reference > 4.4.2 " since HTTP user agents do not send fragments server requests." > What you mean to say is "Since HTTP user agents do not send the > fragment part of URIs to HTTP servers." > 4.4.2.2 s/browser/browser's/ > 5.1.4.1.3 s/consider to not store/refrain from storing/ > 5.* s/may consider to $(verb)/may consider $(verb)ing/ > 5.1.6 Needs some sort of sentence structure > 5.3.2 Needs some sort of sentence structure; or is this intended just > to be a title, with 5.3.3 etc nested under it? > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nov@matake.jp Mon Feb 20 06:11:50 2012 Return-Path: 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 7C93421F8760 for ; Mon, 20 Feb 2012 06:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 lX738f0T1IXb for ; Mon, 20 Feb 2012 06:11:50 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05F0D21F8757 for ; Mon, 20 Feb 2012 06:11:49 -0800 (PST) Received: by dakl33 with SMTP id l33so6080585dak.31 for ; Mon, 20 Feb 2012 06:11:49 -0800 (PST) Received-SPF: pass (google.com: domain of nov@matake.jp designates 10.68.129.73 as permitted sender) client-ip=10.68.129.73; Authentication-Results: mr.google.com; spf=pass (google.com: domain of nov@matake.jp designates 10.68.129.73 as permitted sender) smtp.mail=nov@matake.jp Received: from mr.google.com ([10.68.129.73]) by 10.68.129.73 with SMTP id nu9mr26722228pbb.100.1329747109773 (num_hops = 1); Mon, 20 Feb 2012 06:11:49 -0800 (PST) Received: by 10.68.129.73 with SMTP id nu9mr22840095pbb.100.1329747109730; Mon, 20 Feb 2012 06:11:49 -0800 (PST) Received: from [192.168.1.103] (q032020.dynamic.ppp.asahi-net.or.jp. [203.181.32.20]) by mx.google.com with ESMTPS id n8sm13297672pbf.22.2012.02.20.06.11.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Feb 2012 06:11:48 -0800 (PST) From: nov matake Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Feb 2012 23:11:56 +0900 Message-Id: <58932B8B-2DDE-41D6-A91B-5036CC762C00@matake.jp> To: oauth WG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkrtVAL8q3If0SS4NpRYBBKg/JMckk1itt20SIw6DdsRRbn5Sbzt72mejjaL9lHxjdDl7vo Subject: [OAUTH-WG] Quick question about error response for "response_type=unknown" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:11:50 -0000 Hi OAuthers, My apologies if you already discussed this. When OAuth server received unknown response_type, how should the server = handle the error? 1. Show the error to the user without redirecting back to the client 2. Redirect back to the client including the error in query 3. Redirect back to the client including the error in fragment Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for = me. -- nov= From wmills@yahoo-inc.com Mon Feb 20 08:58:13 2012 Return-Path: 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 2070B21F87BE for ; Mon, 20 Feb 2012 08:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.205 X-Spam-Level: X-Spam-Status: No, score=-16.205 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_40=-0.185, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 4dJavOVG7ppM for ; Mon, 20 Feb 2012 08:58:09 -0800 (PST) Received: from nm10-vm0.bullet.mail.sp2.yahoo.com (nm10-vm0.bullet.mail.sp2.yahoo.com [98.139.91.198]) by ietfa.amsl.com (Postfix) with SMTP id 63A1F21F87C4 for ; Mon, 20 Feb 2012 08:58:09 -0800 (PST) Received: from [98.139.91.69] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 20 Feb 2012 16:58:09 -0000 Received: from [98.139.91.31] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 20 Feb 2012 16:57:09 -0000 Received: from [127.0.0.1] by omp1031.mail.sp2.yahoo.com with NNFMP; 20 Feb 2012 16:57:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 253351.92165.bm@omp1031.mail.sp2.yahoo.com Received: (qmail 28207 invoked by uid 60001); 20 Feb 2012 16:57:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1329757028; bh=T0AJZYXfqrDtuvwVYv6NuKQgkP7qgLdGQiU3ypiryao=; 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=lj28Fh/f6fbzxtlX7otTc0WXYlJYaNjo/jh6TzjVSHOHjkE4HdHlLEEJeQ+yKAvlvOERVuL7/2lPf7OfouSEqz0YakqDAMi2EecsQMmb51if4T/tt5MxjuUY5y+CFJw/l0Xy1p+Ai72P9Y13TTiP3NOpYMWd6HgfJ8/ruJDhi3Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; 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=rWpOYnziU2HF+bETpx8wiCk9nONXgd/xW8mtWxBNdKob3/zDfC2gfpNwK4gR/7uzy8/JqYriSS9b7PxPVK6nKlOg1RXSMlGgdT79wl8hluekNn580ADScnKzMWOuhM8r4p7mlOFwuZLHttBceOVkj8A4nnJVJnVXmyJT1vI/Hww=; X-YMail-OSG: HwuNcJIVM1nBAFLlqOnHK3nINdzLXLJo2ZMNz_1O1QBV55Y OmxKnz4tqTDKYA.vzLLj7J7dHIIipah1CdxT4oE.P2mhw2izLH2Zuedgpbj9 4Za2LN3RGHnuklkmL.z.ENvTNZxvG5qEQhGfDbnu7GvXX1EwQVJSHTlYJE_i lYPUPUJuhbVGcP6t8iFeurHzE3ppa5V_IT5K.QylepmYDXBnyZ9.HeJ6HIvn 1WbwLmYuzlNrqztjakY.0DvJvZe1ig9NN_iqfxuz2My8tTzD9Ry.SNTyqGWE ZYM2lr4g4qruudX88xUXEV7SbWZ00RXfQpbM6pAyOzgMGstArS0Q_qAUT8oZ J9RTnFQMzR3GUc4FM27D4GekdzpISUy5qfMVbu3VWIsIpjINmN2tLeoitSIQ Yl04th4NS5nzRNg9q1u5dfg2tSP4- Received: from [99.31.212.42] by web31808.mail.mud.yahoo.com via HTTP; Mon, 20 Feb 2012 08:57:07 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340031 References: <58932B8B-2DDE-41D6-A91B-5036CC762C00@matake.jp> Message-ID: <1329757027.28055.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Mon, 20 Feb 2012 08:57:07 -0800 (PST) From: William Mills To: nov matake , oauth WG In-Reply-To: <58932B8B-2DDE-41D6-A91B-5036CC762C00@matake.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-122015295-1329757027=:28055" Subject: Re: [OAUTH-WG] Quick question about error response for "response_type=unknown" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 16:58:13 -0000 --258328648-122015295-1329757027=:28055 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Respond with an error in protocol.=A0 Thta won't include a redirect, and th= e client has to know what to do.=0A=0A=0A=0A_______________________________= _=0A From: nov matake =0ATo: oauth WG =0ASe= nt: Monday, February 20, 2012 6:11 AM=0ASubject: [OAUTH-WG] Quick question = about error response for "response_type=3Dunknown"=0A =0AHi OAuthers,=0A=0A= My apologies if you already discussed this.=0A=0AWhen OAuth server received= unknown response_type, how should the server handle the error?=0A=0A1. Sho= w the error to the user without redirecting back to the client=0A2. Redirec= t back to the client including the error in query=0A3. Redirect back to the= client including the error in fragment=0A=0ASince choosing 2 or 3 is impos= sible in this case, 1 seems reasonable for me.=0A=0A=0A--=0Anov=0A_________= ______________________________________=0AOAuth mailing list=0AOAuth@ietf.or= g=0Ahttps://www.ietf.org/mailman/listinfo/oauth --258328648-122015295-1329757027=:28055 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Respond with an error in protocol.  Thta won't include a redirect, a= nd the client has to know what to do.

From: = nov matake <nov@matake.jp>
= To: oauth WG <oauth@ietf.org>
Sent: Monday, February 20, 2012 6:11 AM
Subject: [OAUTH-WG] Quick quest= ion about error response for "response_type=3Dunknown"
<= br>=0AHi OAuthers,

My apologies if you already discussed this.
When OAuth server received unknown response_type, how should the server h= andle the error?

1. Show the error to the user without redirecting b= ack to the client
2. Redirect back to the client including the error in = query
3. Redirect back to the client including the error in fragment
=
Since choosing 2 or 3 is impossible in this case, 1 seems reasonable fo= r me.


--
nov
_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/list= info/oauth


--258328648-122015295-1329757027=:28055-- From igor.faynberg@alcatel-lucent.com Mon Feb 20 09:37:43 2012 Return-Path: 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 2656221F87B6 for ; Mon, 20 Feb 2012 09:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.265 X-Spam-Level: X-Spam-Status: No, score=-7.265 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 SM851vJm28iS for ; Mon, 20 Feb 2012 09:37:39 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 323EC21F87B3 for ; Mon, 20 Feb 2012 09:37:39 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q1KHbaBQ023641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 Feb 2012 11:37:36 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q1KHbZ7t002600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 20 Feb 2012 11:37:36 -0600 Received: from [135.244.28.45] (faynberg.lra.lucent.com [135.244.28.45]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q1KHbYCW011096; Mon, 20 Feb 2012 11:37:35 -0600 (CST) Message-ID: <4F4284DD.3030006@alcatel-lucent.com> Date: Mon, 20 Feb 2012 12:37:33 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <58932B8B-2DDE-41D6-A91B-5036CC762C00@matake.jp> <1329757027.28055.YahooMailNeo@web31808.mail.mud.yahoo.com> In-Reply-To: <1329757027.28055.YahooMailNeo@web31808.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------030700050502030407090607" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] Quick question about error response for "response_type=unknown" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 17:37:43 -0000 This is a multi-part message in MIME format. --------------030700050502030407090607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Could there be a potential security hole in providing an error response? (Not that I see it, but many problems in the past had been caused by helpful responese.) Igor On 2/20/2012 11:57 AM, William Mills wrote: > Respond with an error in protocol. Thta won't include a redirect, and > the client has to know what to do. > > ------------------------------------------------------------------------ > *From:* nov matake > *To:* oauth WG > *Sent:* Monday, February 20, 2012 6:11 AM > *Subject:* [OAUTH-WG] Quick question about error response for > "response_type=unknown" > > Hi OAuthers, > > My apologies if you already discussed this. > > When OAuth server received unknown response_type, how should the > server handle the error? > > 1. Show the error to the user without redirecting back to the client > 2. Redirect back to the client including the error in query > 3. Redirect back to the client including the error in fragment > > Since choosing 2 or 3 is impossible in this case, 1 seems reasonable > for me. > > > -- > nov > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030700050502030407090607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Could there be a potential security hole in providing an error response?  (Not that I see it, but many problems in the past had been caused by helpful responese.)

Igor

On 2/20/2012 11:57 AM, William Mills wrote:
Respond with an error in protocol.  Thta won't include a redirect, and the client has to know what to do.

From: nov matake <nov@matake.jp>
To: oauth WG <oauth@ietf.org>
Sent: Monday, February 20, 2012 6:11 AM
Subject: [OAUTH-WG] Quick question about error response for "response_type=unknown"

Hi OAuthers,

My apologies if you already discussed this.

When OAuth server received unknown response_type, how should the server handle the error?

1. Show the error to the user without redirecting back to the client
2. Redirect back to the client including the error in query
3. Redirect back to the client including the error in fragment

Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for me.


--
nov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------030700050502030407090607-- From andredemarre@gmail.com Mon Feb 20 14:19:01 2012 Return-Path: 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 C1FEC21E8011 for ; Mon, 20 Feb 2012 14:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=-0.918, BAYES_00=-2.599, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 7NK3-8z9oWH8 for ; Mon, 20 Feb 2012 14:19:00 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A579B21E800C for ; Mon, 20 Feb 2012 14:19:00 -0800 (PST) Received: by dakl33 with SMTP id l33so6457969dak.31 for ; Mon, 20 Feb 2012 14:19:00 -0800 (PST) Received-SPF: pass (google.com: domain of andredemarre@gmail.com designates 10.68.212.73 as permitted sender) client-ip=10.68.212.73; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andredemarre@gmail.com designates 10.68.212.73 as permitted sender) smtp.mail=andredemarre@gmail.com; dkim=pass header.i=andredemarre@gmail.com Received: from mr.google.com ([10.68.212.73]) by 10.68.212.73 with SMTP id ni9mr67205912pbc.56.1329776340564 (num_hops = 1); Mon, 20 Feb 2012 14:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xukpAhcXYublj94Eafqg0v7VJ6lZSu5PMs8QNfNUx8k=; b=giDEPw8kh21u8KtyCzxSPGtwp+GaDZg0L8VobqHqLEkZ0oegDsJjDrN/s95NBTiRie wZYhq7uEDXVEuI3zSauK6pntgQsPbROGCrgtvpUcdRw+elXkwT9+mc8kj3/fcacJU+Zd O3BRVxoGwF9cRl5cWdGJZ/4HA9sD5WTHQjYd4= MIME-Version: 1.0 Received: by 10.68.212.73 with SMTP id ni9mr55358842pbc.56.1329776340483; Mon, 20 Feb 2012 14:19:00 -0800 (PST) Received: by 10.68.25.193 with HTTP; Mon, 20 Feb 2012 14:19:00 -0800 (PST) In-Reply-To: <4F412E76.6080408@lodderstedt.net> References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> <4F412E76.6080408@lodderstedt.net> Date: Mon, 20 Feb 2012 14:19:00 -0800 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:19:01 -0000 +1 for keeping the rationale easily accessible in non-normative security documents. Doing so is great for everyone, implementors and spec authors alike. Security can be very nuanced, and some countermeasures are easy to overlook. Also, being transparent with security rationale encourages people to challenge the countermeasures that are recommended or built into the spec. If back references help us accomplish that, we should embrace them. Regards, Andre DeMarre On Sun, Feb 19, 2012 at 9:16 AM, Torsten Lodderstedt wrote: > Hi Tim, > > I just submitted the revised version of the OAuth 2.0 security document > (http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-02). This > revision should address the issues you raised in your AppsDir review. We > especially removed all normative language from the document. > > We took the liberty to leave the back references in Section 5. We conside= r > this back references to section 4 a valuable information for implementors > since they justify the particular countermeasure. All to often security > considerations are given without the corresponding rationales. And withou= t a > justification, the "unconvinced" implementor may tend to ignore or > underestimate the respective controls. > > > regards, > Torsten. > > Am 23.01.2012 22:47, schrieb S Moonesamy: >> >> The following is the AppsDir review performed by Tim Bray. =A0It would b= e >> appreciated if a reply is sent to Tim Bray with a copy to the apps-discu= ss >> mailing list. >> >> >> I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on appsdir, please see >> >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorat= e). >> >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-oauth-v2-threatmodel-01 >> Title: =A0OAuth 2.0 Threat Model and Security Considerations >> Reviewer: Tim Bray >> Review Date: =A0Jan 23, 2012 >> >> Summary: This needs some more editorial work, but is basically sound. >> It's not clear, though, whether it wants to be an Informational RFC or >> not; the use of RFC2119 language needs special attention. =A0I think a >> few of the "minor issues" are worthy of a little bit more work in >> another draft. >> >> Major Issues: >> >> The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. =A0I >> normally wouldn't expect a "threat model" to include normative text. >> The basic idea would be to say "Here is an enumeration of the threats, >> and here are the tools available to OAUTH2 implementors to meet them." >> =A0I was impressed by the enumeration, which seemed very complete and >> well thought through. But the usage of 2119, which makes statements >> normative, seems inconsistent. =A0I can think of 2 ways to address this: >> >> 1. Remove all the 2119 words, so this document isn't normative, and >> publish it as an Informational RFC >> 2. Go through and clean up the 2119 language so it's used >> consistently; then this becomes a normative document. >> >> This is going to affect the references to this document from other >> I-Ds in the OAuth suite, which are currently in last call. >> >> Here are all the section-numbered notes enumerating my issues around >> 2119, as I encountered them: >> >> Section 2.3, I'm a little confused about the use of RFC2119 MAY in a >> threat analysis. =A0When you say "The following data elements MAY be >> stored or accessible...", Is this saying that "The OAuth2 RFC says >> that the following data elements MAY be..." or is it saying something >> else. I don't think there's anything seriously wrong here, but a bit >> more explanation might be in order. =A0I note a comparative absence of >> 2119-ese in section 5 describing countermeasures, where one would >> expect to find it. >> Also in 4.3.1, first bullet point, there's "Authorization servers MUST..= ." >> Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 >> Related: "SHALL"?! in 4.6.3 >> Adding to the concern, there is use of lower-case "must"; note 2nd & >> 3rd bullet points in 4.4.3, which use "MUST" and "must" respectively. >> >> Minor Issues: >> >> 4.1.2 first attack: It says "An attack may obtain the refresh tokens >> issued to a web server client." This needs to be clearer... a "Web >> server client" can be a browser or a native app. =A0Do you mean, "the >> refresh tokens issued by the web server to multiple clients?" >> >> 4.1.2 last attack. =A0In the case where a device is cloned, wouldn't >> "Utilize device lock to prevent unauthorized device access" still be a >> countermeasure? =A0In many devices, such cloning would carry along the >> user's device-lock settings. >> >> 4.4.1.4 2nd bullet. =A0The explanation of why this wouldn't work for >> native clients wasn't comprehensible to me. =A0I'm suspicious of any >> such claims because I can emulate most things a browser can do in a >> mobile client. =A0Perhaps this would be obvious to someone who is an >> OAuth2 implementor. >> >> 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a >> Web Browser control embedded in the native app. =A0If that's not what it >> means, I don't understand what it's saying. =A0If this is true, then the >> second bullet point is probably wrong. >> >> 4.6.6 1st bullet. =A0I'm not convinced that the Cache-Control header >> will *ensure* that a client protects information properly. =A0Should say >> something like "minimize the risk that authenticated content is not >> protected" >> >> 5.* The enumeration, for some but not all of the countermeasures in >> this section, of the threats against which this is a countermeasure, >> reduces readability and, unless it's generated automatically from the >> underlying source, is redundant information, which is unlikely to be >> consistent between sections 4 and 5, and adds difficulty to >> maintenance of this document without adding much value. =A0I'd just wipe >> all these bullet lists out. =A0If it's generated automatically it's less >> damaging, but still reduces readability. =A0In the current draft, this >> is there for some countermeasures but absent for others. =A0Another good >> reason to just take it out. >> >> 5.2.2.5 Device identifiers are very tricky. =A0It's correct that IMEI is >> not adequate, but there are ways to do it without SMS. =A0For more, see >> >> http://android-developers.blogspot.com/2011/03/identifying-app-installat= ions.html >> >> 5.3.4 Surely a little more could be said about device lock. =A0On a >> typical modern phone, "device lock" options include PINs, passwords, >> "face recognition" and so on. =A0These are *not* equal in their level of >> security they provide. >> >> Nits: >> >> Formatting is lousy. =A0There are notations, including ** and _whatever_ >> that I'm not familiar with in the RFC context. >> >> Section 1.0: s/in-built into/built into/ >> 2.1, last bullet point: "An example could by a..." s/by/be/ >> 2.2, 1st bullet point s/eaves drop/eavesdrop/ >> 2.3, 1st para, s/treat/threat/ >> 2.3.1, last bullet, "per authorization process". =A0Adjectival phrases >> should be hyphenated: "per-authorization process" >> 2.3.3, last bullet, ditto >> 3.1, 1st para, "all kinds of tokens" should be "many kinds of tokens" >> 3.1, 2nd para, should be ; not , after "within the authorization server" >> =A0 =A0 =A0s/protected/protect/ >> =A0 =A0 =A0s/different system/different systems/ >> 3.4 1st para, s/intermediary/intermediate/ >> =A0 =A0 =A0list item 1. s/short-living/short-lived/ >> 3.5 s/malicious client/malicious clients/ >> 3.7 top of page 12, what is the underscore notation _client_id_ mean? >> I'm not familiar with this in the RFC context. >> =A01st bullet point: s/token/token's/ >> =A02nd bullet point, multiple issues, 1st sentence should be " the >> initial authorization and issuance of a token by an end-user >> =A0 =A0 to a particular client, and subsequent requests by this client t= o >> =A0 =A0 obtain tokens without user consent (automatic processing of repe= ated >> =A0 =A0 authorization) >> =A0halfway down page 13, s/insures/ensures/ >> =A0 =A0 =A0 =A0 =A0 =A0 s/validates the clients/validates the client's/ >> 4. first sentence, s/this sections/this section/ >> 4.1.2 first para, the last sentence is confusing. How about: "Before >> enumerating the threats, here are some generally applicable >> countermeasures:" >> 4.2.4 2nd bullet s/could not be/can not be/ >> 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests" - I >> assume that's supposed to be a hyperlink to one of the 5.* sections? >> 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that the >> referrer header may contain an Authorization code in a ?a=3Db style >> argument >> 4.4.1.2 first bullet, "can be employed" is inconsistent with style of >> rest of doc >> 4.4.1.3 first 2 bullets have un-labeled links. >> 4.4.1.4 1st bullet s/authentication/authenticate/ >> 4.4.1.4 2nd bullet s/mean/means/ >> 4.4.1.7 2nd bullet s/tokens/token's/ >> 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ >> 4.4.1.10, 3rd bullet, s/aibility/ability/ >> 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ >> 4.4.1.12 I think the href to semicomplete.com needs to be turned into >> an IETF-style reference >> 4.4.2 " since HTTP user agents do not send fragments server requests." >> What you mean to say is "Since HTTP user agents do not send the >> fragment part of URIs to HTTP servers." >> 4.4.2.2 s/browser/browser's/ >> 5.1.4.1.3 s/consider to not store/refrain from storing/ >> 5.* s/may consider to $(verb)/may consider $(verb)ing/ >> 5.1.6 Needs some sort of sentence structure >> 5.3.2 Needs some sort of sentence structure; or is this intended just >> to be a title, with 5.3.3 etc nested under it? >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From igor.faynberg@alcatel-lucent.com Mon Feb 20 14:47:46 2012 Return-Path: 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 8CA1E21F85CF for ; Mon, 20 Feb 2012 14:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] 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 qZRg8kuIO3HO for ; Mon, 20 Feb 2012 14:47:44 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id A1CCA21F85C5 for ; Mon, 20 Feb 2012 14:47:44 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q1KMlhZB005456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 Feb 2012 16:47:43 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q1KMlgYb013601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 20 Feb 2012 16:47:43 -0600 Received: from [135.244.28.45] (faynberg.lra.lucent.com [135.244.28.45]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q1KMlg7g005122; Mon, 20 Feb 2012 16:47:42 -0600 (CST) Message-ID: <4F42CD8D.9020208@alcatel-lucent.com> Date: Mon, 20 Feb 2012 17:47:41 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> <4F412E76.6080408@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:47:46 -0000 Yet another +1 Igor On 2/20/2012 5:19 PM, André DeMarre wrote: > +1 for keeping the rationale easily accessible in non-normative > security documents. Doing so is great for everyone, implementors and > spec authors alike. Security can be very nuanced, and some > countermeasures are easy to overlook. Also, being transparent with > security rationale encourages people to challenge the countermeasures > that are recommended or built into the spec. If back references help > us accomplish that, we should embrace them. > > Regards, > Andre DeMarre > > On Sun, Feb 19, 2012 at 9:16 AM, Torsten Lodderstedt > wrote: >> Hi Tim, >> >> I just submitted the revised version of the OAuth 2.0 security document >> (http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-02). This >> revision should address the issues you raised in your AppsDir review. We >> especially removed all normative language from the document. >> >> We took the liberty to leave the back references in Section 5. We consider >> this back references to section 4 a valuable information for implementors >> since they justify the particular countermeasure. All to often security >> considerations are given without the corresponding rationales. And without a >> justification, the "unconvinced" implementor may tend to ignore or >> underestimate the respective controls. >> >> >> regards, >> Torsten. >> >> Am 23.01.2012 22:47, schrieb S Moonesamy: >>> The following is the AppsDir review performed by Tim Bray. It would be >>> appreciated if a reply is sent to Tim Bray with a copy to the apps-discuss >>> mailing list. >>> >>> >>> I have been selected as the Applications Area Directorate reviewer for >>> this draft (for background on appsdir, please see >>> >>> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. Please wait for direction from your document shepherd >>> or AD before posting a new version of the draft. >>> >>> Document: draft-ietf-oauth-v2-threatmodel-01 >>> Title: OAuth 2.0 Threat Model and Security Considerations >>> Reviewer: Tim Bray >>> Review Date: Jan 23, 2012 >>> >>> Summary: This needs some more editorial work, but is basically sound. >>> It's not clear, though, whether it wants to be an Informational RFC or >>> not; the use of RFC2119 language needs special attention. I think a >>> few of the "minor issues" are worthy of a little bit more work in >>> another draft. >>> >>> Major Issues: >>> >>> The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. I >>> normally wouldn't expect a "threat model" to include normative text. >>> The basic idea would be to say "Here is an enumeration of the threats, >>> and here are the tools available to OAUTH2 implementors to meet them." >>> I was impressed by the enumeration, which seemed very complete and >>> well thought through. But the usage of 2119, which makes statements >>> normative, seems inconsistent. I can think of 2 ways to address this: >>> >>> 1. Remove all the 2119 words, so this document isn't normative, and >>> publish it as an Informational RFC >>> 2. Go through and clean up the 2119 language so it's used >>> consistently; then this becomes a normative document. >>> >>> This is going to affect the references to this document from other >>> I-Ds in the OAuth suite, which are currently in last call. >>> >>> Here are all the section-numbered notes enumerating my issues around >>> 2119, as I encountered them: >>> >>> Section 2.3, I'm a little confused about the use of RFC2119 MAY in a >>> threat analysis. When you say "The following data elements MAY be >>> stored or accessible...", Is this saying that "The OAuth2 RFC says >>> that the following data elements MAY be..." or is it saying something >>> else. I don't think there's anything seriously wrong here, but a bit >>> more explanation might be in order. I note a comparative absence of >>> 2119-ese in section 5 describing countermeasures, where one would >>> expect to find it. >>> Also in 4.3.1, first bullet point, there's "Authorization servers MUST..." >>> Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 >>> Related: "SHALL"?! in 4.6.3 >>> Adding to the concern, there is use of lower-case "must"; note 2nd& >>> 3rd bullet points in 4.4.3, which use "MUST" and "must" respectively. >>> >>> Minor Issues: >>> >>> 4.1.2 first attack: It says "An attack may obtain the refresh tokens >>> issued to a web server client." This needs to be clearer... a "Web >>> server client" can be a browser or a native app. Do you mean, "the >>> refresh tokens issued by the web server to multiple clients?" >>> >>> 4.1.2 last attack. In the case where a device is cloned, wouldn't >>> "Utilize device lock to prevent unauthorized device access" still be a >>> countermeasure? In many devices, such cloning would carry along the >>> user's device-lock settings. >>> >>> 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for >>> native clients wasn't comprehensible to me. I'm suspicious of any >>> such claims because I can emulate most things a browser can do in a >>> mobile client. Perhaps this would be obvious to someone who is an >>> OAuth2 implementor. >>> >>> 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a >>> Web Browser control embedded in the native app. If that's not what it >>> means, I don't understand what it's saying. If this is true, then the >>> second bullet point is probably wrong. >>> >>> 4.6.6 1st bullet. I'm not convinced that the Cache-Control header >>> will *ensure* that a client protects information properly. Should say >>> something like "minimize the risk that authenticated content is not >>> protected" >>> >>> 5.* The enumeration, for some but not all of the countermeasures in >>> this section, of the threats against which this is a countermeasure, >>> reduces readability and, unless it's generated automatically from the >>> underlying source, is redundant information, which is unlikely to be >>> consistent between sections 4 and 5, and adds difficulty to >>> maintenance of this document without adding much value. I'd just wipe >>> all these bullet lists out. If it's generated automatically it's less >>> damaging, but still reduces readability. In the current draft, this >>> is there for some countermeasures but absent for others. Another good >>> reason to just take it out. >>> >>> 5.2.2.5 Device identifiers are very tricky. It's correct that IMEI is >>> not adequate, but there are ways to do it without SMS. For more, see >>> >>> http://android-developers.blogspot.com/2011/03/identifying-app-installations.html >>> >>> 5.3.4 Surely a little more could be said about device lock. On a >>> typical modern phone, "device lock" options include PINs, passwords, >>> "face recognition" and so on. These are *not* equal in their level of >>> security they provide. >>> >>> Nits: >>> >>> Formatting is lousy. There are notations, including ** and _whatever_ >>> that I'm not familiar with in the RFC context. >>> >>> Section 1.0: s/in-built into/built into/ >>> 2.1, last bullet point: "An example could by a..." s/by/be/ >>> 2.2, 1st bullet point s/eaves drop/eavesdrop/ >>> 2.3, 1st para, s/treat/threat/ >>> 2.3.1, last bullet, "per authorization process". Adjectival phrases >>> should be hyphenated: "per-authorization process" >>> 2.3.3, last bullet, ditto >>> 3.1, 1st para, "all kinds of tokens" should be "many kinds of tokens" >>> 3.1, 2nd para, should be ; not , after "within the authorization server" >>> s/protected/protect/ >>> s/different system/different systems/ >>> 3.4 1st para, s/intermediary/intermediate/ >>> list item 1. s/short-living/short-lived/ >>> 3.5 s/malicious client/malicious clients/ >>> 3.7 top of page 12, what is the underscore notation _client_id_ mean? >>> I'm not familiar with this in the RFC context. >>> 1st bullet point: s/token/token's/ >>> 2nd bullet point, multiple issues, 1st sentence should be " the >>> initial authorization and issuance of a token by an end-user >>> to a particular client, and subsequent requests by this client to >>> obtain tokens without user consent (automatic processing of repeated >>> authorization) >>> halfway down page 13, s/insures/ensures/ >>> s/validates the clients/validates the client's/ >>> 4. first sentence, s/this sections/this section/ >>> 4.1.2 first para, the last sentence is confusing. How about: "Before >>> enumerating the threats, here are some generally applicable >>> countermeasures:" >>> 4.2.4 2nd bullet s/could not be/can not be/ >>> 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests" - I >>> assume that's supposed to be a hyperlink to one of the 5.* sections? >>> 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that the >>> referrer header may contain an Authorization code in a ?a=b style >>> argument >>> 4.4.1.2 first bullet, "can be employed" is inconsistent with style of >>> rest of doc >>> 4.4.1.3 first 2 bullets have un-labeled links. >>> 4.4.1.4 1st bullet s/authentication/authenticate/ >>> 4.4.1.4 2nd bullet s/mean/means/ >>> 4.4.1.7 2nd bullet s/tokens/token's/ >>> 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ >>> 4.4.1.10, 3rd bullet, s/aibility/ability/ >>> 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ >>> 4.4.1.12 I think the href to semicomplete.com needs to be turned into >>> an IETF-style reference >>> 4.4.2 " since HTTP user agents do not send fragments server requests." >>> What you mean to say is "Since HTTP user agents do not send the >>> fragment part of URIs to HTTP servers." >>> 4.4.2.2 s/browser/browser's/ >>> 5.1.4.1.3 s/consider to not store/refrain from storing/ >>> 5.* s/may consider to $(verb)/may consider $(verb)ing/ >>> 5.1.6 Needs some sort of sentence structure >>> 5.3.2 Needs some sort of sentence structure; or is this intended just >>> to be a title, with 5.3.3 etc nested under it? >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Mon Feb 20 20:22:41 2012 Return-Path: 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 616E121F854E for ; Mon, 20 Feb 2012 20:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.195 X-Spam-Level: X-Spam-Status: No, score=-17.195 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 Ay7o+aldrKSn for ; Mon, 20 Feb 2012 20:22:40 -0800 (PST) Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) by ietfa.amsl.com (Postfix) with SMTP id 5D90821F854D for ; Mon, 20 Feb 2012 20:22:39 -0800 (PST) Received: from [98.139.212.146] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 21 Feb 2012 04:22:30 -0000 Received: from [98.139.212.230] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 21 Feb 2012 04:22:30 -0000 Received: from [127.0.0.1] by omp1039.mail.bf1.yahoo.com with NNFMP; 21 Feb 2012 04:22:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 865230.14654.bm@omp1039.mail.bf1.yahoo.com Received: (qmail 83214 invoked by uid 60001); 21 Feb 2012 04:22:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1329798150; bh=qF9xBUDSEhbTxCdc0Xz50Ej0Hq4CX/Va/iVtX4Ucaks=; 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=dGjXiCDFGTeMz/HbKNAPCyVju6LIpq5uRLJWY/ps0FBRQJSV9kQGGQKmc4T+rUmApV4aJ3adxq0Kyihur/N4Apk1AoFbeyy67icZK2vwlpqUEvCt9/NW/mbmd+iT4GUYdmkPXHWsdBuVK6iUl0nLeVf2VAgvsZYObABNKayY0wU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; 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=Gn+GUw+sFxzB1RAU2JBKHBws9+X5VOtoqOyZ61SJnJjZOkRowrvrhRWFoRTrJGH+ww8Av1HbC/x92WHWCStqAKn8V8myL+Zj0o2Mv4BnrkT2q+SxxLXaj5FYB0B0yuaB/4zQ6+8AHIObrCwmJ6zpMrFCi5ElU3gnc0dvAPAGw50=; X-YMail-OSG: Kk1fb24VM1mjptXlL7jZoqAIo92_8cyXXs_dNmMRezy6IyG D7afrDhbtwFH6GQIR_.dH.KNqDpXTZiHJ2DW1zKS647.oMjJZiB8TngX6K5x OkxrGiTN168fCIfS4Cp6K3tntTNZtjOsO.S2Y_2ITcF2d6Qqu0.bkuanOitv iOkVEajzr5vDAo._3gFCF4SsFitluwOLLaHstHPaG8m5.jCZqFnLYQXnnEET K_A5uEB6pt7QydfRAJihDr6mTnC44uAHZmXcR8ib3qQ5Yr9b93hT9cOJarmE 8nFf8kYWZhrhzTXqaYtdvUjjgMvlryjgsxyToPajdYdPeDWNKl6fYEUL.FjE bKs.z7Ig42qodK9ozNCtiBM5WNAzjQPobkgKxUukNYES0TrVOjYVD9xQZ.Gm ALJWUYv26l7_U8aOgU_fpmTZ8RjBYPtTHQlembgDhUhNMO7LcfqnPERW5O.u ug7I- Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Mon, 20 Feb 2012 20:22:29 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340031 References: <58932B8B-2DDE-41D6-A91B-5036CC762C00@matake.jp> <1329757027.28055.YahooMailNeo@web31808.mail.mud.yahoo.com> <4F4284DD.3030006@alcatel-lucent.com> Message-ID: <1329798149.78115.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Mon, 20 Feb 2012 20:22:29 -0800 (PST) From: William Mills To: "igor.faynberg@alcatel-lucent.com" , "oauth@ietf.org" In-Reply-To: <4F4284DD.3030006@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-1778805745-1329798149=:78115" Subject: Re: [OAUTH-WG] Quick question about error response for "response_type=unknown" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 04:22:41 -0000 --835683298-1778805745-1329798149=:78115 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I does allow some parts of your server config to be discovered.=A0 More of = a problem in error responses is usually echoing back the user data, or allo= wing user enumeration for example.=A0 Care is required, but you don't have = a ton of options here.=0A=0A=0A=0A________________________________=0A From:= Igor Faynberg =0ATo: oauth@ietf.org =0AS= ent: Monday, February 20, 2012 9:37 AM=0ASubject: Re: [OAUTH-WG] Quick ques= tion about error response for "response_type=3Dunknown"=0A =0A=0ACould ther= e be a potential security hole in providing an error response?=A0 (Not that= I see it, but many problems in the past had been caused by helpful respone= se.)=0A=0AIgor=0A=0AOn 2/20/2012 11:57 AM, William Mills wrote: =0ARespond = with an error in protocol.=A0 Thta won't include a redirect, and the client= has to know what to do.=0A>=0A>=0A>=0A>________________________________=0A= > From: nov matake =0A>To: oauth WG =0A>Sen= t: Monday, February 20, 2012 6:11 AM=0A>Subject: [OAUTH-WG] Quick question = about error response for "response_type=3Dunknown"=0A> =0A>Hi OAuthers,=0A>= =0A>My apologies if you already discussed this.=0A>=0A>When OAuth server re= ceived unknown response_type, how should=0A the server handle th= e error?=0A>=0A>1. Show the error to the user without redirecting back to= =0A the client=0A>2. Redirect back to the client including the e= rror in query=0A>3. Redirect back to the client including the error in=0A = fragment=0A>=0A>Since choosing 2 or 3 is impossible in this case,= 1 seems=0A reasonable for me.=0A>=0A>=0A>--=0A>nov=0A>_________= ______________________________________=0A>OAuth mailing list=0A>OAuth@ietf.= org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A>=0A>=0A______= _________________________________________=0AOAuth mailing list OAuth@ietf.o= rg https://www.ietf.org/mailman/listinfo/oauth =0A_________________________= ______________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.= ietf.org/mailman/listinfo/oauth --835683298-1778805745-1329798149=:78115 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I does allow some parts of your server config to be discovered.  Mor= e of a problem in error responses is usually echoing back the user data, or= allowing user enumeration for example.  Care is required, but you don= 't have a ton of options here.

From: Ig= or Faynberg <igor.faynberg@alcatel-lucent.com>
To: oauth@ietf.org
Sent: Monday, February 20, 2012 9:37 AM
Subject: Re: [OAUTH-WG] Quick ques= tion about error response for "response_type=3Dunknown"
=
=0A
=0A=0A =0A=0A =0A =0A
=0A Cou= ld there be a potential security hole in providing an error=0A response?=   (Not that I see it, but many problems in the past had=0A been cau= sed by helpful responese.)
=0A
=0A Igor
=0A
=0A O= n 2/20/2012 11:57 AM, William Mills wrote:=0A
= =0A
=0A
Respond with an error in protocol.=   Thta won't=0A include a redirect, and the client has to k= now what to do.
=0A

=0A
=0A =
=0A
=0A
= =0A
From:=0A nov matake = <n= ov@matake.jp>
=0A To: oauth=0A WG <oauth@ietf.org>
= =0A Sent:=0A= Monday, February 20, 2012 6:11 AM
=0A = Subject:=0A [OA= UTH-WG] Quick question about error response for=0A "response= _type=3Dunknown"
=0A
=0A
=0A = Hi OAuthers,
=0A
=0A My apologies if= you already discussed this.
=0A
=0A When OAut= h server received unknown response_type, how should=0A the serve= r handle the error?
=0A
=0A 1. Show the error = to the user without redirecting back to=0A the client
=0A = 2. Redirect back to the client including the error in query
=0A = 3. Redirect back to the client including the error in=0A = fragment
=0A
=0A Since choosing 2 or 3 is = impossible in this case, 1 seems=0A reasonable for me.
=0A =
=0A
=0A --
=0A nov
= =0A _______________________________________________
=0A = OAuth mailing list
=0A OAut= h@ietf.org
=0A https://www.ietf.org/mailm= an/listinfo/oauth
=0A
=0A
=0A =
=0A
=0A
=0A 
=0A______________________________=
_________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailm=
an/listinfo/oauth=0A
=0A
=0A
=0A=0A
_______________________________________________
OAuth mailing list
= OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth


<= /div>
--835683298-1778805745-1329798149=:78115-- From matake@gmail.com Tue Feb 21 03:34:36 2012 Return-Path: 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 9854421F8703 for ; Tue, 21 Feb 2012 03:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 XfCOPN86PrQt for ; Tue, 21 Feb 2012 03:34:35 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC7021F85AE for ; Tue, 21 Feb 2012 03:34:35 -0800 (PST) Received: by dakl33 with SMTP id l33so7105440dak.31 for ; Tue, 21 Feb 2012 03:34:34 -0800 (PST) Received-SPF: pass (google.com: domain of matake@gmail.com designates 10.68.218.229 as permitted sender) client-ip=10.68.218.229; Authentication-Results: mr.google.com; spf=pass (google.com: domain of matake@gmail.com designates 10.68.218.229 as permitted sender) smtp.mail=matake@gmail.com; dkim=pass header.i=matake@gmail.com Received: from mr.google.com ([10.68.218.229]) by 10.68.218.229 with SMTP id pj5mr15773492pbc.26.1329824074934 (num_hops = 1); Tue, 21 Feb 2012 03:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=2IXJmpVeyNFew7d1KaA23IDNm163XkgabiV7WQiia/w=; b=a9FTzK9nmYZkDTU8jcbabgWBEvabcHlGd4XwKCO6Uiwzpnic0Bg+/SWzHb1iQ/fbIQ XUjNwL2mhT/tEXHJ1sVXoJFbL1KzC6cua56dfWW0gnxOd3G0RR+AGO68O2qwxD1xjqh2 maXYNVeEeBIWBC3wiZVd6XRRc9Zcc4Vsk4cGU= Received: by 10.68.218.229 with SMTP id pj5mr12885742pbc.26.1329824074805; Tue, 21 Feb 2012 03:34:34 -0800 (PST) Received: from [192.168.1.103] (q032020.dynamic.ppp.asahi-net.or.jp. [203.181.32.20]) by mx.google.com with ESMTPS id q1sm15853529pbv.49.2012.02.21.03.34.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 03:34:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_769C0E38-DB11-48F6-984C-DDCE69C84AAA" From: "matake@gmail" In-Reply-To: <1329798149.78115.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Tue, 21 Feb 2012 20:34:29 +0900 Message-Id: <56F7111A-B65E-459A-BB8A-ED87CDF1EB4A@gmail.com> References: <58932B8B-2DDE-41D6-A91B-5036CC762C00@matake.jp> <1329757027.28055.YahooMailNeo@web31808.mail.mud.yahoo.com> <4F4284DD.3030006@alcatel-lucent.com> <1329798149.78115.YahooMailNeo@web31804.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1257) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Quick question about error response for "response_type=unknown" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 11:34:36 -0000 --Apple-Mail=_769C0E38-DB11-48F6-984C-DDCE69C84AAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 So the answer is "Show the error to the user without redirecting back to = the client", right? I'm now developing OAuth2 and OpenID Connect ruby library, and both of = them return errors case 1. redirect with error in query if response_type is "code" but it's = not supported case 2. redirect with error in fragment if response_type is "token = code", "token id_token", "token code id_token" or "code id_token" but = it's not supported case 3. otherwise show error to the user without redirect since server = cannot understand the response_type at all But other server might not understand some of response_types listed in = case 2 at all and choose case 3 in such case. (ie. OAuth servers which don't understand OpenID Connect won't = understand "id_token") So I'm afraid that it reduces interoperability, a bit. On 2012/02/21, at 13:22, William Mills wrote: > I does allow some parts of your server config to be discovered. More = of a problem in error responses is usually echoing back the user data, = or allowing user enumeration for example. Care is required, but you = don't have a ton of options here. >=20 > From: Igor Faynberg > To: oauth@ietf.org=20 > Sent: Monday, February 20, 2012 9:37 AM > Subject: Re: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown" >=20 > Could there be a potential security hole in providing an error = response? (Not that I see it, but many problems in the past had been = caused by helpful responese.) >=20 > Igor >=20 > On 2/20/2012 11:57 AM, William Mills wrote: >>=20 >> Respond with an error in protocol. Thta won't include a redirect, = and the client has to know what to do. >>=20 >> From: nov matake >> To: oauth WG =20 >> Sent: Monday, February 20, 2012 6:11 AM >> Subject: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown" >>=20 >> Hi OAuthers, >>=20 >> My apologies if you already discussed this. >>=20 >> When OAuth server received unknown response_type, how should the = server handle the error? >>=20 >> 1. Show the error to the user without redirecting back to the client >> 2. Redirect back to the client including the error in query >> 3. Redirect back to the client including the error in fragment >>=20 >> Since choosing 2 or 3 is impossible in this case, 1 seems reasonable = for me. >>=20 >>=20 >> -- >> nov >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_769C0E38-DB11-48F6-984C-DDCE69C84AAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 So = the answer is "Show the error to the user without redirecting back to = the client", right?
I'm now developing OAuth2 and OpenID Connect = ruby library, and both of them return = errors

case 1. redirect with error in query if = response_type is "code" but it's not supported
case 2. = redirect with error in fragment if response_type is "token code", "token = id_token", "token code id_token" or "code id_token" but it's not = supported
case 3. otherwise show error to the user without = redirect since server cannot understand the response_type at = all

But other server might not understand some = of response_types listed in case 2 at all and choose case 3 in such = case.
(ie. OAuth servers which don't understand OpenID Connect = won't understand "id_token")

So I'm afraid that = it reduces interoperability, a bit.
I does allow some parts of your = server config to be discovered.  More of a problem in error = responses is usually echoing back the user data, or allowing user = enumeration for example.  Care is required, but you don't have a = ton of options here.

=
From: Igor Faynberg <igor.faynberg@alcatel-luc= ent.com>
To: = oauth@ietf.org
Sent: Monday, February 20, 2012 = 9:37 AM
Subject: = Re: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown"

=20 =20 =20
Could there be a potential security hole in providing an error response?  (Not that I see it, but many problems in the past = had been caused by helpful responese.)

Igor

On 2/20/2012 11:57 AM, William Mills wrote:
Respond with an error in protocol.  Thta won't include a redirect, and the client has to know what to = do.

From: nov matake <nov@matake.jp>
To: = oauth WG <oauth@ietf.org>
Sent: Monday, February 20, 2012 6:11 AM
Subject: [OAUTH-WG] Quick question about error response for "response_type=3Dunknown"

Hi OAuthers,

My apologies if you already discussed this.

When OAuth server received unknown response_type, how should the server handle the error?

1. Show the error to the user without redirecting back to the client
2. Redirect back to the client including the error in = query
3. Redirect back to the client including the error in fragment

Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for me.


--
nov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
=
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= = --Apple-Mail=_769C0E38-DB11-48F6-984C-DDCE69C84AAA-- From matake@gmail.com Tue Feb 21 04:23:23 2012 Return-Path: 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 398E021F8724 for ; Tue, 21 Feb 2012 04:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 WxMLFyC+Ti6Y for ; Tue, 21 Feb 2012 04:23:19 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2752D21F87B0 for ; Tue, 21 Feb 2012 04:23:19 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so7644280pbc.31 for ; Tue, 21 Feb 2012 04:23:19 -0800 (PST) Received-SPF: pass (google.com: domain of matake@gmail.com designates 10.68.73.103 as permitted sender) client-ip=10.68.73.103; Authentication-Results: mr.google.com; spf=pass (google.com: domain of matake@gmail.com designates 10.68.73.103 as permitted sender) smtp.mail=matake@gmail.com; dkim=pass header.i=matake@gmail.com Received: from mr.google.com ([10.68.73.103]) by 10.68.73.103 with SMTP id k7mr73917169pbv.132.1329826999040 (num_hops = 1); Tue, 21 Feb 2012 04:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=NU0cJtIzbJ8c7gzQIlIB1PekJg2S20LMjU+3x2LI1eE=; b=VQwTuanNOgIftEua957QJsmLHxmA7H6eRhD7iVlCEp9twmMLllS0nBl27gBp5Z/AmU kl4pEUIiDCb3wMqklkwadj1/gwSbKHI/TIuPEBocP0Y22X6ghnwDpMCTM/cW60UeG2WW P6LkZZLsGCVjpGvCWYDTa2RcMoiuZkCeVAU38= Received: by 10.68.73.103 with SMTP id k7mr60943058pbv.132.1329826998899; Tue, 21 Feb 2012 04:23:18 -0800 (PST) Received: from [192.168.1.103] (q032020.dynamic.ppp.asahi-net.or.jp. [203.181.32.20]) by mx.google.com with ESMTPS id p8sm15950856pbs.51.2012.02.21.04.23.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 04:23:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_E6348B93-3DFD-472E-9039-48AFA74CD113" From: "matake@gmail" In-Reply-To: Date: Tue, 21 Feb 2012 21:23:15 +0900 Message-Id: <8799A0DF-4BB9-4122-8CC0-D2A33C507A51@gmail.com> References: <58932B8B-2DDE-41D6-A91B-5036CC762C00@matake.jp> <1329757027.28055.YahooMailNeo@web31808.mail.mud.yahoo.com> <4F4284DD.3030006@alcatel-lucent.com> <1329798149.78115.YahooMailNeo@web31804.mail.mud.yahoo.com> <56F7111A-B65E-459A-BB8A-ED87CDF1EB4A@gmail.com> To: Buhake Sindi X-Mailer: Apple Mail (2.1257) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Quick question about error response for "response_type=unknown" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 12:23:23 -0000 --Apple-Mail=_E6348B93-3DFD-472E-9039-48AFA74CD113 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii When server cannot understand the response_type, it can't know where the = error response should be included. ex.) A JS client used response_type=3Dcode%20id_token and expected all = returned parameters would be included in fragment. However server couldn't understand the response_type and returned error = messages in query. Then client won't be able to handle the error. Actually, clients expects returned parameters in query only when it uses = response_type=3Dcode, at least in current proposed response_types. (I'm thinking "current proposed response_types" as "code", "token", = "code token", "token id_token", "code id_token" and "code token = id_token") On 2012/02/21, at 20:42, Buhake Sindi wrote: > Oops. Sorry, I believe I should have said, case 2. >=20 > And why is case 2 impossible? The only time case 1 is valid in the = redirect_uri is invalid. >=20 > Buhake Sindi >=20 > On 21 February 2012 13:40, Buhake Sindi wrote: > Hi guys, >=20 > OAuth 2, Draft 23, Paragraph 4.1.2.1 clearly states: >=20 > If the request fails due to a missing, invalid, or mismatching = redirection URI, or if the client > identifier is missing or invalid, the authorization server SHOULD = inform the resource owner of > the error, and MUST NOT automatically redirect the user-agent to the = invalid redirection URI. >=20 > So, Case 1 is the only accepted case here. >=20 > Buhake Sindi > =20 >=20 > On 21 February 2012 13:34, matake@gmail wrote: > So the answer is "Show the error to the user without redirecting back = to the client", right? > I'm now developing OAuth2 and OpenID Connect ruby library, and both of = them return errors >=20 > case 1. redirect with error in query if response_type is "code" but = it's not supported > case 2. redirect with error in fragment if response_type is "token = code", "token id_token", "token code id_token" or "code id_token" but = it's not supported > case 3. otherwise show error to the user without redirect since server = cannot understand the response_type at all >=20 > But other server might not understand some of response_types listed in = case 2 at all and choose case 3 in such case. > (ie. OAuth servers which don't understand OpenID Connect won't = understand "id_token") >=20 > So I'm afraid that it reduces interoperability, a bit. >=20 > On 2012/02/21, at 13:22, William Mills wrote: >=20 >> I does allow some parts of your server config to be discovered. More = of a problem in error responses is usually echoing back the user data, = or allowing user enumeration for example. Care is required, but you = don't have a ton of options here. >>=20 >> From: Igor Faynberg >> To: oauth@ietf.org=20 >> Sent: Monday, February 20, 2012 9:37 AM >> Subject: Re: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown" >>=20 >> Could there be a potential security hole in providing an error = response? (Not that I see it, but many problems in the past had been = caused by helpful responese.) >>=20 >> Igor >>=20 >> On 2/20/2012 11:57 AM, William Mills wrote: >>>=20 >>> Respond with an error in protocol. Thta won't include a redirect, = and the client has to know what to do. >>>=20 >>> From: nov matake >>> To: oauth WG =20 >>> Sent: Monday, February 20, 2012 6:11 AM >>> Subject: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown" >>>=20 >>> Hi OAuthers, >>>=20 >>> My apologies if you already discussed this. >>>=20 >>> When OAuth server received unknown response_type, how should the = server handle the error? >>>=20 >>> 1. Show the error to the user without redirecting back to the client >>> 2. Redirect back to the client including the error in query >>> 3. Redirect back to the client including the error in fragment >>>=20 >>> Since choosing 2 or 3 is impossible in this case, 1 seems reasonable = for me. >>>=20 >>>=20 >>> -- >>> nov >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > The Elite Gentleman --Apple-Mail=_E6348B93-3DFD-472E-9039-48AFA74CD113 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii When = server cannot understand the response_type, it can't know where the = error response should be included.

ex.)
A = JS client used response_type=3Dcode%20id_token and expected all returned = parameters would be included in fragment.
However server = couldn't understand the response_type and returned error messages in = query.
Then client won't be able to handle the = error.

Actually, clients expects returned = parameters in query only when it uses response_type=3Dcode, at least in = current proposed response_types.
(I'm thinking "current = proposed response_types" as "code", "token", "code token", "token = id_token", "code id_token" and "code token = id_token")


On 2012/02/21, at = 20:42, Buhake Sindi wrote:

Oops. = Sorry, I believe I should have said, case 2.

And why is case 2 = impossible? The only time case 1 is valid in the redirect_uri is = invalid.

Buhake Sindi

On 21 = February 2012 13:40, Buhake Sindi <buhake@googlemail.com>= wrote:
Hi guys,

OAuth = 2, Draft 23, Paragraph 4.1.2.1 clearly states:

If the request fails due to a missing, invalid, or mismatching = redirection URI, or if the client
identifier is missing or invalid, the authorization server SHOULD inform = the resource owner of
the error, and MUST NOT automatically redirect = the user-agent to the invalid redirection = URI.

So, Case 1 is the only accepted case = here.

Buhake Sindi
 

On 21 = February 2012 13:34, matake@gmail <matake@gmail.com> wrote:
So the answer is "Show the error to = the user without redirecting back to the client", right?
I'm now = developing OAuth2 and OpenID Connect ruby library, and both of them = return errors

case 1. redirect with error in query if = response_type is "code" but it's not supported
case 2. = redirect with error in fragment if response_type is "token code", "token = id_token", "token code id_token" or "code id_token" but it's not = supported
case 3. otherwise show error to the user without redirect since = server cannot understand the response_type at = all

But other server might not understand some = of response_types listed in case 2 at all and choose case 3 in such = case.
(ie. OAuth servers which don't understand OpenID Connect won't = understand "id_token")

So I'm afraid that it = reduces interoperability, a bit.

On = 2012/02/21, at 13:22, William Mills wrote:

I does allow some = parts of your server config to be discovered.  More of a problem in = error responses is usually echoing back the user data, or allowing user = enumeration for example.  Care is required, but you don't have a = ton of options here.

=
From: Igor Faynberg = <igor.faynberg@alcatel-lucent.com>
To: oauth@ietf.org
Sent: Monday, February = 20, 2012 9:37 AM
Subject: Re: [OAUTH-WG] Quick = question about error response for "response_type=3Dunknown"

=20 =20 =20
Could there be a potential security hole in providing an error response?  (Not that I see it, but many problems in the past = had been caused by helpful responese.)

Igor

On 2/20/2012 11:57 AM, William Mills wrote:
Respond with an error in protocol.  Thta won't include a redirect, and the client has to know what to = do.

From: nov matake <nov@matake.jp>
To: oauth WG <oauth@ietf.org>
Sent: Monday, February 20, 2012 6:11 AM
Subject: [OAUTH-WG] Quick question about error response for "response_type=3Dunknown"

Hi OAuthers,

My apologies if you already discussed this.

When OAuth server received unknown response_type, how should the server handle the error?

1. Show the error to the user without redirecting back to the client
2. Redirect back to the client including the error in = query
3. Redirect back to the client including the error in fragment

Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for me.


--
nov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


=
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=


___________= ____________________________________
OAuth mailing list
OAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth








--
The = Elite Gentleman

= --Apple-Mail=_E6348B93-3DFD-472E-9039-48AFA74CD113-- From peter.brindisi@gmail.com Tue Feb 21 05:33:22 2012 Return-Path: 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 63B3B21F87A3 for ; Tue, 21 Feb 2012 05:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ottwJeXCKlmK for ; Tue, 21 Feb 2012 05:33:22 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D99DD21F879F for ; Tue, 21 Feb 2012 05:33:21 -0800 (PST) Received: by ghbg16 with SMTP id g16so3316905ghb.31 for ; Tue, 21 Feb 2012 05:33:21 -0800 (PST) Received-SPF: pass (google.com: domain of peter.brindisi@gmail.com designates 10.236.77.8 as permitted sender) client-ip=10.236.77.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of peter.brindisi@gmail.com designates 10.236.77.8 as permitted sender) smtp.mail=peter.brindisi@gmail.com; dkim=pass header.i=peter.brindisi@gmail.com Received: from mr.google.com ([10.236.77.8]) by 10.236.77.8 with SMTP id c8mr35868231yhe.3.1329831201499 (num_hops = 1); Tue, 21 Feb 2012 05:33:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=OghNVZQNHu9VDUa3f00hf/ZqAajfvNk+2nLDhY2WYmQ=; b=P5Sl60rJn/IxsprTDotf9apJM+zh/UOUf0I1fgswitimOMjpk1M0ALCpU/wP3yh52t bJbaqsfineD2KVepWCn69Wb6k/jlFLZcPIGXThRAs7e//umJatNFZtq9uJsfvUvkF4KF q7Gr0KdhbmIoSqu86P+obbPdvosQkRW5pK1Vc= Received: by 10.236.77.8 with SMTP id c8mr27766627yhe.3.1329831201463; Tue, 21 Feb 2012 05:33:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.147.171.2 with HTTP; Tue, 21 Feb 2012 05:33:01 -0800 (PST) From: Peter Brindisi Date: Tue, 21 Feb 2012 14:33:01 +0100 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=20cf3005153a5fdd9c04b9797407 Subject: [OAUTH-WG] error response for invalid refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 13:33:22 -0000 --20cf3005153a5fdd9c04b9797407 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I am currently implementing version 23 of the oauth2 spec, and I came across a bit of ambiguity. What is the appropriate error code for an invalid refresh token? I am unsure whether it should be 'invalid_grant' or 'invalid_request'. Neither seems 100% clear. Thanks in advance! Best, Peter --20cf3005153a5fdd9c04b9797407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I am currently implementing version 23 of the oa= uth2 spec, and I came across a bit of ambiguity. What is the appropriate er= ror code for an invalid refresh token? I am unsure whether it should be = 9;invalid_grant' or 'invalid_request'. Neither seems 100% clear= .

Thanks in advance!

Best,
=
Peter
--20cf3005153a5fdd9c04b9797407-- From ve7jtb@ve7jtb.com Tue Feb 21 06:16:33 2012 Return-Path: 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 EB9B521F8826 for ; Tue, 21 Feb 2012 06:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.106 X-Spam-Level: X-Spam-Status: No, score=-3.106 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 SoHvs5AJ0ZTK for ; Tue, 21 Feb 2012 06:16:29 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B251421F87B1 for ; Tue, 21 Feb 2012 06:16:29 -0800 (PST) Received: by yenm3 with SMTP id m3so3338090yen.31 for ; Tue, 21 Feb 2012 06:16:29 -0800 (PST) Received-SPF: pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.200.165 as permitted sender) client-ip=10.236.200.165; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.200.165 as permitted sender) smtp.mail=ve7jtb@ve7jtb.com Received: from mr.google.com ([10.236.200.165]) by 10.236.200.165 with SMTP id z25mr34760030yhn.103.1329833789313 (num_hops = 1); Tue, 21 Feb 2012 06:16:29 -0800 (PST) Received: by 10.236.200.165 with SMTP id z25mr26884841yhn.103.1329833787893; Tue, 21 Feb 2012 06:16:27 -0800 (PST) Received: from [192.168.1.213] ([190.22.94.172]) by mx.google.com with ESMTPS id 34sm21528004anu.6.2012.02.21.06.16.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 06:16:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_ABAED77A-16C6-41DF-A58A-C76E59DA2EC5"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <56F7111A-B65E-459A-BB8A-ED87CDF1EB4A@gmail.com> Date: Tue, 21 Feb 2012 11:07:29 -0300 Message-Id: <923A754A-100F-4534-BEBB-7EC5E6297B9E@ve7jtb.com> References: <58932B8B-2DDE-41D6-A91B-5036CC762C00@matake.jp> <1329757027.28055.YahooMailNeo@web31808.mail.mud.yahoo.com> <4F4284DD.3030006@alcatel-lucent.com> <1329798149.78115.YahooMailNeo@web31804.mail.mud.yahoo.com> <56F7111A-B65E-459A-BB8A-ED87CDF1EB4A@gmail.com> To: "matake@gmail" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkYn3o83zxbTM6vnb+myUZOom7ZMr1GPynEy5DSLSbubc9RAfpcPIsDocuxM0vie0CnP5kR Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Quick question about error response for "response_type=unknown" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 14:16:34 -0000 --Apple-Mail=_ABAED77A-16C6-41DF-A58A-C76E59DA2EC5 Content-Type: multipart/alternative; boundary="Apple-Mail=_833D5654-6695-4320-A86D-5E4B414CF715" --Apple-Mail=_833D5654-6695-4320-A86D-5E4B414CF715 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 If the Authorization server, doesn't understand the response_type and = has no other way to determine what sort of flow the client is expecting, = I don't see any choice other than returning a error to the user/browser. In the case of an unknown response_type the client could also be = expecting postMessage, or making a direct connection. You just don't = know. There may be cases that the Authorization server could infer how to = reply based on the client_id, if the client perhaps doesn't have a = client secret issued to it, you could guess that it is using a fragment = encoded flow. I however don't know that guessing is a good practice. Probably best = to always return an error response without a redirect. John B. On 2012-02-21, at 8:34 AM, matake@gmail wrote: > So the answer is "Show the error to the user without redirecting back = to the client", right? > I'm now developing OAuth2 and OpenID Connect ruby library, and both of = them return errors >=20 > case 1. redirect with error in query if response_type is "code" but = it's not supported > case 2. redirect with error in fragment if response_type is "token = code", "token id_token", "token code id_token" or "code id_token" but = it's not supported > case 3. otherwise show error to the user without redirect since server = cannot understand the response_type at all >=20 > But other server might not understand some of response_types listed in = case 2 at all and choose case 3 in such case. > (ie. OAuth servers which don't understand OpenID Connect won't = understand "id_token") >=20 > So I'm afraid that it reduces interoperability, a bit. >=20 > On 2012/02/21, at 13:22, William Mills wrote: >=20 >> I does allow some parts of your server config to be discovered. More = of a problem in error responses is usually echoing back the user data, = or allowing user enumeration for example. Care is required, but you = don't have a ton of options here. >>=20 >> From: Igor Faynberg >> To: oauth@ietf.org=20 >> Sent: Monday, February 20, 2012 9:37 AM >> Subject: Re: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown" >>=20 >> Could there be a potential security hole in providing an error = response? (Not that I see it, but many problems in the past had been = caused by helpful responese.) >>=20 >> Igor >>=20 >> On 2/20/2012 11:57 AM, William Mills wrote: >>>=20 >>> Respond with an error in protocol. Thta won't include a redirect, = and the client has to know what to do. >>>=20 >>> From: nov matake >>> To: oauth WG =20 >>> Sent: Monday, February 20, 2012 6:11 AM >>> Subject: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown" >>>=20 >>> Hi OAuthers, >>>=20 >>> My apologies if you already discussed this. >>>=20 >>> When OAuth server received unknown response_type, how should the = server handle the error? >>>=20 >>> 1. Show the error to the user without redirecting back to the client >>> 2. Redirect back to the client including the error in query >>> 3. Redirect back to the client including the error in fragment >>>=20 >>> Since choosing 2 or 3 is impossible in this case, 1 seems reasonable = for me. >>>=20 >>>=20 >>> -- >>> nov >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_833D5654-6695-4320-A86D-5E4B414CF715 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 If = the Authorization server, doesn't understand the response_type and has = no other way to determine what sort of flow the client is expecting, I = don't see any choice other than returning a error to the = user/browser.

In the case of an unknown response_type = the client could also be expecting postMessage, or making a direct = connection.  You just don't know.

There = may be cases that the Authorization server could infer how to reply = based on the client_id, if the client perhaps doesn't have a client = secret issued to it, you could guess that it is using a fragment encoded = flow.

I however don't know that guessing is a = good practice.   Probably best to always return an error response = without a redirect.

John = B.
On 2012-02-21, at 8:34 AM, matake@gmail = wrote:

So the answer is "Show = the error to the user without redirecting back to the client", = right?
I'm now developing OAuth2 and OpenID Connect ruby library, = and both of them return errors

case 1. redirect = with error in query if response_type is "code" but it's not = supported
case 2. redirect with error in fragment if = response_type is "token code", "token id_token", "token code id_token" = or "code id_token" but it's not supported
case 3. otherwise = show error to the user without redirect since server cannot understand = the response_type at all

But other server might = not understand some of response_types listed in case 2 at all and choose = case 3 in such case.
(ie. OAuth servers which don't understand = OpenID Connect won't understand "id_token")

So = I'm afraid that it reduces interoperability, a = bit.

On 2012/02/21, = at 13:22, William Mills wrote:

I does = allow some parts of your server config to be discovered.  More of a = problem in error responses is usually echoing back the user data, or = allowing user enumeration for example.  Care is required, but you = don't have a ton of options here.

=
From: Igor Faynberg <igor.faynberg@alcatel-luc= ent.com>
To: = oauth@ietf.org
Sent: Monday, February 20, 2012 = 9:37 AM
Subject: = Re: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown"

=20 =20 =20
Could there be a potential security hole in providing an error response?  (Not that I see it, but many problems in the past = had been caused by helpful responese.)

Igor

On 2/20/2012 11:57 AM, William Mills wrote:
Respond with an error in protocol.  Thta won't include a redirect, and the client has to know what to = do.

From: nov matake <nov@matake.jp>
To: = oauth WG <oauth@ietf.org>
Sent: Monday, February 20, 2012 6:11 AM
Subject: [OAUTH-WG] Quick question about error response for "response_type=3Dunknown"

Hi OAuthers,

My apologies if you already discussed this.

When OAuth server received unknown response_type, how should the server handle the error?

1. Show the error to the user without redirecting back to the client
2. Redirect back to the client including the error in = query
3. Redirect back to the client including the error in fragment

Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for me.


--
nov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
=
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_833D5654-6695-4320-A86D-5E4B414CF715-- --Apple-Mail=_ABAED77A-16C6-41DF-A58A-C76E59DA2EC5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MjExNDA3MzBaMCMGCSqGSIb3DQEJBDEWBBQA36aOWmmigVf1Fnc26fAz9kckDTCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQBLi2yqkZxTOy29j1CaEg5YAraWSNyUBzqleirH5Ijravi+NBmFsOZLiAQF//rvto1//+doewv4 vyX1hElCMpVb1vTvWzLjbnFpG6X2MYAowpqWqVj5/iLWk8qK6VGt1b9Yq5s7gz5iSP3szCSKu1da PAYYgJY02YaML61jU4+mez3HHXB16+f4m5+BLr3KwmpI76HwPSv4fJ+/Vwj67TKb8WWxY0/V0gGP kclXrZRK9tZFMYsav0Kof3tnkXh8ppcAxdefw5SK2glJliLbQRm3nwByuxRygL9rYdhPD99ZQqYv 0hVBGovhgg8XVz/PDwERhpFPWF6PILQ83r9HosAvAAAAAAAA --Apple-Mail=_ABAED77A-16C6-41DF-A58A-C76E59DA2EC5-- From matake@gmail.com Tue Feb 21 07:11:50 2012 Return-Path: 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 C897321F885C for ; Tue, 21 Feb 2012 07:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 FGz9kcfB7B7U for ; Tue, 21 Feb 2012 07:11:42 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E460621F8617 for ; Tue, 21 Feb 2012 07:11:41 -0800 (PST) Received: by dakl33 with SMTP id l33so7297719dak.31 for ; Tue, 21 Feb 2012 07:11:36 -0800 (PST) Received-SPF: pass (google.com: domain of matake@gmail.com designates 10.68.129.228 as permitted sender) client-ip=10.68.129.228; Authentication-Results: mr.google.com; spf=pass (google.com: domain of matake@gmail.com designates 10.68.129.228 as permitted sender) smtp.mail=matake@gmail.com; dkim=pass header.i=matake@gmail.com Received: from mr.google.com ([10.68.129.228]) by 10.68.129.228 with SMTP id nz4mr56299786pbb.91.1329837096540 (num_hops = 1); Tue, 21 Feb 2012 07:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=hEvloBJtD9rs9sDdniBRquMpATV4qUwiKb725vUyemw=; b=RnjAfetrki4EtSPozylnA1J8/G03ntiXIIYs0/NjYIsyb1HqE/E+ou1OU4Q7UVedF9 G4HnQwX5qZzry8oPqFzfke+9upC83vl5aNILn5Adw7U6/seWNlYqZjdURm7yt7sgDe+s 25GO7JORFJqToca8xnXwP6zGoVA5DDeSKbBY0= Received: by 10.68.129.228 with SMTP id nz4mr46775331pbb.91.1329837095425; Tue, 21 Feb 2012 07:11:35 -0800 (PST) Received: from [192.168.1.103] (q032020.dynamic.ppp.asahi-net.or.jp. [203.181.32.20]) by mx.google.com with ESMTPS id e10sm27857133pbv.0.2012.02.21.07.11.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 07:11:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_FEC233B3-7C8B-44DF-AD6D-0427B1B24463" From: "matake@gmail" In-Reply-To: <923A754A-100F-4534-BEBB-7EC5E6297B9E@ve7jtb.com> Date: Wed, 22 Feb 2012 00:11:31 +0900 Message-Id: <5FC99886-A2D2-4AC0-93E1-4E07B803DDCD@gmail.com> References: <58932B8B-2DDE-41D6-A91B-5036CC762C00@matake.jp> <1329757027.28055.YahooMailNeo@web31808.mail.mud.yahoo.com> <4F4284DD.3030006@alcatel-lucent.com> <1329798149.78115.YahooMailNeo@web31804.mail.mud.yahoo.com> <56F7111A-B65E-459A-BB8A-ED87CDF1EB4A@gmail.com> <923A754A-100F-4534-BEBB-7EC5E6297B9E@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1257) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Quick question about error response for "response_type=unknown" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 15:11:50 -0000 --Apple-Mail=_FEC233B3-7C8B-44DF-AD6D-0427B1B24463 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 So only when sever understand the response_type but doesn't support it, = it returns "unsupported_response_type" error. It sounds reasonable for me. It will make some servers return "unsupported_response_type" with a = redirect and some don't, though. Thanks. On 2012/02/21, at 23:07, John Bradley wrote: > If the Authorization server, doesn't understand the response_type and = has no other way to determine what sort of flow the client is expecting, = I don't see any choice other than returning a error to the user/browser. >=20 > In the case of an unknown response_type the client could also be = expecting postMessage, or making a direct connection. You just don't = know. >=20 > There may be cases that the Authorization server could infer how to = reply based on the client_id, if the client perhaps doesn't have a = client secret issued to it, you could guess that it is using a fragment = encoded flow. >=20 > I however don't know that guessing is a good practice. Probably best = to always return an error response without a redirect. >=20 > John B. > On 2012-02-21, at 8:34 AM, matake@gmail wrote: >=20 >> So the answer is "Show the error to the user without redirecting back = to the client", right? >> I'm now developing OAuth2 and OpenID Connect ruby library, and both = of them return errors >>=20 >> case 1. redirect with error in query if response_type is "code" but = it's not supported >> case 2. redirect with error in fragment if response_type is "token = code", "token id_token", "token code id_token" or "code id_token" but = it's not supported >> case 3. otherwise show error to the user without redirect since = server cannot understand the response_type at all >>=20 >> But other server might not understand some of response_types listed = in case 2 at all and choose case 3 in such case. >> (ie. OAuth servers which don't understand OpenID Connect won't = understand "id_token") >>=20 >> So I'm afraid that it reduces interoperability, a bit. >>=20 >> On 2012/02/21, at 13:22, William Mills wrote: >>=20 >>> I does allow some parts of your server config to be discovered. = More of a problem in error responses is usually echoing back the user = data, or allowing user enumeration for example. Care is required, but = you don't have a ton of options here. >>>=20 >>> From: Igor Faynberg >>> To: oauth@ietf.org=20 >>> Sent: Monday, February 20, 2012 9:37 AM >>> Subject: Re: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown" >>>=20 >>> Could there be a potential security hole in providing an error = response? (Not that I see it, but many problems in the past had been = caused by helpful responese.) >>>=20 >>> Igor >>>=20 >>> On 2/20/2012 11:57 AM, William Mills wrote: >>>>=20 >>>> Respond with an error in protocol. Thta won't include a redirect, = and the client has to know what to do. >>>>=20 >>>> From: nov matake >>>> To: oauth WG =20 >>>> Sent: Monday, February 20, 2012 6:11 AM >>>> Subject: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown" >>>>=20 >>>> Hi OAuthers, >>>>=20 >>>> My apologies if you already discussed this. >>>>=20 >>>> When OAuth server received unknown response_type, how should the = server handle the error? >>>>=20 >>>> 1. Show the error to the user without redirecting back to the = client >>>> 2. Redirect back to the client including the error in query >>>> 3. Redirect back to the client including the error in fragment >>>>=20 >>>> Since choosing 2 or 3 is impossible in this case, 1 seems = reasonable for me. >>>>=20 >>>>=20 >>>> -- >>>> nov >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_FEC233B3-7C8B-44DF-AD6D-0427B1B24463 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 It sounds = reasonable for me.

It will make some servers return = "unsupported_response_type" with a redirect and some don't, = though.

Thanks.

On = 2012/02/21, at 23:07, John Bradley wrote:

If the Authorization server, = doesn't understand the response_type and has no other way to determine = what sort of flow the client is expecting, I don't see any choice other = than returning a error to the user/browser.

In the = case of an unknown response_type the client could also be expecting = postMessage, or making a direct connection.  You just don't = know.

There may be cases that the Authorization = server could infer how to reply based on the client_id, if the client = perhaps doesn't have a client secret issued to it, you could guess that = it is using a fragment encoded flow.

I however = don't know that guessing is a good practice.   Probably best to = always return an error response without a = redirect.

John B.
On = 2012-02-21, at 8:34 AM, matake@gmail wrote:

So the answer is "Show the = error to the user without redirecting back to the client", = right?
I'm now developing OAuth2 and OpenID Connect ruby library, = and both of them return errors

case 1. redirect = with error in query if response_type is "code" but it's not = supported
case 2. redirect with error in fragment if = response_type is "token code", "token id_token", "token code id_token" = or "code id_token" but it's not supported
case 3. otherwise = show error to the user without redirect since server cannot understand = the response_type at all

But other server might = not understand some of response_types listed in case 2 at all and choose = case 3 in such case.
(ie. OAuth servers which don't understand = OpenID Connect won't understand "id_token")

So = I'm afraid that it reduces interoperability, a = bit.

On 2012/02/21, = at 13:22, William Mills wrote:

I does = allow some parts of your server config to be discovered.  More of a = problem in error responses is usually echoing back the user data, or = allowing user enumeration for example.  Care is required, but you = don't have a ton of options here.

=
From: Igor Faynberg <igor.faynberg@alcatel-luc= ent.com>
To: = oauth@ietf.org
Sent: Monday, February 20, 2012 = 9:37 AM
Subject: = Re: [OAUTH-WG] Quick question about error response for = "response_type=3Dunknown"

=20 =20 =20
Could there be a potential security hole in providing an error response?  (Not that I see it, but many problems in the past = had been caused by helpful responese.)

Igor

On 2/20/2012 11:57 AM, William Mills wrote:
Respond with an error in protocol.  Thta won't include a redirect, and the client has to know what to = do.

From: nov matake <nov@matake.jp>
To: = oauth WG <oauth@ietf.org>
Sent: Monday, February 20, 2012 6:11 AM
Subject: [OAUTH-WG] Quick question about error response for "response_type=3Dunknown"

Hi OAuthers,

My apologies if you already discussed this.

When OAuth server received unknown response_type, how should the server handle the error?

1. Show the error to the user without redirecting back to the client
2. Redirect back to the client including the error in = query
3. Redirect back to the client including the error in fragment

Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for me.


--
nov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
=
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


= --Apple-Mail=_FEC233B3-7C8B-44DF-AD6D-0427B1B24463-- From buhake@googlemail.com Tue Feb 21 03:40:30 2012 Return-Path: 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 1177421F853D for ; Tue, 21 Feb 2012 03:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 FqbIC902opqu for ; Tue, 21 Feb 2012 03:40:26 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A72D21F8518 for ; Tue, 21 Feb 2012 03:40:25 -0800 (PST) Received: by obbwd15 with SMTP id wd15so9709216obb.31 for ; Tue, 21 Feb 2012 03:40:25 -0800 (PST) Received-SPF: pass (google.com: domain of buhake@googlemail.com designates 10.182.14.97 as permitted sender) client-ip=10.182.14.97; Authentication-Results: mr.google.com; spf=pass (google.com: domain of buhake@googlemail.com designates 10.182.14.97 as permitted sender) smtp.mail=buhake@googlemail.com; dkim=pass header.i=buhake@googlemail.com Received: from mr.google.com ([10.182.14.97]) by 10.182.14.97 with SMTP id o1mr15261191obc.57.1329824425321 (num_hops = 1); Tue, 21 Feb 2012 03:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QDeWW+3vFi+ykTsLtf9AEXb1jviSh/cpsii1ceZjqT4=; b=Fw15c0o1PZwxMAx/BlgLlVpmeUtabb586UglxFMjfY+dVrrS58Y4VBZPPbNdW94Kyw sCpdxeYeHG4aCAs5d5Ub8ikXkTe6ss3wlWcOneuTBu1BAZdLGXfX4P8Y7AYYxAx+EvT1 18eilmWnJx/LM1f8Jxy15spjjyBkIr/yDhLjU= Received: by 10.182.14.97 with SMTP id o1mr12991101obc.57.1329824425237; Tue, 21 Feb 2012 03:40:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.62.231 with HTTP; Tue, 21 Feb 2012 03:40:05 -0800 (PST) In-Reply-To: <56F7111A-B65E-459A-BB8A-ED87CDF1EB4A@gmail.com> References: <58932B8B-2DDE-41D6-A91B-5036CC762C00@matake.jp> <1329757027.28055.YahooMailNeo@web31808.mail.mud.yahoo.com> <4F4284DD.3030006@alcatel-lucent.com> <1329798149.78115.YahooMailNeo@web31804.mail.mud.yahoo.com> <56F7111A-B65E-459A-BB8A-ED87CDF1EB4A@gmail.com> From: Buhake Sindi Date: Tue, 21 Feb 2012 13:40:05 +0200 Message-ID: To: "matake@gmail" Content-Type: multipart/alternative; boundary=14dae93996cd7addc104b977e0ef X-Mailman-Approved-At: Tue, 21 Feb 2012 07:15:22 -0800 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Quick question about error response for "response_type=unknown" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 11:40:30 -0000 --14dae93996cd7addc104b977e0ef Content-Type: text/plain; charset=UTF-8 Hi guys, OAuth 2, Draft 23, Paragraph 4.1.2.1 clearly states: If the request fails due to a missing, invalid, or mismatching redirection > URI, or if the client > identifier is missing or invalid, the authorization server SHOULD inform > the resource owner of > the error, and MUST NOT automatically redirect the user-agent to the > invalid redirection URI. > So, Case 1 is the only accepted case here. Buhake Sindi On 21 February 2012 13:34, matake@gmail wrote: > So the answer is "Show the error to the user without redirecting back to > the client", right? > I'm now developing OAuth2 and OpenID Connect ruby library, and both of > them return errors > > case 1. redirect with error in query if response_type is "code" but it's > not supported > case 2. redirect with error in fragment if response_type is "token code", > "token id_token", "token code id_token" or "code id_token" but it's not > supported > case 3. otherwise show error to the user without redirect since server > cannot understand the response_type at all > > But other server might not understand some of response_types listed in > case 2 at all and choose case 3 in such case. > (ie. OAuth servers which don't understand OpenID Connect won't understand > "id_token") > > So I'm afraid that it reduces interoperability, a bit. > > On 2012/02/21, at 13:22, William Mills wrote: > > I does allow some parts of your server config to be discovered. More of a > problem in error responses is usually echoing back the user data, or > allowing user enumeration for example. Care is required, but you don't > have a ton of options here. > > ------------------------------ > *From:* Igor Faynberg > *To:* oauth@ietf.org > *Sent:* Monday, February 20, 2012 9:37 AM > *Subject:* Re: [OAUTH-WG] Quick question about error response for > "response_type=unknown" > > Could there be a potential security hole in providing an error > response? (Not that I see it, but many problems in the past had been > caused by helpful responese.) > > Igor > > On 2/20/2012 11:57 AM, William Mills wrote: > > Respond with an error in protocol. Thta won't include a redirect, and > the client has to know what to do. > > ------------------------------ > *From:* nov matake > *To:* oauth WG > *Sent:* Monday, February 20, 2012 6:11 AM > *Subject:* [OAUTH-WG] Quick question about error response for > "response_type=unknown" > > Hi OAuthers, > > My apologies if you already discussed this. > > When OAuth server received unknown response_type, how should the server > handle the error? > > 1. Show the error to the user without redirecting back to the client > 2. Redirect back to the client including the error in query > 3. Redirect back to the client including the error in fragment > > Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for > me. > > > -- > nov > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --14dae93996cd7addc104b977e0ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi guys,

OAuth 2, Draft 23, Paragraph 4.1.2.1 clearly states:
If the request fails due= to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform th= e resource owner of
the error, and MUST NOT automatically redirect the u= ser-agent to the invalid redirection URI.

So, Case= 1 is the only accepted case here.

Buhake Sindi
=C2=A0

On 21 Fe= bruary 2012 13:34, matake@gmail <matake@gmail.com> wrote:
So the answer is "Show the error t= o the user without redirecting back to the client", right?
I'm= now developing OAuth2 and OpenID Connect ruby library, and both of them re= turn errors

case 1. redirect with error in query if response_type i= s "code" but it's not supported
case 2. redirect wi= th error in fragment if response_type is "token code", "toke= n id_token", "token code id_token" or "code id_token&qu= ot; but it's not supported
case 3. otherwise show error to the user without redirect since server= cannot understand the response_type at all

But ot= her server might not understand some of response_types listed in case 2 at = all and choose case 3 in such case.
(ie. OAuth servers which don't understand OpenID Connect won't= understand "id_token")

So I'm afrai= d that it reduces interoperability, a bit.

On 201= 2/02/21, at 13:22, William Mills wrote:

=
I does allow some parts of your server config to = be discovered.=C2=A0 More of a problem in error responses is usually echoin= g back the user data, or allowing user enumeration for example.=C2=A0 Care = is required, but you don't have a ton of options here.

From: Igor Faynberg <igor.fa= ynberg@alcatel-lucent.com>
T= o: oauth@iet= f.org
Sent: Monday, February 20, = 2012 9:37 AM
Subject: Re= : [OAUTH-WG] Quick question about error response for "response_type=3D= unknown"

=20 =20 =20
Could there be a potential security hole in providing an error response?=C2=A0 (Not that I see it, but many problems in the past had been caused by helpful responese.)

Igor

On 2/20/2012 11:57 AM, William Mills wrote:
Respond with an error in protocol.=C2=A0 Thta won't include a redirect, and the client has to know what to do.

From: nov matake <nov@matake.jp>
To: oauth WG <oauth@ietf.org>
Sent: Monday, February 20, 2012 6:11 AM
Subject: [OAUTH-WG] Quick question about error response for "response_type=3Dunknown"

Hi OAuthers,

My apologies if you already discussed this.

When OAuth server received unknown response_type, how should the server handle the error?

1. Show the error to the user without redirecting back to the client
2. Redirect back to the client including the error in query
3. Redirect back to the client including the error in fragment

Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for me.


--
nov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth= 



_______________________________________________
OAuth mailing list
OAuth@=
ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing = list
OAuth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________= ________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h


____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth





--14dae93996cd7addc104b977e0ef-- From buhake@googlemail.com Tue Feb 21 03:43:17 2012 Return-Path: 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 7138021F8518 for ; Tue, 21 Feb 2012 03:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 7ZIWUOftEkmO for ; Tue, 21 Feb 2012 03:43:13 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A46E21F8738 for ; Tue, 21 Feb 2012 03:43:13 -0800 (PST) Received: by obbwd15 with SMTP id wd15so9713190obb.31 for ; Tue, 21 Feb 2012 03:43:13 -0800 (PST) Received-SPF: pass (google.com: domain of buhake@googlemail.com designates 10.182.1.4 as permitted sender) client-ip=10.182.1.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of buhake@googlemail.com designates 10.182.1.4 as permitted sender) smtp.mail=buhake@googlemail.com; dkim=pass header.i=buhake@googlemail.com Received: from mr.google.com ([10.182.1.4]) by 10.182.1.4 with SMTP id 4mr15266631obi.67.1329824593220 (num_hops = 1); Tue, 21 Feb 2012 03:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+IteTQaILukErutIPyqRyERsAsAgHj07UuA2e/tvsl4=; b=kR1eYjH1qrdyMQ2JgBzFgX+4s7zUTQpNWOhgK69Gq6bcXseQAUCN4lSVBdJ09sAiwx QHGR8v0Ohp+7GQzlXcRpzsazgtyLWNpmA1epxjGyrHhBSp9/gxIkM0EPxVPTleEXCUGr /579y9wjwLZ8f0mx4UcGTEPFHrz6ol8uXv3Sg= Received: by 10.182.1.4 with SMTP id 4mr13001519obi.67.1329824593158; Tue, 21 Feb 2012 03:43:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.62.231 with HTTP; Tue, 21 Feb 2012 03:42:53 -0800 (PST) In-Reply-To: References: <58932B8B-2DDE-41D6-A91B-5036CC762C00@matake.jp> <1329757027.28055.YahooMailNeo@web31808.mail.mud.yahoo.com> <4F4284DD.3030006@alcatel-lucent.com> <1329798149.78115.YahooMailNeo@web31804.mail.mud.yahoo.com> <56F7111A-B65E-459A-BB8A-ED87CDF1EB4A@gmail.com> From: Buhake Sindi Date: Tue, 21 Feb 2012 13:42:53 +0200 Message-ID: To: "matake@gmail" Content-Type: multipart/alternative; boundary=f46d0447a0bd7d22c604b977ea6b X-Mailman-Approved-At: Tue, 21 Feb 2012 07:15:22 -0800 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Quick question about error response for "response_type=unknown" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 11:43:17 -0000 --f46d0447a0bd7d22c604b977ea6b Content-Type: text/plain; charset=UTF-8 Oops. Sorry, I believe I should have said, case 2. And why is case 2 impossible? The only time case 1 is valid in the redirect_uri is invalid. Buhake Sindi On 21 February 2012 13:40, Buhake Sindi wrote: > Hi guys, > > OAuth 2, Draft 23, Paragraph 4.1.2.1 clearly states: > > If the request fails due to a missing, invalid, or mismatching redirection >> URI, or if the client >> identifier is missing or invalid, the authorization server SHOULD inform >> the resource owner of >> the error, and MUST NOT automatically redirect the user-agent to the >> invalid redirection URI. >> > > So, Case 1 is the only accepted case here. > > Buhake Sindi > > > On 21 February 2012 13:34, matake@gmail wrote: > >> So the answer is "Show the error to the user without redirecting back to >> the client", right? >> I'm now developing OAuth2 and OpenID Connect ruby library, and both of >> them return errors >> >> case 1. redirect with error in query if response_type is "code" but it's >> not supported >> case 2. redirect with error in fragment if response_type is "token code", >> "token id_token", "token code id_token" or "code id_token" but it's not >> supported >> case 3. otherwise show error to the user without redirect since server >> cannot understand the response_type at all >> >> But other server might not understand some of response_types listed in >> case 2 at all and choose case 3 in such case. >> (ie. OAuth servers which don't understand OpenID Connect won't understand >> "id_token") >> >> So I'm afraid that it reduces interoperability, a bit. >> >> On 2012/02/21, at 13:22, William Mills wrote: >> >> I does allow some parts of your server config to be discovered. More of >> a problem in error responses is usually echoing back the user data, or >> allowing user enumeration for example. Care is required, but you don't >> have a ton of options here. >> >> ------------------------------ >> *From:* Igor Faynberg >> *To:* oauth@ietf.org >> *Sent:* Monday, February 20, 2012 9:37 AM >> *Subject:* Re: [OAUTH-WG] Quick question about error response for >> "response_type=unknown" >> >> Could there be a potential security hole in providing an error >> response? (Not that I see it, but many problems in the past had been >> caused by helpful responese.) >> >> Igor >> >> On 2/20/2012 11:57 AM, William Mills wrote: >> >> Respond with an error in protocol. Thta won't include a redirect, and >> the client has to know what to do. >> >> ------------------------------ >> *From:* nov matake >> *To:* oauth WG >> *Sent:* Monday, February 20, 2012 6:11 AM >> *Subject:* [OAUTH-WG] Quick question about error response for >> "response_type=unknown" >> >> Hi OAuthers, >> >> My apologies if you already discussed this. >> >> When OAuth server received unknown response_type, how should the server >> handle the error? >> >> 1. Show the error to the user without redirecting back to the client >> 2. Redirect back to the client including the error in query >> 3. Redirect back to the client including the error in fragment >> >> Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for >> me. >> >> >> -- >> nov >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > > -- The Elite Gentleman --f46d0447a0bd7d22c604b977ea6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oops. Sorry, I believe I should have said, case 2.

And why is case 2= impossible? The only time case 1 is valid in the redirect_uri is invalid.<= br>
Buhake Sindi

On 21 February 2012 1= 3:40, Buhake Sindi <buhake@googlemail.com> wrote:
Hi guys,

OAuth 2, Draft 23, Paragraph= 4.1.2.1 clearly states:

If the request fails due to a missing, invalid, or mismatching redirection = URI, or if the client
identifier is missing or invalid, the authorization server SHOULD inform th= e resource owner of
the error, and MUST NOT automatically redirect the u= ser-agent to the invalid redirection URI.

So, Case= 1 is the only accepted case here.

Buhake Sindi
=C2=A0

On 21 February 2012 13:34, ma= take@gmail <matake@gmail.com> wrote:
So the answer is "Show the error t= o the user without redirecting back to the client", right?
I'm= now developing OAuth2 and OpenID Connect ruby library, and both of them re= turn errors

case 1. redirect with error in query if response_type i= s "code" but it's not supported
case 2. redirect wi= th error in fragment if response_type is "token code", "toke= n id_token", "token code id_token" or "code id_token&qu= ot; but it's not supported
case 3. otherwise show error to the user without redirect since server= cannot understand the response_type at all

But ot= her server might not understand some of response_types listed in case 2 at = all and choose case 3 in such case.
(ie. OAuth servers which don't understand OpenID Connect won't= understand "id_token")

So I'm afrai= d that it reduces interoperability, a bit.

On 201= 2/02/21, at 13:22, William Mills wrote:

=
I does allow some parts of your server config to = be discovered.=C2=A0 More of a problem in error responses is usually echoin= g back the user data, or allowing user enumeration for example.=C2=A0 Care = is required, but you don't have a ton of options here.

From: Igor Faynberg <igor.fa= ynberg@alcatel-lucent.com>
T= o: oauth@iet= f.org
Sent: Monday, February 20, = 2012 9:37 AM
Subject: Re= : [OAUTH-WG] Quick question about error response for "response_type=3D= unknown"

=20 =20 =20
Could there be a potential security hole in providing an error response?=C2=A0 (Not that I see it, but many problems in the past had been caused by helpful responese.)

Igor

On 2/20/2012 11:57 AM, William Mills wrote:
Respond with an error in protocol.=C2=A0 Thta won't include a redirect, and the client has to know what to do.

From: nov matake <nov@matake.jp>
To: oauth WG <oauth@ietf.org>
Sent: Monday, February 20, 2012 6:11 AM
Subject: [OAUTH-WG] Quick question about error response for "response_type=3Dunknown"

Hi OAuthers,

My apologies if you already discussed this.

When OAuth server received unknown response_type, how should the server handle the error?

1. Show the error to the user without redirecting back to the client
2. Redirect back to the client including the error in query
3. Redirect back to the client including the error in fragment

Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for me.


--
nov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth= 



_______________________________________________
OAuth mailing list
OAuth@=
ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing = list
OAuth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________= ________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h


____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth