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

[Adam Cashion <[e-mail]>]

email

On Tue, Nov 20, 2018, 1:37 PM <[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: OAuth Security Topics -- Recommend authorization code
>       instead of implicit (John Bradley)
>    2. I-D Action: draft-ietf-oauth-security-topics-10.txt
>       ([e-mail])
>    3. Re: I-D Action: draft-ietf-oauth-security-topics-10.txt
>       (Torsten Lodderstedt)
>    4. Re: Token Binding & implicit (Torsten Lodderstedt)
>
>
>
> ---------- Forwarded message ----------
> From: John Bradley <[e-mail]>
> To: [e-mail]
> Cc:
> Bcc:
> Date: Tue, 20 Nov 2018 12:47:22 -0300
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
>
> Yes the at_hash protects the client from accepting an injected AT.
>
> Unfortunately it doesn't do anything to protect against leakage in logs or
> redirects.
>
> So without the AT using some sort of POP mechanism it is hard to say
> sending it in a redirect is a good security practice.
>
> John B.
> On 11/20/2018 4:35 AM, Torsten Lodderstedt 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]> <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]> <[e-mail]> On Behalf Of Hannes Tschofenig
> Sent: Monday, November 19, 2018 2:34 AM
> To: oauth <[e-mail]> <[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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> ---------- Forwarded message ----------
> From: [e-mail]
> To: <[e-mail]>
> Cc: [e-mail]
> Bcc:
> Date: Tue, 20 Nov 2018 11:26:58 -0800
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
>         Title           : OAuth 2.0 Security Best Current Practice
>         Authors         : Torsten Lodderstedt
>                           John Bradley
>                           Andrey Labunets
>                           Daniel Fett
>         Filename        : draft-ietf-oauth-security-topics-10.txt
>         Pages           : 38
>         Date            : 2018-11-20
>
> Abstract:
>    This document describes best current security practice for OAuth 2.0.
>    It updates and extends the OAuth 2.0 Security Threat Model to
>    incorporate practical experiences gathered since OAuth 2.0 was
>    published and covers new threats relevant due to the broader
>    application of OAuth 2.0.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Torsten Lodderstedt <[e-mail]>
> To: oauth <[e-mail]>
> Cc:
> Bcc:
> Date: Tue, 20 Nov 2018 20:32:50 +0100
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt
> Hi all,
>
> the new revision contains the following changes:
>
> * added section on refresh tokens
> * additional justifications for recommendation for code
> * refactored 2.1 in order to distinguish CSRF, authz response replay and
> mix-up (based on feedback by Joseph Heenan)
> * added requirement to authenticate clients during code exchange (PKCE or
> client credential) to 2.1.1.
> * changed occurrences of SHALL to MUST
>
> As always: looking forward for your feedback.
>
> kind regards,
> Torsten.
>
> > Am 20.11.2018 um 20:26 schrieb [e-mail]:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Web Authorization Protocol WG of the
> IETF.
> >
> >        Title           : OAuth 2.0 Security Best Current Practice
> >        Authors         : Torsten Lodderstedt
> >                          John Bradley
> >                          Andrey Labunets
> >                          Daniel Fett
> >       Filename        : draft-ietf-oauth-security-topics-10.txt
> >       Pages           : 38
> >       Date            : 2018-11-20
> >
> > Abstract:
> >   This document describes best current security practice for OAuth 2.0.
> >   It updates and extends the OAuth 2.0 Security Threat Model to
> >   incorporate practical experiences gathered since OAuth 2.0 was
> >   published and covers new threats relevant due to the broader
> >   application of OAuth 2.0.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> ---------- Forwarded message ----------
> From: Torsten Lodderstedt <[e-mail]>
> To: Brian Campbell <bcampbell=[e-mail]>
> Cc: oauth <[e-mail]>
> Bcc:
> Date: Tue, 20 Nov 2018 20:36:39 +0100
> Subject: Re: [OAUTH-WG] Token Binding & implicit
> I opt for (4) - Remove support/description of binding of access tokens
> issued from the authorization endpoint
>
> I think the potential solution we worked out (slide 6) is to complex and
> the security implications of the redirect via the resource servers are
> still unclear.
>
> > Am 18.11.2018 um 13:32 schrieb Brian Campbell <bcampbell=
> [e-mail]>:
> >
> > During the first OAuth session in Bangkok the question "what to do about
> token binding & implicit?" was raised. There was some discussion but
> session time was limited and we had to move on before any real consensus
> was reached.
> >
> > So I thought I'd bring the question to the WG list to generate some more
> discussion on the issue. It's also related, at least in part, to a couple
> of the other ongoing threads on the list about browser based apps and
> security practices.
> >
> > The slides from the session are linked below. Slides 5 & 6 try and
> explain the awkwardness of doing Token Binding with implicit. While slide 7
> lays out some (not very good) options for how to proceed.
> >
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-token-binding-00
> >
> > 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
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>