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 instead of token.example.com to redeem it. Phil @independentid www.independentid.com <http://www.independentid.com/>[email protected] <mailto:[email protected]> > On Mar 18, 2016, at 4:01 PM, John Bradley <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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/>[email protected] >> <mailto:[email protected]> >> >> >> >> >> >>> On Mar 18, 2016, at 3:38 PM, Brian Campbell <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> How does one Mitm the token endpoint? >>> >>> On Fri, Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
