> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
