If the client specifies the desired audience(s)/resource(s), is that metadata to the client needed? The AS can audience restrict the token as needed or respond with an error if it can't or wont issue a token for the resource the client asked for.
On Tue, Mar 15, 2016 at 9:37 AM, John Bradley <[email protected]> wrote: > Yes, I think bearer tokens with no audience are a bad idea. > > The AS needs to infer an audience from the scopes snd/or have the client > specify the desired audience. > > If the AT has a audience or audiences then as long as the endpoint URI are > provided as meta-data with the token, the client can determine if it is > sending the token to the correct place. > > I think Phil would prefer the server rather than the client do the check, > but the client always needs to take some responsibility to not leak tokens > giving them to the wrong RS or the code to the wrong token endpoint is > leaking. > > I imagine that claims based access tokens are going to become more popular > and the static relationship between one RS and one AS will not be the > majority of deployments over time. > > In any case where the client is configured up front to know the RS and the > AS it seems like that would not require Phil’s Solution, but that is the > only case supported by that discovery. > > If the client itself is bad there is not much you can do to stop it from > passing on the AT in way way it wants. That however is a different problem > and needs claimed URI or attestations to prevent client spoofing. > William and I are working on that in the mobile best practices draft. > > John B. > > > On Mar 15, 2016, at 12:09 PM, George Fletcher <[email protected]> wrote: > > I worry about two directions I see in this thread... > > 1. Client's accessing resources dynamically so that discovery is required > to know the correct AS, etc. This is pretty much the classic use case for > UMA and I'd rather not re-invent the wheel. > > 2. Creating a tight coupling between RS and AS such that RS endpoint > changes must be continually communicated to the AS. If an RS supports > multiple AS's then the RS has to deal with "guaranteed" delivery. The AS > needs an endpoint to receive such communications. If not dynamic via APIs, > then deployment of the new RS is bound by the associated AS's getting and > deploying the new endpoints. Can both endpoints of the RS be supported > within the AS for some period of time, etc. This is an operation nightmare > and almost assuredly going to go wrong in production. > > Maybe an OAuth2 "audience binding" spec is what's needed for those > deployments that require this. I believe that is what John Bradley is > suggesting. > > Thanks, > George > > On 3/14/16 7:29 PM, Hans Zandbelt wrote: > > +1, I've found the very same in OAuth deployments that I was involved in; > the hard part is to give names and descriptions to these concepts so that > they cover all use cases and can be applied unambiguously > > Hans. > > On 3/14/16 10:44 PM, Justin Richer wrote: > > I agree that this is valuable, and not just for PoP. In all honesty, > it’s not even really required for PoP to function in many cases — it’s > just an optimization for one particular kind of key distribution > mechanism in that case. > > In the years of deployment experience with OAuth 2, I think we’ve really > got three different kinds of things that currently get folded into > “scope” that we might want to try separating out better: > > > - What things do I want to access? (photos, profile) > - What actions do I want to take on these things? (read, write, delete) > - How long do I want these tokens to work? > (offline_access/refresh_token, one time use, next hour, etc) > > > I think the first one is close to the audience/resource parameters that > have been bandied about a few times, including in the current token > exchange document. We should be consistent across drafts in that regard. > The second is more traditional scope-ish. The third has been patched in > with things like “offline_access” in certain APIs. > > Just another vector to think about if we’re going to be adding things > like “audience” or “resource” or both to the token requests. > > — Justin > > > On Mar 14, 2016, at 6:26 PM, John Bradley <[email protected] > <mailto:[email protected]> <[email protected]>> wrote: > > Yes I will work on another proposal for allowing clients to specify > what resource they want a token for and providing the meta-data to the > client about the resources that a token is valid for. > > We have part of it in the POP key distribution spec and talked about > separating it, as it is used more places than just for assigning keys. > I know some AS use different token formats for different RS so are > all-ready needing to pass the resource in the request to avoid making > a mess of scopes. > > John B. > > > > > > On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) <[email protected] > <mailto:[email protected]> <[email protected]>> wrote: > > Inline > > Phil > > On Mar 14, 2016, at 14:13, John Bradley <[email protected] > <mailto:[email protected]> <[email protected]>> wrote: > > We had two mandates. One was to provide a spec for AS metadata. > The other was to mitigate the client mixup attack. The request was > to do the latter without requiring the former for clients that don’t > otherwise need discovery. > > There is no mandate for any of this. See > http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt > > > Returning the issuer and client_id from the authorization endpoint > and the client checking them can be done by the client without > discovery. > > > How does this address the issue of whether the client is talking to > the wrong endpoint? > > > Any client that has the resource and issuer hard coded probably > doesn’t need discovery. > > We agree > > > One of the things that a client will need discovery for is to find > the RS, so requiring the client to know the RS URI before getting > the AS config seems backwards to me. > > How can you make an assumption on order? You seem to be conflating > authentication with authorization by assuming the identity drives > what the resource is. > > There are lots of applications that require user rights but are not > identify centric. For example a document service. > > > Unless the client tells the AS where it intends to use the token we > will be leaving a security hole because the bearer tokens will have > too loose an audience if they have one at all. > > This is the biggest risk we have IMHO. > > > True you are telling the AS (Webfinger service) what the RS is but > that is not at a place that is useful in the token production process. > > > This has nothing to do with token production. > > What we want to ensure is whether an honest client is correctly > configured and has not been mislead - eg by a phishing page. > > > I also think there are use cases where the AS doesn’t know all the > possible RS. That is not something that a out of band check can > address. > > > May be. Lets identify them. > > There are also cases where a token might be good at multiple RS > endpoints intentionally. > > > In your solution the client would need to make a discovery request > for each endpoint. > > Sure. Otherwise how would it know if there is one AS or a pool of AS > servers assigned to each instance? > > Those requests lack the context of who the client and resource owner > are. I think that will be a problem in some use cases. > > > Not sure I agree. This is about discovering a valid set of endpoints. > For mitm, we mainly want to check the hostname is correct. If a > client chooses evil.com <http://evil.com/> <http://evil.com/> the cert > can be valid and > TLS will pass. How does it otherwise know it is supposed to talk to > res.example.com <http://res.example.com/> <http://res.example.com/>? > > > If this is added to the token endpoint it would be checked when code > or refresh are exchanged, not every time the token is used. > > Your proposal requires rhe client to check. I am not clear how the AS > can know the exact uri. It is far easier to validate than to lookup > since as you say the client may be authorized to use multiple ASs. > > With a out of band check the client would never know if a RS was > removed/revoked. > > > Not sure that is in scope. > > None of the current proposals address this issue. > > > I don’t see checking when refreshing a token as something that is a > huge burden. > > > Still its a lot more than once. > > Why don't you draft another alternative? > > > If the server wants to do the check on it’s side then we could > require the client to send the RS URI in the token request. that way > you really know the client is not going to get a token for the wrong > RS endpoint. > If you check out of band in discovery you really have no idea if the > client is checking. > > > In the new webfinger draft, the client isn't checking. The service > provider simply does not disclose oauth information to misconfigured > clients. > > > John B. > > > On Mar 14, 2016, at 3:56 PM, Phil Hunt <[email protected] > <mailto:[email protected]> <[email protected]>> wrote: > > Thanks to Mike and John for their feedback. I’ll take each in turn: > > Mike, > > Regarding your suggested amendments > > Item 1: Returning the config URL would create two problems. One,it > makes bound discovery a two-step process - that adds complexity. > It seems far simpler to mandate TLS (which I think it already does > in the security considerations). > > The two-step process allows the current discovery process to > continue. I disagree with this. This is why I put forward an > “alternate" draft that is almost the same but simply adds the check > before returning the configuration data. I worry that developers > would have no incentive to do the two-step approach. They would > just start at step 2 which in turn puts AS’s at risk of exposing > tokens because it works. This makes OAuth promiscuous. > > Regarding existing implementations. Most of those implementations > are for OIDC. I think it makes sense for OIDF to continue use of > OIDC's discovery spec because the UserInfo endpoint is well defined > and the likelihood of a client mis-informed about the resource > endpoint is not there. IMO This does not apply to the broader > OAuth community. > > Item 2: It may be appropriate to have a separate configuration > registry specification, but I think we should hold off until we > have a complete solution and then make the decision what drafts > should exist and how many pieces. A big concern is the perceived > complexity of multiple solutions and multiple drafts. > > As to John Bradley’s comments: > > Re: Discovery is the wrong place to mitigate threats. > I’m confused by this. Our mandate was to solve a security threat > by having a discovery specification to prevent clients being > mis-lead about endpoints (of which resource service is one) in an > oauth protected exchange. Maybe what you mean is we should not use > .well-known of any kind and we should just create a “/Config” > endpoint to OAuth? > > Re: Your proposal for MITM mitigation > You propose that instead the resource endpoint check should be in > the oauth protocol itself. The difference is that validation is > transferred back to the client to get it right. As well, without > the client informing the AS, I can’t see a way for the AS to know > what endpoint the client is using. The webfinger approach does > this once and only requires that the host name be checked in many > cases. > > As a principle, the members have discussed many times that the AS > service should do validation when possible — this was particularly > true at the Germany meeting when this came up. This is why I prefer > the client tell the service provider what it intends to do and the > service provider can fail that request immediately if necessary. We > don’t have to depend on the developer getting the spec correct to > fail the correct way. > > I worry that adding more parameters to the authz and token protocol > flows increases complexity and attack surface. It also means per > authorization validation has to take place vs. a one-time > validation at config time. Placing it in the configuration lookup > phase (whether via web finger or just a special OAuth endpoint) > seems more appropriate and far less complex - as the request itself > is simple and has only one parameter. Here we are not considered > about legitimacy of the client. we’re just concerned with the issue > "has the client been correctly informed?” > > That said, it may be that when we consider all the use cases, some > combination of AS protocol and discovery may be both needed. I’m > not ready to make conclusions about this. The current > oauth-discovery spec seems to put future generic clients at risk > and that is my primary concern. > > Best Regards, > > Phil > > @independentid > www.independentid.com <http://www.independentid.com/> > <http://www.independentid.com/> > [email protected] <mailto:[email protected]> <[email protected]> > > > > > > On Mar 13, 2016, at 10:28 PM, Mike Jones > <[email protected] <mailto:[email protected]> > <[email protected]>> > wrote: > > Thanks for posting this, Phil. It provides a concrete example of > a way that protected resource discovery could be added to > authorization server metadata discovery, and as such, should > provide useful input for working group discussions on this topic. > It’s always great when someone takes the time to write an actual > draft that can be examined and implemented, and I appreciate you > doing that. > The content of your draft points out that there appears to be > complete agreement on what the authorization server metadata > format should be, which is great! I’ll note that Section 3 of > draft-hunt-oauth-bound-config-00 titled “Authorization Server > Metadata” is an exact copy of Section 2 of > draft-ietf-oauth-discovery-01 (with the same title), modulo > applying a correction suggested by the working group. To me this > suggests that the authorization server metadata definitions in > draft-ietf-oauth-discovery (which is now the whole normative > content of the draft) are clearly ready for standardization, since > even your alternative proposal includes them verbatim. > Reading your draft, the problem I have with it is that you are > returning the AS metadata only as a WebFinger response, rather > than as an https-protected resource published by the authorization > server. The choice to only return this via WebFinger makes your > draft incompatible with most deployed implementations of OAuth > metadata, including the 22 implementations using it listed > athttp://openid.net/certification/(see the “OP Config” column in > the table) andOAuth 2.0 libraries such as Microsoft’s “ADAL” > library, which uses the metadata path for client configuration. > Without having ASs provide the metadata as an https-protected > resource, implementations such as ADAL can’t use it for client > configuration as the currently do. > Therefore, I would request that you make these minor revisions to > your draft and republish, so as to provide a unified way forward > that is compatible with all known existing OAuth Discovery > deployments: > 1.Modify your section 2 “Authorization Server WebFinger Discovery” > to have the WebFinger request return the issuer identifier for the > AS as the “WebFinger “rel” value, rather than returning the > metadata values by value as the “properties” value. > 2.Reference the metadata definitions from Section 2 of > draft-ietf-oauth-discovery, rather than duplicating them in your > Section 3. > That would have the advantage of paring your draft down to only > the new things that it proposes, enabling them to be more clearly > understood and evaluated on their own merits. I look forward to > the discussions of ways of performing additional kinds of OAuth > discovery, and consider your draft a valuable input to those > discussions. > Best wishes, > -- Mike > *From:*OAuth [mailto:[email protected] <[email protected]>]*On > Behalf Of*John Bradley > *Sent:*Sunday, March 13, 2016 6:45 PM > *To:*Phil Hunt <[email protected] <mailto:[email protected]> > <[email protected]>> > *Cc:*oauth <[email protected] <mailto:[email protected]> <[email protected]>> > *Subject:*Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-bound-config-00.txt > As I have told Phil off list. > Discovery is the wrong place to try and provide security against > man in the middle attacks on the RS. > This requires the client to know what the RS URI is before > retrieving the information on the AS Configuration. > The proposal Mike and I have been working on requires the client > to have a notion of what API it is looking for and retrieve the > .well-known file for that API from the issuer. That allows a > protocol like Connect to register its own config file that can > point to the RS. > If the API specific well known is not available the client can try > the default oauth-server one. > That then allows us to deal with restricting where AT are > presented as part of the protocol rather then dragging discovery > in as a requirement. > In my opinion the resource the token is targeted to should be > separated from the scope and returned as part of the meta-data > about the AT along with scopes granted and expiry time. We > should also have a input parameter for resources so that a client > can restrict tokens issued to a subset of the ones granted by the > refresh token. It would then also be possible to ask a AS for a > token for a unregistered RS and have the AS produce a JWT access > token with the resource as an audience if policy allows. > That however was supposed to be dealt with as part of the mixed up > client set of mitigations. > In that the goal was to mitigate the attacks by returning > meta-data about the tokens, and not to require discovery. > We intend to return “iss” and “cleint_id” for the code, and I > intend to discuss at the F2F returning resource for AT as well. > Those mitigate the attack. > I will continue to resist mixing up discovery of configuration > meta-data with mitigation of the attacks. > We return meta-data about the tokens now, because AT are opaque to > the client, we neglected to include some of the information for > the client needs to be secure. We just need to add that in to > the existing flows. > While Phil’s proposal is easier for the AS to implement as an add > on, it puts more of a burden on the client needing to potentially > change how it stores the relationships between AS and RS to > prevent compromise, I think the solution should be biased towards > simplicity on the client side. > If we return the resources as part of the existing meta data the > client checks that against the resource it intends to send the > token to and if it is not in the list then it can’t send the > token. Simple check every time it gets a new AT, no optionality. > I am not saying anything new Nat has been advocating basically > this for some time, and dis submit a draft. I prefer to return > the info in the existing format rather than as link headers, but > that is the largest difference between what Nat and I are saying > with respect to resource. > That is the core of my problem with Phil’s draft. > I guess we will need to have a long conversation in BA. > Regards > John B. > > On Mar 13, 2016, at 8:12 PM, Phil Hunt <[email protected] > <mailto:[email protected]> <[email protected]>> wrote: > This draft is a proposed alternate proposal for > draft-ietf-oauth-discovery. As such, it contains the same > registry for OAuth Config Metadata as the authors believe that > both solutions are not required, or depending on WG discussion > they will be merged. The intent is to provide a simple > complete draft for consideration. > How it works... > Given that a client has previously discovered an OAuth > protected resource, the bound configuration method allows a > client to return the configuration for an oauth authorization > server that can issue tokens for the resource URI specified by > the client. The AS is not required to be in the same domain. > The AS is however required to know if it can issue tokens for > a resource service (which presumes some agreement exists on > tokens etc). > The draft does not require that the resource exist (e.g. for > unconfigured or new user based resources). It only requires > that the AS service provider agrees it can issue tokens. > From a security perspective, returning the OAuth service > configuration for a specified resource URI serves to confirm > the client is in possession of a valid resource URI ensuring > the client has received a valid set of endpoints for the > resource and the associated oauth services. > I propose that the WG consider the alternate draft carefully > as well as other submissions and evaluate the broader > discovery problem before proceeding with WGLC on OAuth Discovery. > Thanks! > Phil > @independentid > www.independentid.com <http://www.independentid.com/> > <http://www.independentid.com/> > [email protected] <mailto:[email protected]> > <[email protected]> > > > Begin forwarded message: > *From:*[email protected] > <mailto:[email protected]> <[email protected]> > *Subject: New Version Notification for > draft-hunt-oauth-bound-config-00.txt* > *Date:*March 13, 2016 at 3:53:37 PM PDT > *To:*"Phil Hunt" <[email protected] > <mailto:[email protected]> <[email protected]>>, "Anthony > Nadalin" > <[email protected] <mailto:[email protected]> > <[email protected]>>, > "Tony Nadalin" <[email protected] > <mailto:[email protected]> <[email protected]>> > > > A new version of I-D, draft-hunt-oauth-bound-config-00.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. > > Name:draft-hunt-oauth-bound-config > Revision:00 > Title:OAuth 2.0 Bound Configuration Lookup > Document date:2016-03-13 > Group:Individual Submission > Pages:22 > URL: > > https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt > Status: > https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ > Htmlized: > https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 > > > Abstract: > This specification defines a mechanism for the client of > an OAuth 2.0 > protected resource service to obtain the configuration > details of an > OAuth 2.0 authorization server that is capable of > authorizing access > to a specific resource service. The information > includes the OAuth > 2.0 component endpoint location URIs and as well as > authorization > server capabilities. > > > > > Please note that it may take a couple of minutes from the > time of submission > until the htmlized version and diff are available > attools.ietf.org <http://tools.ietf.org/> <http://tools.ietf.org/>. > > > The IETF Secretariat > > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> <[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> <[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
