Re: [OAUTH-WG] Signatures, Why?

Torsten Lodderstedt <torsten@lodderstedt.net> Tue, 16 March 2010 14:02 UTC

Return-Path: <torsten@lodderstedt.net>
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 A59693A67A4 for <oauth@core3.amsl.com>; Tue, 16 Mar 2010 07:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 ZHvVTcpv+eFz for <oauth@core3.amsl.com>; Tue, 16 Mar 2010 07:02:37 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by core3.amsl.com (Postfix) with ESMTP id B63DB3A693F for <oauth@ietf.org>; Tue, 16 Mar 2010 07:02:36 -0700 (PDT)
Received: from [80.187.213.30] (helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1NrXM2-0006ZG-VV; Tue, 16 Mar 2010 15:02:43 +0100
Message-ID: <4B9F8F7D.3050203@lodderstedt.net>
Date: Tue, 16 Mar 2010 15:02:37 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: igor.faynberg@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>
In-Reply-To: <4B9F29BC.3010709@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: 141509
Cc: 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 14:02:41 -0000

I think signing Authorization Headers would make sense.

regards,
Torsten.

Am 16.03.2010 07:48, schrieb Igor Faynberg:
> 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.)
>
> 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