Subject: [OAUTH-WG] OAuth Security Discussions

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 6 Sep 2012 17:25:03 +0300

Hi all, 

following the discussions at the last IETF meeting and the weeks before Phil and I had prepared a short writeup about the threats, and the security requirements. 

Here is the document: 
http://tools.ietf.org/html/draft-tschofenig-oauth-security-00

Please share your views with us.  Is there something missing? Is further explanation needed? With what do you agree / disagree?

Ciao
Hannes & Phil

---

From: [email-masked]
Date: Fri, 7 Sep 2012 11:23:13 +0800

1. Section 4    “A Resource Server must not be allowed to accept access 
tokens that are not meant for its consumption.”
  says Resource Server authentication to Client is a must.
  section 4.1  “For that purpose the Client will have to authenticate the 
Resource Server before transmitting the access token.”
  says Client authentication to Resource Server  is a must.
  so the two unilateral authentications are must for one thing: client 
sends an access token to a not intended resource server. 
  it seems to me either one is workable, especially the second one is 
enough. The reson:
      If RS is honest, to protect the resource access it must gurantee the 
resource is accessed by proper entity.
      If RS is unhonest, RS redirects the  access token to another RS, and 
another RS authenticates token  provider, the RS fails.
2. In section 4.3 key confirmation 
     The example of symmetrical key, since Ks is only used once, client 
can directly send token and Ks to RS, don't have to compute a MAC with Ks. 

     The example of asymmetrical key is flawed. Without trust (e.g. 
Certificate) implemented, Client can use any pk/sk generated by itself to 
confirm 
its knowledge of sk. 

3. In section 4.4 summary
   "The weak point with this approach..is.. increased complexity: a 
complete key distribution protocol has to  be defined."
Don't have to be always the case.
For example, 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 key confirmation by client without using preinstalled 
key between AS and RS.

[email-masked] 写于 2012-09-06 22:25:03:

> Hi all, 
> 
> following the discussions at the last IETF meeting and the weeks 
> before Phil and I had prepared a short writeup about the threats, 
> and the security requirements. 
> 
> Here is the document: 
> Please share your views with us.  Is there something missing? Is 
> further explanation needed? With what do you agree / disagree?
> 
> Ciao
> Hannes & Phil
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

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

Hi Zhou, 

On Sep 7, 2012, at 6:23 AM, [email-masked] wrote:

> 
> 1. Section 4    “A Resource Server must not be allowed to accept access tokens that are not meant for its consumption.” 
Here is what I wrote: 

"
An
   Authorization Server wants to ensure that it only hands out tokens to
   Clients it has authenticated first and who are authorized.  For this
   purpose, authentication of the Client to the Authorization Server
   will be a requirement to ensure adequate protection against a range
   of attacks. 
"

>   section 4.1  “For that purpose the Client will have to authenticate the Resource Server before transmitting the access token.” 

No. The Client authenticates the Resource Server and not the other way around.  

>   so the two unilateral authentications are must for one thing: client sends an access token to a not intended resource server. 
>   it seems to me either one is workable, especially the second one is enough. The reson: 
>       If RS is honest, to protect the resource access it must gurantee the resource is accessed by proper entity. 
>       If RS is unhonest, RS redirects the  access token to another RS, and another RS authenticates token  provider, the RS fails. 

The two steps are needed for dealing with different attacks. 

>      The example of symmetrical key, since Ks is only used once, client can directly send token and Ks to RS, don't have to compute a MAC with Ks.  

The Ks is not sent to the RS by the Client but the Client instead uses the Ks as input to a cryptographic operation. 

> 
>      The example of asymmetrical key is flawed. Without trust (e.g. Certificate) implemented, Client can use any pk/sk generated by itself to confirm 
> its knowledge of sk. 

It is perfectly fine but there are obviously lots of details missing. If you look at http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01 then see the details. 
>    "The weak point with this approach..is.. increased complexity: a complete key distribution protocol has to  be defined." 
> For example, 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 key confirmation by client without using preinstalled key between AS and RS. 

What you describe is a key distribution protocol.

Ciao
Hannes

---

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

Hi, Hannes,

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

> > 1. Section 4    “A Resource Server must not be allowed to accept 
> access tokens that are not meant for its consumption.” 
> >   section 4.1  “For that purpose the Client will have to 
> authenticate the Resource Server before transmitting the access token.” 

> >   so the two unilateral authentications are must for one thing: 
> client sends an access token to a not intended resource server. 
> >       If RS is honest, to protect the resource access it must 
> gurantee the resource is accessed by proper entity. 
> >       If RS is unhonest, RS redirects the  access token to another
> RS, and another RS authenticates token  provider, the RS fails. 
> 

