Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

TLS on Web Servers is nearly ubiquitous now and works great. Trying to use mutual TLS on many platforms results in a nearly intractable user experience, where the end-users are asked to install certificates into certificate stores. Success rates for those UXs are very low. And it's even worse

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

I agree with Torsten, plus we're getting sender-constrained refresh tokens for said public clients and SPAs so that the AS doesn't have to (according to the browser based apps draft) rotate them, we all know the pain SPA developers have with those. S pozdravem, *Filip Skokan* On Fri, 22 Nov 201

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Mike, > On 22. Nov 2019, at 16:00, Mike Jones > wrote: > > TLS on Web Servers is nearly ubiquitous now and works great. Trying to use > mutual TLS on many platforms results in a nearly intractable user experience, > where the end-users are asked to install certificates into certificate

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Torsten - thanks for the reply. Responses in line. Grüsse Rob On Fri, 22 Nov 2019 at 07:59, Torsten Lodderstedt wrote: > Hi Rob, > > > On 22. Nov 2019, at 15:52, Rob Otto 40pingidentity@dmarc.ietf.org> wrote: > > > > Hi everyone > > > > I'd agree with this. I'm looking at DPOP as an al

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Rob, I agree that managing roots of trust, validating/OCSP etc is not "easy" per se, but the MTLS setup gets really simple with the Self-Signed Certificate Mutual-TLS Method and we made sure combined traffic is simple to signal by t

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Rob, > On 22. Nov 2019, at 16:10, Rob Otto > wrote: > > Hi Torsten - thanks for the reply.. > > Responses in line. > > Grüsse > Rob > > On Fri, 22 Nov 2019 at 07:59, Torsten Lodderstedt > wrote: > Hi Rob, > > > On 22. Nov 2019, at 15:52, Rob Otto > > wrote: > > > > Hi everyone > >

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

I hear you about the difference between Web apps and native apps, Torsten. But using different mechanisms for different application types is a cost in and of itself. It's good to understand the tradeoffs. -- Mike From: OAuth on behalf of Torsten Lodderstedt

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

I couldn't agree more. I think we should, again, try to find a way to utilise TLS in the browser as well. > On 22. Nov 2019, at 16:50, Mike Jones > wrote: > > I hear you about the difference between Web apps and native apps, Torsten. > But using different mechanisms for different applicatio

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Another dimension on SPA is that lots of 1P deployments use only SPA. For them, there is only one type of deployment. On Fri, Nov 22, 2019 at 4:50 PM Mike Jones wrote: > I hear you about the difference between Web apps and native apps, > Torsten. But using different mechanisms for different app

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On 22 Nov 2019, at 07:13, Dick Hardt wrote: > > On Fri, Nov 22, 2019 at 3:08 PM Neil Madden > wrote: > On 22 Nov 2019, at 01:42, Richard Backman, Annabelle > wrote: >> There are key distribution challenges with that if you are doing

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On 22 Nov 2019, at 07:53, Torsten Lodderstedt wrote: > > > >> On 22. Nov 2019, at 15:24, Justin Richer wrote: >> >> I’m going to +1 Dick and Annabelle’s question about the scope here. That was >> the one major thing that struck me during the DPoP discussions in Singapore >> yesterday: we d

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

The main concern about token replay in a SPA is that the access token may be extracted from the app, such as via XSS. Using the Web Crypto API has the advantage of being able to generate a public private key pair where the JS code can't access the private key at all, it can only be used to sign thi

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

It's not a different threat profile. This is the same assumption people made when introducing HttpOnly cookies, which just led to attackers switching to proxy everything through the browser as per things like https://beefproject.com . (This is actually nicer for the at

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi all, For browser based apps it is basically limitations of Fetch API that prevent MTLS binding, as Fetch uses client certificate dialogs and stores. Does it make sense to suggest browser vendors fix the Fetch API to better support MTLS? For example if Fetch API allowed setting up a MTLS requ

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Neil, > On 22. Nov 2019, at 18:08, Neil Madden wrote: > > On 22 Nov 2019, at 07:53, Torsten Lodderstedt > wrote: >> >> >> >>> On 22. Nov 2019, at 15:24, Justin Richer wrote: >>> >>> I’m going to +1 Dick and Annabelle’s question about the scope here. That >>> was the one major thing th

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

