From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Skylar Woodward <skylar@kiva.org>
Date: Tue, 2 Aug 2011 18:02:39 -0700
Thread-Topic: [OAUTH-WG] MAC Tokens body hash
Thread-Index: AcxRaDGRJCRCrcPBR6el4syfcaLtsAAD8EtA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
 <B68A58A7-EE11-4CC9-971F-6A58FB88DFBA@kiva.org>
In-Reply-To: <B68A58A7-EE11-4CC9-971F-6A58FB88DFBA@kiva.org>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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
Precedence: list

The idea is to drop 'ext' and 'bodyhash' due to being underspecified and th=
erefore causing more harm than good. I added 'ext' to allow for application=
 specific data to be included in the signed content. However, the name sugg=
ests this is an extension point for future specifications. I believe authen=
tication schemes should not be extensible in ways that affect their securit=
y 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 wi=
ll do the same, but will be better positioned as an application-specific da=
ta. 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 par=
ameter does not become part of the payload which is inappropriate for HTTP =
requests.

As for the 'bodyhash' parameter, I would like to remove it because it is un=
derspecified (we had an actual deployment experience showing that it doesn'=
t produce interoperable implementations due to the many HTTP body transform=
ation applied in most frameworks). Solving this issue is not possible due t=
o 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.

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. Cons=
idering 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
>=20
> hurrah!
> (not necessarily for losing a way to sign the body, but for simplicity an=
d
> avoiding some of the potential inconsistencies w/ bodyhash).
>=20
> 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?
>=20
> skylar
>=20
> On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote:
>=20
> > I plan to drop support for the bodyhash parameter in the next draft bas=
ed
> 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 s=
tring
> sent on the wire.
> >
> > To fix that, we need to force UTF-8 encoding on both sides. However, th=
at
> 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 param=
eter
> 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 wi=
ll
> introduce unacceptable complexity that will basically make this work usel=
ess.
> >
> > EHL
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth