Belated +1 to this. "sender or key constrained" is good. Also, the new definition of "sender constrained" per Torsten states "knowledge of" but that is only applicable to "key constrained" variant I guess, besides "knowledge" is a bit "fluffy". I feel that just saying as suggested by Brian safer. My 2c.
Nat On Sat, Dec 1, 2018 at 7:24 AM Brian Campbell <bcampbell= 40pingidentity....@dmarc.ietf.org> wrote: > Kind of, yes. I guess so. I think. It's just semantics. But yeah. Key > constrained might be more appropriate. But the Security Topics document > probably should allow for both/either. > > I don't think that these are necessarily terms with widely agreed upon or > understood meaning. But it was pointed out to me that the OAuth 2.0 Pop > Architecture draft defines sender constraint and key confirmation as > different things ( > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.2 > and > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.3 > <https://tools.ietf..org/html/draft-ietf-oauth-pop-architecture-08#section-6.3>). > And the definitions their do kind of make sense when thinking about the > words used. The line between sender and key constrained isn't exactly clear > but it seems MTLS and token binding access tokens are more key constrained > than sender. The -08 version of the MTLS draft dropped the use of the > "sender constrained" terminology based on that feedback. > > I dunno. Maybe the Security Topics could say something in a terminology > section that says when sender or key constrained is used within they can be > taken to mean the same concept. Or something like that. > > On Fri, Nov 30, 2018 at 1:42 PM Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> Hi Brian, >> >> we use „sender constrained tokens“ throughout the BCP to denote tokens >> bound to a sender in possession of a certain key/secret and I thought that >> was established terminology in the group. Are you suggesting „key >> constrained” would be more appropriate? >> >> kind regards, >> Torsten. >> >> Am 30.11.2018 um 21:02 schrieb Brian Campbell <bcampb...@pingidentity.com >> >: >> >> As was pointed out to me in WGLC review of the MTLS document, >> "sender-constrained" has or is likely to be interpreted with a pretty >> specific meaning of the token being bound to the client and the client >> authenticating itself to the resource and the resource checking all that >> matches up. That makes the text more restrictive than is likely intended.. >> Perhaps the text should say something like "sender or key constrained" to >> allow for different variants of PoP access tokens? >> >> >> >> On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt < >> 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>: >>> > >>> > I am ok with that. >>> > >>> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt < >>> tors...@lodderstedt.net wrote: >>> > >>> > > Am 28.11.2018 um 23:50 schrieb n-sakimura <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 / +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> >>> > > 送信日時: 水曜日, 11月 28, 2018 11:38 午後 >>> > > 宛先: n-sakimura >>> > > Cc: Dick Hardt; Hannes Tschofenig; 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>: >>> > >> >>> > >> 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> (Dick Hardt < >>> dick.ha...@gmail.com> の代理) >>> > >> 送信日時: 水曜日, 11月 28, 2018 8:58 午後 >>> > >> 宛先: Hannes Tschofenig >>> > >> Cc: 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> 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 >>> > >> 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 >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited... >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.* >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited... > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
