Re: [OAUTH-WG] MAC Tokens body hash

"William J. Mills" <wmills@yahoo-inc.com> Wed, 03 August 2011 17:27 UTC

Return-Path: <wmills@yahoo-inc.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C383621F84EC for <oauth@ietfa.amsl.com>; Wed, 3 Aug 2011 10:27:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.581
X-Spam-Level:
X-Spam-Status: No, score=-16.581 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ARA0tJZ7T5l for <oauth@ietfa.amsl.com>; Wed, 3 Aug 2011 10:27:46 -0700 (PDT)
Received: from nm14-vm0.bullet.mail.ac4.yahoo.com (nm14-vm0.bullet.mail.ac4.yahoo.com [98.139.52.234]) by ietfa.amsl.com (Postfix) with SMTP id 33DDC21F84E9 for <oauth@ietf.org>; Wed, 3 Aug 2011 10:27:45 -0700 (PDT)
Received: from [98.139.52.191] by nm14.bullet.mail.ac4.yahoo.com with NNFMP; 03 Aug 2011 17:27:55 -0000
Received: from [98.139.52.138] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 03 Aug 2011 17:27:55 -0000
Received: from [127.0.0.1] by omp1021.mail.ac4.yahoo.com with NNFMP; 03 Aug 2011 17:27:55 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 403467.27656.bm@omp1021.mail.ac4.yahoo.com
Received: (qmail 31869 invoked by uid 60001); 3 Aug 2011 17:27:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1312392474; bh=MekHWMz9yy3yoS/fs7WK11LHAzPJeECIAW25mI2jnEc=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Q0XHwkd7HzyS8wJyZ67xi3mdMCaGLSqGxeiyk7EK9wxnEhJBFWx925h1b6CrSp97BFL2GOqc4bTHRj3ovj/zeOCC/vfLtNueidWjiy3mFYwld5jAoHTXEIxfgaEdq+0CYzrP2gt3z0gICJQ7AF4h+s3tK+harHqWyxC45YfWroQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NlLpgi/GMjEGvA+Vc/tFak0XNMcCAfBPs4VXSzv2xqb9uX0UmLHL1m73z57GiZpNhU6PQkBd8TM5KcS/hBqC5O4V/cNiuPjuGCbAGmd6PRzeAbtanWRK4IB4YKY5emWcbtyI8Upiwo+fwzN3uS3IzCvtZa/h56md/PBJf+lTX0E=;
X-YMail-OSG: JmHCWeoVM1kSn2bPtnjrc9ShOfWLtHcRWOIUqF034Gj069K WqpyAQB_FbLFMEvRSFcJ0teT2SmoKWAjj1pbTFlbcNiInnfcEs4HHkyW.ywn Axs6iVycVmmCeKOmZHs7wiQjSp7Wtf9UBFCBaMS5C0N6kK8Zo9ZipuRiU0YX mq3yDHouZexTIIU3t60HSEkbidm5QHWRXbXU4exgAab2RzDaDNijTbtRBkLA TtIE3zn5ElTzY0F5gYK0n_Qg9yMRXY8dybLTunC5NVIj_VnZvw7lXMl5ABrj 9WiVINa8FJMiCqwxIuNTJpEXVi_KZICbwZGwb777VTKT3fbkmInk07qlVKDQ KwPKzbvkrYFAcwNkLmyXo5nS7dERqrHlvV0ck4lVR_2UEoF1HNyxIonIQn68 4
Received: from [209.131.62.115] by web31801.mail.mud.yahoo.com via HTTP; Wed, 03 Aug 2011 10:27:54 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.113.315625
References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <B68A58A7-EE11-4CC9-971F-6A58FB88DFBA@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET> <C78EE39E-A46B-4540-85E0-280B42527A21@oracle.com>
Message-ID: <1312392474.29804.YahooMailNeo@web31801.mail.mud.yahoo.com>
Date: Wed, 03 Aug 2011 10:27:54 -0700
From: "William J. Mills" <wmills@yahoo-inc.com>
To: Phillip Hunt <phil.hunt@oracle.com>, Eran Hammer-Lahav <eran@hueniverse.com>
In-Reply-To: <C78EE39E-A46B-4540-85E0-280B42527A21@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-660586481-1312392474=:29804"
Cc: Ben Adida <ben@adida.net>, OAuth WG <oauth@ietf.org>, "Adam Barth(adam@adambarth.com)" <adam@adambarth.com>
Subject: Re: [OAUTH-WG] MAC Tokens body hash
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "William J. Mills" <wmills@yahoo-inc.com>
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 03 Aug 2011 17:27:47 -0000

