You could do that, but it is probably safer for the AS to know what RS it can issue tokens for and refuse to issue a token for RS A to a client asking for a token with RS X as the aud.
John B. > On Mar 16, 2015, at 8:27 PM, Dixie Baker <dixie.ba...@martin-blanck.com> > wrote: > > The threat that RFC6819 4.6.4 describes is when a client obtains an AT and > then sends it to a counterfeit RS, which then uses the AT to access resources > from a legitimate RS, on the end-user's behalf. > > The suggested countermeasure is a bit difficult to interpret: "Associate the > endpoint URL of the resource server the client talked to with the access > token (e.g., in an audience field) and validate the association at a > legitimate resource server. The endpoint URL validation policy may be strict > (exact match) or more relaxed (e.g., same host). This would require telling > the authorization server about the resource server endpoint URL in the > authorization process." > > As I read this, the suggestion is to have the client pass the URL of the bad > RS in the request to the AS (using the audience field). The AS then would > include that RS URL in the AT. Then, when the client passes the AT to the > bad RS, and it passes it on to the good RS, the good RS will check the > audience field, compare that URL with its own, and refuse the request. > > -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 11:39 AM, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> wrote: > >> Brian and I were talking about "aud" used as a parameter to the token >> endpoint when using a code or refresh token to indicate what RS the >> resulting AT will be used at. >> >> Sending a audience in the AT wouldn't help prevent the attack being >> discussed, though it may stop other sorts of attacks if the RS can tell if >> a AT was issued for it or another RS. >> >> In PoP having the AS check that you are sending the AT to the correct RS is >> less important as the AT if stolen can't be used to replay against the real >> AS. >> >> Though depending on the app the bogus RS feeding the app the wrong info may >> well be a problem as well. >> >> John B. >> >>> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <tors...@lodderstedt.net >>> <mailto: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 >>> <mailto: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 >>>> <mailto: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 >>>>> <mailto: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 >>>>> >>>>> <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 <mailto: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 >>>>>> <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 >>>>>>> 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 >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>> >>>>> >>>> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
