On Mon, Feb 15, 2021 at 3:34 AM <oauth-requ...@ietf.org> wrote:
> Send OAuth mailing list submissions to > oauth@ietf.org > > 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 > oauth-requ...@ietf.org > > You can reach the person managing the list at > oauth-ow...@ietf.org > > 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 <phili...@pragmaticwebsecurity.com> > To: Neil Madden <neil.mad...@forgerock.com> > Cc: Vittorio Bertocci <vittorio.berto...@auth0.com>, oauth@ietf.org > Subject: Re: [OAUTH-WG] Token Mediating and session Information > Backend For Frontend (TMI BFF) > Message-ID: > <8b710018-3605-483d-b4a8-191a5bbff...@pragmaticwebsecurity.com> > Content-Type: text/plain; charset="utf-8" > > > > > On 15 Feb 2021, at 11:50, Neil Madden <neil.mad...@forgerock.com> wrote: > > > >> On 15 Feb 2021, at 10:26, Philippe De Ryck < > phili...@pragmaticwebsecurity.com> wrote: > >> > >>> On 15 Feb 2021, at 11:14, Neil Madden <neil.mad...@forgerock.com > <mailto:neil.mad...@forgerock.com>> wrote: > >>> > >>>> On 15 Feb 2021, at 08:32, Philippe De Ryck < > phili...@pragmaticwebsecurity.com <mailto: > phili...@pragmaticwebsecurity.com>> 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 <neil.mad...@forgerock.com> > To: Philippe De Ryck <phili...@pragmaticwebsecurity.com> > Cc: Vittorio Bertocci <vittorio.berto...@auth0.com>, oauth@ietf.org > Subject: Re: [OAUTH-WG] Token Mediating and session Information > Backend For Frontend (TMI BFF) > Message-ID: <17812f95-7350-4595-9867-ef9d9452c...@forgerock.com> > 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 < > phili...@pragmaticwebsecurity.com> wrote: > > > > ? > >> > >>> On 15 Feb 2021, at 11:50, Neil Madden <neil.mad...@forgerock.com> > wrote: > >>> > >>>> On 15 Feb 2021, at 10:26, Philippe De Ryck < > phili...@pragmaticwebsecurity.com> wrote: > >>> > >>>>> On 15 Feb 2021, at 11:14, Neil Madden <neil.mad...@forgerock.com> > wrote: > >>>>> > >>>>>> On 15 Feb 2021, at 08:32, Philippe De Ryck < > phili...@pragmaticwebsecurity.com> 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 <vladi...@connect2id.com> > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Authorization Header Encoding > Message-ID: <97a82c6d-1410-a9a9-a7aa-e8cff61a1...@connect2id.com> > 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 > > OAuth@ietf.org > > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 148, Issue 45 > ************************************** >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
