[secdir] OAuth

"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> Wed, 18 March 2009 08:55 UTC

Return-Path: <Hannes.Tschofenig@gmx.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 2DB7628C1A0 for <secdir@core3.amsl.com>; Wed, 18 Mar 2009 01:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.273
X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=1.325, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id J5Yb+K+1Shm1 for <secdir@core3.amsl.com>; Wed, 18 Mar 2009 01:55:21 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net []) by core3.amsl.com (Postfix) with SMTP id 34B5A28C1B0 for <secdir@ietf.org>; Wed, 18 Mar 2009 01:55:21 -0700 (PDT)
Received: (qmail invoked by alias); 18 Mar 2009 08:56:03 -0000
Received: from unknown (EHLO 4FIL42860) [] by mail.gmx.net (mp064) with SMTP; 18 Mar 2009 09:56:03 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/a4sBunlfaPi/DWd+Y8XkPnM0c16PI7hxr783s1l 9XeGp6qojpfd3N
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
To: "'Security Area Directorate'" <secdir@ietf.org>
Date: Wed, 18 Mar 2009 10:57:14 +0200
Message-ID: <000301c9a7a7$890fa250$9c11a20a@nsnintra.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C9A7B8.4C987250"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: Acmnp4hrMsAAWt8eRgCo6a29viHzmA==
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.5,0.51
Subject: [secdir] OAuth
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2009 08:55:23 -0000

Hi all, 

I would like to point you to the Open Web authentication BOF on Monday,
1300-1500, in Continental 4. 

Your security related review comments are highly appreciated. Here is the
link to the latest version of the OAuth draft:


>-----Original Message-----
>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] 
>On Behalf Of ext Eran Hammer-Lahav
>Sent: 10 March, 2009 07:34
>To: oauth@ietf.org
>Subject: Re: [oauth] FW: I-D Action:draft-hammer-oauth-01.txt
>Forgot to mention the blog post is:
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] 
>On Behalf 
>> Of Eran Hammer-Lahav
>> Sent: Monday, March 09, 2009 10:20 PM
>> To: oauth@ietf.org
>> Subject: [oauth] FW: I-D Action:draft-hammer-oauth-01.txt
>> I spent the last 3 days writing the entire spec from scratch (except 
>> for the security consideration section which was just 
>adjusted to the 
>> new terminology). The new revision is based on feedback I collected 
>> over the past year for the original specification. The main 
>> differences
>> are:
>> * Terminology. Gone are the confusing terms (consumer, 
>request token, 
>> consumer key, etc.). Instead I am using terms from the HTTP spec, 
>> slightly adjusted.
>> * Structure. The previous revision mixed authentication with 
>> authorization and had very little reason to the way 
>normative text was 
>> placed across sections. The new structure splits the spec in 
>two. The 
>> first part talks about how to make authenticated requests using two 
>> sets of credentials. The second part offers a method (one of 
>many) for 
>> getting a token via redirection.
>> * Encoding. The biggest issue with the previous revision was 
>> over parameter encoding and the signature base string. I cleaned up 
>> that section, added new examples, and removed a couple 
>instruction to 
>> encode the signature (bugs). If followed to the letter, the 
>spec would 
>> break all existing implementations... The good thing is it is 
>> confusing enough that most people understood it the wrong way (which 
>> is actually the right way). Take a look at the old section 
>> ---
>> oauth_signature is set to the concatenated encoded values of the 
>> Consumer Secret and Token Secret, separated by a '&' 
>character (ASCII 
>> code 38), even if either secret is empty. The result MUST be encoded 
>> again.
>> ---
>> 'The result MUST be encoded again' is just plain wrong. It 
>is encoded 
>> again but according to the parameter transmission method, not the 
>> special way OAuth does it, and the spec as written would actually 
>> double encode it.
>> * Normative requirements. The spec previously contained many 
>MUSTs and 
>> SHOULDs about stuff that could not be verified like 
>documentation and 
>> obtaining client credentials. I took out all the ones that didn't 
>> actually made any practical difference.
>> I'm sure there is more, since this is practically a brand new spec 
>> (same exact protocol). Please read and provide feedback.
>> EHL
>> -----Original Message-----
>> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- 
>> bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org
>> Sent: Monday, March 09, 2009 4:45 PM
>> To: i-d-announce@ietf.org
>> Subject: I-D Action:draft-hammer-oauth-01.txt
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> 	Title           : The OAuth Core Protocol
>> 	Author(s)       : E. Hammer-Lahav, B. Cook
>> 	Filename        : draft-hammer-oauth-01.txt
>> 	Pages           : 33
>> 	Date            : 2009-03-09
>> This document specifies the OAuth core protocol.  OAuth provides a 
>> method for clients to access server resources on behalf of another 
>> party (such a different client or an end user).  It also provides a 
>> redirection-based user agent process for end users to 
>authorize access 
>> to clients by substituting their credentials (typically, a username 
>> and password pair) with a different set of delegation- specific 
>> credentials.
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.txt
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> Below is the data which will enable a MIME compliant mail reader 
>> implementation to automatically retrieve the ASCII version of the 
>> Internet-Draft.
>oauth mailing list