I'm staying that it's sufficiently unlikely that it shouldn't be part of the threat model and that a discovery lookup on iss isn't necessary.
On Tue, Jan 26, 2016 at 8:21 AM, George Fletcher <gffle...@aol.com> wrote: > While it's a different way of getting the endpoints mixed up, I don't > think that makes it invalid. If we are going to address the attack vector I > believe we should solve it for "all" cases not just the ones that seem most > likely. > > Thanks, > George > > On 1/26/16 8:37 AM, Brian Campbell wrote: > > I'm not sure what's described in the blog post is actually a variant of an > attack that anyone is really concerned about? A client developer would have > to change a production system to use an unfamiliar value for the token > endpoint based solely on a an email without even looking at service > documentation or metadata. > > > On Fri, Jan 22, 2016 at 6:29 PM, Nat Sakimura <sakim...@gmail.com> wrote: > >> I wrote a blog on why the current mix-up draft approach does not solve >> the issue. >> >> >> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/ >> >> Hopefully, the point I am making is clearer by this. >> >> Best, >> >> Nat >> >> 2016年1月23日(土) 8:32 Mike Jones < <michael.jo...@microsoft.com> >> michael.jo...@microsoft.com>: >> >>> I like the “from which the authorization server's configuration >>> information location can be derived” language. Thanks. I’ll plan to >>> incorporate that the next time the draft is revised. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* Brian Campbell [mailto: <bcampb...@pingidentity.com> >>> bcampb...@pingidentity.com] >>> *Sent:* Friday, January 22, 2016 3:26 PM >>> *To:* Nat Sakimura < <sakim...@gmail.com>sakim...@gmail.com> >>> *Cc:* Mike Jones < <michael.jo...@microsoft.com> >>> michael.jo...@microsoft.com>; Justin Richer <jric...@mit.edu>; < >>> oauth@ietf.org> <oauth@ietf.org> >>> >>> >>> *Subject:* Re: [OAUTH-WG] Call for Adoption >>> >>> >>> >>> I agree that the language describing OAuth issuer could and should be >>> improved. The text now reads like it is the exact and full URL where the >>> metadata/discovery document is located. Perhaps something more like "the >>> URL from which the authorization server's configuration information >>> location can be derived" and explain that adding the .well-known bits to >>> the issuer is where the configuration information can actually be found. >>> >>> >>> >>> On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura < <sakim...@gmail.com> >>> sakim...@gmail.com> wrote: >>> >>> Re: iss. I discussed this a bit with Nov in more details. It probably is >>> a sloppy language of the specs that is making it difficult to read what you >>> wanted to achieve. >>> >>> >>> >>> In mix-up-mitigation draft, OAuth issuer is "the URL of the >>> authorization server's configuration information location". In OAuth >>> discovery draft, there is something called "OAuth 2.0 Configuration >>> Information Location URL", which is equal to "OpenID Connect Issuer". >>> >>> When I wrote the statement, I thought you were pointing to the URL that >>> you can actually pull the configuration information by "the URL of the >>> authorizaiton server's configuration information location" since otherwise >>> you would have used the term "OAuth 2.0 Configuration Information Location >>> URL". But after all, you probably meant these two are the same. Then I >>> would strongly recommend to fix the language. >>> >>> Now, even If that is the case, the relationship like >>> >>> · iss + .well-know/openid-configuration = Connect OP config >>> endoint >>> >>> · OAuth config endpoint - .well-known/openid-configuration = >>> OAuth iss >>> >>> is very confusing. >>> >>> >>> >>> You also claim that your approach is simpler, but to me, your approach >>> seem to be overly complex. It requires discovery and the check for the >>> value of the discovered config information to work as the mitigation. >>> (Right. Draft -01 does not have it, so it does not solve the mix-up issue.) >>> With oauth-meta, you do not need it. >>> >>> >>> >>> Finally, your point that HATEOAS reminds you of WSDL, it is not. If you >>> want to have something similar to WSDL in REST API area, it is Swagger. >>> (Actually, it is gaining a lot of momentum recently, but that's beside the >>> fact ;-). And the point here is not the format but the fact that we need to >>> have a way to associate metadata to the data. The root cause of this mix-up >>> attack is that the metadata and data is not associated properly. We have a >>> standard way of associating the data and metadata with link-rel such as >>> RFC5988 so why not use it? Link-rel-href pattern is used a lot now. Most >>> modern web pages actually have it. Using a proper way to associate metadata >>> with data will save you from a lot of other attacks in the future. Instead >>> of doing patch works, we should solve it architecturally. >>> >>> >>> >>> Nat >>> >>> >>> >>> >>> >>> >>> >>> 2016年1月22日(金) 10:34 Mike Jones < <michael.jo...@microsoft.com> >>> michael.jo...@microsoft.com>: >>> >>> Nat, I’m confused by this statement in the message you reference >>> “Unfortunately, >>> this does not match the value of OAuth issuer defined in Section 2 >>> of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as >>> specified in 3.1. As such, validation as specified in bullet 1 of Section 4 >>> fails in Google's case -- OR it means that the document is internally >>> inconsistent.”. The issuer definition in draft-jones-oauth-discovery >>> is 100% compatible with the one in OpenID Connect Discovery, by design. In >>> the Google example, both the OpenID issuer and the OAuth issuer values >>> would be the string “ <https://accounts.google.com> >>> https://accounts.google.com”. What is the inconsistency that you >>> perceive? >>> >>> >>> >>> The discussion of the duplication problem happened in the private >>> meetings in Yokohama. >>> >>> >>> >>> I will admit, in Yokohama, I didn’t speak up in the public meetings to >>> point out that a simpler alternative to oauth-meta was already being >>> discussed there in private, because then I would have had to talk about the >>> security issues, which we’d decided not to publicly do at that point. So I >>> stayed silent during the poll, out of politeness. Perhaps I should have >>> found a way to say something then anyway, but that’s water under the bridge >>> now. >>> >>> >>> >>> Finally, for what it’s worth, the HATEOAS stuff reminds me far too much >>> of Web Services Description Language (WSDL) – part of the complexity >>> baggage that helped sink Web Services. The use of “link rel” to define an >>> interaction vocabulary and publish endpoints for that vocabulary seems >>> pretty baroque and reminiscent of “microformats” – another cute “Webby” >>> innovation that never caught on. The industry has pretty much voted with >>> its feet and is using JSON for publishing discovery data structures – not >>> “link rel”. I am against us reverting to the “link rel” proposal from 2008 >>> that never caught on when JSON is simpler and does a better job. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* Nat Sakimura [mailto: <sakim...@gmail.com>sakim...@gmail.com] >>> *Sent:* Thursday, January 21, 2016 6:24 AM >>> *To:* Justin Richer < <jric...@mit.edu>jric...@mit.edu>; Mike Jones < >>> <michael.jo...@microsoft.com>michael.jo...@microsoft.com> >>> *Cc:* William Denniss < <wdenn...@google.com>wdenn...@google.com>; < >>> <oauth@ietf.org>oauth@ietf.org> < <oauth@ietf.org>oauth@ietf.org> >>> >>> >>> *Subject:* Re: [OAUTH-WG] Call for Adoption >>> >>> >>> >>> Mike, >>> >>> >>> >>> You just criticize my draft. That's ok, but I would really like to get >>> some response to my questions stated in >>> <https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html> >>> https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To >>> me, it just does not seem to work, and the combination of the oauth-meta >>> and PKCE seems to be much more elegan, nicer, and much simpler to >>> implement. If you just give up the dynamic response at the authorization >>> endpoint, then you even do not have to touch the code but just change a >>> config file. >>> >>> >>> >>> Please convince me by answering to my questions. >>> >>> >>> >>> For the record of Yokohama, I do not recall much about duplication in >>> OAuth session. The poll in the room was 19 for / zero against / 4 >>> persons need more information. Indeed, it is not duplicating much. And if >>> you move to a new model without pre-configured discovery, it is not >>> duplicating any but the resource endpoint URI, which is optional and is for >>> the cases where the client did not know the concrete resource endpoint to >>> start with. >>> >>> >>> >>> I understand your usecases always start from a concrete endpoint >>> location. Mine do not. In a four party model, it is likely not. The user >>> just want to have the service to fetch his data from some resource >>> endpoint. He just hits the service. He does not hit the resource endpoint >>> directly. For example, in the case of a consumer using a personal finance >>> platform (PFP)to manage his pension fund, he hits the PFP and not the >>> Pension fund. Assuming that the pension fund has delegated the >>> authorization control to the authorization server, then, the authorization >>> server should return both the access token and the endpoint of the pension >>> fund so that the PFP can pull the data using them. A similar model holds >>> for personal health service and health care providers. >>> >>> >>> >>> Best, >>> >>> >>> >>> Nat >>> >>> >>> >>> >>> >>> 2016年1月21日(木) 21:18 Justin Richer < <jric...@mit.edu>jric...@mit.edu>: >>> >>> Convergence is exactly what I’m arguing for, though. These things ought >>> to work together. >>> >>> >>> >>> — Justin >>> >>> >>> >>> On Jan 21, 2016, at 2:55 AM, Mike Jones < <michael.jo...@microsoft.com> >>> michael.jo...@microsoft.com> wrote: >>> >>> >>> >>> My memory of the discussions of the oauth-meta draft in Yokohama were >>> that many people felt that it was unnecessarily dynamically duplicating a >>> lot of information that the client already had. Most of us that were aware >>> of the attacks then were in favor of a more targeted, minimal approach. >>> You were listened to in Yokohama, but that didn’t necessarily mean that >>> people agreed with the approach. Participants were already aware of the >>> oauth-meta proposal in Darmstadt but no one spoke up in favor of it that I >>> can recall. Rather, I think people were thinking that “less is more”. >>> >>> >>> >>> There have also been discussions in the last day about how dynamically >>> returning a resource URL, which oauth-meta does, is both unnecessary (since >>> the client initiated the resource authorization already knowing what >>> resource it wants to access) and often problematic, since many >>> authorization servers can authorize access to multiple resources. If >>> anything, the client should be telling the authorization server what >>> resource it wants to access – not the other way around. >>> >>> >>> >>> I’m not saying that there aren’t some good ideas in the oauth-meta draft >>> – I’m sure there are, just as there are in the approach designed by the >>> participants in Darmstadt. While I volunteered to write the first draft of >>> the mix-up-mitigation approach, it really reflects something a lot of >>> people have already bought into – as evidenced in the passion in the >>> high-volume “Mix-Up About The Mix-Up Mitigation” thread, and not just my >>> personal project. >>> >>> >>> >>> If you think there are things missing or wrong in the mix-up-mitigation >>> draft, please say what they are. That will help us quickly converge on a >>> solution that will work for everyone. >>> >>> >>> >>> Sincerely, >>> >>> -- Mike >>> >>> >>> >>> *From:* Nat Sakimura [ <sakim...@gmail.com>mailto:sakim...@gmail.com >>> <sakim...@gmail.com>] >>> *Sent:* Wednesday, January 20, 2016 11:17 PM >>> *To:* Mike Jones < <michael.jo...@microsoft.com> >>> michael.jo...@microsoft.com>; William Denniss < <wdenn...@google.com> >>> wdenn...@google.com>; Justin Richer < <jric...@mit.edu>jric...@mit.edu> >>> *Cc:* <oauth@ietf.org>oauth@ietf.org >>> *Subject:* Re: [OAUTH-WG] Call for Adoption >>> >>> >>> >>> Hi Mike. >>> >>> >>> >>> Conversely, I would like to ask why this approach does not work for >>> Mix-up attack. As Nov stated, we in fact have discussed the approach in >>> quite a length back in Yokohama. I really would like to know why it does >>> not work. >>> >>> >>> >>> Besides, for oauth-meta approach, mix-up attack is only one of the thing >>> it solves. >>> >>> >>> >>> Nat Sakimura >>> >>> >>> >>> 2016年1月21日(木) 16:02 Mike Jones < <michael.jo...@microsoft.com> >>> michael.jo...@microsoft.com>: >>> >>> Not to be negative, but I disagree with adopting >>> draft-sakimura-oauth-meta. We should define and promote one mitigation >>> approach to the mix-up attacks. Having two would confuse implementers and >>> cause compatibility problems – reducing overall security. >>> >>> >>> >>> The approach defined in draft-jones-oauth-mix-up-mitigation was created >>> in collaboration with the security researchers who identified the problems >>> in the first place, was vigorously discussed in the security meeting Hannes >>> and Torsten held in Darmstadt, and has been since refined based on >>> substantial input from the working group. And at least three implementers >>> have already stated that they’ve implemented it. I’m not saying that it’s, >>> but if there are things missing or things that need to be improved in our >>> approach, we should do it there, rather introducing a competing approach. >>> >>> >>> >>> Also, standard OAuth deployments register the client and then use the >>> information gathered at registration time for subsequent protocol >>> interactions. They do not need all the configuration information for the >>> authorization server to be retransmitted at runtime. The oauth-meta draft >>> goes too far in that direction, at least as I see it. Returning things two >>> ways creates its own problems, as discussed in the Duplicate Information >>> Attacks security considerations section (7.2) of the mix-up-mitigation >>> draft. >>> >>> >>> >>> I’ll note that the mix-up-mitigation approach is compatible with >>> existing practice in both static and dynamic metadata discovery. Replying >>> to Justin’s comment that “It's the pre-configured discovery document >>> that's at the root of the mix-up attack in the first place” – this is >>> not the case. The attacks can be performed without either discovery or >>> dynamic registration. >>> >>> >>> >>> I would be interested in hearing a technical discussion on whether there >>> are aspects of the oauth-meta approach that mitigate aspects of the attacks >>> that the mix-up-mitigation approach does not. That could help inform >>> whether there are additional things we should add to or change in the >>> mix-up draft. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* OAuth [mailto: <oauth-boun...@ietf.org>oauth-boun...@ietf.org] *On >>> Behalf Of *William Denniss >>> *Sent:* Wednesday, January 20, 2016 10:37 PM >>> *To:* Justin Richer < <jric...@mit.edu>jric...@mit.edu> >>> *Cc:* <oauth@ietf.org>oauth@ietf.org >>> *Subject:* Re: [OAUTH-WG] Call for Adoption >>> >>> >>> >>> +1 to adopt this, and I agree with Justin's comments. >>> >>> >>> >>> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer < <jric...@mit.edu> >>> jric...@mit.edu> wrote: >>> >>> +1 >>> >>> Inline discovery and pre-configured discovery (ie, .well-known) should >>> at the very least be compatible and developed together. It's the >>> pre-configured discovery document that's at the root of the mix-up attack >>> in the first place. >>> >>> -- Justin >>> >>> >>> >>> On 1/19/2016 10:30 PM, Nat Sakimura wrote: >>> >>> Just to give more context, at IETF 94, I have done a presentation on >>> discovery. >>> >>> >>> >>> According to the minutes, >>> >>> >>> >>> (f) Discovery (Nat) >>> >>> >>> >>> Nat explains his document as an example of the work that has >>> to be done >>> >>> in the area of discovery, which is a topic that has been >>> identified >>> >>> as necessary for interoperability since many years but so far >>> there >>> >>> was not time to work on it. Mike, John and Nat are working on >>> a new >>> >>> document that describes additional discovery-relevant >>> components. >>> >>> >>> >>> Poll: 19 for / zero against / 4 persons need more information. >>> >>> >>> >>> The document discussed there was >>> <https://tools.ietf.org/html/draft-sakimura-oauth-meta-05> >>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a >>> simple (only 1-page!) but a very powerful document that nudges towards >>> HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-up >>> attack without introducing the concept of issuer which is not in RFC6749. >>> It is also good for selecting different endpoints depending on the user >>> authentication and authorization results and more privacy sensitive than >>> pre-announced Discovery document. It also allows you to find to which >>> protected resource endpoint you can use the access token against. >>> >>> >>> >>> In the last sentence of the minutes, it talks about "a new document that >>> describes additional discovery-relevant components". This is >>> <https://tools.ietf.org/html/draft-jones-oauth-discovery-00> >>> https://tools.ietf.org/html/draft-jones-oauth-discovery-00. It went >>> for the call for adoption. However, it is only a half of the story. I >>> believe <https://tools.ietf.org/html/draft-sakimura-oauth-meta-05> >>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was >>> discussed at IETF 94 and had support there should be adopted as well. >>> >>> >>> >>> Nat Sakimura >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 2016年1月20日(水) 12:05 Nat Sakimura < <sakim...@gmail.com> >>> sakim...@gmail.com>: >>> >>> Thanks Hannes. >>> >>> >>> >>> I did not find >>> <https://tools.ietf.org/html/draft-sakimura-oauth-meta-05> >>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which was >>> discussed in Yokohama, and was largely in agreement if my recollection is >>> correct. Why is it not in the call for adoption? >>> >>> >>> >>> >>> >>> >>> >>> 2016年1月19日(火) 20:39 Hannes Tschofenig < <hannes.tschofe...@gmx.net> >>> hannes.tschofe...@gmx.net>: >>> >>> Hi all, >>> >>> we have submitted our new charter to the IESG (see >>> <http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and >>> since some IESG members like to see an updated list of milestones as >>> well. For this reason, based on a suggestion from Barry, we are also >>> starting a call for adoption concurrently with the review of the charter >>> text by the IESG. >>> >>> We will post separate mails on the individual documents. Your feedback >>> is important! Please take the time to look at the documents and provide >>> your feedback. >>> >>> Ciao >>> Hannes & Derek >>> >>> _______________________________________________ >>> OAuth mailing list >>> <OAuth@ietf.org>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 >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> <OAuth@ietf.org>OAuth@ietf.org >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> <OAuth@ietf.org>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 >>> >>> >>> >> > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
