Subject: Re: [OAUTH-WG] Signature crypto

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 11:07:25 -0700

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:[email-masked]]
> Sent: Thursday, November 26, 2009 7:43 PM
> To: Eran Hammer-Lahav; Stephen Farrell
> Cc: OAuth WG ([email-masked])
> 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

---

From: Breno <[email-masked]>
Date: Fri, 4 Dec 2009 10:16:51 -0800

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 <[email-masked]>wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 11:21:47 -0700

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:[email-masked]]
Sent: Friday, December 04, 2009 10:17 AM
To: Eran Hammer-Lahav
Cc: Manger, James H; Stephen Farrell; OAuth WG ([email-masked])
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 <[email-masked]<mailto:[email-masked]>> wrote:
Is there actual demand to make the HMAC method more generic to allow other kinds of MAC?

EHL

> From: Manger, James H [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: OAuth WG ([email-masked]<mailto:[email-masked]>)
> However, there are other MAC algorithms - based on block ciphers for
> instance (eg CMAC-AES).
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

--
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Fri, 4 Dec 2009 10:23:25 -0800

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 <[email-masked]>wrote:

> 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:[email-masked]]
> *Sent:* Friday, December 04, 2009 10:17 AM
> *To:* Eran Hammer-Lahav
> *Cc:* Manger, James H; Stephen Farrell; OAuth WG ([email-masked])
>
> *Subject:* Re: [OAUTH-WG] Signature crypto
>
>
>

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 11:28:27 -0700

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:[email-masked]]
Sent: Friday, December 04, 2009 10:23 AM
To: Eran Hammer-Lahav
Cc: Manger, James H; Stephen Farrell; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Signature crypto

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 <[email-masked]<mailto:[email-masked]>> wrote:
I was not suggesting to explicitly mention them, just allow them.

EHL

