Am 03.01.20 um 11:33 schrieb Torsten Lodderstedt: > Hi Brian, > > I’m on the fence regarding your proposal. > > What I like is it moves the focus onto leakage prevention and prevention of > injection in the authorization response, which are the direct threats to the > front channel flow. Especially token leakage prevention somehow got lost in > the process. Indeed, we should check again if leakage prevention is sufficiently emphasized in the BCP. > > Beside this, your proposal does not change the meaning of the spec since > sender constrained access tokens are still recommended through 3.2. > > I’m not sure it is worth the change now taking into account how much energy > it has cost to come up with a consensus for this piece of text. I would > encourage more WG members to share their thoughts.
I'm with Annabelle on this: These kinds of exceptions are exactly what the SHOULD NOT is for. -Daniel > > best regards, > Torsten. > >> On 2. Jan 2020, at 22:53, Richard Backman, Annabelle >> <[email protected]> wrote: >> >> Brian and others with similar use cases (Filip?): >> >> The current text does not prohibit your approach, provided you’ve done the >> due diligence required by BCP 14 to go against a SHOULD NOT. Could you >> provide more detail on the scenarios where you have opted to use these >> implicit-based solutions? Is it impractical or infeasible to use an >> authorization code-based approach in these scenarios? If this is a >> particularly niche use case, then it may not be worth including in the BCP >> (that’s basically what SHOULD NOT is for). But if it’s more broadly >> applicable, then it may be worth tweaking the “unless…” clause of that >> paragraph. >> >> – >> Annabelle Richard Backman >> AWS Identity >> >> >> From: OAuth <[email protected]> on behalf of Mike Jones >> <[email protected]> >> Date: Saturday, December 28, 2019 at 9:47 AM >> To: Brian Campbell <[email protected]>, Torsten Lodderstedt >> <[email protected]> >> Cc: oauth <[email protected]> >> Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response >> types + form_post response mode >> >> I agree with Brian's suggested text changes. >> >> -- Mike >> From: Brian Campbell <[email protected]> >> Sent: Saturday, December 28, 2019 5:33:24 AM >> To: Torsten Lodderstedt <[email protected]> >> Cc: Mike Jones <[email protected]>; oauth <[email protected]> >> Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response >> types + form_post response mode >> >> The requirement for replay/injection prevention at resource servers is still >> there in section 3.2. This change only drops it as a specific qualification >> on that SHOULD NOT for flows that send access tokens in the authorization >> response. And instead focuses that qualification on the additional risks >> that come with sending access tokens in the authorization response. To me, >> this feels more consistent. >> >> Looking again at section 3, I'd suggest also moving the fourth paragraph of >> section 3.1.2 into section 3.2 so that the description of sender-constrained >> is in the subsection that is about sender-constraining. >> >> >> On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt >> <[email protected]> wrote: >>> Your proposal sounds reasonable on first sight. But thinking again, it >>> would mean to keep token injection prevention in authorization responses a >>> requirement while dropping the requirement for replay/injection prevention >>> at resource servers. To me this feels inconsistent. >>> >>> >>>> Am 28..12.2019 um 00:02 schrieb Brian Campbell >>>> <[email protected]>: >>>> >>>> I'm not suggesting that it should be a recommended flow. But recommending >>>> against it, as the text does now, seems overreaching and unnecessary. I >>>> know *consensus* was previously found on the text in -13 but best I can >>>> recall that discussion was mostly around Nat advocating to allow room for >>>> some future self-issued IDP type case and the conversation kind of got >>>> hung up on that. >>>> >>>> Here's some proposed text, which I think still largely captures the intent >>>> of the BCP while not explicitly recommending against legitimate cases like >>>> the one I brought here or Nat's or something like JARM. >>>> >>>> In order to avoid these issues, clients SHOULD NOT use the implicit >>>> grant (response type "token") or other response types issuing >>>> access tokens in the authorization response, unless access token >>>> injection >>>> in the authorization response is prevented and the aforementioned token >>>> leakage >>>> vectors are mitigated. >>>> >>>> The draft already recommends sender-constrained access tokens elsewhere in >>>> the document. It doesn't need to be repeated as a qualifying condition >>>> around this SHOULD NOT. >>>> >>>> I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefully >>>> is evident from several attempts at bringing/doing related work here) but >>>> I do worry that the recommendation in the draft is sufficiently >>>> unachievable to the vast majority that it might undermine the credibility >>>> of the document. But I get the aspirational aspect of it and, other >>>> thansome suggested tweaks, am resigned to see it stay in the document. But >>>> let's let that recommendation stand on its own in the document and not >>>> also tie it to other considerations. >>>> >>>> >>>> On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt >>>> <[email protected]> wrote: >>>>> As Brian said, we have discussed this several times and this text found >>>>> consensus. >>>>> >>>>> Using post reduces the attack surface but does not allow to bind the >>>>> access token to the legitimate client. We are recommending sender >>>>> constrained access tokens in the BCP. So recommending a flow that does >>>>> not support sender constrained access tokens is a contradiction. >>>>> >>>>> What do other WG members think? >>>>> >>>>> >>>>>> Am 27.12.2019 um 21:28 schrieb Mike Jones >>>>>> <[email protected]>: >>>>>> >>>>>> I agree with Brian. Please update the text to describe this already safe >>>>>> usage. >>>>>> >>>>>> -- Mike >>>>>> >>>>>> From: OAuth <[email protected]> on behalf of Brian Campbell >>>>>> <[email protected]> >>>>>> Sent: Friday, December 27, 2019 11:03:30 AM >>>>>> To: oauth <[email protected]> >>>>>> Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response >>>>>> types + form_post response mode >>>>>> >>>>>> We have a-sometimes used scenario where a client makes an >>>>>> authorization/authentication request with a "token id_token" response >>>>>> type and "form_post" response mode (nonce is also sent and exact >>>>>> redirect URI matching is done at the AS). The access token is never >>>>>> exposed in any URLs and access token injection is prevented by the >>>>>> at_hash claim in the id token. >>>>>> >>>>>> That seems to me like a legitimate and reasonable usage scenario. >>>>>> However, it would fall on the wrong side of the SHOULD NOT in Section >>>>>> 3.1.2 of the Security BCP-to-be, which has: >>>>>> >>>>>> In order to avoid these issues, clients SHOULD 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. >>>>>> >>>>>> I know this particular text has been discussed over and over again so I >>>>>> hate to revisit it. But based on the aforementioned scenario I think >>>>>> maybe it still doesn't quite hit the mark. Access token injection is >>>>>> prevented. The token leakage scenarios mentioned in that section are all >>>>>> avoided. And while I know sender-constrained is recommended elsewhere in >>>>>> the draft, it's not really a realistic option for the majority of >>>>>> deployments. >>>>>> >>>>>> 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 >>>>>> [email protected] >>>>>> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
