Managed Device Attestation - ACME - Request Authorization

Question

Created Jun ’22

Replies 2

Boosts 0

Views 1.6k

Participants 2

I'm curious about suggested workflows for a 3rd party ACME server handling a request for a managed device. Specifically, when the MDM server does not control the ACME server like it likely would when using the ACME payload for the MDM client identity.

i.e., an organization with a CA that can distribute client identities using ACME; how should ACME servers validate the request is authorized? The server, of course, would be able to validate that the attestation is valid from Apple, but how would an ACME server validate that the request is authorized for a device?

I would assume that the ACME server would use the ClientIdentifier key similarly to a SCEP challenge. And that identifier should be populated in MDM either as a static challenge or dynamically fetched by MDM from the ACME service?

Or possibly that the ACME service would need a connection (i.e., through a restful API) to the MDM server to validate it is a device under management and fetch the generated client identifier and therefore determine that the device is authorized to request certs from the enterprise CA?

It would be great if the device could attest that it is under management and have an OID for the check-in URL or the APNS topic is registered against. This might eliminate the ACME server's need to authorize a request against the MDM server or help improves the validation of the request etc.

In any case, I'm curious on folks' thoughts around this in general :)

Boost

Answer 1

Device Management Engineer OP

Apple

Jun ’22

You're right that the ClientIdentifier can work similarly to the SCEP challenge. ClientIdentifier management systems amount to some kind of coordination between the ACME server and the system that's generating the configuration profile containing an ACME payload (usually the MDM server). There's many ways to arrange it: It could be that the ACME server and MDM server agree on some ClientIdentifier generation scheme based on increasing counters or timestamps, or the MDM server asks the ACME server to issue a ClientIdentifier to embed in the profile, or the MDM server generates them and the ACME server verifies them when a certificate is requested.

But this is ultimately weak evidence. If the ClientIdentifier is fumbled at any step of the way, someone else could use it. That's why the only specifically recommended use is as a rate limiting system, so that the ACME server can quickly reject clients that don't have valid ClientIdentifiers.

So how does the ACME server know whether it should issue a cert? I think there's another way to look at the whole problem: What does the issued certificate represent? It's mainly proof that the ACME server has verified the identity of the device by evaluating the attestation. If that's all it represents, there's no disadvantage to just issuing a certificate for every request. Then later when the device uses the client identity to try to access a resource, the resource server can use the device's identity to query other parts of device posture: It can look up whether the device is currently managed. I think this is more of a "zero trust architecture". It's also a natural for that check to happen regularly, since management state may change. It can also get more posture information from the MDM server, such as whether the passcode policy is applied, whether security apps are currently installed, and other details that may be important to the resource server's trust evaluation.

If you want to centralize the check for management of the device by having only the ACME server validate management and device posture information that the MDM server collects, then the ACME server can contact the MDM server at issuance time. But thereafter some system should react when that state changes and revoke the certificate. This requires resource servers to perform revocation checks, or use something like OCSP stapling. This likely makes the resource servers simpler since many of them already do revocation checking, so they only need to trust the ACME CA. Revocation checking has its own drawbacks.

All the possible designs have trade-offs between security, complexity and performance. Managed Device Attestation is a building block that's very useful for creating a more secure architecture. It's up to the organization to incorporate it into the security architecture that best fits their needs.

1

Answer 2

Device Management Engineer OP

Apple

Jun ’22

It would be great if the device could attest that it is under management and have an OID for the check-in URL or the APNS topic is registered against. This might eliminate the ACME server's need to authorize a request against the MDM server or help improves the validation of the request etc.

The only properties that could potentially appear in attestations are things that the Secure Enclave did.

It's the OS's responsibility to enroll the device and keep track of the check-in URL, push topic, and other management-related properties. So to attest it, the OS would have to tell the Secure Enclave these properties. A compromised OS could lie to the Secure Enclave about these management properties. So to trust attestation of those properties, you'd have to trust the OS as well. And if you're trusting the OS, the attestation of that property isn't giving you any additional security over just asking the OS to report the property directly.

1