Re: [OAUTH-WG] why are we signing?

John Kemp <john@jkemp.net> Mon, 09 November 2009 14:28 UTC

Return-Path: <john@jkemp.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 82C4D3A693D for <oauth@core3.amsl.com>; Mon, 9 Nov 2009 06:28:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 TaWnxxrfXqvz for <oauth@core3.amsl.com>; Mon, 9 Nov 2009 06:28:02 -0800 (PST)
Received: from outbound-mail-10.bluehost.com (outbound-mail-10.bluehost.com [69.89.17.210]) by core3.amsl.com (Postfix) with SMTP id 9D74F3A685E for <oauth@ietf.org>; Mon, 9 Nov 2009 06:28:02 -0800 (PST)
Received: (qmail 18371 invoked by uid 0); 9 Nov 2009 14:28:28 -0000
Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy1.bluehost.com with SMTP; 9 Nov 2009 14:28:28 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=N7mq7MR57mDloCLXLHHDxmUZhEFQZObckK79GnCR93uIwDVPsINuPIIGtOKY+3wiYNvPOQisvKY9jS9bWCDs164an75+LMYQG5GjCEzeVyqJYJapdAsaPiWUbyVXon7t;
Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.103]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from <john@jkemp.net>) id 1N7VEK-0003Pe-FH; Mon, 09 Nov 2009 07:28:28 -0700
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
From: John Kemp <john@jkemp.net>
In-Reply-To: <daf5b9570911082102u215dcf22gf0aeb2f3578e5ea0@mail.gmail.com>
Date: Mon, 09 Nov 2009 09:28:27 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net>
References: <daf5b9570911082102u215dcf22gf0aeb2f3578e5ea0@mail.gmail.com>
To: Brian Eaton <beaton@google.com>
X-Mailer: Apple Mail (2.1076)
X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net}
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] why are we signing?
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, 09 Nov 2009 14:28:06 -0000

On Nov 9, 2009, at 12:02 AM, Brian Eaton wrote:

[...]

>
> My guess is we need at least two out of those four choices (one with
> bearer tokens, a la OAuth 1.0 plaintext) and another with
> cryptography.  But I'm not sure whether we need to sign entire
> messages, or if we can get away with something simpler and still have
> reasonable security.

I agree that bearer tokens are useful.

As for signatures, the question is really all in the subject line. And  
I guess the answers I would come up with, generally-speaking would be:

i) To authenticate the entity doing the signing, by means of the use  
and verification of that entity's key. Such authentication can be a  
basis for authorizing that entity via the presence of the token in the  
message to do whatever is asked for in the request message.
ii) To bind the token and the rest of the message together to ensure  
that the recipient can detect whether the (important parts of the)  
message was tampered with by a third-party.

If we are only interested in i) then signing any piece of the message  
might be sufficient. If we are interested in ii) (or some other  
security property) then we will need to identify which pieces of the  
message we want to provide that, or other, security properties for.

- johnk