(chair hat off) Hi Nat,
Section 3.8.1.2<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.8.1.2> of draft-ietf-oauth-security-topics-10 lists the following options for implementing sender constraint tokens: * Token Binding * MTLS * Signed HTTP Requests * JPOP JPOP is an individual submission. The work on signed HTTP requests stalled. Token Binding, as we learned at the last IETF meeting, has serious deployment problems. That essentially leaves us with MTLS. I am, however, not entirely sure MTLS works well with the implicit grant. My conclusion so far from the discussion is that implicit grant cannot be secured practically. For IoT, as I mentioned, the story does not look so grim since with IoT protocols, CoAP or MQTT, one can still use TLS as well as application layer security. (At least that’s the current understanding.) I am happy to get corrected. Ciao Hannes From: n-sakimura <n-sakim...@nri.co.jp> Sent: Saturday, December 1, 2018 10:44 AM To: Hannes Tschofenig <hannes.tschofe...@arm.com>; Aaron Parecki <aa...@parecki.com>; Torsten Lodderstedt <tors...@lodderstedt.net> Cc: Daniel Fett <f...@danielfett.de>; IETF oauth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit OAuth MTLS has been implemented in Banking industry so we have at least an alternative. Sender Constrained includes cases where it is not key bound but name bound as I understand and it may have some utility so we f there are doubts, mentioning the both may be good. Outlook for iOS<https://aka.ms/o0ukef> を入手 ________________________________ 差出人: OAuth <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> (Hannes Tschofenig <hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>> の代理) 送信日時: 土曜日, 12月 1, 2018 6:07 午後 宛先: Aaron Parecki; Torsten Lodderstedt Cc: Daniel Fett; IETF oauth WG 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit I agree with Aaron here and I think Section 3.8.1.2<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.8.1.2> of draft-ietf-oauth-security-topics-10 already does a pretty good job. I was, however, wondering about the subtle implication of the requirement for sender constrained tokens. My understanding of the token binding discussion, which is one of the ways to provide sender-constrained tokens, is that we don’t have good faith in seeing deployment anytime soon. Hence, we are essentially (reading in between the lines of Section 3.8.1.2) saying that you cannot use implicit grant in a practical setup for the web*. Am I misunderstanding it? Ciao Hannes PS: The IoT case is likely different. From: OAuth <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> On Behalf Of Aaron Parecki Sent: Saturday, December 1, 2018 3:18 AM To: Torsten Lodderstedt <tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>> Cc: Daniel Fett <f...@danielfett.de<mailto:f...@danielfett.de>>; IETF oauth WG <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit +1 I would also like to ensure there is a clear definition of "sender constrained" tokens in this BCP. Aaron On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt <tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>> wrote: Hi all, based on your feedback on the list and off list, Daniel and I polished the text. That’s our proposal: — In order to avoid these issues, clients MUST NOT use the implicit grant (response type "token") or any other response type issuing access tokens in the authorization response, such as "token id_token" and "code token id_token“, unless the issued access tokens are sender-constrained and access token injection in the authorization response is prevented. — Explantation: - we wanted to have the right balance between a generic definition of the response types we do not recommend/allow to be used and a concrete/actionable list of the affected response types. - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported by William We look forward to seeing your feedback. kind regards, Torsten. > Am 29.11.2018 um 15:15 schrieb John Bradley > <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>: > > I am ok with that. > > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt > <tors...@lodderstedt.net<mailto:tors...@lodderstedt.net> wrote: > > > Am 28.11.2018 um 23:50 schrieb n-sakimura > > <n-sakim...@nri.co.jp<mailto:n-sakim...@nri.co.jp>>: > > > > That works. > > Good! > > I just realized this text has an issue with „token“ (only). It would allow > „token“ to be used if the token would sender constrained. This completely > ignores the fact implicit also shall be abandoned because of its > vulnerability for access token injection. > > I therefore propose a modified text: > > In order to avoid these issues, Clients SHOULD NOT use the implicit > grant. Furthermore, clients SHOULD only use other response types causing > the authorization server to > issue an access token in the authorization response, if the particular > response type detects access token > injection and the issued access tokens are sender-constrained. > > Or we just state: > > In order to avoid these issues, Clients SHOULD NOT use the response type > „token". The response types > „token id_token“ and „code token id_token“ SOULD NOT be used, if the issued > access tokens are not > sender-constrained. > > > > > In fact, I would further go and say MUST NOT but that probably is too much > > for a security consideration. > > > > Mike suggested to go with a SHOULD NOT to get the message out but give > implementors time to move/change. > > > Best, > > > > Nat > > > > Nat Sakimura / n-sakim...@nri.co.jp<mailto:n-sakim...@nri.co.jp> / > > +81-90-6013-6276 > > > > このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。 > > > > PLEASE READ :This e-mail is confidential and intended for the named > > recipient only. > > If you are not an intended recipient, please notify the sender and delete > > this e-mail. > > > > 差出人: Torsten Lodderstedt > > <tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>> > > 送信日時: 水曜日, 11月 28, 2018 11:38 午後 > > 宛先: n-sakimura > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org<mailto:oauth@ietf.org> > > 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code > > instead of implicit > > > > Hi Nat, > > > >> Am 28.11.2018 um 21:10 schrieb n-sakimura > >> <n-sakim...@nri.co.jp<mailto:n-sakim...@nri.co.jp>>: > >> > >> I would support > >> > >> 1) clearly defining Implicit as the flow that returns access token from > >> the authorization endpoint ( some people confuses implicit as the flow > >> that returns ID Token in the front channel) > > > > That’s the current text: > > > > In order to avoid these issues, Clients SHOULD NOT use the implicit > > grant or any other response type causing the authorization server to > > issue an access token in the authorization response. > > > > What would you like to modify? > > > >> > >> 2) Banning the returning of the access token that are not sender > >> constrained from the authorization endpoint > > > > In order to avoid these issues, Clients SHOULD NOT use the implicit > > grant or any other response type causing the authorization server to > > issue an access token in the authorization response, if this access > > tokens is not sender-constraint. > > > > What about this? > > > > kind regards, > > Torsten. > > > >> > >> Best, > >> > >> Nat > >> > >> > >> Outlook for iOS を入手 > >> > >> 差出人: OAuth <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> (Dick > >> Hardt <dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>> の代理) > >> 送信日時: 水曜日, 11月 28, 2018 8:58 午後 > >> 宛先: Hannes Tschofenig > >> Cc: oauth@ietf.org<mailto:oauth@ietf.org> > >> 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code > >> instead of implicit > >> > >> +1 > >> > >> While there are various mechanisms to alleviate some of the issues of > >> implicit, I don't think we can recommend specifics, and there may be > >> future ones in the future. I think we all agree that implicit without any > >> mitigation is problematic. > >> > >> How about we recommend against using implicit alone? > >> > >> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig > >> <hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>> wrote: > >> Hi all, > >> > >> The authors of the OAuth Security Topics draft came to the conclusion that > >> it is not possible to adequately secure the implicit flow against token > >> injection since potential solutions like token binding or JARM are in an > >> early stage of adoption. For this reason, and since CORS allows > >> browser-based apps to send requests to the token endpoint, Torsten > >> suggested to use the authorization code instead of the implicit grant in > >> call cases in his presentation (see > >> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01). > >> > >> A hum in the room at IETF#103 concluded strong support for his > >> recommendations. We would like to confirm the discussion on the list. > >> > >> Please provide a response by December 3rd. > >> > >> Ciao > >> > >> Hannes & Rifaat > >> > >> > >> > >> IMPORTANT NOTICE: The contents of this email and any attachments are > >> confidential and may also be privileged. If you are not the intended > >> recipient, please notify the sender immediately and do not disclose the > >> contents to any other person, use it for any purpose, or store or copy the > >> information in any medium. Thank you. > >> _______________________________________________ > >> 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<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 -- ---- Aaron Parecki aaronparecki.com<http://aaronparecki.com> @aaronpk<http://twitter.com/aaronpk> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
