Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450963A6E15 for ; Fri, 1 Oct 2010 15:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.403 X-Spam-Level: X-Spam-Status: No, score=-10.403 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XOQbUQICUUo for ; Fri, 1 Oct 2010 15:47:20 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5856D3A6E06 for ; Fri, 1 Oct 2010 15:47:20 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 1 Oct 2010 15:48:03 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.15]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0218.012; Fri, 1 Oct 2010 15:48:02 -0700 From: Yaron Goland To: PRATEEK MISHRA Thread-Topic: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests? Thread-Index: ActcLVkcw12z9VXcRZaPemtNsnYbYQAQ74MAAVJFP2A= Date: Fri, 1 Oct 2010 22:48:02 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C635D3859@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C635347FF@TK5EX14MBXC111.redmond.corp.microsoft.com> <4C9D23B6.8090605@oracle.com> In-Reply-To: <4C9D23B6.8090605@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C635D3859TK5EX14MBXC113r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 22:47:22 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C635D3859TK5EX14MBXC113r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the core OAuth spec the scenario is a tightly related token and applicat= ion endpoint. It presumes that they will take the appropriate security mech= anisms between them such as signed tokens but doesn't require any particula= r solution for how to implement such a mechanism. When the issue was extended to address discovery based scenarios (a scenari= o not currently supported by the core spec) this brought up the problem tha= t a standard mechanism to provide audience protection is needed. So my arti= cle suggests that when discovery is in scope then we will introduce a stand= ard mechanism (in my article I suggest a standardized signed token format i= ncluding an audience value) to address the issue. In other words, the current spec leaves the issue unaddressed because it is= n't in scope but when the scope extends to discovery we'll have to provide = an explicit mechanism. Yaron From: PRATEEK MISHRA [mailto:prateek.mishra@oracle.com] Sent: Friday, September 24, 2010 3:19 PM To: Yaron Goland Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests? Yaron, You have referenced the SAML browser SSO protocol (POST profile) in your b= log posting, and correctly observed that the same problem would manifest it= self there as well. As a counter-measure, the SAML POST profile explicitly requires that the ta= rget (destination) URL or similar identifier be carried as part of the SAM= L payload, and, that further the SAML payload is signed. This allows for th= e recipient to determine whether it was the intended target and to ignore p= ayloads directed at other targets. I dont believe that similar constraints have been placed on the OAuth acces= s token - it is essentially undefined? - but maybe I missed that in my read= ing of the specification draft. - prateek My understanding of Eran's article (http://hueniverse.com/2010/09/oauth-2-0= -without-signatures-is-bad-for-the-web/) is that Eran believes that bearer = tokens are not good enough as a security mechanism because they allow for r= eplay attacks in discovery style scenarios. He then, if I understood the ar= ticle correctly, argues that the solution to the replay attack is to sign O= Auth 2.0 requests. In http://www.goland.org/bearer-tokens-discovery-and-oauth-2-0/ I tried to = demonstrate that in fact one can easily prevent replay attacks in discovery= scenarios using OAuth 2.0 and bearer tokens. If the article is correct the= n it is not a requirement to introduce message signing into OAuth 2.0 in or= der to prevent the attacks that Eran identified. So this leaves me wondering, what's the critical scenario that can't be met= unless we use sign OAuth 2.0 requests? Thanks, Yaron ________________________________ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_7C01E631FF4B654FA1E783F1C0265F8C635D3859TK5EX14MBXC113r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the core OAuth spec= the scenario is a tightly related token and application endpoint. It presu= mes that they will take the appropriate security mechanisms between them su= ch as signed tokens but doesn't require any particular solution for how to implement such a mechanism.<= /span>

 

When the issue was ext= ended to address discovery based scenarios (a scenario not currently suppor= ted by the core spec) this brought up the problem that a standard mechanism= to provide audience protection is needed. So my article suggests that when discovery is in scope then we will introd= uce a standard mechanism (in my article I suggest a standardized signed tok= en format including an audience value) to address the issue.

 

In other words, the cu= rrent spec leaves the issue unaddressed because it isn't in scope but when = the scope extends to discovery we'll have to provide an explicit mechanism.=

 

   &nbs= p;            &= nbsp;           &nbs= p;   Yaron

 

From: PRATEEK MISHRA [mailto:prateek.mishra@oracle.com]
Sent: Friday, September 24, 2010 3:19 PM
To: Yaron Goland
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 re= quests?

 

Yaron,

You have referenced the SAML browser SSO protocol  (POST profile) in y= our blog posting, and correctly observed that the same problem would manife= st itself there as well.

As a counter-measure, the SAML POST profile explicitly requires that the ta= rget  (destination) URL or similar identifier be carried as part of th= e SAML payload, and, that further the SAML payload is signed. This allows f= or the recipient to determine whether it was the intended target and to ignore payloads directed at other target= s.

I dont believe that similar constraints have been placed on the OAuth acces= s token - it is essentially undefined? - but maybe I missed that in my read= ing of the specification draft.

- prateek

My understanding of Eran's article (= http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-w= eb/) is that Eran believes that bearer tokens are not good enough as a security mechanism because they all= ow for replay attacks in discovery style scenarios. He then, if I understoo= d the article correctly, argues that the solution to the replay attack is t= o sign OAuth 2.0 requests.

In http://www.goland.org/bearer-tokens-discovery-and-oauth-2-0/ I tried to= demonstrate that in fact one can easily prevent replay attacks in discover= y scenarios using OAuth 2.0 and bearer tokens. If the article is correct th= en it is not a requirement to introduce message signing into OAuth 2.0 in order to prevent the attacks that Eran i= dentified.

 

So this leaves me wondering, what's the critical sce= nario that can't be met unless we use sign OAuth 2.0 requests?

 

        &nbs= p;       Thanks,

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; Yaron

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