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

"Richard L. Barnes" <rbarnes@bbn.com> Fri, 24 September 2010 15:25 UTC

Return-Path: <rbarnes@bbn.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 7E1A83A69EA for <oauth@core3.amsl.com>; Fri, 24 Sep 2010 08:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.405
X-Spam-Level:
X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 UB+1qTHYPS21 for <oauth@core3.amsl.com>; Fri, 24 Sep 2010 08:25:54 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A4DB63A687F for <oauth@ietf.org>; Fri, 24 Sep 2010 08:25:54 -0700 (PDT)
Received: from ros-dhcp192-1-51-60.bbn.com ([192.1.51.60]:62810) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1OzAAL-000HGw-V1; Fri, 24 Sep 2010 11:26:26 -0400
Message-Id: <BFF19F03-2B06-4C93-8CE0-2C9A6A267CE4@bbn.com>
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: Justin Richer <jricher@mitre.org>
In-Reply-To: <1285339868.15179.139.camel@localhost.localdomain>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 24 Sep 2010 11:26:25 -0400
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>
X-Mailer: Apple Mail (2.936)
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 15:25:55 -0000

> 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.

Ah, perhaps I was unclear.  I didn't mean *signing* metadata, I meant  
*sending* metadata.  Using a completely made-up syntax:

1. Signer computes signature sig_val over data object:
    { user_agent: "Mozilla", method: "GET" }
2. Signer sends { signed_fields: ['user_agent', 'method'], sig:  
sig_val }
3. Recipient reconstructs data object using signed_fields
4. Recipient verifies sig_val == sign(reconstructed_object)

--Richard