Josh, I was curious how you secure the first step. If your client app is started by invoking a custom URL, what’s to stop the attacker using that and passing in https://attacker.com as the desired RS and audience?
Phil @independentid www.independentid.com [email protected] > On Mar 16, 2015, at 11:12 AM, Josh Mandel <[email protected]> wrote: > > Hi Phil, > > It might help me if you spelled out the phishing scenario you have in mind. > The key threat we're attempting to mitigate against with an "aud" param is: > > 1. Phishing link tells app to launch against RS at https://attacker.com > <https://attacker.com/> > 2. App queries https://attacker.com/metadata <https://attacker.com/metadata> > (this is a healthcare API called FHIR, which exposes server metadata) to > discover which authorization server to talk to. Attacker lies and tells app > to authorize at "https://my-real-hospital.com/authorize > <https://my-real-hospital.com/authorize>". > 3. App attempts to authorize against > "https://my-real-hospital.com/authorize?client_id=...&state=&...&aud=https://attacker.com > > <https://my-real-hospital.com/authorize?client_id=...&state=&...&aud=https://attacker.com>" > 4. The hospital's authorization server rejects the authorization request > because https://attacker.com <https://attacker.com/> is not a legitimate > resource server. > > Now you may be describing a different attacker where in step #2 the attacker > tells the app to authorize against "https://attacker.com/authorize > <https://attacker.com/authorize>", and this page asks a user to sign in with > her hospital credentials. That's indeed a phishing attack that we need > separate mitigation against. Happy to think through other mitigations on this > front, but it's a separate issue than what I was trying to address with this > thread. (Today our primary mitigation for this kind of phishing threat, where > attacker.com <http://attacker.com/> asks the user to enter her EHR > credentials, is user training.) > > -J > > On Mon, Mar 16, 2015 at 10:59 AM, Phil Hunt <[email protected] > <mailto:[email protected]>> wrote: > Josh, > > I’m not sure this helps. It seems to me, a phishing link could tell your app > to launch and pass in any RS value could it not? > > Phil > > @independentid > www.independentid.com <http://www.independentid.com/>[email protected] > <mailto:[email protected]> > >> On Mar 16, 2015, at 10:47 AM, Josh Mandel <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Torsten, >> >> You're absolutely correct. The implementation we're contemplating for SMART >> Platforms does indeed derive the "aud" parameter from the actual URL that >> the client used to communicate with the RS. Very briefly, the flow is: >> >> 1. Electronic Health Record system tells an app to launch, passing the app >> its RS endpoint as an issuer (iss) URL parameter. >> 2. App queries the RS's issuer URL to learn what AS to talk to >> 3. App contacts AS's authorize endpoint, passing an "aud" param that was the >> same as the issuer from step 1. >> 4. After obtaining a token, app talks to the RS using that token. >> >> -Josh >> >> >> On Mon, Mar 16, 2015 at 10:40 AM, Torsten Lodderstedt >> <[email protected] <mailto:[email protected]>> wrote: >> I don't think putting an aud into an AT will help to prevent counterfeit RSs >> (as long as the aud is nit directly derived from the original URL used by >> the client to invoke the counterfeit RS. as long as the aud is a symbolic >> name of any kind, the counterfeit RS will accept ATs for the legitimate RS >> and just (ab)use it. >> >> POP on the contrary helps since the counterfeit RS, in order to send a >> message to the legitimate RS, needs to produce a new digitally signed >> message using the correct secret, which it doesn't know. >> >> kind regards, >> Torsten. >> >> >> >> Am 16.03.2015 um 17:40 schrieb Dixie Baker <[email protected] >> <mailto:[email protected]>>: >> >>> Using the "aud" parameter makes sense to me. Good suggestion. >>> >>> Authenticating the client to the RS would not address the counterfeit RS >>> threat. >>> >>> -Dixie >>> >>> >>> Dixie B. Baker, Ph.D. >>> Senior Partner >>> Martin, Blanck and Associates >>> Office (Redondo Beach, CA): 310-791-9671 <tel:310-791-9671> >>> Mobile: 310-279-2579 <tel:310-279-2579> >>> On Mar 16, 2015, at 6:43 AM, Brian Campbell <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to help >>>> identify the RS to whom the AT should be issued. It is useful but it's >>>> mostly about getting format/content/etc of the AT correct for the RS >>>> rather than it is about preventing possible AT leaks. >>>> >>>> I do think an "aud(iance)" parameter at both token and authorization >>>> endpoints would have utility beyond the POP work. So defining it >>>> independently might make sense. >>>> >>>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> In POP key distribution we do introduce a "audiance" parameter to the >>>> token_endpoint. >>>> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1 >>>> >>>> <https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1> >>>> >>>> It would be possible to have a small spec to define using "aud" with >>>> bearer tokens, however that would be undefined behaviour at this point. >>>> >>>> I don't know of any clients that would try to access a RS server and then >>>> besed on the error response try and get a access token from the AS >>>> specified in the error. >>>> >>>> In POP we are trying to both protect agains that attack and more common >>>> ones like doing a MiM to intercept the AT or the RS being hacked and >>>> leaking the token. >>>> >>>> Using "aud" with bearer tokens would be useful, but probably won't stop >>>> the majority of possible AT leaks. >>>> >>>> John B. >>>> >>>> >>>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Hi Josh, >>>>> >>>>> I'm not aware of a common practice to use such a parameter. The WG is >>>>> instead heading towards authenticated requests to the resource server >>>>> (see https://tools.ietf.org/html/rfc6819#section-5.4.2 >>>>> <https://tools.ietf.org/html/rfc6819#section-5.4.2>). >>>>> >>>>> Please take a look onto >>>>> http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture >>>>> <http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture> and >>>>> further drafts on this topic. >>>>> >>>>> kind regards, >>>>> Torsten. >>>>> >>>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>>> Hi All, >>>>>> >>>>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource >>>>>> Server"), RFC6819 describes a threat where a counterfeit resource server >>>>>> tricks a client into obtaining and sharing an access token from a >>>>>> legitimate authorization server. One of the proposed mitigations >>>>>> involves: "telling the authorization server about the resource server >>>>>> endpoint URL in the authorization process." >>>>>> >>>>>> In other words, this mitigation would ask the client to pass an >>>>>> additional parameter when redirecting to the Authorization server's >>>>>> "authorize" URL, effectively something like: >>>>>> >>>>>> https://auth-server/authorize <https://auth-server/authorize>? >>>>>> response_type=code& >>>>>> client_id=123& >>>>>> state=456& >>>>>> scope=read-all& >>>>>> redirect_uri=https://app-server/after-auth&; >>>>>> <https://app-server/after-auth&;> >>>>>> resource_server_that_told_me_to_authorize_here=https://attacker.com >>>>>> <https://attacker.com/> >>>>>> >>>>>> (And if the authorization server saw a value it didn't like in the final >>>>>> parameter, it would reject the request.) >>>>>> >>>>>> This is obviously not appropriate in every authorization scenario, but >>>>>> it is useful anytime there's a discovery process by which apps learn >>>>>> about authorization servers from resource servers. Since it's something >>>>>> of a common need, I wanted to see if there was any common practice in >>>>>> how to name this parameter, or whether it's worth registering a standard >>>>>> extension at >>>>>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml >>>>>> <http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml> >>>>>> . (I don't see one there now -- possibly I'm just missing it.) >>>>>> >>>>>> If so, what should it be called? The name I used in the example above is >>>>>> a bit verbose :-) >>>>>> >>>>>> Best, >>>>>> >>>>>> Josh >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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> >>>> >>>> >>> >> >> _______________________________________________ >> 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