From: Breno [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, December 04, 2009 10:17 AM
To: Eran Hammer-Lahav
Cc: Manger, James H; Stephen Farrell; OAuth WG ([email-masked]<mailto:[email-masked]>)

EHL

--
Breno de Medeiros

--
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Fri, 4 Dec 2009 10:29:52 -0800

>
>
> 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”
>
>
>

I pick the second. It's the right level of abstraction and actually slightly
easier to implement.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 11:34:28 -0700

Do all MAC functions work like this:

digest = mac(key, text)

It would be hard to generalize a signature method if not.

EHL

From: Breno [mailto:[email-masked]]
Sent: Friday, December 04, 2009 10:30 AM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Signature crypto

The client replies:

method="HMAC:sha-256"

2. MAC-generic:

The server sends:

I pick the second. It's the right level of abstraction and actually slightly easier to implement.

---

From: Brian Eaton <[email-masked]>
Date: Fri, 4 Dec 2009 10:37:46 -0800

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 <[email-masked]> wrote:
> It’s not really.
> method=”MAC:hmac-sha256”
> 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 <[email-masked]>
Date: Fri, 4 Dec 2009 10:46:07 -0800

Yes, they all do.

On Fri, Dec 4, 2009 at 10:34 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> *Sent:* Friday, December 04, 2009 10:30 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG ([email-masked])
>

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 11:46:32 -0700

We need to group them by class so that they can be applied in a consistent way.

This needs to work without having to write a spec to go from HMAC-SHA1 to HMAC-SHA256. While it is intuitive for some, it is not for others... I can extrapolate HMAC-SHA256 from the definition of HMAC-SHA1, but I have no clue what ECC implies and how it should work based on the defined methods (maybe it doesn't).

Right now we have three classes:

HMAC, RSA, and Plain. Plain does not take any parameters. HMAC and RSA take a hash algorithm name as parameter.

If we are to generalize these to MAC (and possibly RSA to PK-something, if we decide not to drop it), I need to be able to write a spec that can be applied consistently.

We have two ways to accomplish a baseline interop. One is to pick a small number of algorithms like 1.0 did and leave the rest to be defined by extensions. The second is to pick a small number of well-defined classes of algorithm which can be applies in a consistent way, and either define a registry for algorithm names or reuse one.

EHL

> From: Brian Eaton [mailto:[email-masked]]
> Sent: Friday, December 04, 2009 10:38 AM
> To: Eran Hammer-Lahav
> Cc: Breno; OAuth WG ([email-masked])
> 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
> 
> > 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.
> >
> >
> >
> > On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav
> > <[email-masked]>
> > wrote:
> >
> > 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
> >
> >
> >
> > 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
> > <[email-masked]>
> > wrote:
> >
> >> OAuth (at least the authentication part) mainly needs a MAC
> >> algorithm, not a hash algorithm.
> >> P.S. The body-signing OAuth extension is the one place that uses a
> >> hash (not a MAC) directly.
> >>
> >> James Manger

---

From: Breno <[email-masked]>
Date: Fri, 4 Dec 2009 10:46:29 -0800

+1

On Fri, Dec 4, 2009 at 10:37 AM, Brian Eaton <[email-masked]> wrote:

> are
> > Is there actual demand to make the HMAC method more generic to allow
> other
> > kinds of MAC?
> >
> > EHL
> >
> >> OAuth (at least the authentication part) mainly needs a MAC algorithm,
> not
> >> a
> >> hash algorithm.

-- 
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Fri, 4 Dec 2009 10:48:19 -0800

The difference between HMAC and RSA is artificial, I agree with Brian.

All integrity/authenticity mechanisms take a key and a text. Everything else
is defined by the algorithm itself.

HMAC-SHA1, HMAC-SHA256, and RSA-SHA1 are completely different mechanisms.
The fact that RSA-SHA1 and HMAC-SHA1 share a hash algorithm is an
implementation detail that OAuth should not be aware of.

On Fri, Dec 4, 2009 at 10:46 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> This needs to work without having to write a spec to go from HMAC-SHA1 to
> HMAC-SHA256. While it is intuitive for some, it is not for others... I can
> extrapolate HMAC-SHA256 from the definition of HMAC-SHA1, but I have no clue
> what ECC implies and how it should work based on the defined methods (maybe
> it doesn't).
>
> If we are to generalize these to MAC (and possibly RSA to PK-something, if
> we decide not to drop it), I need to be able to write a spec that can be
> applied consistently.
>
> We have two ways to accomplish a baseline interop. One is to pick a small
> number of algorithms like 1.0 did and leave the rest to be defined by
> extensions. The second is to pick a small number of well-defined classes of
> algorithm which can be applies in a consistent way, and either define a
> registry for algorithm names or reuse one.
>
> EHL
>
> > > other kinds of MAC?

-- 
Breno de Medeiros

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Dec 2009 18:54:31 +0000

Me too.
S.
> On Fri, Dec 4, 2009 at 10:28 AM, Eran Hammer-Lahav <[email-masked] 
> > wrote:
> > It’s not really.
> >
> >
> >
> > We are talking about:
> >
> >
> >
> > 1. HMAC-specific:
> >
> >
> >
> > The server sends:
> >
> >
> >
> > On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav <[email-masked] 
> >
> > wrote:
> >
> there are
> > On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav <[email-masked] 
> >
> > wrote:
> >
> > Is there actual demand to make the HMAC method more generic to  
> allow other
> > kinds of MAC?
> >
> > EHL
> >
> >> >> Sounds reasonable if all you need to negotiate are hash  
> algorithm
> >> >> names.
> >> >> Is that the case?
> >>
> >> > Yes.
> >>
> >> Not quite.
> algorithm, not
> >> P.S. The body-signing OAuth extension is the one place that uses  
> a hash
> >> (not
> >> a MAC) directly.
> >>
> >> James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 12:10:20 -0700

Not exactly. MAC and RSA require a different kind of shared secret and are validated differently.

I am trying to avoid the need to publish a specification every time you want to add a new MAC-based algorithm. I am not trying to actually pick and choose specific ones.

OAuth can be crypto agnostic. I am not suggesting otherwise. I am simply looking for the easiest way to support common extensions such as HMAC with new hash functions.

EHL

From: Breno [mailto:[email-masked]]
Sent: Friday, December 04, 2009 10:48 AM
To: Eran Hammer-Lahav
Cc: Brian Eaton; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Signature crypto

All integrity/authenticity mechanisms take a key and a text. Everything else is defined by the algorithm itself.

HMAC-SHA1, HMAC-SHA256, and RSA-SHA1 are completely different mechanisms. The fact that RSA-SHA1 and HMAC-SHA1 share a hash algorithm is an implementation detail that OAuth should not be aware of.
On Fri, Dec 4, 2009 at 10:46 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
We need to group them by class so that they can be applied in a consistent way.

EHL

> From: Brian Eaton [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Breno; OAuth WG ([email-masked]<mailto:[email-masked]>)
> On Fri, Dec 4, 2009 at 10:28 AM, Eran Hammer-Lahav
> <[email-masked]<mailto:[email-masked]>> wrote:
> > It's not really.
> >
> >
> >
> > We are talking about:
> >
> >
> >
> > 1. HMAC-specific:
> >
> >
> >
> > The server sends:
> >
> >
> >
> > <[email-masked]<mailto:[email-masked]>>
> > wrote:
> >
> > <[email-masked]<mailto:[email-masked]>>
> > wrote:
> >

--
Breno de Medeiros

---

From: Brian Eaton <[email-masked]>
Date: Fri, 4 Dec 2009 11:12:43 -0800

On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav <[email-masked]> 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

---

From: Breno <[email-masked]>
Date: Fri, 4 Dec 2009 11:20:21 -0800

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.

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 12:24:37 -0700

That's beside the point. You are talking about implementation and I'm talking about specification.

Are you expecting them to write a new RFC to add support for HMAC-1024? That's the implications of what you are suggesting. Instead, I am trying to define a few (1 or 2) classes of algorithms, provide well-defined process of them, and provide an easy registration process for new algorithms which fit the class.

A MAC class would be defined as applying any MAC algorithm which can be described by digest=mac(key,text) where text is the signature base string, key is the symmetric shared secret associated with the token, and digest is the value sent to the server for authentication (after properly encoded).

With this definition, you can extend the protocol by simply sending an email to a designated list, get quick feedback, and register a new algorithm that fits this template. However, if you want to use a new algorithm that requires, say, asymmetric shared secret or a different normalization of the HTTP request (something different from the signature base string), then you need to write an RFC (or any other Open Standard) and go through a longer process.

EHL

> Sent: Friday, December 04, 2009 11:13 AM
> To: Eran Hammer-Lahav
> > 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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 12:25:41 -0700

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:[email-masked]]
Sent: Friday, December 04, 2009 11:20 AM
To: Brian Eaton
Cc: Eran Hammer-Lahav; OAuth WG ([email-masked])
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 <[email-masked]<mailto:[email-masked]>> wrote:

--
Breno de Medeiros

---

From: "Paul C. Bryan" <[email-masked]>
Date: Fri, 04 Dec 2009 11:29:35 -0800

+1

---

From: [email-masked]
Date: Fri, 4 Dec 2009 19:44:19 -0000 (GMT)

I think the +1's for HMAC-SHA1 etc should be followed here.
Attempting to reflect the internals of a signature or MACing
scheme in this protocol would be a mistake.

> Are you expecting them to write a new RFC to add support for HMAC-1024?

Yes. (Not that such a beast would make much sense.)

> That's the implications of what you are suggesting. Instead, I am trying
> to define a few (1 or 2) classes of algorithms, provide well-defined
> process of them, and provide an easy registration process for new
> algorithms which fit the class.

No thanks. I'd rather not see HMAC-snakeoil widely
deployed.

> ...asymmetric shared secret ...

Excellent example. That's precisely why we want an RFC and
a proper review process.

S.

---

From: Breno <[email-masked]>
Date: Fri, 4 Dec 2009 11:46:21 -0800

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 <[email-masked]>wrote:

> Point where?
>
>
>
> I didn’t mean new spec for the algorithm, just for how it is used with the
> OAuth authentication scheme.
>
>
>
> EHL
>
>
>
> *Sent:* Friday, December 04, 2009 11:20 AM
> *To:* Brian Eaton
> *Cc:* Eran Hammer-Lahav; OAuth WG ([email-masked])
>

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 13:35:21 -0700

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:[email-masked]]
Sent: Friday, December 04, 2009 11:46 AM
To: Eran Hammer-Lahav
Cc: Brian Eaton; OAuth WG ([email-masked])
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 <[email-masked]<mailto:[email-masked]>> wrote:
Point where?

EHL

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

--
Breno de Medeiros

--
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 13:36:38 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Friday, December 04, 2009 12:35 PM
To: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Signature crypto

EHL

EHL

--
Breno de Medeiros

--
Breno de Medeiros

---

From: Richard Barnes <[email-masked]>
Date: Tue, 8 Dec 2009 19:17:31 -0500

This isn't quite right.  First of all, you're not constraining the  
types of *tokens*, you're constraining the types of token *secrets*  
(the private part, not the public part; the key, not the key label).

Second, there's basically only two classes of signature/secret anyway,  
symmetric and asymmetric.  MAC algorithms generally take any string of  
bytes as a key (possibly with a length constraint), since they're just  
going to XOR it with data anyway.  Public-key algorithms require the  
secret key to have an relationship to its public half.  The practical  
implication is that you can use your tokens as MAC keys if you want,  
but you might need to carry tokens separately if you're using an  
asymmetric signature algorithm.

Net of all that, I'll agree with Brian's earlier claim that OAuth 1.0  
had this basically right by having the server advertise what  
algorithms it supports, with  the one major change that we probably  
should use the same base string for all algorithms.

--Richard

On Dec 4, 2009, at 3:35 PM, Eran Hammer-Lahav wrote:

> 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.
>
> 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
>
>
>
>
> 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.
>
> 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 <[email-masked] 
> > wrote:
> Point where?
>
> I didn’t mean new spec for the algorithm, just for how it is used  
> with the OAuth authentication scheme.
>
> EHL
>
> 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:10 AM, Eran Hammer-Lahav <[email-masked] 
> > wrote:

---

From: Breno <[email-masked]>
Date: Tue, 8 Dec 2009 19:09:51 -0800

On Tue, Dec 8, 2009 at 4:17 PM, Richard Barnes <[email-masked]> wrote:

> This isn't quite right.  First of all, you're not constraining the types of
> *tokens*, you're constraining the types of token *secrets* (the private
> part, not the public part; the key, not the key label).
>

Good security practice indicates that a key (the secret part) should be used
with a single algorithm. Different algorithm --> different key.

> symmetric and asymmetric.  MAC algorithms generally take any string of bytes
> as a key (possibly with a length constraint), since they're just going to
> XOR it with data anyway.  Public-key algorithms require the secret key to
> have an relationship to its public half.  The practical implication is that
> you can use your tokens as MAC keys if you want, but you might need to carry
> tokens separately if you're using an asymmetric signature algorithm.
>

While MAC algorithms take any type of key, it is not good practice to use a
key with two different MAC algorithms. So while technically it will work, it
is not advised practice.

>
> Net of all that, I'll agree with Brian's earlier claim that OAuth 1.0 had
> this basically right by having the server advertise what algorithms it
> supports, with  the one major change that we probably should use the same
> base string for all algorithms.
>

> 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.
>
> 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.
>
> 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.).
>
> 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:[email-masked]<[email-masked]>
> ]
> *Sent:* Friday, December 04, 2009 11:46 AM
> *To:* Eran Hammer-Lahav
> *Cc:* Brian Eaton; OAuth WG ([email-masked])
> 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.

