Re: [OAUTH-WG] signatures, v2

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 22 July 2010 22:01 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 AA5943A6A0B for <oauth@core3.amsl.com>; Thu, 22 Jul 2010 15:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.091
X-Spam-Level:
X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
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 KGswQfczJv-9 for <oauth@core3.amsl.com>; Thu, 22 Jul 2010 15:01:48 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by core3.amsl.com (Postfix) with ESMTP id F40F63A680C for <oauth@ietf.org>; Thu, 22 Jul 2010 15:01:47 -0700 (PDT)
Received: from p4ffd12ee.dip.t-dialin.net ([79.253.18.238] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1Oc3q7-00007p-SU; Fri, 23 Jul 2010 00:02:04 +0200
Message-ID: <4C48BFD2.9060406@lodderstedt.net>
Date: Fri, 23 Jul 2010 00:01:54 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: Dirk Balfanz <balfanz@google.com>
References: <AANLkTim7pvrLnQtz4WnDvYVRv0jbWgk3j8uMJj07CsM1@mail.gmail.com> <4C431BA3.2000907@lodderstedt.net> <AANLkTilBFabSRsxshSuBbzbYqwv7MzPbMq-fUBShjX9L@mail.gmail.com>
In-Reply-To: <AANLkTilBFabSRsxshSuBbzbYqwv7MzPbMq-fUBShjX9L@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------080300090502000107070000"
X-Df-Sender: 141509
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] signatures, v2
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: Thu, 22 Jul 2010 22:01:49 -0000

> On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt 
> <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> wrote:
>
>     Hi Dirk,
>
>     I have some questions concerning your proposal:
>
>     - As far as I understand, the difference to "magic signatures"
>     lays in the usage of a JSON token carrying issuer, not_before,
>     not_after and audience. While such properties are important for
>     security tokens (assertions), I cannot see an advantage of using
>     this format for signatures of HTTP requests. Would you please explain?
>
>
> You mean advantage over magic signatures? It's really a similar idea - 
> it's just that magic signatures as is don't quite fit the bill. For 
> example, they have newlines in them: 
> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html#anchor5

I mean, what is the reason for including issuer, not_before, not_after 
and audience into a signature?

>     - Key management
>     From my point of view, your proposal does cover key management for
>     web applications using RSA signatures. What about web applications
>     intending to sign resource server requests using HMAC (for
>     performance reasons)? Do they need to exchange secrets with the
>     resource server?
>
>
> Correct - I'm not saying how HMAC keys are being distributed. 
> Presumably, you would use a similar system to what many platform 
> providers use today - you sign up as a developer, and they give you a 
> "developer key" (or "API key").

Such a system will work for a relatively static relation between client 
and server only. Do you suggest a client should register with every 
resource server in advance?

What about dynamic clients? Suppose a client is just configured with a 
URL pointing to a PortableContacts resource. The client discovers the 
respective authz server and obtains a token. What if the client wants to 
sign the messages to the resource server?


>     What about installed applications (mobile, desktop, set top boxes,
>     gaming devices)?
>
>
> I don't think that installed apps can ever authenticate themselves 
> (i.e., prove the statement "I am a copy of the FooBar app"), so I'm 
> not trying to solve that. What we _can_ do is deliver OAuth tokens to 
> an installed app of the user's choice, but the server won't know who 
> received the token - only the user does.

I think we can do more. Even installed applications can use signatures 
to protect messages on transport. What about that use case? Clearly they 
need appropriate key material. The token secret  issued by the 
authorization server could server that purpose.

>      1) RSA: Do they need to provide their public key on a web server?
>     This would be an additional requirement for such applications.
>      2) HMAC: Same as for web apps, but even harder because either (a)
>     the installed app has a static secret burned
>     into source code or (b) it needs to use a protocol for dynamic key
>     management the resource server has to implement. Is this the plan?
>

regards,
Torsten.