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> 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 [mailto:sakim...@gmail.com] > Sent: Wednesday, January 20, 2016 11:17 PM > To: Mike Jones <michael.jo...@microsoft.com>; William Denniss > <wdenn...@google.com>; Justin Richer <jric...@mit.edu> > Cc: 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 > <mailto: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 <mailto:oauth-boun...@ietf.org>] > On Behalf Of William Denniss > Sent: Wednesday, January 20, 2016 10:37 PM > To: Justin Richer <jric...@mit.edu <mailto:jric...@mit.edu>> > Cc: oauth@ietf.org <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto: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
