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

[John Bradley <[e-mail]>]

Phil someone is giving the client the bad endpoints.  From the perspective of the client that is an AS.

I count that as two entities one good and one bad.

We agreed not to force clients to do discovery.  

How is the client being given this bad set of endpoints?

If it is being given them by dereferencing a issuer to get the .well-known then the mitigation will stop the attack because the two issuers can’t be the same unless the attacker has compromised the good AS’s .well-known, and that I would argue is a different problem.

John B.



> On Mar 18, 2016, at 8:28 PM, Phil Hunt <[e-mail]> wrote:
> 
> John
> 
> You are trying to solve a completely different problem.
> 
> In the bad discovery scenario there is no good AS and bad AS.
> 
> 1.  There is only one AS and one RS infrastrucutre
> 
> 2.  The client is mis-configured because it has been given a bad endpoint for one of dyn-reg, token, or resource
> 
> The client has no way to know what constitutes a valid set of endpoints.
> 
> The AS is acting in good faith in all respects.  It become promiscuous because it is turning over grants and/or tokens over to clients that are sending them to a bad endpoint.
> 
> Phil
> 
> @independentid
> www.independentid.com <http://www.independentid.com/>[e-mail] <mailto:[e-mail]>
> 
> 
> 
> 
> 
>> On Mar 18, 2016, at 4:16 PM, John Bradley <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 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] <mailto:[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] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>