Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests?

PRATEEK MISHRA <prateek.mishra@oracle.com> Fri, 24 September 2010 22:19 UTC

Return-Path: <prateek.mishra@oracle.com>
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 71E663A6A7A for <oauth@core3.amsl.com>; Fri, 24 Sep 2010 15:19:30 -0700 (PDT)
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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 gd5jGZhnKzTY for <oauth@core3.amsl.com>; Fri, 24 Sep 2010 15:19:29 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 187703A6A69 for <oauth@ietf.org>; Fri, 24 Sep 2010 15:19:29 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8OMJxtJ022353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Sep 2010 22:20:01 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8OLXMxC015273; Fri, 24 Sep 2010 22:19:59 GMT
Received: from abhmt005.oracle.com by acsmt355.oracle.com with ESMTP id 635583531285366716; Fri, 24 Sep 2010 15:18:36 -0700
Received: from [192.168.1.7] (/209.6.179.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 Sep 2010 15:18:36 -0700
Message-ID: <4C9D23B6.8090605@oracle.com>
Date: Fri, 24 Sep 2010 18:18:30 -0400
From: PRATEEK MISHRA <prateek.mishra@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Yaron Goland <yarong@microsoft.com>
References: <7C01E631FF4B654FA1E783F1C0265F8C635347FF@TK5EX14MBXC111.redmond.corp.microsoft.com>
In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C635347FF@TK5EX14MBXC111.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------010800030508090509010103"
Cc: "oauth@ietf.org" <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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Sep 2010 22:19:30 -0000

Yaron,

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

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

I dont believe that similar constraints have been placed on the OAuth 
access token - it is essentially undefined? - but maybe I missed that in 
my reading 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 replay attacks in discovery 
> style scenarios. He then, if I understood the article correctly, 
> argues that the solution to the replay attack is to 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 discovery scenarios using OAuth 2.0 and bearer tokens. If 
> the article is correct then it is not a requirement to introduce 
> message signing into OAuth 2.0 in order 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
>