Great! Just drop me an email if you need support. > On 4. Sep 2020, at 15:07, Karsten Meyer zu Selhausen > <karsten.meyerzuselhau...@hackmanit.de> wrote: > > I am fairly new to this working group (and the IETF in general), so I will > probably need some guidance, but I would be happy to help better defining > mix-up preventions. I will start to work on an ID. > > Best regards, > Karsten > > On 29.08.2020 14:34, Torsten Lodderstedt wrote: >>> On 11. Aug 2020, at 08:20, Karsten Meyer zu Selhausen >>> <karsten.meyerzuselhau...@hackmanit.de> >>> wrote: >>> >>> Hi all, >>> >>> I think we all agree that proper countermeasures of mix-up attacks should >>> definitely be part of the BCP and 2.1 due to the severe impact successful >>> mix-up attacks have. >>> Theoretically speaking every client which supports multiple AS is >>> potentially vulnerable to mix-up attacks. While in practice it might seem >>> unlikely it is possible that one of the honest AS the client supports gets >>> compromised and can be utilized for a mix-up attack. >>> >>> In a previous thread of last November ( >>> https://mailarchive.ietf.org/arch/msg/oauth/A7F5xSEa8DdfxHKWHW3Mqol_a4A/ >>> ) I discussed why “use distinct redirect URIs for each AS” is not an >>> effective countermeasure against mix-up attacks (if dynamic client >>> registration is used). I would argue that this is especially important for >>> mobile applications, SPAs, and other native applications because it is very >>> common for them to use dynamic client registration. Many iOS applications >>> now must support multiple AS since Apple forces the support for “Sign in >>> with Apple” if any single sign-on provider is supported. This policy makes >>> mix-up attacks applicable. >>> >>> I fully agree with Daniel, Brian, and Mike that it is important to define >>> and register the “iss” parameter properly to ensure that both clients and >>> AS understand and use it in the correct way. I understand that OAuth 2.1 is >>> not meant to introduce and define new parameters but I strongly suggest >>> that the “iss” parameter should be introduced and defined elsewhere so that >>> it can be natively included in 2.1. In other words the “iss” parameter >>> should be integrated in 2.1 the same way PKCE is: the initial definition of >>> the parameter(s) is in another document (RFC 7636 in the case of PKCE) and >>> then included in 2.1. >>> >>> What do you think would be the best place to define and register the “iss” >>> parameter? Would it be worthwhile to reactivate and update >>> “draft-ietf-oauth-mix-up-mitigation”? >>> >> That’s a decision of the authors. Alternatively, a new small draft >> (referring to the BCP’s attack description) should do the job as well. Mind >> to write an ID? :-) >> >> >>> Best regards, >>> >>> Karsten >>> >>> >>> >>> On 18.06.2020 22:49, Mike Jones wrote: >>> >>>> I support documenting the use of the issuer to mitigate mix-up attacks. >>>> Note that while issuer was first defined by OpenID Connect, it became art >>>> of OAuth 2.0 in RFC 8414 - OAuth 2.0 Authorization Server Metadata. >>>> >>>> -- Mike >>>> >>>> From: OAuth >>>> <oauth-boun...@ietf.org> >>>> On Behalf Of Brian Campbell >>>> Sent: Thursday, June 18, 2020 1:32 PM >>>> To: Daniel Fett >>>> <f...@danielfett.de> >>>> >>>> Cc: oauth >>>> <oauth@ietf.org> >>>> >>>> Subject: [EXTERNAL] Re: [OAUTH-WG] Mix-Up Revisited >>>> >>>> In my (probably simplistic) understanding of things, the root underlying >>>> issue that allows for mix-up in its variations is the lack of anything >>>> identifying the AS in the authorization response. Following from that, >>>> introducing and using an `iss` authorization response parameter has always >>>> seemed like the most straightforward approach for mitigating the issue >>>> (which was part of the draft-ietf-oauth-mix-up-mitigation but other >>>> parameters were also included and, for reasons I'm not sure about, >>>> interest in that work faded in favor of telling clients to use per AS >>>> redirect URIs) . Though for the `iss` authorization response parameter to >>>> be effective, all parties involved need to know about it and act on it. So >>>> I think it'd need to be something more than a passing recommendation in >>>> the BCP. It should be defined, registered, explained, etc.. Actually >>>> introducing a new parameter is maybe going beyond the expected scope of >>>> the BCP (or 2.1). But maybe that's ok, if we're at least more intentional >>>> about it. >>>> >>>> On Sun, Jun 7, 2020 at 7:53 AM Daniel Fett >>>> <f...@danielfett.de> >>>> wrote: >>>> Hi all, >>>> I was wondering if we should move towards introducing and (more >>>> explicitly) recommending the iss parameter in the security BCP, for the >>>> reasons laid out below and in the article (which is now >>>> athttps://danielfett.de/2020/05/04/mix-up-revisited/). >>>> >>>> Any thoughts on this? >>>> >>>> -Daniel >>>> >>>> Am 04.05.20 um 19:34 schrieb Daniel Fett: >>>> 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 JARM to prevent mix-up attacks? >>>> I wrote down several attack variants and configurations in the following >>>> document: >>>> https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html >>>> >>>> >>>> The key takeaways are: >>>> >>>> • The security BCP needs to make clear that per-AS redirect URIs are >>>> only sufficient if OAuth Metadata is not used to resolve multiple issuers. >>>> Otherwise, per-Issuer redirect URIs or the iss parameter MUST be used. >>>> • PAR-enabled authorization servers can protect the integrity better >>>> and protect against Mix-Up Attacks better if they ONLY accept PAR requests. >>>> • We should emphasize the importance of the iss parameter (or issuer) >>>> in the authorization response. Maybe introduce this parameter in the >>>> security BCP or another document? >>>> • Sender-constrained access tokens help against mix-up attacks when the >>>> access token is targeted. >>>> • Sender-constraining the authorization code (PAR + PAR-DPoP?) might be >>>> worth looking into. >>>> I would like to hear your thoughts! >>>> >>>> -Daniel >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> 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 >>>> >>>> >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> -- >>> Karsten Meyer zu Selhausen >>> IT Security Consultant >>> Phone: +49 (0)234 / 54456499 >>> Web: >>> >>> https://hackmanit.de >>> >>> | IT Security Consulting, Penetration Testing, Security Training >>> >>> Unsere nächste Live Online-Schulung zur Sicherheit von OAuth und OpenID >>> Connect am 24.09 + 25.09: >>> >>> >>> https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020 >>> >>> >>> >>> Hackmanit GmbH >>> Universitätsstraße 60 (Exzenterhaus) >>> 44789 Bochum >>> >>> Registergericht: Amtsgericht Bochum, HRB 14896 >>> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. >>> Christian Mainka, Dr. Marcus Niemietz >>> >>> _______________________________________________ >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > -- > Karsten Meyer zu Selhausen > IT Security Consultant > Phone: +49 (0)234 / 54456499 > Web: > https://hackmanit.de > | IT Security Consulting, Penetration Testing, Security Training > > Unsere nächste Live Online-Schulung zur Sicherheit von OAuth und OpenID > Connect am 24.09 + 25.09: > > https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020 > > > Hackmanit GmbH > Universitätsstraße 60 (Exzenterhaus) > 44789 Bochum > > Registergericht: Amtsgericht Bochum, HRB 14896 > Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. > Christian Mainka, Dr. Marcus Niemietz >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