-- 
Breno de Medeiros

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 9 Dec 2009 00:57:30 -0500

We're not talking about using the same key with multiple MACs (that's  
an issue of how the keys are managed).  Rather, we're trying to figure  
out a taxonomy of signing algorithms according to some practical  
criteria.  "Arbitrary bit-string" vs. "Algebraically meaningful" for a  
key seems to be an important distinction for this protocol (since  
there's a question as to what the protocol should use for a signing  
key), but it doesn't imply that you would use the same protocol for  
all signing algorithms of a given class -- this idea is clearly  
ridiculous for asymmetric algorithms, and has some risks, as you say,  
for symmetric algorithms.

--Richard

On Dec 8, 2009, at 10:09 PM, Breno wrote:

> Good security practice indicates that a key (the secret part) should  
> be used with a single algorithm. Different algorithm --> different  
> key.
>
>
> Second, there's basically only two classes of signature/secret  
> anyway, symmetric and asymmetric.  MAC algorithms generally take any  
> string of bytes as a key (possibly with a length constraint), since  
> they're just going to XOR it with data anyway.  Public-key  
> algorithms require the secret key to have an relationship to its  
> public half.  The practical implication is that you can use your  
> tokens as MAC keys if you want, but you might need to carry tokens  
> separately if you're using an asymmetric signature algorithm.
>
> While MAC algorithms take any type of key, it is not good practice  
> to use a key with two different MAC algorithms. So while technically  
> it will work, it is not advised practice.
>
>
>
> Net of all that, I'll agree with Brian's earlier claim that OAuth  
> 1.0 had this basically right by having the server advertise what  
>> 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.).
>>
>> signature scheme, PKCS#11 does establish a signature scheme based  
>> on RSA + SHA-1.
>>
>> 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.
>>