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]> 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] > 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
