Or by OAuth 2 PoP.
> On Mar 17, 2015, at 6:00 PM, Bill Mills <[email protected]> wrote: > > "Yes but it is custom. People are inventing structured scopes like > "aud:https://foo.com <http://foo.com/>", and that potentially doesn't solve > the security issue if a client just passes on the scopes it receives in the > error response, the bad RS just adds a scope for the good RS." > > This isn't solved by "aud", it is solved by OAuth 1.0a though.... > > > > > On Tuesday, March 17, 2015 1:54 PM, John Bradley <[email protected]> wrote: > > > Yes but it is custom. People are inventing structured scopes like > "aud:https://foo.com <http://foo.com/>", and that potentially doesn't solve > the security issue if a client just passes on the scopes it receives in the > error response, the bad RS just adds a scope for the good RS. > > The client then potentially needs to understand the custom structures scopes > of every AS it might deal with. > > I think that would lead to lots of problems trying to make that a pattern > long term. At teh moment yes you can do it with a scope as long as the > client and AS both understand what is going on. > > > We added "aud" as a separate parameter for PoP as the token format for > different RS might be different as well as the symmetric pop keys needing to > be encrypted with different keys. > Yes we could have invented a special scope to carry the audience but a > separate parameter was much cleaner. > > I know some people have started using "aud" as a way to communicate the > resource when a scope applies to multiple RS but they may take different > token formats JWT vs opaque etc. > > Brian commented that the "aud" parameter may be useful beyond PoP so we might > want to think about documenting it in it's own mini spec, if I understood him > correctly. > > I think that may not be a bad idea as we are also planning on using it in > NAPPS. > > John B. > >> On Mar 17, 2015, at 5:39 PM, Bill Mills <[email protected] >> <mailto:[email protected]>> wrote: >> >> I don't think it's "overloading scope names" to use them that way. The aud >> value(s) could as easily be carried in scope as anywhere. Nothing says a >> scope can't be "https://foo.com <https://foo.com/>", and that Foo.com >> <http://foo.com/> requires that scope to be present for a token to be >> accepted. I would not make it foo.com <http://foo.com/>-read-mail for >> example. >> >> If it's more convenient to put it in aud I can accept that, but it's the >> same functionality and can be implemented in scopes now. >> >> >> >> On Tuesday, March 17, 2015 12:41 PM, John Bradley <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> People have been overloading scope names to create implicit audience. >> >> The problem is that clients need to know via some magic method that you need >> to ask for scope "purple" to get write access to RS 2. >> >> Having an explicit "aud" parameter gives clients a way to communicate to the >> AS what RS they are asking for a token for. >> >> the security issue is that if a client discovers a API out via some out of >> band mechanism the OAuth error code can tell the client go to AS X and ask >> for Scope Y. >> >> Unfortunately without POP tokens or at-least passing the URI of the RS to >> the AS via "aud", a bad RS could get a legitimate client to give it a token >> that can be replayed at a legitimate RS. >> >> This was one of the issues that Eran Hammer-Lahav was particularly concerned >> about. >> >> I think I proposed a "aud" parameter to the token endpoint back then as a >> alternative to requiring HMAC tokens, but that got lost in the confusion at >> the time. >> >> At that time though people were not yet thinking about interoperable OAuth >> API, only relatively tightly bound clients that were preconfigured for the >> API endpoints they were using. >> >> In Health and other places we are starting to see standard clients that >> discover API endpoints and configure themselves based on a users Identity to >> use a arbitrary OAuth AS, moving into federation of AT. >> >> That is one of the reasons POP will be important, as it prevents RS from >> misusing federated tokens by presenting them at other RS. >> >> The simplest thing to do is have the client say what RS it is trying to >> access explicitly (The "aud" parameter), and including an audience in the >> AT. to protect against malicious RS. >> >> PoP is the step up that also protects against tokens being intercepted and >> replayed by another client. >> >> John B. >> >>> On Mar 17, 2015, at 4:10 PM, Bill Mills <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> This may have been hashed out already and I missed it, but "aud" just >>> becomes another kind of scope, correct? >>> >>> >>> >>> >>> On Tuesday, March 17, 2015 8:50 AM, John Bradley <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[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 >>> Mobile: 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> >>> >>> >> >> >> > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
