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

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

And I don't think sending client the mac key or hot-sk is good.
Since distributing shared keys between AS and RS is already a cubersome 
work,
sending key to client implies the key is only one time thing, that will 
further increase the complexity.

ZhouSuJing00132831/user/zte_ltd 写于 2012-09-10 16:46:47:

> 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. 
> > 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:
> > 
> > > 
> > > 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. 
> > > 
> > > 
> > >     _______________________________________________
> > > OAuth mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/oauth
> > 
> >

---

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

Hi Zhou, 

> And I don't think sending client the mac key or hot-sk is good. 

The Client and the Resource Server need to obtain this session key somehow. 
Only two mechanisms exist: 

a) Key Transport 
b) Key Agreement 

Here a key transport based mechanism is used and that's not uncommon. 

> Since distributing shared keys between AS and RS is already a cubersome work, 
> sending key to client implies the key is only one time thing, that will further increase the complexity. 
> 
An authentication and key exchange protocols is a complex thing. 
No doubt about that. 

Ciao
Hannes

> > > MAC key should be shared between AS and RS, Client don't have to know them;

---

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

Hi, Hannes,
 
> Here a key transport based mechanism is used and that's not uncommon. 
I have no doubt about that.
My concern is may be there are some better ways to do proof-of-posession, 
or proof-of-knowledge of keys. 
For example, as I wrote in  the review of 
draft-tschofenig-oauth-security-00:
client send H(R) in token request to AS, AS includes the H(R) in the 
token, and client sends (token,R) to RS,
RS can verify the access capablity by recalculating H(R) and checking 
access toekn, 
by feature of hash, RS can trust R provider,this method does not use 
pre-shared key between AS  and RS.

> An authentication and key exchange protocols is a complex thing. 

But Oauth is aimed at simple solutiion and better user experience. 
An AKE and be complex, but some AKE can be simpler than others, depending 
on requirements.

---

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

Hi Zhou, 

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

> For example, as I wrote in  the review of draft-tschofenig-oauth-security-00: 
> client send H(R) in token request to AS, AS includes the H(R) in the token, and client sends (token,R) to RS, 
> RS can verify the access capablity by recalculating H(R) and checking access toekn, 
> by feature of hash, RS can trust R provider,this method does not use pre-shared key between AS  and RS. 

I am sure that we can come up with many different protocols; the area of key agreement protocols isn't necessarily a new one. 

(What by the way is "H(R)" standing for?) 
> An AKE and be complex, but some AKE can be simpler than others, depending on requirements. 
> 

"simple" is a common but often misunderstood concept in the design of protocols. 

With the increasing number of security properties we want to provide the solution will get more complex. 
And it is important to keep in mind that user's don't get to see anything thing about this. I even expect normal application developers not to get exposed to these details either. 

Ciao
Hannes

---

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

I guess I figured it out. H(R) is the hash of a random number. 

The issue with this approach is that the Client can only use the Access Token once with your approach. 
Of course, one could extend the approach to a hash chain and then disclose the reverse hash chain. 

Still, this approach requires that the hash chain is bound to the access token in some way and this requires a key. In general, to secure the Access Token it is necessary to protect the token anyway (for other reasons as well). 

While I like these hash chain proposals (and I have seen these already back in the Mobile IPv6 days) I don't think they make anything simpler in the end. 

I prefer to go for a well-established scheme

---

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

Hi,

> or proof-of-knowledge of keys.

Keep in mind that this is a short-lived session key that's valid only
for this client<->RS Instance.  The MAC Key is tied to the Access Token,
which is (hopefully!) tied to the client_id.  The MAC key is a
throw-away key.  Future access tokens would use *different* MAC Keys.

Please take a look at the Kerberos Authenticator for prior art that
explains how this works.

> pre-shared key between AS  and RS.

Sure, this works for a single request.  However it also means you need
to have the AS involved in *every* request because you cannot reuse R.
Another option would be:

