-
Notifications
You must be signed in to change notification settings - Fork 410
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
Option to bind JWK provisioner tokens with CSR #1637
Comments
Quick note: Unlike certificates, there is no canonical "fingerprint" for CSRs as far as I know. Rather one would generate the message digest of the der format.
There is a rather 🔥 discussion on this right here: https://security.stackexchange.com/questions/262476/getting-fingerprint-of-certificate-signing-request |
@daFritz84, that was the idea, and that's exactly how the certificate fingerprint is calculated. |
@daFritz84 after our team discussion, some voices were not fully convinced about adding this. |
@maraino sure thing. I whipped up a quick sketch to illustrate my case: So I do have a scenario where an 'IoT device' is requesting a certifcate from the 'Certificate authority' in the cloud. The request is transfered via asynchronous communication (publish/subscribe). There is only segment-by-segment encrypted tunnels, and the CSR (as by the nature of async communication of Kafka and MQTT) cached at, at least, two other services. Hence I would prefer a strong binding between the JWT and the CSR. I hope I have described the scenario clearly, and this brings my point across. Btw. async communication (MQTT) was implemented due to low bandwidth/unreliable networks. In my threat model, the edge gateway or the proxy could be compromised to allow MITM attacks on the CSRs. |
@daFritz84, we will add support for this in our cli and certificates, it is not a high priority, so it can take some time. |
@maraino Thanks for the x-mas gift 😄, I'll take it. |
I've been working on a yet incomplete implementation where tokens for the JWK and X5C provisioners can have a confirmation claim, The payload of a token with this will look like: {
"aud": "https://ca.smallstep.com:9000/1.0/sign",
"cnf": {
"kid": "PJLNhtQoBE1yGN_ZKzr4Y2U5pyqIGiyyszkoz2raDOw"
},
"exp": 1703803318,
"iat": 1703803018,
"iss": "mariano@smallstep.com",
"jti": "458bd150aaa7ba0bf1b0c927f17e1f52e22954db64e3aaa3b7da92a4ddcdc832",
"nbf": 1703803018,
"sans": [
"mariano@smallstep.com"
],
"sha": "a78a850025c0c234385eda23d7192964ca56aa9d727f535653b0afb81c1e0559",
"sub": "mariano@smallstep.com"
} In this case, that When the JWK or X5C provisioner of the CA sees a token with that confirmation claim, it will validate that the fingerprint matches the provided CSR or SSH public key; if it does not, it will return a 403 error. Note that the fingerprint for a CSR will be based on the full CSR, not just the key. |
This commit allows to tie tokens with the provided CSR or SSH public key. Tokens with a confirmation claim kid (cnf.kid) will validate that the provided fingerprint (kid) matches the CSR or SSH public key. This check will only be present in JWK and X5C provisioners. Fixes #1637
This commit allows tying tokens with the provided CSR or SSH public key. Tokens with a confirmation claim kid (cnf.kid) will validate that the provided fingerprint (kid) matches the CSR or SSH public key. This check will only be present in JWK and X5C provisioners. Fixes #1637
This commit allows passing confirmation claims to tokens to tie the tokens with a provided CSR or SSH public key. Fixes smallstep/certificates#1637
This commit allows tying tokens with the provided CSR or SSH public key. Tokens with a confirmation claim kid (cnf.kid) will validate that the provided fingerprint (kid) matches the CSR or SSH public key. This check will only be present in JWK and X5C provisioners. Fixes #1637
This commit allows passing confirmation claims to tokens to tie the tokens with a provided CSR or SSH public key. The confirmation claim is implemented in the token command as well as the com commands that uses a given CSR or ssh public key. Those are: - step ca token - step ca sign - step ssh certificate --sign Fixes smallstep/certificates#1637
Description
In #1636, @daFritz84 proposes that binding JWT tokens for the JWK provisioner to a given CSR might be a good option to prevent some attacks.
Optionally, adding a new field in the token with a CSR fingerprint can be a good idea. Commands that generate their own token and CSR can always add the new field, and the JWK provisioner will validate it.
step ca token
can have an extra flag to add that fingerprint and a flag to pass a CSR to get the fingerprint from.It might also be a good idea to add a fingerprint to
x509util.CertificateRequest
, so it can be optionally checked in a template or in a webhook, although the raw CSR is also present in a webhook request.The text was updated successfully, but these errors were encountered: