Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00

Eran Hammer-Lahav <eran@hueniverse.com> Tue, 22 February 2011 18:39 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 A9BCC3A6966 for <oauth@core3.amsl.com>; Tue, 22 Feb 2011 10:39:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level:
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 ms7BJNrHajNv for <oauth@core3.amsl.com>; Tue, 22 Feb 2011 10:39:54 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E41FA3A695D for <oauth@ietf.org>; Tue, 22 Feb 2011 10:39:49 -0800 (PST)
Received: (qmail 22155 invoked from network); 22 Feb 2011 18:40:33 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Feb 2011 18:40:33 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 22 Feb 2011 11:40:28 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Brian Eaton <beaton@google.com>
Date: Tue, 22 Feb 2011 11:40:12 -0700
Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00
Thread-Index: AcvSUmxeu8ZLGiUAR0yfeSjRDfnrIQAbUL8g
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D47FF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4D6165F1.6010401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A91D4581@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTikaGZaBJ7R+0yKSi7yX5y9FcTrMqDyzyf8J2iCN@mail.gmail.com>
In-Reply-To: <AANLkTikaGZaBJ7R+0yKSi7yX5y9FcTrMqDyzyf8J2iCN@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A91D47FFP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00
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: Tue, 22 Feb 2011 18:39:59 -0000

IETF rules require a security considerations section. That doesn't mean we can't also incorporate additional security text into each grant section. But having one comprehensive security section makes the other parts easier to read.

EHL

From: Brian Eaton [mailto:beaton@google.com]
Sent: Monday, February 21, 2011 9:36 PM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00

On Sun, Feb 20, 2011 at 3:47 PM, Eran Hammer-Lahav <eran@hueniverse.com<mailto:eran@hueniverse.com>> wrote:
How do you envision this being incorporated into v2? Just section 5 or the entire document?

My two cents: rather than dedicating a single section of the core doc to security considerations, smaller sections should be added to individual profiles.  I think the following sections would be useful:

User-agent and web-server flow: mostly the same security considerations for these two flows.  I think there are subsections here.
   1) Authorization server implementation
   2) Client implementation

Token design: Design and implementation recommendations for refresh tokens and access tokens.

Client id, client secret, and assertions: when and how to use client secrets, when and how to use assertions, how to store, etc...

Other flows: each of the other flows has separate security considerations.  In some cases they are brief, but they pretty much always need to be there.

Cheers,
Brian