AS sends an Access token, encrypted to the RS, and includes a MAC
Session Key (Kms).  The Client can send the token, a Nonce (N), and N
encrypted with Kms ({N}Kms) to prove posession of Kms.  Of course to
protect replay attacks the RS has to keep a cache of all Nonces used
under Kms.

> An AKE and be complex, but some AKE can be simpler than others, depending on

Do you have a particular use-case in mind?

-derek

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

---

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

> (What by the way is "H(R)" standing for?) 

I'm pretty sure he means Hash of R.  E.g. you send the SHA-1 Hash of R
as a commitment of R, and then later you send R.  But see my previous
message, because this *requires* the AS be involved in EVERY request.  I
don't think that's a reasonable architecture.  Tokens should have a
validity period and the client should be free to continually use the
token without going back to the AS during that period.  Otherwise the AS
becomes a single point of failure and a bottleneck.

-derek

---

From: [email-masked]
Date: Tue, 11 Sep 2012 09:53:42 +0800

Hi,

> Please take a look at the Kerberos Authenticator for prior art that

I have no doubt about how it works. 

> > client send H(R) in token request to AS, AS includes the H(R) in the 
token,
> > and client sends (token,R) to RS,
access
> > toekn,
Prove knowledge of key by encryption is not a good idea,as you mentioned, 
for having to 
keep a cache.

> > An AKE and be complex, but some AKE can be simpler than others, 
depending on
> > requirements.
No.

---

From: [email-masked]
Date: Tue, 11 Sep 2012 10:23:07 +0800

> I guess I figured it out. H(R) is the hash of a random number. 
Yes. 
> Access Token once with your approach. 
access token generally have time limit from a few minutes to 1 hour. 
according to oauth2, access token must be transported in TLS for 
confidentiality,
attacker can only obtain H(R), and it is difficult  to reverse a hash 
result in one hour. 
In this case, R can be used more than once.

> disclose the reverse hash chain. 
That is a better method to extend the above access token to more than 
once. 

> Still, this approach requires that the hash chain is bound to the 
> access token in some way and this requires a key. In general, to 
> secure the Access Token it is necessary to protect the token anyway 
> (for other reasons as well). 
On the path from AS　to client , the access token and H(R) can be bound by 
a key shared between AS and client, which may be inevitably needed for 
client authentication to AS.
On the path from Client to RS, access token is transported in 
confifential, the validity of access token can be checked as usual(how is 
a access token verified when there is no shared key 
between AS and RS?), plus a verification of H(R).

> While I like these hash chain proposals (and I have seen these 
> already back in the Mobile IPv6 days) I don't think they make 
> anything simpler in the end. 
It provides an option where AS and RS don't need shared key and where 
access  time is quite limited especially when access limitation is done by 
access number. 

> > client send H(R) in token request to AS, AS includes the H(R) in 
> the token, and client sends (token,R) to RS,

---

From: [email-masked]
Date: Tue, 11 Sep 2012 10:26:47 +0800

Derek Atkins <[email-masked]> 写于 2012-09-10 21:23:12:

> > I am sure that we can come up with many different protocols; the 
> area of key agreement protocols isn't necessarily a new one. 
> >

Concerning access token is time limited from a few minutes to 1 hour, 
and R is transported in TLS, it is not necessarily used only once.

---

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

> Prove knowledge of key by encryption is not a good idea,as you
> mentioned, for having to keep a cache.

You only have to keep a cache for the validity of the token.  In your
case you have to keep a cache forever, because the token could
theoretically be reused over and over with the same commitment and R
values.  At best the caches are the same, but in both cases you have to
contain a cache.  Therefore your statement above is invalid.

-derek

---

From: [email-masked]
Date: Tue, 18 Sep 2012 11:07:29 +0800

> theoretically be reused over and over with the same commitment and R

In my case, token can also have validity time, and the token could not be 
used over and over again 
even using the same commitment and R, because the commitment is boud to 
the token, use of R is limited to 
the validity time of the token.
> contain a cache.  Therefore your statement above is invalid.
I am not saying my case is superior to the example you mentioned.
What I am tyring to say is we could think about more options.