Re: [OAUTH-WG] OAuth Digest, Vol 121, Issue 43

[Adam Cashion <[e-mail]>]

On Tue, Nov 20, 2018, 6:25 AM <[e-mail] wrote:

> Send OAuth mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
> Today's Topics:
>
>    1. Re: draft-parecki-oauth-browser-based-apps-00 (Aaron Parecki)
>    2. Re: OAuth Security Topics -- Recommend authorization code
>       instead of implicit (Torsten Lodderstedt)
>    3. Dynamic Client Registration - client_secret_expires_at
>       (Filip Skokan)
>    4. Re: OAuth Security Topics -- Recommend authorization code
>       instead of implicit (Neil Madden)
>
>
>
> ---------- Forwarded message ----------
> From: Aaron Parecki <[e-mail]>
> To: OAuth WG <[e-mail]>
> Cc:
> Bcc:
> Date: Mon, 19 Nov 2018 18:09:03 -0800
> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
> On Wed, Nov 7, 2018 at 7:20 AM Joseph Heenan <[e-mail]> wrote:
>
>
>> It may be worth slightly rewording 7..2 as it may encourage a growing
>> misconception that all native apps must be public clients. With many
>> devices now having embedded HSMs, we’ve seen increasing interest in mobile
>> apps being dynamically (per-install) registered oauth2 private clients, and
>> that model has a lot of advantages. (I’m not sure if we might see a similar
>> model evolving for web apps.)
>>
>
> That's a great point, thanks. I've removed the reference to native apps
> being public clients since it doesn't really add anything to this spec if I
> have to caveat the description.
>
> On Thu, Nov 15, 2018 at 12:58 PM Torsten Lodderstedt <
> [e-mail]> wrote:
>
> > > First of all the AS decides whether it issues refresh tokens or not.
>> Having the ability does not mean the AS must do it. If you feel it’s safer
>> to not do it. Fine.
>> > Sure, and this should be mentioned then somewhere (either in the
>> threats doc or in this proposed best practice doc). Not all end developers
>> using these protocols fully understand the ramifications.
>> @Aaron: I suggest this goes to the SPA BCP since this is client specific.
>
>
> Thanks, I agree that this document should include some recommendations
> around refresh token handling. Looking at the discussion in this thread, it
> seems there are a few different strategies folks are taking. Since it seems
> like there isn't a strong consensus, it sounds like this would be better
> suited for the "Security Considerations" section, and to not make
> MUST/SHOULD recommendations, but rather just point out the issues. Any
> thoughts on that before I take a stab at writing something?
>
> I've incorporated some of the other feedback here and published an updated
> version:
>
> https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-01
>
> Thanks for the feedback so far.
>
> ---
> Aaron Parecki
> https://aaronparecki.com
>
>
>
> ---------- Forwarded message ----------
> From: Torsten Lodderstedt <[e-mail]>
> To: Mike Jones <Michael.Jones=[e-mail]>
> Cc: Hannes Tschofenig <[e-mail]>, oauth <[e-mail]>
> Bcc:
> Date: Tue, 20 Nov 2018 08:35:17 +0100
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
> Hi Mike,
>
> I agree that OIDC hybrid flows offer additional security over the OAuth
> implicit grant and are used in the wild. On my slides and in the initial
> version of the new section, we had included the hybrid OIDC flows because
> of their known token injection countermeasures.
>
> I nevertheless feel very uncomfortable to recommend those flows and any
> flow issuing access tokens in the front channel. In the course of the
> detailed review of the new text we realized two issues:
>
> 1) Since the access token is exposed in the URL, such flows possess a
> significantly higher risk to leak the access token (e.g. through browser
> history, open redirection and even referrer headers) than the code grant.
> 2) There is no viable way to sender constrain access tokens issued in the
> front channel. Given the WG decided to recommend use of sender constraint
> tokens (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2),
> it seems contradictory to recommend response types not supporting such an
> approach.
>
> kind regards,
> Torsten.
>
> > Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=
> [e-mail]>:
> >
> > This description of the situation is an oversimplification.  OpenID
> Connect secures the implicit flow against token injection attacks by
> including the at_hash (access token hash) in the ID Token, enabling the
> client to validate that the access token was created by the issuer in the
> ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note
> that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
> >
> > Given the prevalence of this known-good solution for securing the
> implicit flow, I would request that the draft be updated to describe this
> mitigation.  At the same time, I’m fine with the draft recommending the
> code flow over the implicit flow when this mitigation is not used.
> >
> >                                                                 Thank
> you,
> >                                                                 -- Mike
> >
> > From: OAuth <[e-mail]> On Behalf Of Hannes Tschofenig
> > Sent: Monday, November 19, 2018 2:34 AM
> > To: oauth <[e-mail]>
> > Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
> >
> > 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 (seehttps://
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> ---------- Forwarded message ----------
> From: Filip Skokan <[e-mail]>
> To: oauth <[e-mail]>
> Cc:
> Bcc:
> Date: Tue, 20 Nov 2018 12:44:50 +0100
> Subject: [OAUTH-WG] Dynamic Client Registration - client_secret_expires_at
> Hi all,
>
> a recent query about expiring client credentials (secrets) got me thinking
> about client_secret_expires_at client metadata from RFC 7591 used also in
> 7592 as well as OpenID Connect Dynamic Client Registration 1.0
>
> *What does expired client secret (in the sense of client_secret_expires_at
> with a non 0 value) mean beyond obviously not processing secret-based
> client authentication (basic, post and client_secret_jwt) after the given
> timestamp?* *Fingers Crossed* I'm hoping for your comments and experience
> from existing deployments on the topic to shed some light on this for me
> and maybe others too. Also that this doesn't get lost between the current
> BCP/implicit discussions.
>
> This is my best shot at an implementable policy when it comes to clients
> with expired client secrets: *"all operations requiring a secret will be
> rejected when an expired one is presented"*
>
>    - it is not valid for client secret based endpoint auth (basic, post,
>    client secret jwt), the AS will reject with 401 invalid_client in those
>    cases
>    - it will not be used for validating symmetrically signed request
>    object (JAR), the AS will reject the authorization request with ...?
>    - it will not be used by the AS to symmetrically sign id tokens,
>    userinfo, introspection or authorization responses (JARM), the AS will
>    reject the requests with ...?
>    - anything else?
>
>
>
> I feel this is reasonable interpretation and if so, are there appropriate
> errors to return to clients (both front and back-channel) when an expired
> secret is encountered during one of the operations that need it?
>
> Thank you very much for your thoughts and comments.
>
> Best,
> Filip
>
>
>
> ---------- Forwarded message ----------
> From: Neil Madden <[e-mail]>
> To: Torsten Lodderstedt <[e-mail]>
> Cc: Mike Jones <Michael.Jones=[e-mail]>, oauth <
> [e-mail]>
> Bcc:
> Date: Tue, 20 Nov 2018 12:24:55 +0000
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
> I think the draft should elaborate more on what it means by “token replay”
> in section 2.2 and how the proposal to use sender-constrained tokens
> prevents it. As far as I can tell, of the 4 methods presented in section
> 3.8.1.2, only jpop signed requests actually includes any specific
> countermeasure for replay (in the form of negotiated nonces).
>
> If we are discussing this in the context of client-side web apps/SPAs,
> then surely the threat model includes malicious 3rd party scripts - for
> which neither token binding nor mTLS constrained tokens are very effective
> as those scripts run in the same TLS context as the legitimate client?
>
> — Neil
>
> > On 20 Nov 2018, at 07:35, Torsten Lodderstedt <[e-mail]>
> wrote:
> >
> > Hi Mike,
> >
> > I agree that OIDC hybrid flows offer additional security over the OAuth
> implicit grant and are used in the wild. On my slides and in the initial
> version of the new section, we had included the hybrid OIDC flows because
> of their known token injection countermeasures.
> >
> > I nevertheless feel very uncomfortable to recommend those flows and any
> flow issuing access tokens in the front channel. In the course of the
> detailed review of the new text we realized two issues:
> >
> > 1) Since the access token is exposed in the URL, such flows possess a
> significantly higher risk to leak the access token (e.g. through browser
> history, open redirection and even referrer headers) than the code grant.
> > 2) There is no viable way to sender constrain access tokens issued in
> the front channel. Given the WG decided to recommend use of sender
> constraint tokens (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2),
> it seems contradictory to recommend response types not supporting such an
> approach.
> >
> > kind regards,
> > Torsten.
> >
> >> Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=
> [e-mail]>:
> >>
> >> This description of the situation is an oversimplification.  OpenID
> Connect secures the implicit flow against token injection attacks by
> including the at_hash (access token hash) in the ID Token, enabling the
> client to validate that the access token was created by the issuer in the
> ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note
> that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
> >>
> >> Given the prevalence of this known-good solution for securing the
> implicit flow, I would request that the draft be updated to describe this
> mitigation.  At the same time, I’m fine with the draft recommending the
> code flow over the implicit flow when this mitigation is not used.
> >>
> >>                                                                Thank
> you,
> >>                                                                -- Mike
> >>
> >> From: OAuth <[e-mail]> On Behalf Of Hannes Tschofenig
> >> Sent: Monday, November 19, 2018 2:34 AM
> >> To: oauth <[e-mail]>
> >> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
> >>
> >> 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 (seehttps://
> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>