Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode

[Daniel Fett <[e-mail]>]

After thinking about this a bit more, I think Brian's proposal makes
sense. Reading closely, it actually makes the advice stronger.
Sender-constrained tokens are a SHOULD somewhere else, so that still
applies. I will adopt the wording into the BCP (unless I hear protests).

-Daniel

Am 09.01.20 um 23:37 schrieb Brian Campbell:
> The scenario I described in the beginning of this thread
> (response_type=token+id_token and response_mode=form_post) started out
> a bit more humbly as a way to facilitate a simple and efficient
> cross-domain sign-on with id_token response type and form_post
> response mode. Somewhat analogous to SAML SSO using the POST binding.
> All the transactional data flows through the browser in the front
> channel so no additional calls from the client/RP to the AS/OP are
> needed. And no short-lived-transactional data has to be shared amongst
> AS nodes (or between geographic locations).  There are some nice
> aspects to front channel flows.
>
> Then along came the desire to have the ability to periodically refresh
> the user attributes associated with the session created off of SSO at
> the client/RP so as to have fresh data on which to base access control
> decisions. That was done by adding an access token into the mix, hence
> the response_type=token+id_token with response_mode=form_post, and the
> RP using it to periodically call the user info endpoint. Of course
> this isn't the same as an ID-token-only-front-channel SSO but it still
> retains some of the same benefits being a mostly front channel flow.
>
> I don't know how niche these cases are or even how often they are
> actually put into use in actual deployments. But the token+id_token
> and form_post flow was fresh in my mind for unrelated reasons when I
> was re-reviewing the security BCP draft, which made me think again
> about the SHOULD NOT wording in Section 3.1.2. And that led me to this
> thread and my proposed text that would let the SHOULD for using
> sender-constrained access tokens stand on its own and adjust the
> qualification on the SHOULD NOT for implicit style access tokens to
> focus on the issues that are particular to those flows. This doesn't
> actually change the underlying meaning of the draft because
> sender-constrained access tokens are still a SHOULD. But I think it
> would make the draft more cohesive in terms of where and why certain
> recommendations are made.
>
>
>
>
>
>
>
> On Thu, Jan 2, 2020 at 2:53 PM Richard Backman, Annabelle
> <[e-mail] <mailto:richanna@amazon..com>> 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 <[e-mail]
>     <mailto:[e-mail]>> on behalf of Mike Jones
>     <Michael.Jones=[e-mail]
>     <mailto:[e-mail]>>
>     *Date: *Saturday, December 28, 2019 at 9:47 AM
>     *To: *Brian Campbell <[e-mail]
>     <mailto:[e-mail]>>, Torsten Lodderstedt
>     <torsten=[e-mail]
>     <mailto:[e-mail]>>
>     *Cc: *oauth <[e-mail] <mailto:[e-mail]>>
>     *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 <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* Saturday, December 28, 2019 5:33:24 AM
>     *To:* Torsten Lodderstedt
>     <torsten=[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* Mike Jones <[e-mail]
>     <mailto:[e-mail]>>; oauth <[e-mail]
>     <mailto:[e-mail]>>
>     *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
>     <torsten=[e-mail]
>     <mailto:[e-mail]>> 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
>             <bcampbell=[e-mail]
>             <mailto:[e-mail]>>:
>
>             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 than some suggested tweaks
>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FRKujONej-92dT5lr9cLu6hHnw8I&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342096923&sdata=3fCGjTOAD43xXLzFaw3d6VC1kY43QvBfzNwdNfDckE0%3D&reserved=0>,
>             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
>             <torsten=[e-mail]
>             <mailto:[e-mail]>> 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
>                     <Michael.Jones=[e-mail]
>                     <mailto:[e-mail]>>:
>
>                     I agree with Brian. Please update the text to
>                     describe this already safe usage.
>
>                     -- Mike
>
>                     ------------------------------------------------------------------------
>
>                     *From:*OAuth <[e-mail]
>                     <mailto:[e-mail]>> on behalf of
>                     Brian Campbell
>                     <bcampbell=[e-mail]
>                     <mailto:[e-mail]>>
>                     *Sent:* Friday, December 27, 2019 11:03:30 AM
>                     *To:* oauth <[e-mail] <mailto:[e-mail]>>
>                     *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
>                     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-13%23section-3....1..2&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342096923&sdata=mfnQwsGUZgz0PgEZoqOl%2BsszPYxncmFbgBaJs4qex38%3D&reserved=0>,
>                     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
>                     [e-mail] <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/oauth
>                     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342106891&sdata=qO6%2BY%2FMoef0lyx4HwNLV8ID5DguAe3XjCQyxtvoFrPo%3D&reserved=0>
>
>
>             */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./*
>
>
> /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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth