Open device-attest-01 support

[benlongo]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

There is no support for device-attest-01 TPM certificate flows in our open source packages.

#1545

Why is this needed?

There are many applications for device-attest-01 beyond just enterprise MDM, and it's a shame the implementation isn't open source.

[hslatman]

Hi @benlongo, what exactly are you looking for?

Our implementation of device-attest-01 does in fact support the tpm format. Our CLI has very basic support for it too. Our crypto package has several parts related to supporting TPMs. The part that's not in step-ca is the attestation CA, but in terms of responsibilities, implementation scope and business requirements, that part is supposed to be in an independent/different system, IMO. Then, after the attestation CA does its job, step-ca can authorize an ACME request using the tpm format.

We currently do make a few assumptions, so it's possible some changes are required to make it work for more cases. I think we're open to suggestions there, if needed.

[benlongo]

Hi @hslatman, thanks for your response. I believe I have misinterpreted the contents of #1545 which to me seemed to suggest that a critical component was missing to implement device-attest-01 with tpm, but after reading more carefully it appears my understanding of the protocol was flawed and I was conflating the attestation CA with step-ca.

[glance-]

I'd be happy with a simple example attestation CA service code and some documentation/examples that shows what the flow actually would be.

When I played around with this it was all way to opaque for me to be able to figure out what bits go where.

[hslatman]

@benlongo No problem 🙂 I have to admit that the tpm format and how to use it with step-ca is currently not that well explained/documented, so I understand where you're coming from.

@glance- I'll see what I can do. It'll probably be documentation based first.

[eamontaf]

@hslatman We are also interested in documentation around using the device-attest-01 flow with TPMs, so any documentation you can provide would be much appreciated.

[tashian]

We are developing a step-ca Pro edition, for commercial use. It's a drop-in replacement for step-ca and it will include more device identity and attestation features. Schedule a time to talk with us if you'd like to learn more!

[benlongo]

@tashian I'm interpreting your message as an indication that smallstep does not plan on making the TPM2 attestation workflows available in their open source packages. This seems to be contrary to @hslatman's previous comment which suggested that this was indeed part of the open source offering.

I would be very disappointed if this is the case, but understand the business case for it. If you do not plan on open sourcing device-attest-01 support, then please close this issue.

For what it's worth, I don't appreciate GitHub issues I've created being turned into sales pitches, and I don't anticipate other folks will appreciate it either.

[tashian]

Hi @benlongo, thanks for the feedback. I admit it's tricky to find a balance because I want people to know that we have commercial options that may be a better fit for them, but I'm not here to pollute the conversation with ads.

And I think you may have read a bit too much into my note, so I should clarify.

My understanding of this issue is that we already have device attestation features in open source—some added very recently—that are not very well documented. Our docs contain approximately one paragraph about device-attest-01. So, I think there’s more we could do and am discussing with Herman where the gaps are. Personally, I'd like to see a YubiKey example at minimum. I've opened smallstep/docs#321 to cover this part.

In the meantime, beyond our current docs, we have the following blog posts about device attestation, which might help you:

• Managed Device Attestation: ACME as the Bottom Turtle in Mobile Device Management
• Managed Device Attestation Explained

Now, on to the meat of the issue. It's true that we have no plans to release an open source TPM attestation CA, and if that's what this issue is really about, then we should close it.

However, I understood the issue to be a bit more broad. step-ca has always been focused on DevOps use cases. The value of this issue is that it advocates for "applications for device-attest-01 beyond just enterprise MDM" — TPM or otherwise — and that's something we should continue to explore. And that's the case for keeping it open, so people can voice their support and help shape future developments.

So, while our focus on DevOps for step-ca doesn't preclude further device attestation features, it does mean we need to serve the greatest need for DevOps first. And that need is for workload identity certificates. If device certs are to be in scope at all, they are secondary.

Finally, I want to say with humility that this is a sensitive topic for us right now. We are 5 years into the development of step-ca, yet the philosophical boundaries of this project are still emerging—especially the boundaries between open source and commercial. These boundaries are critical for discerning what is out of scope. We do not want this project to be burdened by unrelated or niche features that are not serving its core use cases. I would say that's been a huge risk for open source projects in the past, and it's one we'd like to avoid.

[benlongo]

@tashian thanks for the response - I do understand the difficulty in defining the boundaries both in broader scope, and where to split the line between commercial and open source. I also admit my understanding of the various pieces of the device-attest-01 protocol is limited and I haven't looked at it in awhile.

Perhaps it would be useful to explain my use case that ultimately motivated creating this issue because I think it is much more aligned with the scope of DevOps than MDM which feels more 'IT'. Our team has a large number of servers deployed at remote locations. These devices ultimately need to authenticate with AWS workloads. AWS offers IAM Roles Anywhere, and y'all even have an excellent blog post illustrating how to use this with step-ca: https://smallstep.com/blog/smallstep-and-aws-iam-roles-anywhere/. My ultimate goal is to utilize the TPM2 on these servers with device-attest-01 to get IAM Roles Anywhere certificates onto these servers.

From my perspective, this is definitely in the scope of DevOps, although it does share almost identical technical structure to the MDM use case.

At a higher level, I think this kind of abstraction would be really useful for IoT device identity problems. ACME seems like a natural fit to me, and the use cases are definitely not restricted to just AWS. It seems possible to fully automate device enrollment with this kind of tech.

I don't know if there's any kind of technical approach to split the IT customer segment from the DevOps segment here but I hope I've made the case for this feature in the step-ca repo.

edit:
upon more searching it looks like this use case is already being considered and might be in the commercial pipeline https://smallstep.com/integrations/aws-iam/