In thinking about this I'm coming around to the viewpoint that a single additional predefined spot is sufficient.  If the app developer wants to include addtional data there (iun the specified format) that's fine.  If what they want to do is include a signature of other payload that's fine too.

I'm not in love with the name "app" though, "ext" is better.



________________________________
From: Phillip Hunt <phil.hunt@oracle.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Cc: Ben Adida <ben@adida.net>; OAuth WG <oauth@ietf.org>; "Adam Barth(adam@adambarth.com)" <adam@adambarth.com>
Sent: Tuesday, August 2, 2011 7:14 PM
Subject: Re: [OAUTH-WG] MAC Tokens body hash




Phil

On 2011-08-02, at 18:02, Eran Hammer-Lahav <eran@hueniverse.com> wrote:


The idea is to drop 'ext' and 'bodyhash' due to being underspecified and therefore causing more harm than good. I added 'ext' to allow for application specific data to be included in the signed content. However, the name suggests this is an extension point for future specifications. I believe authentication schemes should not be extensible in ways that affect their security or interop properties and without additional text (registry, process, etc) for the 'ext' parameter, it will cause more issues than help.
>
>Instead of the 'ext' parameter I am suggesting the 'app' parameter which will do the same, but will be better positioned as an application-specific data. The prose will go a step further and recommend that the parameter value include a hash of the data, not the data itself. This is to ensure the parameter does not become part of the payload which is inappropriate for HTTP requests.
>-1 what you describe appears to be a separate feature from ext


>As for the 'bodyhash' parameter, I would like to remove it because it is underspecified (we had an actual deployment experience showing that it doesn't produce interoperable implementations due to the many HTTP body transformation applied in most frameworks). Solving this issue is not possible due to the many different types of bodies and frameworks (and clearly operating on the "raw" body doesn't work). Instead, developers can use the new 'app' parameter to accomplish that.
>
+1



>As for the normalized string, it will be adjusted to reflect these changes when they are made, so no placeholders which will require code change. Considering this is -00, it is clearly not a stable document.
>
>
Will these changes work with your use cases?
>
>EHL
>
>
>-----Original Message-----
>>
>From: Skylar Woodward [mailto:skylar@kiva.org]
>>
>Sent: Tuesday, August 02, 2011 4:02 PM
>>
>To: Eran Hammer-Lahav
>>
>Cc: OAuth WG; Ben Adida; 'Adam Barth (adam@adambarth.com)'
>>
>Subject: Re: [OAUTH-WG] MAC Tokens body hash
>>
>
>>
>hurrah!
>>
>(not necessarily for losing a way to sign the body, but for simplicity and
>>
>avoiding some of the potential inconsistencies w/ bodyhash).
>>
>
>>
>Is your plan to reserve an empty line 6 for the Normalized Request String
>>
>(which was used for bodyhash) or eliminate it, brining the total to six
>>
>elements?
>>
>
>>
>skylar
>>
>
>>
>On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote:
>>
>
>>
>I plan to drop support for the bodyhash parameter in the next draft based
>>>
>on bad implementation experience. Even with simple text body, UTF
>>
>encoding has introduced significant issues for us. The current draft does not
>>
>work using simple JS code between a browser and node.js even when both
>>
>use the same v8 engine due to differences in the body encoding. Basically,
>>
>the JS string used to send a request from the browser is not the actual string
>>
>sent on the wire.
>>
>
>>>
>To fix that, we need to force UTF-8 encoding on both sides. However, that
>>>
>is very much application specific. This will not work for non-text bodies.
>>
>Instead, the specification should offer a simple way to use the ext parameter
>>
>for such needs, including singing headers. And by offer I mean give
>>
>examples, but leave it application specific for now.
>>
>
>>>
>I am open to suggestions but so far all the solutions I came up with will
>>>
>introduce unacceptable complexity that will basically make this work useless.
>>
>
>>>
>EHL
>>>
>_______________________________________________
>>>
>OAuth mailing list
>>>
>OAuth@ietf.org
>>>
>https://www.ietf.org/mailman/listinfo/oauth
>>>
>_______________________________________________
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth