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 at https://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: > > 1. 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. > 2. PAR-enabled authorization servers can protect the integrity better > and protect against Mix-Up Attacks better if they ONLY accept PAR > requests. > 3. 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? > 4. Sender-constrained access tokens help against mix-up attacks when > the access token is targeted. > 5. 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
