Hi Neil, I agree that PIKA would not protect against an attacker compromising a JWKS URI via a mis-issued TLS cert.
I was thinking of a simpler attack where the attacker compromises the server where a JWKS URI is hosted or the JWKS is stored. For instance consider an JWKS which is read from a database. An attacker could use a SQL injection to add their own key to the JWKS. Because such an attacker does not compromise any TLS certificates PIKA would defeat this attack (assuming the verifier required PIKA for that JWT issuer). Today, write access to a JWKS is sufficient to comprise the signing authority of a JWT issuer. With PIKA write access to a JWKS may not be sufficient to compromise the signing authority of a JWT issuer. Thanks, Ethan On Thu, Apr 11, 2024 at 5:15 PM Neil Madden <neil.e.mad...@gmail.com> wrote: > On 11 Apr 2024, at 01:12, Ethan Heilman <eth...@gmail.com> wrote: > > > I want to voice my support for this draft: Proof of Issuer Key Authority > (PIKA). The ability to reason about the past validity of JWKS is extremely > useful for using OIDC in signing CI artifacts and e2e encrypted > messaging.This includes what we are building at OpenPubkey ( > github.com/openpubkey/openpubkey) and also proposed security improvements > to software supply chain systems like SigStore ( > https://arxiv.org/pdf/2307.08201.pdf). > > I want to underscore the value of PIKA to increase the security of JWKS > URIs and OpenID Connect. Currently if an attacker compromises an OpenID > Provider's JWKS URI the attackers can substitute their own public keys and > impersonate any user to any relying parties who depend that OpenID > Provider. The effects of Google, Microsoft or Okta's JWKS URI being > controlled by a malicious party for even a few minutes could be > devastating. The widespread deployment of PIKA would remove this risk and > require that attackers compromise not only the JWKS URI but also the PIKA > signing keys. > > > 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. > > Perhaps I'm missing something? > > [1]: > https://docs.google.com/document/u/1/d/e/2PACX-1vQQ-FhNjW0ZhZVTnK1VG_87IBNZKBaJmweYZb1VBRdQCMAWXekqKfxdNl8wL6FWFDJ9pxXxpr66-GZp/pub?utm_source=illuminatedsecurity&utm_medium=email > > > -- Neil >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
