The mechanism in the draft provides some separation between the trust establishment and distribution which is useful. This is definitely applicable to the use cases described in the draft and I agree with Ethan that it can help in other areas as well depending upon how things are deployed. I support this draft.
Joe On Thu, Apr 11, 2024 at 7:16 PM Ethan Heilman <eth...@gmail.com> wrote: > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
