Re: [OAUTH-WG] Signatures, Why?

"Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> Tue, 16 March 2010 18:50 UTC

Return-Path: <zachary.zeltsan@alcatel-lucent.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F26D3A67EF for <oauth@core3.amsl.com>; Tue, 16 Mar 2010 11:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.141
X-Spam-Level:
X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAAXz7rbS5j5 for <oauth@core3.amsl.com>; Tue, 16 Mar 2010 11:50:20 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id AC9853A67A8 for <oauth@ietf.org>; Tue, 16 Mar 2010 11:50:19 -0700 (PDT)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o2GIoRir005933; Tue, 16 Mar 2010 13:50:27 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o2GIoRNs024694; Tue, 16 Mar 2010 13:50:27 -0500 (CDT)
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 16 Mar 2010 13:50:27 -0500
From: "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com>
To: John Kemp <john@jkemp.net>, "Faynberg, Igor (Igor)" <igor.faynberg@alcatel-lucent.com>
Date: Tue, 16 Mar 2010 13:50:25 -0500
Thread-Topic: [OAUTH-WG] Signatures, Why?
Thread-Index: AcrFEmYkprFk5UEXR0e6k01D4MirugAJbUhg
Message-ID: <5710F82C0E73B04FA559560098BF95B124F0B2C232@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <d37b4b431003041200n1fc6cc5au83194aca28763b0d@mail.gmail.com> <4B99B2DD.3000405@stpeter.im> <4B99D783.1090905@lodderstedt.net> <4B9EB99F.1050609@lodderstedt.net> <cb5f7a381003152322m5c6ec744nb8336e329860439e@mail.gmail.com> <b71cdca91003152330p74409dc5ua34fb4ef06702a15@mail.gmail.com> <4B9F29BC.3010709@alcatel-lucent.com> <C39FEB3C-4975-4DEB-9D42-E0AF3F143FC7@jkemp.net>
In-Reply-To: <C39FEB3C-4975-4DEB-9D42-E0AF3F143FC7@jkemp.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Signatures, Why?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 16 Mar 2010 18:50:22 -0000

>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-bounces@ietf.org [mailto:oauth-bounces@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 <jpanzer@google.com <mailto:jpanzer@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
>>  <torsten@lodderstedt.net <mailto:torsten@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