IETF Logo Mail Archive

Re: [OAUTH-WG] Signature crypto

Eran Hammer-Lahav <eran@hueniverse.com> Fri, 04 December 2009 18:21 UTC

Return-Path: <eran@hueniverse.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 4E5EF3A6936 for <oauth@core3.amsl.com>; Fri, 4 Dec 2009 10:21:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.947
X-Spam-Level:
X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, 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 3yYq51oN3uf9 for <oauth@core3.amsl.com>; Fri, 4 Dec 2009 10:21:41 -0800 (PST)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EA6F63A676A for <oauth@ietf.org>; Fri, 4 Dec 2009 10:21:40 -0800 (PST)
Received: (qmail 13270 invoked from network); 4 Dec 2009 18:21:31 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 18:21:30 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 4 Dec 2009 11:21:29 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Breno <breno.demedeiros@gmail.com>
Date: Fri, 04 Dec 2009 11:21:47 -0700
Thread-Topic: [OAUTH-WG] Signature crypto
Thread-Index: Acp1DfoKVFZn651CTY+nRdcS2P72vgAAFpJw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <f98165700912041016k10366b88tb001f7700405083f@mail.gmail.com>
In-Reply-To: <f98165700912041016k10366b88tb001f7700405083f@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343785293683P3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Signature crypto
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: Fri, 04 Dec 2009 18:21:46 -0000

I was not suggesting to explicitly mention them, just allow them.

Currently, I am proposing a HMAC option with the hash algorithm as a parameter. This would mean changing it to a MAC option with the MAC type and hash algorithm as parameters.

It adds a bit more complexity but nothing significant. However, if there are no compelling reasons to do so (no actual use cases or requirements), I am more inclined to stick with HMAC and allow others to extend it by adding a new CMAC (etc.) method.

EHL

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Friday, December 04, 2009 10:17 AM
To: Eran Hammer-Lahav
Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Signature crypto

While there are technical merits, both from security and performance standpoints, to the alternative MAC proposals, there is not extensive library support for those, and AFAIK they have little usage in the Internet. I am not sure if it makes sense for OAuth to be on the leading edge in terms of MAC algorithm adoption.
On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav <eran@hueniverse.com<mailto:eran@hueniverse.com>> wrote:
Is there actual demand to make the HMAC method more generic to allow other kinds of MAC?

EHL

> -----Original Message-----
> From: Manger, James H [mailto:James.H.Manger@team.telstra.com<mailto:James.H.Manger@team.telstra.com>]
> Sent: Thursday, November 26, 2009 7:43 PM
> To: Eran Hammer-Lahav; Stephen Farrell
> Cc: OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)
> Subject: RE: [OAUTH-WG] Signature crypto
>
> >> Sounds reasonable if all you need to negotiate are hash algorithm names.
> >> Is that the case?
>
> > Yes.
>
> Not quite.
> OAuth (at least the authentication part) mainly needs a MAC algorithm, not a
> hash algorithm.
> HMAC is one popular MAC algorithm that is build from a hash algorithm.
> However, there are other MAC algorithms - based on block ciphers for
> instance (eg CMAC-AES).
> The hash registry http://www.iana.org/assignments/hash-function-text-
> names/ is not really going to help.
>
> P.S. The body-signing OAuth extension is the one place that uses a hash (not
> a MAC) directly.
>
> James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



--
Breno de Medeiros

v2.23.0 | Report a Bug | By Email