-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Self-signed WITs #54
Comments
@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. |
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. I'm not arguing that Self-signed WIT should be the only way to go, just that it should be an option to implement. |
My intuition is that the authority signed WIT would also be obtained during this stage. And the general model in the document remains unchanged. |
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. |
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? |
Yes, the Destination Workload must validate that the For the self-signed WIT, For the self-signed WIT:
|
Discussion: on hold for -01. |
I've proposed an alternate approach to conveying the Proof-of-possession based on Transport-layer security in Issue #75 |
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.
The text was updated successfully, but these errors were encountered: