Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt

Thanks William and nice to see you pop up on the list again. Your perspective and feedback is appreciated (and missed a little bit these days). Attempts to respond to things that seemed to warrant a response are inline below. On Sun, May 3, 2020 at 5:54 PM William Denniss wrote: > Hi Brian, et.

Re: [OAUTH-WG] May 4th Interim Meeting Material

All, You can find the meeting minutes and the link to the recording on the following link: https://datatracker.ietf.org/meeting/interim-2020-oauth-07/materials/minutes-interim-2020-oauth-07-202005041200 Thanks to *Jared Jennings* for taking these notes. Regards, Rifaat On Mon, May 4, 2020 at

Re: [OAUTH-WG] DPoP: Threat Model

On 4 May 2020, at 21:44, Daniel Fett wrote: > > Am 04.05.20 um 21:27 schrieb Philippe De Ryck: >> (https://beefproject.com ) rather than exfiltrating tokens/proofs. >>> As a sidenote: BeEF is not really XSS but requires a full browser >>> compromise. >>> >>

Re: [OAUTH-WG] DPoP: Threat Model

Am 04.05.20 um 21:27 schrieb Philippe De Ryck: > >>> (https://beefproject.com ) rather than >>> exfiltrating tokens/proofs. >> >> As a sidenote: BeEF is not really XSS but requires a full browser >> compromise. >> > > No, it’s not. The hook for BeEF is a single JS file, co

Re: [OAUTH-WG] DPoP: Threat Model

>> (https://beefproject.com ) rather than >> exfiltrating tokens/proofs. > As a sidenote: BeEF is not really XSS but requires a full browser compromise. > No, it’s not. The hook for BeEF is a single JS file, containing a wide variety of attack payloads that can be lau

Re: [OAUTH-WG] DPoP: Threat Model

Am 04.05.20 um 19:54 schrieb Neil Madden: > I mentioned another one in my recent email - BREACH attacks against > HTTP compression being used to steal access tokens in transit. Excellent point, I added that one. > > There’s a variant of the online XSS attacks in which the attacker just > proxies re

Re: [OAUTH-WG] DPoP: Threat Model

Hi Denis, We discussed these kinds of collusion attacks at great length previously on this list. My views on them have not changed. Am 04.05.20 um 20:06 schrieb Denis: > As soon as a software solution would be available to perform this > collaborative attack, everybody would be able to use it. T

Re: [OAUTH-WG] DPoP: Threat Model

Hi Daniel, Yes indeed. For another attack, please see my email sent to the list on 01/05/2020 at 10:47 (Paris time). The subject was: DPoP draft-ietf-oauth-dpop-0 Client collaborative attacks. When the JWT does not contain a sufficient number of attributes that would allow to identify the use

Re: [OAUTH-WG] DPoP: Threat Model

I mentioned another one in my recent email - BREACH attacks against HTTP compression being used to steal access tokens in transit. There’s a variant of the online XSS attacks in which the attacker just proxies requests through the victim’s browser (https://beefproject.com

[OAUTH-WG] Mix-Up Revisited

Hi all, to make substantiated recommendations for FAPI 2.0, the security considerations for PAR, and the security BCP, I did another analysis on the threats that arise from mix-up attacks. I was interested in particular in two questions: * Does PAR help preventing mix-up attacks? * Do we need

[OAUTH-WG] DPoP: Threat Model

Hi all, as mentioned in the WG interim meeting, there are several ideas floating around of what DPoP actually does. In an attempt to clarify this, if have unfolded the use cases that I see and written them down in the form of attacks that DPoP defends against: https://danielfett.github.io/notes/o

Re: [OAUTH-WG] May 4th Interim Meeting Material

I'll be taking notes here https://docs.google.com/document/d/1gVTUzkMFvS-XyrYBiXOqbUnl5zp5nlhZf57oKFY2bzc/edit?usp=sharing Of course, Rifaat will publish once complete. -Jared Skype:jaredljennings Signal:+1 816.730.9540 WhatsApp: +1 816.678.4152 On Sun, May 3, 2020 at 4:02 PM Rifaat Shekh-Yusef

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

Some review comments: Section 1: I think terms like “relatively simple” are subjective and should be left out. I don’t think the machinery of JWS signature verification (and associated security issues) is necessarily simple at all. “stronger methods … such as [RFC8705] or [token binding]” I wou

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Hello Benjamin, First of all, you don't need to use an aggressive language to state your opinion. Please follow BCP 54, i.e. RFC 7154, issued inMarch 2014 with the following title:"IETF Guidelines for Conduct". In particular: " Regardless of these individual differences, participants tre

Re: [OAUTH-WG] JWT profile and IdentityServer

Oh - and last thing I forgot to mention. We had the luxury of designing IdentityServer from the ground up after OIDC has been released. So it really was fine tuned to be a OIDC + OAuth implementation. Hence the strong semantics of the sub claim for both the OIDC and OAuth parts. We think this is r

Re: [OAUTH-WG] JWT profile and IdentityServer

Hey, No problem - this email was not intended to make you change the document. Just my conclusions. OK - let me just set the scene first * IdentityServer is not a “off the shelf” product or SaaS - it is a framework. IOW - developers have much greater flexibility and less constraints to implement

Re: [OAUTH-WG] JWT profile and IdentityServer

Thank you Dominick, very useful! I’d like to understand more about the security risks you mention. My goal is not to change your mind on the implementatio, just to make sure I better understand the general implication. >* the user info endpoint needs to do extra checking This is an interesting us

[OAUTH-WG] JWT profile and IdentityServer

Hey, Just some notes on applying the JWT profile to IdentityServer * we emit the at+jwt typ - that’s very useful * we emit iat in addition to nbf (if we would remove nbf, we would break the .NET JWT library from Microsoft - I guess that’s the reason AAD emits it as well) * we have an option to em