I also drafted a more generalized mechanism (that was much less WS-*-y) for doing an arbitrary token swap:
https://tools.ietf.org/html/draft-richer-oauth-chain-00 <https://tools.ietf.org/html/draft-richer-oauth-chain-00> Phil had pretty much the same idea separately. Personally, I still think that the token-exchange draft needs to use a syntactical mechanism like this instead of something so strictly tied to the assertion formats. — Justin > On Mar 17, 2015, at 8:28 PM, John Bradley <ve7...@ve7jtb.com> wrote: > > Security Token Service (STS) Sorry it is WS-* speak > http://en.wikipedia.org/wiki/Security_token_service > <http://en.wikipedia.org/wiki/Security_token_service> > > You can emulate some of it with the assertions extension. > > The WG has a document as a starting position for a more general approach. > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 > <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01> > > > Brian Campbell and I also documented our take on it for discussion. > https://tools.ietf.org/html/draft-campbell-oauth-sts-01 > <https://tools.ietf.org/html/draft-campbell-oauth-sts-01> > > At the moment they don't really take into account issuing PoP tokens in > exchange but I expect that would be added as a WG document progresses. > > It is on the WG to do list. > > John B. > >> On Mar 17, 2015, at 8:01 PM, Bill Mills <wmills_92...@yahoo.com >> <mailto:wmills_92...@yahoo.com>> wrote: >> >> STS? >> >> >> >> On Tuesday, March 17, 2015 2:40 PM, John Bradley <ve7...@ve7jtb.com >> <mailto:ve7...@ve7jtb.com>> wrote: >> >> >> This is fun:) >> >> I might ask what part of a OAuth 1.0a token is the user credential. That >> is a slippery idea in itself. The token is a reference to some notion of >> identity (in some cases) that needs to be dereferenced anyway. >> >> So in the same way a POP JWT access token in OAuth 2 that may indeed contain >> claims about the subject would need to be exchanged at a AS for a new token >> containing claims about the subject and the new presenter, or depending on >> the security model it could be included directly in a new self signed AT. >> >> From a enterprise policy point of view having a REST like STS functionality >> is I think the right long term answer. >> >> John B. >> >> >> >>> On Mar 17, 2015, at 6:32 PM, Bill Mills <wmills_92...@yahoo.com >>> <mailto:wmills_92...@yahoo.com>> wrote: >>> >>> In practice one of the drawbacks of the Oauth 1.0a tokens was that they >>> were not proxyable and so a connection to the edge then means you have to >>> unwrap that and make a new internal token to be usedwhich isn't as good as >>> the actual user credential. >>> >>> >>> >>> On Tuesday, March 17, 2015 2:26 PM, John Bradley <ve7...@ve7jtb.com >>> <mailto:ve7...@ve7jtb.com>> wrote: >>> >>> >>> PoP tokens need to be presented with a proof the presenter knows the >>> secret. That is the same principal as in OAuth 1.0a with needing to show >>> knowledge of the "token secret". >>> >>> I don't know what you mean by proxies internally. If the RS needs another >>> token to access a resource it should use the assertion flow and >>> authenticate itself to get another token based on the access token. >>> Passing around a PoP token as a bearer token is insecure/bad. >>> >>> In OAuth 1.0a because of the tight relationship between the "Service >>> Provider" and the "Protected Resource" people would be less likely to try >>> it but because the protected resource knows the "token secret" it could >>> still do lots of unexpected bad things. >>> >>> Proxying access tokens is not something RS should do, they need to be >>> exchanged at a AS for a new AT with the correct rights and optionally >>> binding it to a new PoP key. >>> >>> John B. >>> >>> >>> >>> On Mar 17, 2015, at 6:14 PM, Bill Mills <wmills_92...@yahoo.com >>> <mailto:wmills_92...@yahoo.com>> wrote: >>>> >>>> Yes. There's still the open question of whether/how PoP tokens can be >>>> proxied internally within a site though. If they can be proxied then it >>>> goes back to unsolved. >>>> >>>> >>>> >>>> On Tuesday, March 17, 2015 2:12 PM, John Bradley <ve7...@ve7jtb.com >>>> <mailto:ve7...@ve7jtb.com>> wrote: >>>> >>>> >>>> Or by OAuth 2 PoP. >>>> >>>> >>>>> On Mar 17, 2015, at 6:00 PM, Bill Mills <wmills_92...@yahoo.com >>>>> <mailto:wmills_92...@yahoo.com>> 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 <ve7...@ve7jtb.com >>>>> <mailto:ve7...@ve7jtb.com>> 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 <wmills_92...@yahoo.com >>>>>> <mailto:wmills_92...@yahoo.com>> 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 <ve7...@ve7jtb.com >>>>>> <mailto:ve7...@ve7jtb.com>> 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 <wmills_92...@yahoo.com >>>>>>> <mailto:wmills_92...@yahoo.com>> 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 <ve7...@ve7jtb.com >>>>>>> <mailto:ve7...@ve7jtb.com>> 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 >>>>>>>> <dixie.ba...@martin-blanck.com <mailto: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> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 > https://www.ietf.org/mailman/listinfo/oauth
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
