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

Brian Eaton <beaton@google.com> Thu, 12 November 2009 01:53 UTC

Return-Path: <beaton@google.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 E07ED3A694E for <oauth@core3.amsl.com>; Wed, 11 Nov 2009 17:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 4Y6fvgb7ZjL7 for <oauth@core3.amsl.com>; Wed, 11 Nov 2009 17:53:36 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 8EC663A67F2 for <oauth@ietf.org>; Wed, 11 Nov 2009 17:53:35 -0800 (PST)
Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id nAC1s3tl012899 for <oauth@ietf.org>; Wed, 11 Nov 2009 17:54:03 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257990844; bh=LRpMBCw6iQ/WTmvEaibK3crL7Pk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=TR6x9nDLE7LunDVuKiyRio0aESqJADmXKDiNYH4w5QgoqHoDfNw7U5ct9wFj2GcCi Y3/KGUUejReCIkEJuvrxg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=H6nEVIi/6AYe+KwxdArLEgLcy5abRg2q52lzBzyd58U2LCCCnP1I14/18GPp8Grf3 5T6t9lfQdwE9dQS7dxBFw==
Received: from pwi15 (pwi15.prod.google.com [10.241.219.15]) by zps78.corp.google.com with ESMTP id nAC1s1xL001472 for <oauth@ietf.org>; Wed, 11 Nov 2009 17:54:01 -0800
Received: by pwi15 with SMTP id 15so1081533pwi.24 for <oauth@ietf.org>; Wed, 11 Nov 2009 17:54:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.143.2 with SMTP id q2mr142595rvd.0.1257990841207; Wed, 11 Nov 2009 17:54:01 -0800 (PST)
In-Reply-To: <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de>
References: <daf5b9570911082102u215dcf22gf0aeb2f3578e5ea0@mail.gmail.com> <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <daf5b9570911092158k682aff63l959c423c399b2277@mail.gmail.com> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de>
Date: Wed, 11 Nov 2009 17:54:01 -0800
Message-ID: <daf5b9570911111754u49f72a0aia59814b5da497a51@mail.gmail.com>
From: Brian Eaton <beaton@google.com>
To: BeckW@telekom.de
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
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: Thu, 12 Nov 2009 01:53:37 -0000

So we've got at least five different use cases for signing requests
with the oauth access token and token secret.

Sweet.

The downside to the use cases is that they all have incompatible
signature base strings.  I'd like to see us come up with something so
that we don't have to reinvent the base string again for every single
use case.

Cheers,
Brian

On Wed, Nov 11, 2009 at 5:49 PM,  <BeckW@telekom.de> wrote:
>
> On Mon, Nov 9, 2009 at 6:28 AM, John Kemp <john@jkemp.net> wrote:
>> If we are only interested in i) [authenticating the entity] then
> signing any piece of the message might
>> be sufficient. If we are interested in ii) [binding the signature to
> the message] (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.
>
>> Brian Eaton wrote:
>> OK, let me try to summarize what I've heard on this thread about the
>> different use-cases for message signing:
>>
>> - sign the HTTP request
>>   Used to prevent MITM from replaying token to a different URL.  Also
>> limits the replay attack window to minutes instead of hours.
>>
>> - sign various other parts of the message
>>   DKIM: signs various message headers
>>   SIP: unspecified, just says "relevant parts of SIP request"
> Hannes Tschofenig suggested handle SIP messages the way described in RfC
> 4474 (SIP identity). It lists the parts of a SIP messsage that need to
> be protected.
>
> Wolfgang
>