And what about code injection and open redirectors? I think we already have a lot of deployment experience that should be used to evolve the spec.
Sent by MailWise – See your emails as clean, short chats. -------- Originalnachricht -------- Betreff: Re: [OAUTH-WG] OAuth 2.1 Von: "Phil Hunt (IDM)" <phil.h...@oracle.com> An: Mike Jones <michael.jo...@microsoft.com> Cc: Torsten Lodderstedt <tors...@lodderstedt.net>,oauth@ietf.org >I believe all we need is a new draft that deals with the new "dynamic/mix-up" >cases as these were not considered in the original spec process. > >The updated by method works best for this. It also consolidates a lot of >piecemeal specs into one consistent spec. > >Phil > >> On Apr 7, 2016, at 15:25, Mike Jones <michael.jo...@microsoft.com> wrote: >> >> Yes - an intentionally conservative, implementation- and experience-driven >> path. >> >> Revising OAuth 2.0 is a *big deal*. We shouldn't even be talking about it >> until we've completed steps 1-5 below - *including* the "iterate" step, as >> necessary. If we get this wrong, we'll fragment OAuth, which is a terrible >> and irresponsible outcome we should consciously avoid at all costs. >> >> In particular, we should not recharter for an OAuth 2.1 until we already >> know what will be in it and know from deployment experience that it's the >> right stuff. >> >> -- Mike >> >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] >> Sent: Thursday, April 7, 2016 3:16 PM >> To: Mike Jones <michael.jo...@microsoft.com> >> Cc: Samuel Erdtman <sam...@erdtman.se>; Anthony Nadalin >> <tony...@microsoft.com>; oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth 2.1 >> >> Hi Mike, >> >> in my opinion, you described a possible path towards 2.1. Would you agree? >> >> best regards, >> Torsten. >> >>> Am 07.04.2016 um 13:38 schrieb Mike Jones <michael.jo...@microsoft.com>: >>> >>> I am strongly against creating a 2.1 spec until we have at least a year of >>> deployment experience with the contents we're adding to 2.0, so as not to >>> fragment the OAuth marketplace. >>> >>> I think we should: >>> 1. Continue working on new security mitigations in new drafts (such >>> as mix-up-mitigation, etc.) that add features to use with 2.0 2. >>> Continue working on PoP specs (such as pop-key-distribution, etc.) >>> that add features to use with 2.0 3. Continue working on other new >>> specs (such as discovery, resource-indicators, etc.) that add features >>> to use with 2.0 4. Learn from deployment experience with all of them >>> 5. Iterate if the deployment experience tells us that we need to >>> >>> Only after we believe we have all the features right and we know that they >>> work together well should we consider creating a 2.1. If we rush to a 2.1 >>> and get it wrong, we'll lose developers' trust and we'll never get it back. >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Samuel >>> Erdtman >>> Sent: Thursday, April 7, 2016 12:48 PM >>> To: Anthony Nadalin <tony...@microsoft.com> >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] OAuth 2.1 >>> >>> +1 on a 2.1 version >>> >>> -1 on defining scopes more precisely in 2.1 >>> >>> Sent from my iPhone >>> >>>> On 7 apr. 2016, at 14:46, Anthony Nadalin <tony...@microsoft.com> wrote: >>>> >>>> I don't belive that scopes should be defined more precisely as this >>>> opaqueness was a design feature, I'm not seeing the reason why scopes need >>>> to be defined, as these are application specific. >>>> >>>> -----Original Message----- >>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten >>>> Lodderstedt >>>> Sent: Thursday, April 7, 2016 5:32 AM >>>> To: George Fletcher <gffle...@aol.com> >>>> Cc: oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] OAuth 2.1 >>>> >>>> Hi all, >>>> >>>> as I already said in the meeting: I would very much prefer to have an >>>> extension/update of RFC 6819 covering all "new" threats, including: >>>> - mix up >>>> - code injection aka copy and paste >>>> - open redirector at AS and client >>>> - potential other threats in the context of "dynamic" OAuth >>>> >>>> I also assume mitigations for (at least some of) the threats need to go >>>> into an update of RFC 6749 as normative text. To give an example: if we >>>> agree on using the state parameter at the token endpoint to mitigate code >>>> injection, this MUST be part of the core spec (request description and >>>> security consoderations). Otherwise, noone will even consider it. >>>> >>>> We should also use the opportunity to improve/enhance the text of the >>>> spec. In the course of the last years, we have learned a lot about >>>> ambiquities of the text and how different implementations utilize OAuth. >>>> >>>> I think time is right to define scopes more precisely. As the discussions >>>> in the last days proved again (at least for me), scope is not sufficiently >>>> defined to come up with interoperable implementations. Additionally, there >>>> seems to be a need to represent resource server locations (to not say >>>> identities :-)) in this context. >>>> >>>> To bundle all changes in a version 2.1 would also make communication into >>>> the market much easier. >>>> >>>> best regards, >>>> Torsten. >>>> >>>>> Am 06.04.2016 um 16:05 schrieb George Fletcher <gffle...@aol.com>: >>>>> >>>>> I'd definitely prefer a single solution document to many little ones that >>>>> have to be combined to actually build a secure solution. It's already >>>>> getting complex with the additional specs that have been added. >>>>> >>>>> Additionally, I'm not against working on OAuth 2.1. >>>>> >>>>> Thanks, >>>>> George >>>>> >>>>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: >>>>>> >>>>>> Existing implementations are for the large part ok and do not need these >>>>>> mitigations. >>>>>> >>>>>> Only the new use cases we have been discussing (configure on the fly and >>>>>> multi-as, etc) really need mitigation. >>>>>> >>>>>> The updated by approach seems like a good way to address the new cases. >>>>>> >>>>>> Phil >>>>>> >>>>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig <hannes.tschofe...@gmx.net> >>>>>>> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> today we discussed the OAuth Authorization Server Mixup draft. We >>>>>>> were wondering what types of threats the document should find solutions >>>>>>> for. >>>>>>> >>>>>>> We discussed various document handling approaches including >>>>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate >>>>>>> solution documents >>>>>>> * combined solution document covering the OAuth Mix-Up and the >>>>>>> Cut-and-Paste attacks. >>>>>>> >>>>>>> Barry pointed out that these documents could update the OAuth base >>>>>>> specification. >>>>>>> >>>>>>> As a more radical change it was also suggested to revise RFC 6749 >>>>>>> "OAuth >>>>>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model >>>>>>> and Security Considerations". >>>>>>> >>>>>>> Opening up the OAuth base specification obviously raises various >>>>>>> other questions about cleaning up parts that go far beyond the AS >>>>>>> mix-up and the cut-and-paste attacks. Other specifications, such >>>>>>> as the Open Redirector, could be folded into such a new specification. >>>>>>> >>>>>>> Derek and I would appreciate your input on this topic before we >>>>>>> make a decision since it has significant impact on our work. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes & Derek >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw >>>>>>> w >>>>>>> w >>>>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40mi >>>>>>> c >>>>>>> r >>>>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91a >>>>>>> b >>>>>>> 2 >>>>>>> d7cd011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI% >>>>>>> 3 >>>>>>> d >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >>>>>> ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micr >>>>>> o >>>>>> s >>>>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d >>>>>> 7 c >>>>>> d011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >>>>> i >>>>> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micros >>>>> o >>>>> f >>>>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd >>>>> 0 >>>>> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >>>> i >>>> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microso >>>> f >>>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0 >>>> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>>> >>>> _______________________________________________ >>>> 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
