[Openid-specs-ab] Audience restriction of access_token/resource ep response in OpenID Connect

Nat Sakimura sakimura at gmail.com
Sat Nov 12 12:06:41 UTC 2011


On 2011/11/12, at 7:53, Mike Jones <Michael.Jones at microsoft.com> wrote:

  All four countermeasures are listed below.  Comments on each follow:



   o  Clients SHOULD not make authenticated requests with an access

      token to unfamiliar resource servers, regardless of the presence

      of a secure channel.  If the resource server address is well-known

      to the client, it may authenticate the resource servers (see

      Section 5.1.2<http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-5.1.2>
).



This one is good practice, but would translate in the OpenID Connect case
to something like “Don’t use unfamiliar OpenID Providers”.  That’s somewhat
opposed to the “open” intent of OpenID Connect – hence we probably
shouldn’t recommend it in the specs.


Actually it is not. It simply says that do not exercise the access token to
anywhere but the endpoint prescribed by the authorization server. For
bearer token, it is not only a recommendation but I think this is a MUST.



   o  Associate the endpoint address of the resource server the client

      talked to with the access token (e.g. in an audience field) and

      validate association at legitimate resource server.  The endpoint

      address validation policy may be strict (exact match) or more

      relaxed (e.g. same host).  This would require to tell the

      authorization server the resource server endpoint address in the

      authorization process.



This is the one that the working group decided to recommend following on
Thursday’s call.


Yes. At the same time, including audience in the token is only one way of
doing it.
I strongly believe that it should be left to the implementations to chose
which method.
Having the server keep the states of the opaque token is one of the most
potent and common way of doing it without interfering with the existing
implementation, thoug I agree that it is not particularly scalable.



   o  Associate an access token with a client and authenticate the

      client with resource server requests (typically via signature in

      order to not disclose secret to a potential attacker).  This

      prevents the attack because the counterfeit server is assumed to

      miss the capabilities to correctly authenticate on behalf of the

      legitimate client to the resource server (Section
5.4.2<http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-5.4.2>
).



The client isn’t signing the Access Token in our use cases, so I’m not sure
that this one is applicable.


I think having a way to send JWS over e access token and nonce to the
resource server is a good thing, though it is something to be considered in
OAuth Wg and not here.



   o  Restrict the token scope (see Section
5.1.5.1<http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-5.1.5.1>)
and or limit the

      token to a certain resource server (Section
5.1.5.5<http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-5.1.5.5>
).



This is essentially the same as the one that the working group
recommended.  We would restrict the scope of the Access Token by including
an audience.


+1

Actually, I would go further than that. It is a MUST in the distributed
environment like ours.



                                                                Comments?

                                                                -- Mike



*From:* Axel.Nennker at telekom.de [mailto:Axel.Nennker at telekom.de]
*Sent:* Friday, November 11, 2011 3:07 AM
*To:* Mike Jones; ve7jtb at ve7jtb.com; sakimura at gmail.com
*Cc:* openid-specs-ab at lists.openid.net
*Subject:* RE: [Openid-specs-ab] Audience restriction of
access_token/resource ep response in OpenID Connect



Why should we favour one of the four listed countermeasures?

http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.6.4



Does the Oauth Spec favour one?



Shouldn’t we concentrate on Connect specific threats and let the developer
handle the oauth threats as suggested by the oauth countermeasures? Or does
the Connect-Binding of Oauth lead to favouring one countermeasure?







*From:* openid-specs-ab-bounces at lists.openid.net
[mailto:openid-specs-ab-bounces at lists.openid.net] *On Behalf Of *Mike Jones
*Sent:* Freitag, 11. November 2011 05:37
*To:* John Bradley; Nat Sakimura
*Cc:* openid-specs-ab at lists.openid.net
*Subject:* Re: [Openid-specs-ab] Audience restriction of
access_token/resource ep response in OpenID Connect



Section 4.6.4 of the OAuth Threat Model and Security
Considerations<http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01>document
contains the following.   The highlighting is mine:





*4.6.4**.  Threat: Access token phishing by counterfeit resource server*



   An attacker may pretend to be a particular resource server and to

   accept tokens from a particular authorization server.  If the client

   sends a valid access tokens to this counterfeit resource server, the

   server in turn may use that token to access other services on behalf

   of the resource owner.



   Countermeasures:



   o  Associate the endpoint address of the resource server the client

      talked to with the access token (e.g. in an audience field) and

      validate association at legitimate resource server.  The endpoint

      address validation policy may be strict (exact match) or more

      relaxed (e.g. same host).  This would require to tell the

      authorization server the resource server endpoint address in the

      authorization process.



I believe we need to follow this recommendation and require an audience in
the access token on at least a SHOULD basis, per the decision on the
working group call today.  If anyone disagrees on security grounds, please
say why.



                                                            -- Mike



P.S.  Requiring encryption to restrict the audience seems like SUBSTANTIAL
overkill.



*From:* openid-specs-ab-bounces at lists.openid.net
[mailto:openid-specs-ab-bounces at lists.openid.net] *On Behalf Of *John
Bradley
*Sent:* Thursday, November 10, 2011 6:58 PM
*To:* Nat Sakimura
*Cc:* openid-specs-ab at lists.openid.net
*Subject:* Re: [Openid-specs-ab] Audience restriction of
access_token/resource ep response in OpenID Connect



With asymmetric keys putting it in the access token works.  This is a bit
like holder of key confirmation without the TLS.



There are a bunch of security issues with symmetric keys.

The protected resource has to be closely related to the authorization
server, as it can masquerade as the

Authorization server or the client with the shared secret.

You may also need to encrypt the token to the protected resource, otherwise
it too could leak and you pare back to square one.



John B.



On 2011-11-10, at 8:04 PM, Nat Sakimura wrote:



Hi.



Currently, as it turns out in OpenID Connect, the way to audience restrict

the response of a resource endpoint is to encrypt the response

using the key of the intended client. The server has to keep track of

to whom the access_token was issued, i.e., client audience restriction,

and use the registration information of that client to find out the
relevant key.



By doing so, even if the request comes from a rogue party who phished the

legitimate client, the rogue party cannot read the response, so it is
secure.



As to the resource endpoint audience restriction is concerned,

it is done implicitly in the sense that as the access_token is opaque,

only the intended endpoint can actually interprete and validate it.

This is how the resource endpoint audience restriction is done

in OAuth 2.0 as I understand.



As it is written right now, how to record both client and resource endpoint

audience restriction is an implementation detail.

I think it should remain implementation detail, but

it is worthwhile to note that somehow the audience restriction MUST be
done.

I am ok with RECOMMENDing that these audience to be encoded

in the access_token itself, but would like to let the implementors have

choices on it.



-- 
Nat Sakimura (=nat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111112/edf3a75b/attachment-0001.html>


More information about the Openid-specs-ab mailing list