Re: [OAUTH-WG] Basic signature support in the core specification

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 27 September 2010 18:25 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 844253A6B85 for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 11:25:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level:
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
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 Ih28j1lSPr3y for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 11:25:07 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by core3.amsl.com (Postfix) with ESMTP id 82DA13A6C09 for <oauth@ietf.org>; Mon, 27 Sep 2010 11:25:06 -0700 (PDT)
Received: from p4ffd2875.dip.t-dialin.net ([79.253.40.117] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1P0IOR-0002DZ-Ka; Mon, 27 Sep 2010 20:25:39 +0200
Message-ID: <4CA0E1A2.60606@lodderstedt.net>
Date: Mon, 27 Sep 2010 20:25:38 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: Anthony Nadalin <tonynad@microsoft.com>
References: <C8C2AB33.3AD38%eran@hueniverse.com> <BFD0447E-42BB-441F-A7B3-B0CFB0F6317B@gmail.com> <E0B0A685-4BA7-451B-B0DF-C0FC429595D1@xmlgrrl.com> <4CA0C96E.8090907@alcatel-lucent.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70CB6FF@TK5EX14MBXC101.redmond.corp.microsoft.com>
In-Reply-To: <1990A18DEA6E97429CFD1B4D2C5DA7E70CB6FF@TK5EX14MBXC101.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: 141509
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Basic signature support in the core specification
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: Mon, 27 Sep 2010 18:25:08 -0000

  Am 27.09.2010 19:11, schrieb Anthony Nadalin:
> What is needed is needed is the security considerations section complete, I don't think that the signature specification has to be in the core to be complete, there are previsions to use SSL, if one needs to go beyond this then a reference to the signature specification would be in the security considerations section. The separation allows for an OAuth independent solution that would/could cover message and token encryption and signing. If signature is going to be an extension point

I don't understand why signing tokens and signing message shall be 
solved with the same solution.

In my opinion, tokens are opaque to any client and are just passed 
through as an uninterpreted string from authorization server (AS) to the 
resource server (RS) via the client. So the OAuth spec does not 
necessarily have to standardize their format (incl. signatures) in order 
to facilitate protocol interoperability. AS and RS just have to use the 
same format. Since both have a thight relationship that should not be a 
problem. If one like it can use an existing formats like SAML assertions 
or SWT.

That's completely different from message signing. Here all parties are 
involved. So any client accessing a pair of AS and RS has to know how to 
sign a message in order to prove legitimate token ownership and/or 
protect the message from modifications.

regards,
Torsten.

> why have any in the core? Already we would have questions from our customers on the use of HMAC-SHA1. According to Hannes the security considerations section is underway and will explain what signatures provide and what they do not provide and let the implementer choose what scenarios they are implementing for and the risk factors of those scenarios and if signatures are needed or just SSL.
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Faynberg
> Sent: Monday, September 27, 2010 9:42 AM
> To: Eve Maler
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Basic signature support in the core specification
>
> I think Torsten's previous comment explains it well: We cannot expect approval of the core, if security is not sufficiently addressed. I also agree that it cannot be addressed without the signature mechanism clearly specified. Therefore, if anything is going to delay the core, it is the absence of the signature specification. A dangling reference to work in progress won't help; the referred spec must be there.
>
> But if both the OAuth signatures and the OAuth core specifications are complete and going for approval at the same time, why not actually have them in the same spec, especially given that we experts who have agreed working on this and ARE working on this?
>
>
> Igor
>
>
>
> Eve Maler wrote:
>> It seems like you figured it out pretty quickly, given the message you
>> sent immediately after. :-)
>>
>> Referencing another spec from the core spec using normative text is
>> effectively "including it by reference". I meant that I'm sympathetic
>> (+1) to signaling in core OAuth that signatures are to be considered
>> an integral part of it, and that if it makes sense to do so by
>> pointing to a spec module that is pointable-to by other specs that are
>> not OAuth, that's fine (call it a soft -1 to including the signature
>> details directly in the core OAuth spec).
>>
>> Eve
>>
>> On 24 Sep 2010, at 10:39 PM, Dick Hardt wrote:
>>
>>> wrt. developers knowing what they need =>  I think the AS / PR will
>>> tell developers if they need to use signatures, or if they need to
>>> use HTTPS, or if they need to use assertions.
>>>
>>> Sorry for including more than one topic in my email :: my main point
>>> was that I was confused by what Eve was proposing.
>>>
>>> -- Dick
>>>
>>>
>>> On 2010-09-24, at 7:23 PM, Eran Hammer-Lahav wrote:
>>>
>>>> Most developers don't know if they need signatures! By putting them
>>>> elsewhere we will be promoting the bearer token approve as the
>>>> default choice and that's unacceptable to me. It is promoting a
>>>> specific security compromise (for developer ease) that is far from
>>>> industry consensus.
>>>>
>>>> I can make the same arguments about assertions. Or any single
>>>> profile. Or any client credentials type. The bits that are in are
>>>> based solely on a team effort in trying to accommodate as many
>>>> people as possible. Seems like those opposed signatures got
>>>> everything they want, don't really care about others, and are ready
>>>> to call it a day.
>>>>
>>>> EHL
>>>>
>>>>
>>>> On 9/24/10 5:20 PM, "Dick Hardt"<dick.hardt@gmail.com
>>>> <x-msg://12/dick.hardt@gmail.com>>  wrote:
>>>>
>>>>      That's a confusing answer Eve. Is it in the spec or pointed to
>>>>      from the spec?
>>>>
>>>>      I think there is consensus that there are enough use cases that
>>>>      signatures need to be spec'ed -- the question is if the
>>>>      signature spec is in core or a separate spec.
>>>>
>>>>      For people that don't need signatures, having them separate
>>>>      keeps the core spec simpler. Having a separate spec enables
>>>>      other groups to reuse the signature mechanism without confusing
>>>>      their readers with the rest of the OAuth spec.
>>>>
>>>>      On 2010-09-24, at 1:37 PM, Eve Maler wrote:
>>>>
>>>>      >  +1 for signature support in the core spec (which may look like
>>>>      normative pointers out to a separate spec module if it turns out
>>>>      there's wider usage for that module beyond OAuth).
>>>>      >
>>>>      >        Eve
>>>>      >
>>>>      >  On 23 Sep 2010, at 6:43 PM, Eran Hammer-Lahav wrote:
>>>>      >
>>>>      >>  Since much of this recent debate was done off list, I'd like
>>>>      to ask people
>>>>      >>  to simply express their support or objection to including a
>>>>      basic signature
>>>>      >>  feature in the core spec, in line with the 1.0a signature
>>>>      approach.
>>>>      >>
>>>>      >>  This is not a vote, just taking the temperature of the group.
>>>>      >>
>>>>      >>  EHL
>>>>      >>
>>>>      >>  _______________________________________________
>>>>      >>  OAuth mailing list
>>>>      >>  OAuth@ietf.org<x-msg://12/OAuth@ietf.org>
>>>>      >>  https://www.ietf.org/mailman/listinfo/oauth
>>>>      >
>>>>      >
>>>>      >  Eve Maler
>>>>                                       http://www.xmlgrrl.com/blog
>>>>      >  +1 425 345 6756
>>>>                              http://www.twitter.com/xmlgrrl
>>>>      >
>>>>      >  _______________________________________________
>>>>      >  OAuth mailing list
>>>>      >  OAuth@ietf.org<x-msg://12/OAuth@ietf.org>
>>>>      >  https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>
>> Eve Maler                                  http://www.xmlgrrl.com/blog
>> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>>
>> ----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> 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