I would love see this happen! Note: you would also need to create a cert. > On 22. Nov 2019, at 19:38, Petteri Stenius > wrote: > > Hi all, > > For browser based apps it is basically limitations of Fetch API that prevent > MTLS binding, as Fetch uses client certificate dialogs and stores. Doe

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> Yes of course. But this is the HMAC *tag* not the original key. Sure. And if the client attenuates the macaroon, it is used as a key that the client proves possession of by presenting the chained HMAC. Clients doing DPoP aren’t proving possession of the “original key” (i.e., a key used to gener

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> I would argue TLS basically prevents leakage and not replay Doesn’t token binding, which is esentially a TLS extension, prevent some forms of token replay? -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On Nov 22, 2019, at 7:26 AM, Richard Backman, Annabelle > wrote: >

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Torsten, On 22 Nov 2019, at 12:15, Torsten Lodderstedt wrote: > > Hi Neil, > >> On 22. Nov 2019, at 18:08, Neil Madden wrote: >> >> I think the phrase "token replay" is ambiguous. Traditionally it refers to >> an attacker being able to capture a token (or whole requests) in use and >> th

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

The dichotomy of "TLS working" and "TLS failed" only applies to a single TLS connection. In non-end-to-end TLS environments, each TLS terminator between client and RS introduces additional token leakage/exfiltration risk, irrespective of the quality of the TLS connections themselves. Each termin

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Hi Neil, > On 22. Nov 2019, at 20:50, Neil Madden wrote: > > Hi Torsten, > > On 22 Nov 2019, at 12:15, Torsten Lodderstedt wrote: >> >> Hi Neil, >> >>> On 22. Nov 2019, at 18:08, Neil Madden wrote: >>> >>> I think the phrase "token replay" is ambiguous. Traditionally it refers to >>> an a

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> On 22. Nov 2019, at 21:21, Richard Backman, Annabelle > wrote: > > The dichotomy of "TLS working" and "TLS failed" only applies to a single TLS > connection. In non-end-to-end TLS environments, each TLS terminator between > client and RS introduces additional token leakage/exfiltration ris

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

The service provider doesn't own the entire connection. They have no control over corporate or government TLS gateways, or other terminators that might exist on the client's side. In larger organizations, or when cloud hosting is involved, the service team may not even own all the hops on their

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> On 22. Nov 2019, at 22:12, Richard Backman, Annabelle > wrote: > > The service provider doesn't own the entire connection. They have no control > over corporate or government TLS gateways, or other terminators that might > exist on the client's side. In larger organizations, or when cloud

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

> how are cookies protected from leakage, replay, injection in a setup like > this? They aren't. But my primary concern here isn't web browser traffic, it's calls from services/apps running inside a corporate network to services outside a corporate network (e.g., service-to-service API calls tha

[OAUTH-WG] WGLC review of draft-ietf-oauth-security-topics-13

Hi, All of my comments on oauth-security-topics-13 are remarks/questions/suggestions for clarification in the document, i.e., I do not have any fundamental objections. Overall, the draft is, in my opinion, in good shape to be published and as already discussed, open points can be updated later. I

Re: [OAUTH-WG] WGLC review of OAuth 2.0 Security Best Current Practice by Mike Jones

On Wed, Nov 20, 2019 at 03:40:34AM +, Mike Jones wrote: > I did a complete read of > draft-ietf-oauth-security-topics-13. > My review comments follow, divided into substantive and editorial sections. > > SUBSTANTIVE > [...] >