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>: > 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] *On Behalf Of *William > Denniss > *Sent:* Wednesday, January 20, 2016 10:37 PM > *To:* Justin Richer <jric...@mit.edu> > *Cc:* 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> 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. 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. 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 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>: > > Thanks Hannes. > > > > I did not find 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>: > > Hi all, > > we have submitted our new charter to the IESG (see > 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 > 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 > 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 https://www.ietf.org/mailman/listinfo/oauth
