Subject: [OAUTH-WG] MAC: body-hash

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 19 Nov 2011 08:39:05 -0700

I want to reaffirm our previous consensus to drop the body-hash parameter and leave the ext parameter. Body-hash as currently specified is going to cause significant interop issues due to character (and other) encoding issues. Providers who desire to MAC the body can define their own ext use case.

Let me know if you have an objection to this change.

EHL

---

From: William Mills <[email-masked]>
Date: Sat, 19 Nov 2011 07:46:26 -0800 (PST)

I haven't read the MAC spec recently enough, did you already deal with the character set issue (if there was one) comparable to the ones in the Bearer spec?

I am +1 on the -body_hash +ext change.

________________________________
 From: Eran Hammer-Lahav <[email-masked]>
To: OAuth WG <[email-masked]> 
Sent: Saturday, November 19, 2011 7:39 AM
Subject: [OAUTH-WG] MAC: body-hash

 
EHL
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Sat, 19 Nov 2011 08:28:41 -0800

Sounds good.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 19 Nov 2011 09:39:11 -0700

The charset is restricted so no issues.

From: William Mills [mailto:[email-masked]]
Sent: Saturday, November 19, 2011 7:46 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] MAC: body-hash

________________________________
From: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
To: OAuth WG <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, November 19, 2011 7:39 AM
Subject: [OAUTH-WG] MAC: body-hash
I want to reaffirm our previous consensus to drop the body-hash parameter and leave the ext parameter. Body-hash as currently specified is going to cause significant interop issues due to character (and other) encoding issues. Providers who desire to MAC the body can define their own ext use case.

EHL

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Peter Wolanin <[email-masked]>
Date: Wed, 23 Nov 2011 14:53:24 -0500

As long as a specific service can make an ext containing the body hash
required, I think this is fine.  Can the spec include body hash as an
example of an ext?

Thanks,

Peter

On Sat, Nov 19, 2011 at 10:39 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> I want to reaffirm our previous consensus to drop the body-hash parameter
> and leave the ext parameter. Body-hash as currently specified is going to
> cause significant interop issues due to character (and other) encoding
> issues. Providers who desire to MAC the body can define their own ext use
> case.
>
>
>

-- 
Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. Inc.
[email-masked] : 781-313-8322

"Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"

---

From: Peter Wolanin <[email-masked]>
Date: Thu, 24 Nov 2011 08:02:36 -0500

I'd lobby for something more than just prose, since for me, including
the body or body hash in the HMAC is a pretty essential piece of
security for any real implementation.  I understand that you think it
should not be 100% required by all servers, and hence should not be a
specified field, but then I think it should be something like a
"standard" extension.

For example, retain some of the existing text describing the bodyhash
as using the same algorithm as the HMAC and show an example like:

ext="bodyhash:k9kbtCIy0CkI3/FEfpS/oIDjk6k="

Are there any other specific things you see as common examples of ext
values?  Is there a suggested system for indicating or separating
multiple ext values?

It seems to me without a standardized way to include the body hash in
the ext field, you immediately invite more diversity in
implementations.  It would also seem by putting it in the ext field,
any client could include the hash even if the server doesn't require
it?

Best,

Peter

On Thu, Nov 24, 2011 at 12:21 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> In prose, sure. But I'd rather not go further than that.
>
> EHL
>
>> -----Original Message-----
>> From: Peter Wolanin [mailto:[email-masked]]
>> Sent: Wednesday, November 23, 2011 11:53 AM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> required, I think this is fine.  Can the spec include body hash as an example of
>> an ext?
>>
>> Thanks,
>>
>> Peter
>>
>> > I want to reaffirm our previous consensus to drop the body-hash
>> > parameter and leave the ext parameter. Body-hash as currently
>> > specified is going to cause significant interop issues due to
>> > character (and other) encoding issues. Providers who desire to MAC the
>> > body can define their own ext use case.
>> >
>> >
>> >

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Nov 2011 10:17:07 -0700

That like trying to eat the cake and have it too.

We dropped the body-hash parameter because it doesn't work. There are too many complications in getting an interop solution across platforms and body types. There are ASCII, UTF8, binary, etc. bodies and they will all produce different hash value based on at what level the client hashes them. In addition, the HTTP layer can do many things to the data including encoding. On top of that, you have HTTP headers that change the meaning of the payload.

We've tried it and could not come up with any reasonable solution.

As someone who have and wants to implement this, I understand the need for it, but at this point within the limitations of HTTP, this belongs as a vendor specific extension until more real-world experience is gained.

EHL

> Sent: Thursday, November 24, 2011 5:03 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> I'd lobby for something more than just prose, since for me, including the
> body or body hash in the HMAC is a pretty essential piece of security for any
> real implementation.  I understand that you think it should not be 100%
> required by all servers, and hence should not be a specified field, but then I
> think it should be something like a "standard" extension.
> 
> For example, retain some of the existing text describing the bodyhash as
> using the same algorithm as the HMAC and show an example like:
> 
> values?  Is there a suggested system for indicating or separating multiple ext
> values?
> 
> It seems to me without a standardized way to include the body hash in the
> ext field, you immediately invite more diversity in implementations.  It would
> also seem by putting it in the ext field, any client could include the hash even
> if the server doesn't require it?
> 
> Best,
> 
> Peter
> 
> >> As long as a specific service can make an ext containing the body
> >> hash required, I think this is fine.  Can the spec include body hash
> >> as an example of an ext?
> >>
> >> Thanks,
> >>
> >> Peter
> >>
> >> > character (and other) encoding issues. Providers who desire to MAC
> >> > the body can define their own ext use case.
> >> >
> >> >
> >> >