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 <[email protected]> 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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> Or by OAuth 2 PoP. >> >> >>> On Mar 17, 2015, at 6:00 PM, Bill Mills <[email protected] >>> <mailto:[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] >>> <mailto:[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
