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. 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. 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
