OAuth Extensions Google Group

OAuth-Extensions Group Closed

2009-04-06T16:08:36Z

In order to avoid the fragmentation of the community working on OAuth
extensions, we are closing this list and leaving it as an archive
(read-only). Please post all messages to the main OAuth list:

[link]

EHL

Re: [oauth-extensions] Re: last call for comments on body signing

2009-04-04T23:51:38Z

Yes, I see what you're saying, but until you have read the body, you
don't know the length of the data you are reading.
You read the value of the Content-length header before you start
reading the body data.
And you could verify that it was correctly signed before you are
forced to create buffers to read the body. And if the signature isn't

Re: last call for comments on body signing

2009-04-04T17:20:23Z

Sure, but if you're already hashing the content, you won't be able to
truly modify the effective content length without changing the body
signature, so in other words the content-length is already being
verified by virtue of the hashing of the body.

That's not the case for content-type, which, if you try to "sniff"

Oauth header integrity

2009-04-03T22:59:30Z

My first cut at an outline draft - attached to my blog
[link] Naturally
leveraged Brian's body hash spec figuratively and literally.
There is lot of work to be done from formatting to processing model to
examples and running code. Also need to find a way to get a

RE: [oauth-extensions] Re: last call for comments on body signing

2009-04-03T18:20:22Z

I am working on a preliminary first cut at a header hash draft, based on the discussions. Will send out a draft by tonight.

Cheers
<k/>

Re: [oauth-extensions] Re: last call for comments on body signing

2009-04-03T17:36:04Z

Ben (and now cc'ing the main list since I hear 'extensions' is going
away),
Isn't that 'hint' often used to determine the size of a buffer used to
hold the content following the headers, or to constrain the number of
bytes read by the recipient?
Are you suggesting that the signing of these headers be included in

Re: last call for comments on body signing

2009-04-03T17:27:55Z

Agreed that it does make it more difficult, but still it seems there's
a pretty big hole.

Of course, but if you're trying to build a REST-compliant service,
then that's an ugly hack.

I'm certainly not suggesting signing all headers, as that would indeed
be complicated. I'm only suggesting signing content-type and (as JK

Re: [oauth-extensions] Re: last call for comments on body signing

2009-04-03T16:33:10Z

FYI, grand XML Master James Clark proposed secure HTTP Responses a
while ago. There's some blog posts before and after this one too.

[link]

Cheers,
Dave

On Fri, Apr 3, 2009 at 9:24 AM, Krishna Sankar (ksankar)

RE: [oauth-extensions] Re: last call for comments on body signing

2009-04-03T16:24:21Z

Yep, content-length is hint at most. But might as well include it as it has some value.

Cheers
<k/>

Re: [oauth-extensions] Re: last call for comments on body signing

2009-04-03T16:19:58Z

The addition of the body hash doesn't completely prevent that from
happening, but it sure makes it more difficult. Instead of the
attacker being able to do arbitrary manipulation of content-type and
body, they are restricted to tampering with the content-type. Also
note that if you are building a file upload API that you think might

Re: last call for comments on body signing

2009-04-03T16:02:11Z

I can see the argument for content-encoding, so I would support that
one as it could lead to misinterpretation of the body. I think content-
length wouldn't make a difference, since it's just a hint regarding
what comes next, right?

is already very useful. I'd love to be simply compliant with it,

Re: [oauth-extensions] Re: last call for comments on body signing

2009-04-03T12:02:13Z

Hello Ben,

I tend to agree.

How about Content-Encoding and Content-Length then?

[...]

What spec.? ;)

- johnk

Re: last call for comments on body signing

2009-04-03T11:45:47Z

Hi Brian,

My general attitude is not to design based only on known attacks,
since that only helps you fight the last war. Designing defensively
for security seems like the more prudent things to do, although of
course one has to stop somewhere. That's why I'm not advocating
signing every header. But if you're going to sign the body, signing a

RE: [oauth-extensions] ProtectServe: centralized and formalized authorization for distributed SPs

2009-04-03T00:14:07Z

Eve,
Looks interesting from a quick glance. Need to dig deeper into
the exchanges to compare with Oauth et al.

BTW, I think this is very relevant and should be posted to the
main oauth list. Moreover, just saw an e-mail from EHL that this mailer
would be RO from next week.
Cheers
<k/>

Proposal: Close the OAuth-Extensions list

2009-04-03T00:15:17Z

Over the past year activity on the extensions list slowed down. I no longer
think there is much value in maintaining two separate lists when the
audience is pretty much the same.
Unless anyone objects, I will turn the extension list to read-only on
Monday. The list will remain open for archive purposes.