Re: [OAUTH-WG] Signature crypto

+1

On Fri, Dec 4, 2009 at 10:37 AM, Brian Eaton <beaton@google.com> wrote:

> I think OAuth 1.0 got this right.  Just specify the signature
> algorithm.  That can cover HMAC-SHA1, HMAC-SHA256, ECC, RSA-SHA1,
> RSA-SHA256, and whatever other fancy magic someone comes up with next
> year.
>
> Cheers,
> Brian
>
> On Fri, Dec 4, 2009 at 10:28 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> > 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>
> > 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]
> > 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>
> > 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]
> >> Sent: Thursday, November 26, 2009 7:43 PM
> >> To: Eran Hammer-Lahav; Stephen Farrell
> >> Cc: OAuth WG (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
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > --
> > Breno de Medeiros
> >
> >
> > --
> > Breno de Medeiros
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
>

-- 
Breno de Medeiros