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 <http://github.com/openpubkey/openpubkey>)
> and also proposed security improvements to software supply chain systems like
> SigStore (https://arxiv.org/pdf/2307.08201.pdf
> <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
<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
