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

John Bradley ve7jtb at ve7jtb.com
Sat Nov 12 14:56:02 UTC 2011


inline

On 2011-11-12, at 7:06 AM, Nat Sakimura wrote:

> 
> 
> 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).
>>  
>> 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. 

I agree, however we don't want to preclude the access token being used at other endpoints by Clients when it makes sense.

If PayPal wants to have a portable contacts endpoint they also make available when a client asks for a contacts scope, we don't want to preclude that.  It is the point of using OAuth, unless i missed something.

Perhaps adding something to Discovery to list the valid resource endpoints for access tokens issued by this issuer, is all we need.


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

We can say how you should do it with JWT, but requiring JWT tokens is too much.

> 
>> 
>>  
>>    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).
>>  
>> 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. 

I think adding a holder of key method would be useful in OAuth but may destroy the reason people want Bearer rather than MAC now.  This is a OAuth discussion.  

> 
>> 
>>  
>>    o  Restrict the token scope (see Section 5.1.5.1) and or limit the
>>       token to a certain resource server (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. 


I wasent on the call, but there are two separate issues.

1 Resource servers only taking tokens intended for them.  This is a MUST, we can recommend a method using JWT but others are allowed.

2. Clients not sending access tokens to the wrong endpoints.  Discovery could do this in a token independent way.


There are lots of reasons why the Authorization server may want to make the Access token a JWE.
Putting information for the client in the access token may be an optimization in some circumstances, but may break the general model if we depend on it.

John B.
> 
>> 
>>  
>>                                                                 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 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/12d64bd4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111112/12d64bd4/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list