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

[Joey Galvin <[e-mail]>]

On Mon, Feb 15, 2021 at 3:34 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: Token Mediating and session Information Backend For
>       Frontend (TMI BFF) (Philippe De Ryck)
>    2. Re: Token Mediating and session Information Backend For
>       Frontend (TMI BFF) (Neil Madden)
>    3. Re: Authorization Header Encoding (Vladimir Dzhuvinov)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 15 Feb 2021 12:09:10 +0100
> From: Philippe De Ryck <[e-mail]>
> To: Neil Madden <[e-mail]>
> Cc: Vittorio Bertocci <[e-mail]>, [e-mail]
> Subject: Re: [OAUTH-WG] Token Mediating and session Information
>         Backend For Frontend (TMI BFF)
> Message-ID:
>         <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> >
> > On 15 Feb 2021, at 11:50, Neil Madden <[e-mail]> wrote:
> >
> >> On 15 Feb 2021, at 10:26, Philippe De Ryck <
> [e-mail]> wrote:
> >>
> >>> On 15 Feb 2021, at 11:14, Neil Madden <[e-mail]
> <mailto:[e-mail]>> wrote:
> >>>
> >>>> On 15 Feb 2021, at 08:32, Philippe De Ryck <
> [e-mail] <mailto:
> [e-mail]>> wrote:
> >>>>
> >>>> [...]
> >>>>
> >>>> Compared to using a worker for handling RTs, I believe the TMI-BFF
> only adds a single security benefit: an attacker is no longer able to run a
> silent flow to obtain a fresh set of tokens (since the client is now a
> confidential client).
> >>>
> >>> But they can just call the bff-token endpoint to do the same. If there
> is a security advantage, IMO it is as a defence in depth against open
> redirects, unicode normalisation attacks (ie not validating the
> redirect_uri correctly at the AS), etc.
> >>
> >> A Web Worker and the TMI-BFF both encapsulate the RT and only expose
> the (short-lived) AT.
> >
> > I don?t think this distinction matters at all from a security point of
> view. It?s the AT that attackers are after - why bother with a RT if I can
> just call the bff-token endpoint to get a new AT every time?
>
> Getting an AT from the BFF (or a worker) is an ?online? attack, which only
> works as long as the application/malicious code is loaded in the browser of
> the user.
>
> Stealing a working refresh token (e.g., with a silent flow) is an
> ?offline? attack, which gives long-term access (lifetime of the RT),
> independent of the state of the application in the user?s browser.
>
> There is a clear distinction, but whether that matters is a different
> discussion. It depends on how the application used, and how token lifetimes
> are configured. FWIW, the DPoP threat model makes the same distinction
> ("Stolen token (XSS)? vs ?XSS (Victim is online)?) here:
> https://danielfett.de/2020/05/04/dpop-attacker-model/ <
> https://danielfett.de/2020/05/04/dpop-attacker-model/>
>
> Philippe
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210215/9caa8a97/attachment.htm
> >
>
> ------------------------------
>
> Message: 2
> Date: Mon, 15 Feb 2021 11:15:47 +0000
> From: Neil Madden <[e-mail]>
> To: Philippe De Ryck <[e-mail]>
> Cc: Vittorio Bertocci <[e-mail]>, [e-mail]
> Subject: Re: [OAUTH-WG] Token Mediating and session Information
>         Backend For Frontend (TMI BFF)
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> Yes, I?ve argued against this distinction for DPoP too. Since the first
> days of HttpOnly attackers learnt to proxy requests through the browser (as
> you know of course). This is not only to bypass the restrictions but it?s
> also just much better for the attacker because it hides their traffic and
> origin. People are online all the time now, so this is at best a mild
> inconvenience.
>
> ? Neil
>
> > On 15 Feb 2021, at 11:09, Philippe De Ryck <
> [e-mail]> wrote:
> >
> > ?
> >>
> >>> On 15 Feb 2021, at 11:50, Neil Madden <[e-mail]>
> wrote:
> >>>
> >>>> On 15 Feb 2021, at 10:26, Philippe De Ryck <
> [e-mail]> wrote:
> >>>
> >>>>> On 15 Feb 2021, at 11:14, Neil Madden <[e-mail]>
> wrote:
> >>>>>
> >>>>>> On 15 Feb 2021, at 08:32, Philippe De Ryck <
> [e-mail]> wrote:
> >>>>>>
> >>>>> [...]
> >>>>>
> >>>>> Compared to using a worker for handling RTs, I believe the TMI-BFF
> only adds a single security benefit: an attacker is no longer able to run a
> silent flow to obtain a fresh set of tokens (since the client is now a
> confidential client).
> >>>>
> >>>> But they can just call the bff-token endpoint to do the same. If
> there is a security advantage, IMO it is as a defence in depth against open
> redirects, unicode normalisation attacks (ie not validating the
> redirect_uri correctly at the AS), etc.
> >>>
> >>> A Web Worker and the TMI-BFF both encapsulate the RT and only expose
> the (short-lived) AT.
> >>
> >> I don?t think this distinction matters at all from a security point of
> view. It?s the AT that attackers are after - why bother with a RT if I can
> just call the bff-token endpoint to get a new AT every time?
> >
> > Getting an AT from the BFF (or a worker) is an ?online? attack, which
> only works as long as the application/malicious code is loaded in the
> browser of the user.
> >
> > Stealing a working refresh token (e.g., with a silent flow) is an
> ?offline? attack, which gives long-term access (lifetime of the RT),
> independent of the state of the application in the user?s browser.
> >
> > There is a clear distinction, but whether that matters is a different
> discussion. It depends on how the application used, and how token lifetimes
> are configured. FWIW, the DPoP threat model makes the same distinction
> ("Stolen token (XSS)? vs ?XSS (Victim is online)?) here:
> https://danielfett.de/2020/05/04/dpop-attacker-model/
> >
> > Philippe
> >
> >
>
> --
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210215/6d5945f3/attachment.htm
> >
>
> ------------------------------
>
> Message: 3
> Date: Mon, 15 Feb 2021 13:34:10 +0200
> From: Vladimir Dzhuvinov <[e-mail]>
> To: [e-mail]
> Subject: Re: [OAUTH-WG] Authorization Header Encoding
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Justin,
>
> Thanks for alerting us on this development.
>
> +1 for keeping the updated HTTP semantics unencumbered by the
> Authorization header formatting in RFC 6750.
>
> IMO revising the RFC 6750 to reflect that is too late now, as few people
> will notice. So updating the Bearer header definition in OAuth 2.1 seems
> like the most sensible move. I expect OAuth 2.0 implementers who
> maintain their software to pick up the 2.1 spec, sooner or later.
>
> Vladimir
>
>
> On 12/02/2021 00:01, Justin Richer wrote:
> > The HTTP Working Group opened an issue for discussion in relation to
> > the updated HTTP semantics specification. The core of the issue is the
> > format of the ?Authorization? header, which of course gets used by the
> > ?Bearer? scheme defined in RFC6750.
> >
> > https://github.com/httpwg/http-core/issues/733
> >
> > As it turns out, Bearer defines a more limited character set than is
> > allowed by core HTTP, and doesn?t follow the HTTP guidelines and
> > definitions for the Authorization header. There were a few
> > observations on the call:
> >
> > ?- The Bearer spec was limited because OAuth tokens were also allowed
> > in HTTP URLs and form parameters (and therefore had to have a more
> > limited character set)
> > ?- In practice people don?t actually restrict the values they put into
> > this field; pretty much any implementation is just going to
> > concatenate whatever access token value they get to the magic word
> > ?Bearer? and send it
> > ?- It?s not likely (or in my opinion proper) for the HTTP spec to
> > change to address the oddities of RFC6750 and decisions that were made
> > many years ago
> >
> > So the question is, what do we do about it? We could do a revision of
> > 6750 that reflects reality better, pretty much just changing the ABNF.
> >
> > Or, we could update the definition of the Bearer header in the
> > upcoming OAuth 2.1 specification.
> >
> > Are there other options?
> >
> > ?? Justin
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> --
> Vladimir Dzhuvinov
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210215/10958cdf/attachment.htm
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 4007 bytes
> Desc: S/MIME Cryptographic Signature
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210215/10958cdf/attachment.p7s
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 148, Issue 45
> **************************************
>