Re: [OAUTH-WG] Signature crypto

Eran Hammer-Lahav <eran@hueniverse.com> Fri, 04 December 2009 18:28 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 D94CF3A693B for <oauth@core3.amsl.com>; Fri, 4 Dec 2009 10:28:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.982
X-Spam-Level:
X-Spam-Status: No, score=-2.982 tagged_above=-999 required=5 tests=[AWL=-0.384, 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 W7qoEqq0HE7M for <oauth@core3.amsl.com>; Fri, 4 Dec 2009 10:28:24 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id DCC5F3A67AC for <oauth@ietf.org>; Fri, 4 Dec 2009 10:28:23 -0800 (PST)
Received: (qmail 3112 invoked from network); 4 Dec 2009 18:28:15 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 18:28:15 -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:28:10 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Breno <breno.demedeiros@gmail.com>
Date: Fri, 04 Dec 2009 11:28:27 -0700
Thread-Topic: [OAUTH-WG] Signature crypto
Thread-Index: Acp1Dt9zcaU6LxO5SjOwmo1b+5cBwgAAEYhw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378529368A@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> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <f98165700912041023y3207d801r42f01c7a0c4352bb@mail.gmail.com>
In-Reply-To: <f98165700912041023y3207d801r42f01c7a0c4352bb@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_90C41DD21FB7C64BB94121FBBC2E7234378529368AP3PW5EX1MB01E_"
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:28:31 -0000

It's not really.

We are talking about:

1. HMAC-specific:

The server sends:

methods="HMAC:sha-1,sha-256"

The client replies:

method="HMAC:sha-256"

2. MAC-generic:

The server sends:

methods="MAC:hmac-sha1,hmac-sha256"

The client replies:

method="MAC:hmac-sha256"

Pick!

EHL

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

There is no reason to make HMAC + hash a separate thing.

It would make sense to define a way to specify a MAC, and to specify HMAC with SHA-1 you need only say HMAC-SHA1 as the algorithm name.

This is pretty conventional.
On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav <eran@hueniverse.com<mailto:eran@hueniverse.com>> wrote:
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<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<mailto: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



--
Breno de Medeiros