Re: [OAUTH-WG] Basic signature support in the core specification
Justin Richer <jricher@mitre.org> Mon, 27 September 2010 19:03 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 1959D3A6D57 for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 12:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.491
X-Spam-Level:
X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 LKomHfbZLZ4b for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 12:03:12 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 43E6C3A6B49 for <oauth@ietf.org>; Mon, 27 Sep 2010 12:03:12 -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 o8RJ3oK6016607 for <oauth@ietf.org>; Mon, 27 Sep 2010 15:03:50 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o8RJ3oQv016604; Mon, 27 Sep 2010 15:03:50 -0400
Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Mon, 27 Sep 2010 15:03:49 -0400
From: Justin Richer <jricher@mitre.org>
To: Eran Hammer-Lahav <eran@hueniverse.com>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DB2F3@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <C8C15057.3AC64%eran@hueniverse.com> <D01C840D-BA0A-42AE-A6C4-C43E6E84C2F2@gmail.com> <255B9BB34FB7D647A506DC292726F6E1126BFB1574@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D45D80132@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CD71CDA0-15FA-4860-87EA-BE9C4B6932E4@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D45D80136@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimKJGRBqXPiUVROYQNRhj0KPEp0C4K8KXqUHjsr@mail.gmail.com> <9706DE2E-1691-48D1-BC8A-3AEEEAB5C6C4@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D460DB2F3@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 27 Sep 2010 15:03:49 -0400
Message-ID: <1285614229.15179.179.camel@localhost.localdomain>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 8bit
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Basic signature support in the core specification
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: Mon, 27 Sep 2010 19:03:14 -0000
Arguments like this are why I have been advocating for separating the "developers guide" from the "protocol spec" for a while now. I believe that they support two different audiences. A developers' guide then has the option of combining multiple specs, selecting profiles of those specs, and laying out exactly what's happening at each step for people to follow. -- Justin On Mon, 2010-09-27 at 11:35 -0400, Eran Hammer-Lahav wrote: > This is a stupid discussion. We have been talking past each other (the > working group) for over a year. We are not likely to convince either > side that bearer tokens are bad or good idea. > > > > All these experts reviewed WRAP in the strict context of their own > environment, with existing protocols and other weaknesses. Other and I > are reviewing it in the wider context of what is good for the web, and > am much less concerned about complexity. IOW, I don’t believe that in > this case WRAP made the right choice between developer ease and > security. > > > > This is also exactly the problem with the current specification. New > readers are more likely to assume that what is good for these big > companies is also good for them, without making their own threat model > analysis. How would they reach any other conclusion when the > specification doesn’t offer a complete alternative? > > > > We should focus on finding a compromise everyone can live with, since > clearly debating the two sides has produced nothing. I think > positioning bearer tokens as the primary mechanism, but including a > signature alternative in the same specification is a reasonable > compromise. Bearer token fans get the spotlight, while those looking > for a signature (providing the same protections as 1.0a HMAC-SHA-1) > get some algorithm included. > > > > We need to find a way to give each side something to live with. > > > > EHL > > > > > > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Monday, September 27, 2010 6:31 AM > To: John Panzer; Eran Hammer-Lahav > Cc: OAuth WG; Ben Laurie > Subject: Re: [OAUTH-WG] Basic signature support in the core > specification > > > > > I'll echo John's comments and remind you that Micrsoft, Yahoo! and > Google security experts with plenty of real world experience worked on > WRAP which is OAuth bearer tokens. > > > > > Microsoft, Google, Salesforce, Facebook and others have deployed > bearer token OAuth in production after internal security reviews. I > don't think that is a personal opinion, that is fact. > > > > > wrt. another comment you had about security considerations, Brian > Eaton did write up a bunch of security considerations for WRAP. > > > > > On 2010-09-27, at 12:01 AM, John Panzer wrote: > > > > > On Sun, Sep 26, 2010 at 11:37 PM, Eran Hammer-Lahav > <eran@hueniverse.com> wrote: > > > > > -----Original Message----- > > From: Dick Hardt [mailto:dick.hardt@gmail.com] > > Sent: Sunday, September 26, 2010 11:21 PM > > > > What I absolutely object to is presenting a specification that to > a new > > reader will read as if bearer tokens are the default way to go. > OAuth 2.0 core > > today reads like a complete protocol and that's my problem. > > > > It is a complete protocol for many existing use cases. > > > That's clearly a matter of personal opinion :-) and why we have been > arguing about this for over a year. > > > > For those use cases > > where it is not, you can call require signatures and point people to > the > > signature spec, just like the use of bearer tokens points people to > the TLS > > specs. > > > According to Ben Laurie [1] and Ben Adida [2], a simple reference to > TLS is a recipe for disaster. > > > > > Actually in [1], Ben Laurie does not say that a simple reference to > TLS is a recipe for disaster. (Go read it.) In fact his first point > is that you need a well-define threat model before you can talk > sensibly about any of this; I would really like us to do that in this > case too. > > > > > > People tend to implement TLS incorrectly on the client side > which voids many of the important protections it is meant to > provide. > > > > > The bits they tend to implement incorrectly (specifically, things like > checking for certificate revocations) seem to me to be very general > and exactly the kinds of things one needs in order to implement _any_ > protection against the endpoint impersonation you are worried about. > Why would they be more likely to get it right for a new protocol than > for an existing one? > > > > > > > As the editor, I am having a hard time consolidating your view > which treats readers as security experts, capable of making > educated decisions about the protocol, and the demands from > others that the specification should be completely accessible > to any developer (especially those with no security > background) and read like a tutorial on OAuth. > > If we want to keep the full range, we need to clearly express > it, including highlighting the significant shortcomings of > bearer tokens, the known TLS deployment issues, and the value > in whatever signature proposals we have ready to reference or > include. > > Standards are meant to improve interoperability, but also > security. This is why any IETF charter dealing with an > existing technology states that the working group may break > compatibility if it has interop or security reasons to do so. > We are doing fine on interop, but doing pretty badly on > security. > > EHL > > [1] http://www.links.org/?p=846 > [2] http://benlog.com/articles/2009/12/22/its-a-wrap/ > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > >
- [OAUTH-WG] Basic signature support in the core sp… Eran Hammer-Lahav
- Re: [OAUTH-WG] Basic signature support in the cor… William Mills
- Re: [OAUTH-WG] Basic signature support in the cor… Torsten Lodderstedt
- Re: [OAUTH-WG] Basic signature support in the cor… Bastian Hofmann
- Re: [OAUTH-WG] Basic signature support in the cor… George Fletcher
- Re: [OAUTH-WG] Basic signature support in the cor… Justin Richer
- Re: [OAUTH-WG] Basic signature support in the cor… Igor Faynberg
- Re: [OAUTH-WG] Basic signature support in the cor… Eve Maler
- Re: [OAUTH-WG] Basic signature support in the cor… Justin Richer
- Re: [OAUTH-WG] Basic signature support in the cor… Doreswamy, Rangan
- Re: [OAUTH-WG] Basic signature support in the cor… John Panzer
- Re: [OAUTH-WG] Basic signature support in the cor… David Recordon
- Re: [OAUTH-WG] Basic signature support in the cor… Dick Hardt
- Re: [OAUTH-WG] Basic signature support in the cor… Dick Hardt
- Re: [OAUTH-WG] Basic signature support in the cor… Nat
- Re: [OAUTH-WG] Basic signature support in the cor… Eran Hammer-Lahav
- Re: [OAUTH-WG] Basic signature support in the cor… Eran Hammer-Lahav
- Re: [OAUTH-WG] Basic signature support in the cor… Eran Hammer-Lahav
- Re: [OAUTH-WG] Basic signature support in the cor… Dick Hardt
- Re: [OAUTH-WG] Basic signature support in the cor… Dick Hardt
- Re: [OAUTH-WG] Basic signature support in the cor… Mark Mcgloin
- Re: [OAUTH-WG] Basic signature support in the cor… Torsten Lodderstedt
- Re: [OAUTH-WG] Basic signature support in the cor… Eran Hammer-Lahav
- Re: [OAUTH-WG] Basic signature support in the cor… Eran Hammer-Lahav
- Re: [OAUTH-WG] Basic signature support in the cor… Dick Hardt
- Re: [OAUTH-WG] Basic signature support in the cor… Eve Maler
- Re: [OAUTH-WG] Basic signature support in the cor… Dick Hardt
- Re: [OAUTH-WG] Basic signature support in the cor… Manger, James H
- Re: [OAUTH-WG] Basic signature support in the cor… Eran Hammer-Lahav
- Re: [OAUTH-WG] Basic signature support in the cor… Dick Hardt
- Re: [OAUTH-WG] Basic signature support in the cor… Eran Hammer-Lahav
- Re: [OAUTH-WG] Basic signature support in the cor… John Panzer
- Re: [OAUTH-WG] Basic signature support in the cor… Dick Hardt
- Re: [OAUTH-WG] Basic signature support in the cor… Mark Mcgloin
- Re: [OAUTH-WG] Basic signature support in the cor… Eran Hammer-Lahav
- Re: [OAUTH-WG] Basic signature support in the cor… Dick Hardt
- Re: [OAUTH-WG] Basic signature support in the cor… Igor Faynberg
- Re: [OAUTH-WG] Basic signature support in the cor… Eran Hammer-Lahav
- [OAUTH-WG] CORRECTION: Re: Basic signature suppor… Igor Faynberg
- Re: [OAUTH-WG] Basic signature support in the cor… William Mills
- Re: [OAUTH-WG] Basic signature support in the cor… Anthony Nadalin
- Re: [OAUTH-WG] CORRECTION: Re: Basic signature su… Dick Hardt
- Re: [OAUTH-WG] Basic signature support in the cor… Torsten Lodderstedt
- Re: [OAUTH-WG] Basic signature support in the cor… Justin Richer
- Re: [OAUTH-WG] Basic signature support in the cor… Dick Hardt
- Re: [OAUTH-WG] Basic signature support in the cor… Eran Hammer-Lahav
- Re: [OAUTH-WG] Basic signature support in the cor… Torsten Lodderstedt
- Re: [OAUTH-WG] Basic signature support in the cor… Justin Richer