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 2. App queries 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";. 3. App attempts to authorize against " 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 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";, 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 asks the user to enter her EHR credentials, is user training.) -J On Mon, Mar 16, 2015 at 10:59 AM, Phil Hunt <phil.h...@oracle.com> 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 > phil.h...@oracle.com > > On Mar 16, 2015, at 10:47 AM, Josh Mandel <jman...@gmail.com> 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 < > tors...@lodderstedt.net> 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 <dixie.ba...@martin-blanck.com >> >: >> >> 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 >> Mobile: 310-279-2579 >> >> On Mar 16, 2015, at 6:43 AM, Brian Campbell <bcampb...@pingidentity.com> >> 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 <ve7...@ve7jtb.com> 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 >>> >>> 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 < >>> tors...@lodderstedt.net> 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). >>> >>> Please take a look onto >>> 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? >>> response_type=code& >>> client_id=123& >>> state=456& >>> scope=read-all& >>> redirect_uri=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 >>> . (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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
