I would imagine that things like Content-Length: , Content-Encoding: and Cache-Control: would be targets for attacks if they were not protected. There are also a lot of custom X- headers out there with unknown semantics.
BTW, another advantage of TLS is that it handles integrity of the HTTP response as well. I don't think the signing proposals include the response, do they? On Tue, Mar 16, 2010 at 11:50 AM, Zeltsan, Zachary (Zachary) < zachary.zelt...@alcatel-lucent.com> wrote: > > >Would you care if some proxy or other intermediary changed the contents of > >the Authorization HTTP header? > > In OAuth 1.0 the oauth_ parameters can be transmitted in the HTTP > Authorization header - this is one of the options (and is the preferred > one). In that case protection of the Authorization header's content is > needed, but it is already provided by the signature. The parameter > oauth_signature contains a signature over a string that includes the OAuth > protocol parameters (excluding "oauth_signature"). > > >How about if they changed the URL path passed or the HTTP method from GET > >to POST? > > GET and POST (they are not parts of the HTTP headers) are also included in > the signature base string in OAuth 1.0 > > I believe that when OAuth parameters are transmitted in the Authorization > header, OAuth 1.0 provides an adequate protection of that header's contents. > > Zachary > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > John Kemp > Sent: Tuesday, March 16, 2010 9:45 AM > To: Faynberg, Igor (Igor) > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Signatures, Why? > > On Mar 16, 2010, at 8:48 AM, Igor Faynberg wrote: > > > That's what I have been thinking. Why is it important to sign the > headers? (I am not against signing them, but I cannot see the need in the > specific cases we had discussed. In other words, if I had signed the body of > the request, I probably would not care if someone changed the headers.) > > Would you care if some proxy or other intermediary changed the contents of > the Authorization HTTP header? How about if they changed the URL path passed > or the HTTP method from GET to POST? Which other HTTP headers might you wish > to be carried through intermediaries with the property of integrity? > > Regards, > > - johnk > > > > > Igor > > > > Paul Lindner wrote: > >> What about > http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html? > >> > >> That's in use and has been implemented in shindig for quite some time. > >> > >> That draft adds protection of the body -- I don't know of any draft that > covers signing the headers... > >> > >> > >> On Mon, Mar 15, 2010 at 11:22 PM, John Panzer <jpan...@google.com<mailto: > jpan...@google.com>> wrote: > >> > >> I'm confused by one "pro" for signatures: > >> > >> "Protect integrity of whole request - authorization data and > >> payload when communicating over unsecure channel" > >> > >> I do not believe there is an existing concrete proposal that will > >> protect the whole request, unless you add additional restrictions > >> on the request types -- e.g., only HTTP GET or POST with > >> form-encoded data variables only. > >> > >> If the assertion is that signatures will actually provide > >> integrity for arbitrary HTTP request bodies as well as the URL, > >> authority, and HTTP method: I would like to see at least one > >> concrete proposal that will accomplish this. IIRC there's only > >> one that I think is possibly implementable in an interoperable > >> way, and it supports only JSON payloads. In other words, anyone > >> using body signing would need to wrap their data in JSON to do it. > >> (This is not necessarily the worst thing in the world, of course, > >> but it is something to be taken into account when listing pros and > >> cons.) > >> > >> On Mon, Mar 15, 2010 at 3:50 PM, Torsten Lodderstedt > >> <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote: > >> > >> Hi all, > >> > >> I composed a detailed summary at > >> http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy. > >> Please review it. > >> > >> @Zachary: I also added some of your recent notes. > >> > >> regards, > >> Torsten. > >> > >>> I volunteer to write it up. > >>>> <hat type='chair'/> > >>>> > >>>> On 3/4/10 1:00 PM, Blaine Cook wrote: > >>>> > >>>>> One of the things that's been a primary focus of both today's WG > call > >>>>> and last week's call is what are the specific use cases for > >>>>> signatures? > >>>>> > >>>>> - Why are signatures needed? > >>>>> - What do signatures need to protect? > >>>>> > >>>>> Let's try to outline the use cases! Please reply here, so that > we have > >>>>> a good idea of what they are as we move towards the Anaheim WG. > >>>>> > >>>> This was a valuable thread. Perhaps someone could write up a > summary of > >>>> the points raised, either on the list or at the wiki? > >>>> > >>>> Peter > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>> > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org <mailto:OAuth@ietf.org> > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org <mailto:OAuth@ietf.org> > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org <mailto: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 > > _______________________________________________ > 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
