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
