Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

Eran Hammer-Lahav <eran@hueniverse.com> Fri, 24 September 2010 16:09 UTC

Return-Path: <eran@hueniverse.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 173743A69E2 for <oauth@core3.amsl.com>; Fri, 24 Sep 2010 09:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level:
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599]
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 84jdHLxm8H+d for <oauth@core3.amsl.com>; Fri, 24 Sep 2010 09:09:04 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 103013A6AE0 for <oauth@ietf.org>; Fri, 24 Sep 2010 09:09:04 -0700 (PDT)
Received: (qmail 12712 invoked from network); 24 Sep 2010 16:09:35 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 24 Sep 2010 16:09:35 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 24 Sep 2010 09:09:26 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Justin Richer <jricher@mitre.org>
Date: Fri, 24 Sep 2010 09:06:10 -0700
Thread-Topic: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec
Thread-Index: ActcAtt7x3XPvXLOSvSMNggg+yObhA==
Message-ID: <51097F4B-C0C7-499E-BB51-C55E55D2291A@hueniverse.com>
References: <C8C16037.3AC75%eran@hueniverse.com> <1285335868.15179.98.camel@localhost.localdomain> <440E4C9A-41A2-4203-80B8-B6967D886A80@bbn.com> <1285339868.15179.139.camel@localhost.localdomain>
In-Reply-To: <1285339868.15179.139.camel@localhost.localdomain>
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 <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec
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 16:09:06 -0000

Validating the signed data delivered with the request is as much magic as the current 1.0 approach. Go write the validation rules and see.

I'm getting really tired of this argument because it is not grounded in reality. Any attempt to compare the HTTP request to what was signed, whether it is sent with the request or not, is as difficult. Sending the signed data just makes it easier for the server to make bad assumptions and be flexible in an insecure way. 

EHL

On Sep 24, 2010, at 10:51, "Justin Richer" <jricher@mitre.org> wrote:

>>> I think that any signature method that we end up using needs to rely
>>> less on magic and anecdote and more on explicit declaration.
>> 
>> This is certainly correct ...
>> 
>> 
>>> I think
>>> that Brian Eaton's approach of sending the bare string that was  
>>> signed,
>>> which was also a JSON element that could be parsed and validated,  
>>> was an
>>> essential simplification.
>> 
>> ... but this does not follow.  The signer can specify what was signed  
>> without sending the data...
>> 
>>> Even OpenID states which of the parameters on
>>> the request were signed, which makes it easier to validate.
>> 
>> ... as in this pattern.  There are some other examples of elements of  
>> the signed object being conditionally included:
>> 1. HTTP Digest authentication [1]
>> 2. The IKEv2 key exchange messages [2]
> 
> And I'm marginally OK with either pattern, though I think that the
> former is a much cleaner way to do it. I believe either case to be
> worlds better than the OAuth 1.0 method, which has caused countless
> problems. I actually had to help someone debug between sending that
> first email and this one, so I can attest that the problem has not gone
> away! :)
> 
>> As has been pointed out before, there is a security risk in sending  
>> the signed request data itself (as opposed to metadata that allows the  
>> recipient to reconstruct the data), because the recipient can choose  
>> not to verify the binding between the signed data and the request.
> 
> Yes, there is certainly a risk if someone just checks the signature and
> does not verify the content of the message. This is a bad implementation
> of an authorization system, to be sure, and it's an issue that people
> need to be aware of. But simply signing metadata doesn't completely
> solve the problem, either. In both cases there can be parameters that
> are outside of the signed request that need to be checked and treated
> appropriately. 
> 
> -- Justin
>