Sorry for my mistakes. What I　concern is if two unilateral authentication 
or a mutual authentication between Client and RS is required. 
Of course mutual authentication is better for security, but is it a must 
here ?

> >      The example of symmetrical key, since Ks is only used once, 
> client can directly send token and Ks to RS, don't have to compute a
> MAC with Ks. 
> 
> The Ks is not sent to the RS by the Client but the Client instead 
> uses the Ks as input to a cryptographic operation. 

I know the procedure. What I was questioning is since Ks is temporal and 
only used once, why not just send Ks to RS.
I can see from other mails that access token are intended for multiple 
usages, then that can make sense. 

> 
> > 
> >      The example of asymmetrical key is flawed. Without trust (e.
> g. Certificate) implemented, Client can use any pk/sk generated by 
> itself to confirm 
> > its knowledge of sk. 
> 
> It is perfectly fine but there are obviously lots of details 
> missing. If you look at http://tools.ietf.org/html/draft-tschofenig-
> oauth-hotk-01 then see the details. 
I checked the hotk draft again, I didn't find any method ensuring binding 
between access toekn and pk, it just said including the encoding of pk 
into access token,that can not be looked as a binding, unless you attach a 
mac(access token,k) to the access token, but that will require a long 
lived key shared between AS ans RS, asymmetric key shows no benifit here.

> >    "The weak point with this approach..is.. increased complexity: 
> a complete key distribution protocol has to  be defined." 
> > For example, client send H(R) in token request to AS, AS includes 
> the H(R) in the token, and client sends (token,R) to RS, 

No, it is not a key distribution protocol. 
It is like a commitment protocol.

---

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

> oauth-hotk-01 then see the details. 

it says in draft-tschofenig-oauth-security-00 that "When the Client 
requests an access token the Authorization Server creates an ephemeral 
public / privacy key pair  (PK/SK) and places the public key PK into the 
protected token."
--- AS selects the  Pk,sk, and sends sk, pk to Client
in draft-tschofenig-oauth-hotk-01, it says Client includes pk_info in 
request, it implies sk,pk are chosen by client.

They are different. And selecting pk,sk by client is reasonable.
But how pk and access token are bound ?

---

From: [email-masked]
Date: Tue, 11 Sep 2012 11:17:17 +0800

Since it is prefered to have long lived key shared between AS and RS in 
this WG,
Is there any consideration for this key distribution and its security 
requirements?

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Sep 2012 15:06:33 +0300

Hi Zhou,

On 09/11/2012 06:10 AM, [email-masked] wrote:
> it says in *draft-tschofenig-oauth-security-00* that "When the Client 

That's correct. The approach changed in the two versions. The issue was
the following: if the Authorization Server creates the ephemeral key
pair then it has to also send the private key to the client. Since I
wanted to re-use only available mechanisms this was not possible since
http://datatracker.ietf.org/doc/draft-jones-jose-json-private-key/
didn't exist at that time.

> But how pk and access token are bound ?

The Client sends the PK to the Authorization Server when it requests the
Access Token. The Authorization Server then binds the PK to the Access
Token.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Sep 2012 15:11:24 +0300

> Is there any consideration for this key distribution and its security 

So far we have had only discussions regarding the standardization of the
AS<->RS server interaction in the context of the UMA work.

You may want to have a look at
http://tools.ietf.org/html/draft-hardjono-oauth-umacore

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Sep 2012 15:27:32 +0300

Hi Zhou,

On 09/11/2012 04:11 AM, [email-masked] wrote:
> Sorry for my mistakes. What I　concern is if two unilateral 
> authentication or a mutual authentication between Client and RS is 
> required.

The answer depends on what you assume as the baseline working
assumption. See Section 4.1, 4.2., and 4.3 of
http://tools.ietf.org/html/draft-tschofenig-oauth-security-00

When going for the approach outlined in Section 4.3 then the client
authentication is really "only" key confirmation.

