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/>phil.h...@oracle.com <mailto:phil.h...@oracle.com> > On Mar 18, 2016, at 4:01 PM, John Bradley <ve7...@ve7jtb.com> 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 <phil.h...@oracle.com >> <mailto:phil.h...@oracle.com>> 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/>phil.h...@oracle.com >> <mailto:phil.h...@oracle.com> >> >> >> >> >> >>> On Mar 18, 2016, at 3:38 PM, Brian Campbell <bcampb...@pingidentity.com >>> <mailto:bcampb...@pingidentity.com>> wrote: >>> >>> How does one Mitm the token endpoint? >>> >>> On Fri, Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) <phil.h...@oracle.com >>> <mailto:phil.h...@oracle.com>> 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 <bcampb...@pingidentity.com >>> <mailto:bcampb...@pingidentity.com>> 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 <gffle...@aol.com >>>> <mailto:gffle...@aol.com>> 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 >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
