Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

Skylar Woodward <skylar@kiva.org> Mon, 07 February 2011 17:24 UTC

Return-Path: <skylar@kiva.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 E728D3A6E3A for <oauth@core3.amsl.com>; Mon, 7 Feb 2011 09:24:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
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 ExGtZB-+24rc for <oauth@core3.amsl.com>; Mon, 7 Feb 2011 09:24:45 -0800 (PST)
Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by core3.amsl.com (Postfix) with SMTP id 9652C3A6E2F for <oauth@ietf.org>; Mon, 7 Feb 2011 09:24:44 -0800 (PST)
Received: from source ([209.85.215.175]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKTVAq4G8U5vaBs+jkd9wFRL5TcqJGR9QO@postini.com; Mon, 07 Feb 2011 09:24:49 PST
Received: by eya28 with SMTP id 28so2305978eya.34 for <oauth@ietf.org>; Mon, 07 Feb 2011 09:24:47 -0800 (PST)
Received: by 10.204.56.14 with SMTP id w14mr15976780bkg.27.1297099484614; Mon, 07 Feb 2011 09:24:44 -0800 (PST)
Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id a17sm2183660bku.23.2011.02.07.09.24.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 09:24:43 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1082)
From: Skylar Woodward <skylar@kiva.org>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Mon, 07 Feb 2011 18:24:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@kiva.org>
References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav <eran@hueniverse.com>, OAuth WG <oauth@ietf.org>
X-Mailer: Apple Mail (2.1082)
Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02
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, 07 Feb 2011 17:24:46 -0000

On body-hash...

Having completed a trial implementation, it seems redundant, and potentially problematic, to include the body-hash in the Authentication header. The danger is that implementors may neglect to recalculate the hash themselves, reusing the value (even if incorrect) provided by the client. Why not just require the provider to calculate this and validate it by comparing the final signature? This way it's clearer for everyone what the expectations are in validating the signature.

I propose either a flag (eg, usebodyhash="1") or an algorithm (bodyhashalgorithm="sha1"). If this parameter was provided, the correct hash would be added to the base string for signing. If omitted (or set false?) then an empty string is used for base string element #4.


On including parameters for signing...

I'd retract my suggestion that we'd include parameter-hash in the header. Instead, I would suggest making parameters optional in calculating the signature using a flag as with bodyhash. Providers could require including parameters if so desired. Parameters could be included as currently defined, or with a hash method similar to entity-body (which I find both simpler and more congruent). 

Again, the goal in making query parameters optional is to allow providers to make signature calculation as simple as possible for clients (so much as it is in line with the security requirements of the provider) and avoid complexities in implementation such as those that tripped up OAuth 1.



On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote:

> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02
>  
> New version includes the following changes:
>  
>    o  Added body-hash support.
>    o  Updated OAuth 2.0 reference to -12 and added token type registration template.
>    o  Removed error and error URI attributes (codes were just a duplication of the HTTP status codes).
>  
> Feedback would be greatly appreciated.
>  
> EHL
>  
>  
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth