Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec
Justin Richer <jricher@mitre.org> Fri, 24 September 2010 14:50 UTC
Return-Path: <jricher@mitre.org>
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 96B643A6AF1 for <oauth@core3.amsl.com>; Fri, 24 Sep 2010 07:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.497
X-Spam-Level:
X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, 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 ahAUQDvpJWpU for <oauth@core3.amsl.com>; Fri, 24 Sep 2010 07:50:39 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 14D4F3A695A for <oauth@ietf.org>; Fri, 24 Sep 2010 07:50:39 -0700 (PDT)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o8OEp9QZ010782 for <oauth@ietf.org>; Fri, 24 Sep 2010 10:51:10 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o8OEp94B010777; Fri, 24 Sep 2010 10:51:09 -0400
Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Fri, 24 Sep 2010 10:51:09 -0400
From: Justin Richer <jricher@mitre.org>
To: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <440E4C9A-41A2-4203-80B8-B6967D886A80@bbn.com>
References: <C8C16037.3AC75%eran@hueniverse.com> <1285335868.15179.98.camel@localhost.localdomain> <440E4C9A-41A2-4203-80B8-B6967D886A80@bbn.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 24 Sep 2010 10:51:08 -0400
Message-ID: <1285339868.15179.139.camel@localhost.localdomain>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
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 14:50:41 -0000
> > 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
- [OAUTH-WG] Google's view on signatures in the cor… Eric Sachs
- Re: [OAUTH-WG] Google's view on signatures in the… Anthony Nadalin
- Re: [OAUTH-WG] Google's view on signatures in the… Eran Hammer-Lahav
- Re: [OAUTH-WG] Google's view on signatures in the… Anthony Nadalin
- Re: [OAUTH-WG] Google's view on signatures in the… Eric Sachs
- Re: [OAUTH-WG] Google's view on signatures in the… Dick Hardt
- Re: [OAUTH-WG] Google's view on signatures in the… Richard L. Barnes
- Re: [OAUTH-WG] Google's view on signatures in the… Eran Hammer-Lahav
- Re: [OAUTH-WG] Google's view on signatures in the… Justin Richer
- Re: [OAUTH-WG] Google's view on signatures in the… Richard L. Barnes
- Re: [OAUTH-WG] Google's view on signatures in the… Justin Richer
- Re: [OAUTH-WG] Google's view on signatures in the… Richard L. Barnes
- Re: [OAUTH-WG] Google's view on signatures in the… Eran Hammer-Lahav
- Re: [OAUTH-WG] Google's view on signatures in the… John Panzer
- Re: [OAUTH-WG] Google's view on signatures in the… Richard L. Barnes
- Re: [OAUTH-WG] Google's view on signatures in the… John Panzer
- Re: [OAUTH-WG] Google's view on signatures in the… John Panzer
- Re: [OAUTH-WG] Google's view on signatures in the… Richard L. Barnes