Therefore, the client has an understanding of the protocol of the RS and can possibly discover related endpoints (what webfinger was really designed for) but it can't support some random new protocol. As I wrote in my response to John Bradley, I believe audience binding should use an abstract identifier not an API endpoint.
Thanks, George On 3/15/16 11:40 AM, Phil Hunt wrote:
Regarding 2.The bound config spec makes no such requirement of knowing the and its path structure.If you feel that you have other security measures and that clients will always have the proper AS, then you can wildcard the whole resource parameter. It still might be advisable to at least check that your clients are using a URL of the form https://*.aol.com/* or https://*.partner.com/*.The benefit is that at least you know the client is intending to wield the token somewhere in your domain or your partner’s domain. as opposed to something like news.aol.myevildomain.com <http://news.aol.myevildomain.com>.The difference here is that security remains the responsibility of the service provider in all cases. The check is up to the service provider rather than the client. This means that we don’t have to rely on trusting that the client developer bothered to check the configuration (as in other proposals that modify OAuth protocol itself) — we know well they won’t because they won’t have to. The server side validation is trivial. I’m not sure how much easier this can be.Phil @independentid www.independentid.com <http://www.independentid.com> phil.h...@oracle.com <mailto:phil.h...@oracle.com>On Mar 15, 2016, at 8:09 AM, George Fletcher <gffle...@aol.com <mailto:gffle...@aol.com>> 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 unambiguouslyHans. 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 reallygot 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 thathave been bandied about a few times, including in the current tokenexchange document. We should be consistent across drafts in that regard. The second is more traditional scope-ish. The third has been patched inwith 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. — JustinOn Mar 14, 2016, at 6:26 PM, John Bradley <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>> wrote: Yes I will work on another proposal for allowing clients to specifywhat resource they want a token for and providing the meta-data to theclient about the resources that a token is valid for. We have part of it in the POP key distribution spec and talked aboutseparating 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) <phil.h...@oracle.com <mailto:phil.h...@oracle.com>> wrote: Inline Phil On Mar 14, 2016, at 14:13, John Bradley <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>> 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 wasto do the latter without requiring the former for clients that don’totherwise need discovery.There is no mandate for any of this. Seehttp://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txtReturning 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 agreeOne 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 butthat 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 ownerare. 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 aclient chooses evil.com <http://evil.com> <http://evil.com/> the cert can be valid andTLS will pass. How does it otherwise know it is supposed to talk to res.example.com <http://res.example.com> <http://res.example.com/>?Your proposal requires rhe client to check. I am not clear how the ASIf this is added to the token endpoint it would be checked when codeor refresh are exchanged, not every time the token is used.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 couldrequire 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 wrongRS endpoint.If you check out of band in discovery you really have no idea if theclient 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 <phil.h...@oracle.com <mailto:phil.h...@oracle.com>> 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 doesin 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 checkbefore 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 ofOIDC's discovery spec because the UserInfo endpoint is well definedand 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 anoauth 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 particularlytrue at the Germany meeting when this came up. This is why I preferthe client tell the service provider what it intends to do and theservice provider can fail that request immediately if necessary. Wedon’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 protocolflows 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 itselfis simple and has only one parameter. Here we are not consideredabout 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/> phil.h...@oracle.com <mailto:phil.h...@oracle.com>On Mar 13, 2016, at 10:28 PM, Mike Jones<michael.jo...@microsoft.com <mailto:michael.jo...@microsoft.com>>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 normativecontent of the draft) are clearly ready for standardization, sinceeven 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, ratherthan as an https-protected resource published by the authorizationserver. 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 theAS 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:oauth-boun...@ietf.org]*On Behalf Of*John Bradley*Sent:*Sunday, March 13, 2016 6:45 PM*To:*Phil Hunt <phil.h...@oracle.com <mailto:phil.h...@oracle.com>>*Cc:*oauth <oauth@ietf.org <mailto:oauth@ietf.org>> *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 trythe 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 upclient 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 tothe 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 <phil.h...@oracle.com <mailto:phil.h...@oracle.com>> wrote: This draft is a proposed alternate proposal for draft-ietf-oauth-discovery. As such, it contains the sameregistry for OAuth Config Metadata as the authors believe that both solutions are not required, or depending on WG discussionthey 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 authorizationserver that can issue tokens for the resource URI specified bythe client. The AS is not required to be in the same domain.The AS is however required to know if it can issue tokens fora 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 broaderdiscovery problem before proceeding with WGLC on OAuth Discovery.Thanks! Phil @independentid www.independentid.com <http://www.independentid.com/> phil.h...@oracle.com <mailto:phil.h...@oracle.com> Begin forwarded message:*From:*internet-dra...@ietf.org <mailto:internet-dra...@ietf.org><mailto:internet-dra...@ietf.org> *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" <phil.h...@yahoo.com <mailto:phil.h...@yahoo.com>>, "Anthony Nadalin" <tony...@microsoft.com <mailto:tony...@microsoft.com>>, "Tony Nadalin" <tony...@microsoft.com <mailto:tony...@microsoft.com>>A new version of I-D, draft-hunt-oauth-bound-config-00.txt has been successfully submitted by Phil Hunt and posted to theIETF 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 ofan 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 availableattools.ietf.org <http://attools.ietf.org> <http://tools.ietf.org/>.The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth_______________________________________________ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth_______________________________________________ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
-- Chief Architect Identity Services Engineering Work: george.fletc...@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
