Re: [OAUTH-WG] Signature crypto

[Eran Hammer-Lahav <[e-mail]>]

And if it is not clear, this is very different from 1.0 in which the signature method includes what is being signed as well as how to normalize the output into the authenticated request. This separates the how to sign with what to sign and gives each a name.

EHL

From: [e-mail] [mailto:[e-mail]] On Behalf Of Eran Hammer-Lahav
Sent: Friday, December 04, 2009 12:35 PM
To: OAuth WG ([e-mail])
Subject: Re: [OAUTH-WG] Signature crypto

We have been to some extent talking part each other. Breno and I spend some time talking about this off line and reached a better understanding of our positions.

We have been approaching this from the wrong direction.

The server should not be broadcasting what types of algorithms it supports. Instead it should be listing what kind of *tokens* it supports. Since a token secret issued for use with HMAC-SHA1 should/may be different from that used with HMAC-SHA512, it is the token class that determines what it can be used with.

The server should indicate the kinds of tokens supported for a given resource/realm. When obtaining such tokens, the client will be provided with a new attribute indicating the token type (which will dictate how it should use it to sign/etc. the canonicalized request.).

The server should indicate in the WWW-Authenticate header which canonicalizations it supports (with bearer token being a special case).

The authentication scheme should specify how to take the raw signature and encode it into the Authentication header.

This means *are* going to pick a few token types to standardize which will include the crypto used, and allow extensions by publishing an RFC + registration.

EHL




From: Breno [mailto:[e-mail]]
Sent: Friday, December 04, 2009 11:46 AM
To: Eran Hammer-Lahav
Cc: Brian Eaton; OAuth WG ([e-mail])
Subject: Re: [OAUTH-WG] Signature crypto

I am not sure I buy this. For instance, RSA-SHA1 is _not_ a signature scheme, PKCS#11 does establish a signature scheme based on RSA + SHA-1.

So to delve beyond the level of abstraction of 'authentication mechanism name' you need to point to a separate spec for both signing and verification.

I am not sure how much one needs to do beyond defining the byte representation of what needs to be signed.

Some MACs require random pads in addition to keys. Those won't fit into this abstraction but I don't think we need absolute generality here.
On Fri, Dec 4, 2009 at 11:25 AM, Eran Hammer-Lahav <[e-mail]<mailto:[e-mail]>> wrote:
Point where?

I didn't mean new spec for the algorithm, just for how it is used with the OAuth authentication scheme.

EHL

From: Breno [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Friday, December 04, 2009 11:20 AM
To: Brian Eaton
Cc: Eran Hammer-Lahav; OAuth WG ([e-mail]<mailto:[e-mail]>)

Subject: Re: [OAUTH-WG] Signature crypto

There is no need to publish a new spec for a new MAC algorithm. MAC algorithms typically go through certification (e.g., NIST) and have detailed specs, including test vectors for interoperability.

For OAuth, if you want to explicitly support a new MAC algorithm you will not need to change the transport and you just have to point to the particular spec that defines the MAC algorithm.
On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav <[e-mail]<mailto:[e-mail]>> wrote:
> I am trying to avoid the need to publish a specification every time you want
> to add a new MAC-based algorithm.
People are going to end up needing to write new code every time they
want to add a new MAC-based algorithm.
Cheers,
Brian



--
Breno de Medeiros



--
Breno de Medeiros