Self-signed WITs

[kenmccracken-google]

In "Section 4.1. The Workload Identity Token", the spec states:

It is issued by the Identity Server and binds a public key to the workload identity.

Could we relax this to allow for self-signed WITs as well?

Self-signed WITs could reduce potential load on the Identity Server, and mitigate availability concerns on this centralized issuer. These WITs would be signed by the Workload's Private Key. To validate the WIT signature, we could build on the X.509 certificate credentials that have already been distributed to Workloads. All we would need is to convey the chain to a Trust Anchor via the x5c claim.

In Section 6.1 WIMSE Identity, the spec states:

The association of an issuer, trust domain and a cryptographic trust root MUST be communicated securely out of band.

If we already have machinery to distribute Trust Anchors for a Trust Domain out of band, the certificate chain can be validated against an appropriate Trust Anchor.

[yaronf]

@kenmccracken-google I'm a bit confused by your assumptions here. According to the current draft (and we may have not been clear on that) the workload only needs a certificate if it is going to use Mutual TLS. If it's using any of the app-level options (Sec. 4.2 or 4.3), it would only request a WIT from the Identity Server. I expect there will be some workloads that are provisioned with both a cert and a WIT, but that wouldn't be common.

[kenmccracken-google]

Hi Yaron, thanks for your response and apologies for not being clear on my assumptions.

I think we should consider as a base case mTLS authentication between Workloads. To support this base case, Workload agents generate private key/public key pairs, construct CSRs, and request and receive X.509 Certificates, after passing through the Attestation steps described in the draft WIMSE Architecture document. Workload agents also bootstrap and periodically update Trust Domains and their corresponding Trust Bundles.

One option is to contact a central IdP for a centrally-signed WIT, with the proof-of-possession coming in the form of one of (Sec. 4.2 or 4.3); as is currently in the draft. I filed this issue to consider supporting an additional use case: a self-signed WIT option.

For the self-signed WIT option, the Workload agent can use the workload's private key and X.509 Certificate chain to construct a self-signed WIT. The X.509 Certificate chain can be conveyed in the x5c token header of the WIT. The Workload can establish mTLS communication with compatible destination Workloads, together with a self-signed WIT.

Here's a more detailed diagram:

graph LR
A(Identity Server)
B(Workload Agent) -->|Workload API| A(Identity Server)
A -->|x509 cred| B
B -->|X509 cred| C(Source Workload)
C(Source Workload) -->|mTLS & WIT| D(Proxy)
    B -->|Generate WIT| B
    B -->|WIT cred| C
    D -->|Add x5t header| D
    D -->|WIT & x5t| E(Destination Workload)
    E -->|validate WIT & x5t| E

When a Proxy is deployed between the source Workload and the destination Workload, mTLS is terminated at the Proxy. The Proxy can terminate mTLS, and add an x5t header containing the fingerprint of the client's X.509 Certificate that was used in the mTLS handshake. The self-signed WIT could be forwarded by the Proxy intact in a request header, together with the x5t header. The destination Workload can then validate the Source Workload's self-signed WIT and the x5t using the information provided in the request, together with the corresponding Trust Domain's Trust Bundles.

I'm not arguing that Self-signed WIT should be the only way to go, just that it should be an option to implement.

[bc-pi]

... Workload agents generate private key/public key pairs, construct CSRs, and request and receive X.509 Certificates, after passing through the Attestation steps described in the draft WIMSE Architecture document. Workload agents also bootstrap and periodically update Trust Domains and their corresponding Trust Bundles.

My intuition is that the authority signed WIT would also be obtained during this stage. And the general model in the document remains unchanged.

[kenmccracken-google]

I'm a little worried that the Workload developers won't understand their responsibilities with respect to the many tokens, and could get it wrong, leading to bugs in issuance or validation that aren't necessarily in the core competence of the developer to resolve. That's why I thought a single token signed by the Workload Agent's private key might offer a simpler protocol for the Workload developer, allowing them to focus primarily on the business logic.

[jsalowey]

What identity is in the self-signed WIT? When you validate the key against the certificate do you also validate the identity in the WIT against an Identity in the certificate?

[kenmccracken-google]

sub would be the same as in the current draft:

• sub: The subject of the token, which is the identity of the workload, represented by a URI.

Yes, the Destination Workload must validate that the sub matches the one in the X.509 certificate SAN.

For the self-signed WIT, iss would be the Workload Identity URI. For the IdP-signed WIT, iss would be the IdP issuer URL.

For the self-signed WIT:

1. The Proxy MUST validate the mTLS handshake protocol parameters match the client's x.509 certificate.
2. The Proxy MAY validate the X.509 certificate chain to a known Trust Anchor for the X.509 certificate's SAN URI's TrustDomain.
3. The Proxy MUST compute the x5t#S256, and append it to each request originating from that client TLS connection.
4. The Destination Workload MUST validate the JWS signature.
5. The Destination Workload MUST validate the fingerprint from the Proxy matches the one computed from the leaf certificate found in the x5c chain.
6. The Destination Workload MUST validate the sub in the WIT matches with the exactly-one-URI-SAN from the leaf certificate found the x5c certificate chain.
7. The Destination Workload MUST validate the x5c certificate chain to a known and trusted TrustAnchor for the SAN's TrustDomain, a.k.a. using the appropriate TrustDomain's known TrustBundle.

[yaronf]

Discussion: on hold for -01.