Subject: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

From: [email-masked]
Date: Mon, 10 Sep 2012 15:57:10 +0800

Hi, 

  I have a question concerning draft-ietf-oauth-v2-http-mac-01： 
  The propose is that Client obtains MAC credentials (i.e., MAC keys) from 
Resource Server first, then Client genertate MAC access token using MAC 
keys, and send MAC access token to RS, RS recalculates MAC access token to 
verify the validity, right? 
  But in Section 5.1 it says the Authorization server issues the MAC 
access token. 
  I am totally lost, 
    if AS to issue MAC access token, then for RS to verify, the MAC key 
should be shared between AS and RS, Client don't have to know them; 
    if RS to issue MAC access token, then it is not conforming to OAuth 
2.0 framework.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 Sep 2012 11:06:34 +0300

Hi Zhou, 

here is the story. 

The Authorization Server gives an Access Token to the Client and the client presents that Access Token to Resource Servers. 
This has not changed in comparison to Bearer Tokens.

However, in addition to just presenting the Access Token by the Client to the Resource Server the Client also needs to compute a keyed message digest on the access request to the protected resource. 

It needs a key to compute the keyed message digest. 

This key, called MAC key, is provided by the Authorization Server together with the Access Token. 

What is not said in the document is how the Resource Server obtains the MAC key from the Authorization Server. It is assumed to be shared somehow.

Hope that makes more sense. 

Ciao
Hannes

On Sep 10, 2012, at 10:57 AM, [email-masked] wrote:

>   The propose is that Client obtains MAC credentials (i.e., MAC keys) from Resource Server first, then Client genertate MAC access token using MAC keys, and send MAC access token to RS, RS recalculates MAC access token to verify the validity, right? 
>   But in Section 5.1 it says the Authorization server issues the MAC access token. 
>   I am totally lost, 
>     if AS to issue MAC access token, then for RS to verify, the MAC key should be shared between AS and RS, Client don't have to know them; 
>     if RS to issue MAC access token, then it is not conforming to OAuth 2.0 framework.   
> 
> 
>     _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: [email-masked]
Date: Mon, 10 Sep 2012 16:46:47 +0800

Hi, Hannes,
  Thank you for the clarity.
  Yes, it makes sense.
  Then http-mac and hot-sk are quite similar. Why do redundant work?

Hannes Tschofenig <[email-masked]> 写于 2012-09-10 16:06:34:

> Hi Zhou, 
> 
> here is the story. 
> 
> The Authorization Server gives an Access Token to the Client and the
> client presents that Access Token to Resource Servers. 
> However, in addition to just presenting the Access Token by the 
> Client to the Resource Server the Client also needs to compute a 
> keyed message digest on the access request to the protected resource. 
> 
> What is not said in the document is how the Resource Server obtains 
> the MAC key from the Authorization Server. It is assumed to be shared 
somehow.
> >   The propose is that Client obtains MAC credentials (i.e., MAC 
> keys) from Resource Server first, then Client genertate MAC access 
> token using MAC keys, and send MAC access token to RS, RS 
> recalculates MAC access token to verify the validity, right? 
> >     if AS to issue MAC access token, then for RS to verify, the 
> MAC key should be shared between AS and RS, Client don't have to know 
them;

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 10 Sep 2012 09:57:33 +0100

Hi Hannes

> What is not said in the document is how the Resource Server obtains the MAC key from the Authorization Server. It is assumed to be shared somehow.
In our case we have structured access tokens and MAC key is simply
treated as an extra token property

Cheers, Sergey

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 Sep 2012 12:04:48 +0300

Hi Sergey, 

> treated as an extra token property
Since the token is opaque to the Client a key transported inside the Access Token (hopefully encrypted) can only be meant for consumption by the Resource Server. But you are right that this is an alternative to transporting the key from the Authorization Server to the Resource Server. 

This still leaves the question about how the Client obtains that key and, as mentioned in my other mail to Zhou, there are really only two ways to do that.

Ciao
Hannes

---

From: [email-masked]
Date: Mon, 10 Sep 2012 17:40:58 +0800

Hannes Tschofenig <[email-masked]> 写于 2012-09-10 17:04:48:

> Since the token is opaque to the Client a key transported inside the
> Access Token (hopefully encrypted) can only be meant for consumption
> by the Resource Server. But you are right that this is an 

But in http-mac, and hot-sk, client needs to know the key to calculate 
MAC,
contradiction?

> alternative to transporting the key from the Authorization Server to
> the Resource Server. 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 Sep 2012 12:45:26 +0300

Yes, with the solutions in Section 4.3 of http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 the Client has to use keying material.  With the solution in Section 4.1 of the same document they don't. 

On Sep 10, 2012, at 12:40 PM, [email-masked] wrote:

> But in http-mac, and hot-sk, client needs to know the key to calculate MAC, 
> contradiction?

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 Sep 2012 13:30:56 +0300

Hi Zhou, 

>   Then http-mac and hot-sk are quite similar. Why do redundant work? 

Even though the two solutions fall in the same category does not mean that they are equal. There are actually quite substantial differences between the two. However, they are just contributions to make progress in the discussions and we have not yet decided what to standardize. For that reason the requirements document was published recently. 

Ciao
Hannes

> > the MAC key from the Authorization Server. It is assumed to be shared somehow.
> > 
> > MAC key should be shared between AS and RS, Client don't have to know them;

---

From: Derek Atkins <[email-masked]>
Date: Mon, 10 Sep 2012 09:14:37 -0400

> What is not said in the document is how the Resource Server obtains the MAC key from the Authorization Server. It is assumed to be shared somehow.

It could even, theoretically, be included in the Access Token!

> Hope that makes more sense. 

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: William Mills <[email-masked]>
Date: Mon, 10 Sep 2012 21:52:10 -0700 (PDT)

> It could even, theoretically, be included in the Access Token!

It certainly could, this is the simplest form of holder of key in fact.

________________________________
From: Derek Atkins <[email-masked]>
To: Hannes Tschofenig <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Monday, September 10, 2012 6:14 AM
Subject: Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

-derek

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Sep 2012 10:24:33 +0300

I certainly agree. That would then even look like Kerberos ;-)

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Sep 2012 11:42:12 +0300

> It certainly could, this is the simplest form of holder of key in fact.

The IETF has certainly lots of experience with that approach.