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

[John Bradley <[e-mail]>]

The mitigation prevents the client from sending the code to a token endpoint that is not associated with the AS returning the code.

I think you need to describe a MiTM attack on the token endpoint that the proposed mitigation that was reviewed by the researchers doesn’t mitigate.

You seem to have defined some new attacks as not being the confused client attacks that you are trying to mitigate.

Perhaps not understanding the attack is causing some of us to not understand the value of the mitigation you propose.

John B.


 
> On Mar 18, 2016, at 8:19 PM, Phil Hunt <[e-mail]> wrote:
> 
> John,
> 
> I haven’t changed my mind. But I now think we’ve come away with a different understanding of the threats.
> 
> I recall that we agreed that “iss” and “client_id” are for mitigating mix-up, by allowing a client to figure out what token endpoint a grant is for.  There is nothing that helps a client to determine that the token endpoint it is about to use is valid.  IOW. The client could have the correct “iss” and “client_id” from the AS authorization endpoint, but it thinks it is supposed to pass the grant to token.evil.com <http://token.evil.com/> instead of token.example.com <http://token.example.com/> to redeem it.
> 
> Phil
> 
> @independentid
> www.independentid.com <http://www.independentid.com/>[e-mail] <mailto:[e-mail]>
> 
> 
> 
> 
> 
>> On Mar 18, 2016, at 4:01 PM, John Bradley <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> The Mitigation we agreed on for the bad token endpoint is returning the issuer and client_id form the authorization endpoint.
>> 
>> Phil are you saying that you no longer agree with that? 
>> 
>> The question that was unresolved was how the client would get a bad resource URI, and what the correct mitigation is if any.
>> 
>> John B.
>> 
>> 
>>> On Mar 18, 2016, at 7:52 PM, Phil Hunt <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> By convincing the client to use a bad URL.  That’s kinda why we’re worried about bad discovery no?
>>> 
>>> Depending on the type of client authentication, the client will establish a valid connection to the hacker’s proxy which then replays the token request to the real endpoint.  The hacker now has the token.
>>> 
>>> Same thing for the resource endpoint - except worse. The hacker doesn’t need the token as they now see the payload.
>>> 
>>> Phil
>>> 
>>> @independentid
>>> www.independentid.com <http://www.independentid.com/>[e-mail] <mailto:[e-mail]>
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Mar 18, 2016, at 3:38 PM, Brian Campbell <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> How does one Mitm the token endpoint?
>>>> 
>>>> On Fri, Mar 18, 2016 at 4: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>
>> 
>