On 11 Apr 2024, at 21:15, Neil Madden <neil.e.mad...@gmail.com> wrote:
> I'm still digesting this draft, and generally supportive of it. However, I don't think it stops the attack you mention here, which sounds similar to threats that Ryan Sleevi discussed for FastFed in [1]. Essentially, in the current OIDC model, an attacker that briefly compromises the jwks_uri of an OP (e.g. through a mis-issued TLS cert) can serve a JWK Set containing public keys under their own control with a long Cache-Control header. Clients then might blindly cache that key set even beyond the time when the certificate is revoked and the rightful owner restored. > > But I think this attack is basically the same even with PIKA. The attacker in this case just uses their mis-issued cert to sign the PIKA and serve that instead, perhaps putting a really long "exp" claim in it so that clients cache it for a really long time. The only thing that would stop that is if the draft insisted that clients regularly perform an OCSP or CRL lookup on the cert in the x5c chain to make sure it hasn't been revoked. But that would completely negate the benefits of avoiding clients all hitting the OP jwks_uri: we've just shifted the burden from the OP to the CA. I am also supportive of this draft. Chain of Trust is a real problem in JWT issuance, and it's nice to see a simple solution that addresses it. Regarding Neil's attack above, rather than requiring clients to separately do OCSP or CRL, you could envision an OCSP stapling-like approach that could include a signature over a timestamped PIKA as a "staple" in a JWT, which moves up the proof of issuer validity to the time of issuance of the JWT, rather than just the last time you retrieved the PIKA. If you see a new PIKA staple, you know you need to fetch again. If you see a staple for a PIKA you've already cached, then you know it hasn't been revoked. You could additionally layer this approach by stapling the PIKAs themselves, where the PIKA staples are periodically updated to assert continued validity of the signing certificate. With such a system, you can provide guarantees regarding validity latency down the entire signature chain. - John
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
