SPIFFE JWT token security when talking to public Fulcio directly

[letmaik]

The document at https://github.com/sigstore/community/blob/main/docs/zero-trust-supply-chains.pdf says:

For publicly distributed artifacts, organizations have a few options. An internal build service can
request short-lived certificates from the public Fulcio instance directly. The organization
operating the build service can register with the public Fulcio by uploading their root trust
domain certificate and the SPIFFE ID corresponding to the workload for the build server,
something like spiffe://prod.acme.com/build. The build server can make API requests
directly to the public Fulcio instance and authenticate with its SPIFFE bundle.

I think this particular scenario introduces some trust issues. The organisation has to fully trust the public Fulcio instance to not leak the SPIFFE JWT token, since it can potentially be used to gain access to other systems of the organisation.

The SPIFFE docs also advise against using the JWT token if possible.

If X.509-SVID could be used instead, it would get rid of this particular issue.

[dlorenc]

How would the x509 SVIDs work here? I get the concern with replay attacks, but I think that's partially mitigated by using a custom audience field and the short expiration time.

[dlorenc]

See here for the audience field: https://github.com/spiffe/spiffe/blob/main/standards/JWT-SVID.md#32-audience

[letmaik]

Audience would work but only if you get a fulcio-specific token which I think is not how SPIFFE works. I think it issues SVID documents (JWT/X509) periodically to the workload/VM/... but not on demand scoped to some specific use case. So, you get a SVID that's scoped to all the systems you need to access. Please correct me if that's wrong, I'm not fully sure.

X509 SVIDs act as mutual TLS auth certs where the fulcio service would look at the cert instead of a token. Since you can't re-use a TLS session against another service it's safer than a token.

[dlorenc]

Audience would work but only if you get a fulcio-specific token which I think is not how SPIFFE works. I think it issues SVID documents (JWT/X509) periodically to the workload/VM/... but not on demand scoped to some specific use case

I don't think that's correct. See here for how to pass in an audience to the workloadAPI FetchJWTSVID call:
https://pkg.go.dev/github.com/spiffe/go-spiffe/v2/workloadapi#FetchJWTSVID

[letmaik]

You're right, makes sense. In that case it's "just" the replayability. If fulcio accepts TLS connections directly (not via an L7 load balancer) then it shouldn't be too hard to switch to X509 SVIDs.

[dlorenc]

We currently terminate ssl at the load balancer level.

What's the exact threat model? The requests are over TLS so I'm not sure I understand the MITM concern for stealing a SVID.

We could always work around replay concerns some other way with an in memory cache or a 1-1 relationship between SVIDs and issued certificates.

[letmaik]

The attack could be done by someone with access to the platforms where the load balancer or Fulcio is running. So either an inside attack or an outside hack. But given that monitors/auditors currently can't validate Fulcio's honest operation (Fulcio has to be trusted to only issue certs if an authentication took place, see also #80), fixing this particular replay problem wouldn't help much anyway. I'm happy to close this particular SPIFFE issue as solving it doesn't improve general security by much I think.

[dlorenc]

Thanks - I think you're correct overall, and this is eventually the role of the CT log Fulcio issues certs to. All Fulcio behavior should be auditable using these logs, so any misbehavior could be detected.

Combined with the Rekor log, you can actually trace any Fulcio misbehavior all the way from a mis-issued certificate to the artifacts that were signed, allowing for very fine-grained revocation.