Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"

[John Bradley <[e-mail]>]

You still have a good AS and a bad AS it is just that the bad AS is using the good AS’s authorization endpoint.

I guess it comes down to how you define what a AS is if it is malicious.

Remember all of the attacks postulated in the papers require a xsrf attack or man in the network to cause a client to start a authorization with the bad AS triggering bad discovery and registration.

If the bad AS is publishing a malicious RS and the “good” registration, authorization, and token endpoints.   It will have a different issuer from the 
good AS authorization endpoint.   When the client performs authorization thinking it is going to bad AS and gets back the issuer for good AS that will trigger an error in the client and it will never present the AT to the bad RS’s resource endpoint.

If the developer hard codes some bad RS endpoint in the client then, I admit returning the iss and client_id from the authorization endpoint won’t help.

John B.


> On Mar 18, 2016, at 7:27 PM, Phil Hunt (IDM) <[e-mail]> wrote:
> 
> There are two variations. 
> 
> Mitm the token endpoint is different then working one legit token endpoint against another thru redirect and state misdirection. 
> 
> In the mitm version you don't need multiple AS's.
> 
> Phil
> 
> On Mar 18, 2016, at 15:04, Brian Campbell <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated by returning an identifier for the AS in the authorization response. It is something that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access tokens tokens don't help.
>> 
>> Maybe that's obvious but there seems to be a lot of confusion on all this so I wanted to reiterate it.
>> 
>> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher <[e-mail] <mailto:[e-mail]>> wrote:
>> Goals:
>> 
>> 1. Help the client not send a token to the "wrong" endpoint
>>    a. wrong AS /token endpoint
>>    b. evil RS endpoint(s)
>> 2. Allow good RS to determine if the token being validated was intended for that RS
>> 
>> Other high-level goals?
>> 
>> Use cases:
>> 
>> 1. RS that supports multiple AS (we've had this in production since 2011)
>> 2. RS rejects token not issued for use at the RS
>> 3. Client that dynamically supports new RS (say any client that supports the jabber API)
>> 4. Client that dynamically supports new AS
>> 
>> Feel free to add to the list :)
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth