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 <[email protected]> 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/>[email protected] > <mailto:[email protected]> > > > > > >> On Mar 18, 2016, at 4:01 PM, John Bradley <[email protected] >> <mailto:[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 >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