(Note also that the currently specified client authentication is really
only application authentication rather than client instance authentication.

I don't know whether this makes sense, as I tried to explain it.

> usages, then that can make sense.

This is certainly a design decision we need to make, namely how often
the Access Token shall be re-usable (with the same key). This is a very
important design decision.

Luckily, OAuth 2.0 has a mechanism to request new Access Tokens - a
feature OAuth 1.0 didn't provide.

> I checked the hotk draft again, I didn't find any method ensuring 
> binding between access toekn and pk, it just said including the encoding 
> of pk into access token,that can not be looked as a binding, unless you 
> attach a mac(access token,k) to the access token, but that will require 
> a long lived key shared between AS ans RS, asymmetric key shows no 
> benifit here.

At the beginning of Section 4 I write:

"
   A large range of threats can be mitigated by protecting the content
   of the token, using a digital signature or a keyed message digest.
   Alternatively, the content of the token could be passed by reference
   rather than by value (requiring a separate message exchange to
   resolve the reference to the token content).  To simplify the
   subsequent description we assume that the token itself is digitally
   signed by the Authorization Server and therefore cannot be modified.

"

I did not suggest any specific way to protect the token (neither
symmetric nor asymmetric keys) but there is a lot of existing deployment
for both. SAML uses asymmetric keys to protect the SAML assertions (if
they are protected), and Kerberos Tickets are protected using symmetric
keys.

In our standardization efforts we are getting there to create a JSON
based structure that can use both mechanisms.

> It is like a commitment protocol.

Have a look at the Handbook of Applied Cryptography (available for free
at http://cacr.uwaterloo.ca/hac/) and let us see whether we can agree on
the right terminology here.

Ciao
Hannes

---

From: Justin Richer <[email-masked]>
Date: Mon, 17 Sep 2012 10:13:28 -0400

> http://tools.ietf.org/html/draft-hardjono-oauth-umacore
Not quite true. There's also the token introspection, like Ping has 
published[1] or what AOL or MITRE have both implemented. You also have 
to account for those using structured tokens (like JWTs) with signatures 
to communicate using the token itself, analogous to SAML assertions.

When we brought it up during the re-chartering discussion, there seemed 
to be a number of folks willing to work on publishing something in this 
area.

  -- Justin

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Sep 2012 19:21:38 +0300

Good point, Justin.  I was thinking a bit too narrowly here.

---

From: John Bradley <[email-masked]>
Date: Mon, 17 Sep 2012 13:36:33 -0300

I have had interest from a number of people in standardizing a AS -> RS introspection method.

Ping is happy to contribute our draft as a starting point for work.   The OAuth WG doesn't have this as a work item at the moment.

We could do it as a ID with a number of contributors or find another place to work on it, and then contribute it similar to OAuth itself.

What are people's thoughts.   It is something that I am seeing customers ask for.

John B.

On 2012-09-17, at 11:13 AM, Justin Richer <[email-masked]> wrote:

> Not quite true. There's also the token introspection, like Ping has published[1] or what AOL or MITRE have both implemented. You also have to account for those using structured tokens (like JWTs) with signatures to communicate using the token itself, analogous to SAML assertions.
> 
> When we brought it up during the re-chartering discussion, there seemed to be a number of folks willing to work on publishing something in this area.
> 
> -- Justin
>

---

From: [email-masked]
Date: Tue, 18 Sep 2012 14:00:20 +0800

Hannes Tschofenig <[email-masked]> 写于 2012-09-17 20:27:32:

> >  > >   it seems to me either one is workable, especially the second 
one
> >  > is enough. The reson:
May I understand your explaination as not all requirements are to be 
implemented in an OAuth protocol,
whether one requirement is applicable depends on specific protocol?

> >  > missing. If you look at 
http://tools.ietf.org/html/draft-tschofenig-
> based structure that can use both mechanisms.
I see.
> the right terminology here.
As I understand, key distribution protocol is used to establish key to 
entities by transportation of agreement.
Here I did't mean to distribute any key. If you view R as a key, in a key 
distribution protocol, R should be encrypted or by a confidential channel.
Here R don't have to be encrypted.
The idea is commitment to something then disclose it, which is common  in 
contract signing. 
Yes, you are right, this method has limited period, I propose it on the 
base that access token is only used once.
What I am trying to say is that may be you don't have to limit key 
confirmation methods (section 4.3) to precondition that key distribution 
has to be defined to share keys between AS and RS,
although I think sharing keys between AS and RS is acceptable.

---

From: [email-masked]
Date: Wed, 19 Sep 2012 14:36:19 +0800

Hi, Hannes,
   draft-hardjono-oauth-umacore-04 is on interaction between AS and RS 
utilizing OAuth;
   Ping's "OAuth Authorization Server Verification Interface" is on RS 
requesting AS to verify access token for it because RS could not do it 
itself. 
   They are not on sharing long lived keys between AS and RS which may be 
used in calculating and verifying access token. 
   Ping's draft is an alternative solution for verifying access token 
produced  by knowledge of a key , e.g., MAC,    without sharing the keys 
between AS and RS.
   It may be seen as a conter-example to “a complete key distribution 
protocol has to be defined.”