Draft PR - "Margo Identity and Authorization Framework" (MIAF) SUP

[matlec]

First draft of the "Margo Identity and Authorization Framework" (MIAF) SUP for community feedback.

Background: Thoughts on Identity and Interoperability in Margo - From PR1 to GA

[phil-abb]

@margo/technical-wg - A new SUB has been started. Please take a look and talk with @matlec if you're interested in helping develop this SUP.

[phil-abb]

@matlec I'm not too familiar with SPIFFE yet. How much of this will work out of the box with an existing SPIFFE implementation, and how much of this is a custom Margo implementation?

[stormc]

With making this normative, i.e. mandatory, we're ruling out devices that cannot fulfill hardware trust anchor configurations such as constrained devices. Alike, there is no "standard" TPM (interface) on ARM systems as there is for x86. Furthermore, with this, you may encounter problems in certain markets.

So, what about, e.g., introducing a flag trusted || untrusted for devices managed in Margo? With this, you immediately see the trust status of devices but are still able to manage them. Making this mandatory may also prevent Margo adoption / transformation of brownfield scenarios in which field devices simply cannot be upgraded or even (re-)configured to meet this requirement.

[matlec]

Yeah, that's a valid concern. The current "Device Key Protection" section already allows storage of private keys without hardware protection:

- Keys **MUST** be generated and stored in secure hardware (TPM, Secure Element, or TEE) where available and **MUST NOT** be exportable.
- Where only software storage is possible, implementations **MUST** provide at-rest encryption, integrity protection, and OS/process isolation (e.g., dedicated key service with strict ACLs).

...but: even the (admittedly lax) requirements for software storage might be too much for constrained devices.

I think the right direction is something similar to what you're proposing: what do you think about introducing key protection classes that the device reports during enrollment? Something like:

Class	Description	Examples
hardware	Key in dedicated secure hardware, non-exportable	TPM, Secure Element, ARM TrustZone, ...
software-isolated	Key in software with OS-level process isolation and at-rest encryption	Linux with keyring, ...
software-basic	Key in software without isolation	Bare-metal MCU, ...

This would give the MIS and other components an indication on the security level supported by the device and allow components to have different policies based on different protection levels.

What do you think? Are those the "right" classes? Would a device simply report its class or we need any kind of attestation evidence? And should those classes drive policies (e.g., SVID lifetime, ...) or should this be deployment-specific? Open for any feedback...

[stormc]

Hm, what is now normative and what is optional? In other words, on what technologies / standards do we base upon and mark them as mandatory?

[matlec]

Does my comment to @phil-abb's comment answer your question? In response to another comment from @phil-abb, I defined the "Factory Certificate Method (mTLS)" as the interoperability baseline in the SUP.

[matlec]

@matlec I'm not too familiar with SPIFFE yet. How much of this will work out of the box with an existing SPIFFE implementation, and how much of this is a custom Margo implementation?

The SUP reuses SPIFFE for identity naming (SPIFFE IDs), credential formats (X.509-SVID, JWT-SVID), and trust distribution (Trust Bundles). Existing SPIFFE libraries and tooling can be used for SVID validation, Trust Bundle handling, and SPIFFE ID processing. Everything else - device bootstrap methods, the discovery document, enrollment / renewal / revocation APIs, the LDI / PDI / ESI binding model, and device replacement / lifecycle rules - is Margo-specific and would need to be implemented on top. The revised draft now includes a "Relationship to SPIFFE" section with a classification table that makes this boundary explicit.

[stormc]

Factory certificates / credentials means pre-shared authentication "material" such as pre-shared keys or pre-shared secrets?

[matlec]

I think the confusion here is partly caused by my wording. In the current SUP, "factory credentials" was intended to refer to X.509 certificates used by the "Factory Certificate" bootstrap methods, not to PSKs or symmetric secrets. But I agree that "credentials" is broader - I will fix that in the SUP.

Your comment also made me reflect on the term "factory certificate" itself. Right now that wording suggests manufacturer-provisioned bootstrap material. But the mechanism currently described is closer to "device presents a pre-provisioned certificate that the MIS trusts". This raises the broader question whether this method should be limited to manufacturer-issued certificates, or should we also cover operator-provisioned certificates? In the latter case, we might want to rename the term to e.g. "pre-provisioned bootstrap certificate". What do you think @stormc?

[matlec]

Slide deck presented to TWG

[nilanjan-samajdar]

High level comments for now on overall strategy for adopting this SUP and demarcation between the specification and implementation, will review from API perspective on the latest version of the SUP.

[nilanjan-samajdar]

In this statement, It is not clear if "WFM Client Identity" is within the scope of the IMS in this SUP.

[matlec]

Hey @nilanjan-samajdar! Please review the Future Work section that I added to the SUP since you left your comment. Does that resolve your question?

[nilanjan-samajdar]

Maybe this definition is needed for the 'Margo Identity' to function with the SPIFFE framework ?

[matlec]

I'm not exactly sure I understood your question. The ESI serves multiple purposes in the framework:

1. It enables idempotent enrollment of devices / identities (it makes enrollment safe to retry across network failures without creating duplicate identities).
2. It gives the MIS a single consistent key to look up whether it has seen this device before regardless of how the device is authenticated (per bootstrap method).
3. It enables swapping the hardware while preserving the logical identity. A replacement device brings a new PDI (which will produce a different ESI), which can then be bound to an existing LDI.

I think of an ESI as a stable, bootstrap method-independent, privacy-preserving key that lets the MIS answer the question: "is this the same physical device?" without being coupled to any particular bootstrap method / protocol.

[nilanjan-samajdar]

It seems that the ESI is internal to the MIS, where it determines if the device bootstrap credential is already known, hence should the ESI be kept internal to the MIS ?
However, MARGO functions might need the ESI for some use-cases, for example -

• In case a device is being ESI 'expires', the WFM may need to be informed and the applications 'drained' from the device
• In case the ESI is re-assigned, the WFM should do a full state-sync

[matlec]

The ESI should remain internal to the MIS as it is an concept of the enrollment layer, and exposing it would couple other components to bootstrap internals. That said, I agree that the use cases you describe are real operational needs. But I'd rather address them via LDI lifecycle events (revocation, re-issuance). The WFM cares that spiffe://.../margo/device/ was revoked or re-issued, not which ESI was involved.

For now, I'd treat this as a gap that can be addressed by future work (e.g., by defining a lifecycle event/notification mechanism). Or do you think this is critical to include in a first iteration?

[nilanjan-samajdar]

WFM actions on 'Expiry' and 'Renewal' should be defined.

[matlec]

See my comment in this thread.

[nilanjan-samajdar]

It seems that SPIFFE and it's SVID are being adopted as the standard for MARGO, but the text earlier pointed to a more generic specification for MIAF where one of the possible implementations is SPIFFE

[matlec]

I have updated the SUP since you left your comment to clarify the relationship with SPIFFE and make it more explicit. Please check if this updated section is sufficient / addresses your comment.

[nilanjan-samajdar]

Is there a separate Trust-Domain for WFM services accessing the MIAF and a separate one for the Devices ? Is there a suggested mapping to topology ?

[matlec]

No, there is a single trust domain for an entire deployment which would include WFM-related identities (once we have established a MIAF-compatible concept for them, see Future Work)

[nilanjan-samajdar]

For the Data-Model do you plan to provide a LinkML version ?

[matlec]

I don't have a plan for now, but if we agree on Silvano's SUP, I will not resist to update any LinkML specs while integrating this SUP into the spec once/if approved :)

[nilanjan-samajdar]

Do you plan to provide a Swagger version for the Data-Model and OpenAPI ?

[matlec]

See my answer in this thread

[matlec]

Hey @margo/technical-wg!

I made a couple of changes to the SUP over the last days and would love to hear your feedback.

1. I completed the integration of the FDO bootstrap method in the framework to support onboarding edge devices based on FIDO Device Onboard.
2. I removed the IEEE 802.1AR bootstrap method from the SUP. The 802.1AR standard does only define requirements for the format (and secure storage) of a "birth certificate", not an onboarding protocol. Hence, the existing certificate-based bootstrap methods already support the use of IDevID certificates and standardizing on e.g. IDevIDs can be a policy decision within a Trust Domain. I added an informative note to the SUP that reflects this decision.
3. I added another bootstrap method based on a single-use enrollment token to the SUP to address concerns on how to integrate brownfield, low-cost, and constrained devices. @stormc This is related to your request for bootstrapping devices based on a pre-shared key. Please review the enrollment token method I added and provide feedback whether this addresses the concerns you expressed.

Thanks everyone for the feedback you provided so far!

[chrisgclayton]

I am personally in alignment with the concept of SPIFFE. The questions I would have on this are around when doing the outside in interrogation to determine identities do we have any additional that we require for our purposes?

[chrisgclayton]

If we are going to use the SPIFFE id which is generally used for workloads vs. device ids I would recommend we do not recommend it is the same trust domain (device and workload) to ensure we do not have conflicts. An alternative is to use the same format with different scheme (i.e., instead of SPIFFE://trustdomain/path we use MARGO://trustdomain/path).

[matlec]

I am personally in alignment with the concept of SPIFFE. The questions I would have on this are around when doing the outside in interrogation to determine identities do we have any additional that we require for our purposes?

First of all, thanks for reviewing the SUP! If by

outside in interrogation to determine identities

you mean the attestation step used to determine what identity a caller should receive, then I think that is the right question. My understanding is that SPIFFE gives us the identity primitives, SVID formats, and trust-domain model, but it does not standardize the local interrogation or attestation mechanism itself. This is implementation-specific and in the case of SPIRE addressed by node and workload attestation. For the SUP, the device profile is intentionally operating one layer above that: it defines additional Margo-specific requirements for remote device bootstrap and lifecycle (including discovery, standardized bootstrap methods, binding validated bootstrap evidence to a persistent device identity, renewal, replacement, and revocation). So, yes, we do have additional requirements for our purposes, but they are mainly around device bootstrap and lifecycle rather than changing the SPIFFE identity model itself.

If we later define workload- or WFM Client-style identities (WFM Client identities rather sooner than later ;)), we should be explicit about whether local attestation remains implementation-specific or whether Margo wants to standardize that layer as well.

I hope this addresses your concern...

[matlec]

If we are going to use the SPIFFE id which is generally used for workloads vs. device ids I would recommend we do not recommend it is the same trust domain (device and workload) to ensure we do not have conflicts. An alternative is to use the same format with different scheme (i.e., instead of SPIFFE://trustdomain/path we use MARGO://trustdomain/path).

I would prefer to keep the spiffe:// scheme rather than introducing a margo:// scheme (actually, I introduced and dropped a margo: scheme in an earlier version of this SUP). The main value of this approach is that we are reusing the existing SPIFFE standard, its concepts, validation semantics, ... so that we benefit from existing tooling and implementations.
Regarding shared trust domains, I actually think devices and workloads being in the same trust domain can be the right model for a deployment. The trust domain should represent the shared security boundary, while different principal types (devices, workloads, WFM clients, ...) are separated by distinct SPIFFE ID path namespaces (e.g. /margo/device/... for devices) and authorization policy. That lets a device use its SVID to authenticate as a device to the MIS or to other workloads, and makes patterns like issuing a WFM Client identity bound to an authenticated device identity straightforward, without requiring separate trust domains or a non-SPIFFE URI scheme. So I wouldn't enforce separation of trust domains per spec, but rather treat that as a deployment decision. But happy to further discuss this and learn more about your concerns and thoughts.

[chrisgclayton]

I am personally in alignment with the concept of SPIFFE. The questions I would have on this are around when doing the outside in interrogation to determine identities do we have any additional that we require for our purposes?

First of all, thanks for reviewing the SUP! If by

outside in interrogation to determine identities

you mean the attestation step used to determine what identity a caller should receive, then I think that is the right question. My understanding is that SPIFFE gives us the identity primitives, SVID formats, and trust-domain model, but it does not standardize the local interrogation or attestation mechanism itself. This is implementation-specific and in the case of SPIRE addressed by node and workload attestation. For the SUP, the device profile is intentionally operating one layer above that: it defines additional Margo-specific requirements for remote device bootstrap and lifecycle (including discovery, standardized bootstrap methods, binding validated bootstrap evidence to a persistent device identity, renewal, replacement, and revocation). So, yes, we do have additional requirements for our purposes, but they are mainly around device bootstrap and lifecycle rather than changing the SPIFFE identity model itself.

If we later define workload- or WFM Client-style identities (WFM Client identities rather sooner than later ;)), we should be explicit about whether local attestation remains implementation-specific or whether Margo wants to standardize that layer as well.

I hope this addresses your concern...

Yes I mean the attestation step which to your point is addressed in SPIRE.

I believe in the future we need to get to workload and agree we should be explicit about it.

[chrisgclayton]

If we are going to use the SPIFFE id which is generally used for workloads vs. device ids I would recommend we do not recommend it is the same trust domain (device and workload) to ensure we do not have conflicts. An alternative is to use the same format with different scheme (i.e., instead of SPIFFE://trustdomain/path we use MARGO://trustdomain/path).

I would prefer to keep the spiffe:// scheme rather than introducing a margo:// scheme (actually, I introduced and dropped a margo: scheme in an earlier version of this SUP). The main value of this approach is that we are reusing the existing SPIFFE standard, its concepts, validation semantics, ... so that we benefit from existing tooling and implementations. Regarding shared trust domains, I actually think devices and workloads being in the same trust domain can be the right model for a deployment. The trust domain should represent the shared security boundary, while different principal types (devices, workloads, WFM clients, ...) are separated by distinct SPIFFE ID path namespaces (e.g. /margo/device/... for devices) and authorization policy. That lets a device use its SVID to authenticate as a device to the MIS or to other workloads, and makes patterns like issuing a WFM Client identity bound to an authenticated device identity straightforward, without requiring separate trust domains or a non-SPIFFE URI scheme. So I wouldn't enforce separation of trust domains per spec, but rather treat that as a deployment decision. But happy to further discuss this and learn more about your concerns and thoughts.

I am ok with it being the same trust domain as long as the pathing is clearly different. I want to be sure there is never an authorization decision that is workload related and based on the device identity, or vice versa.

[phil-abb]

I have a concern about ownership here. The MIS is an implementation that has to be running within the trust domain, but there is no clear expectation that anyone is going to "own" this service since it's meant to be a general service. So, the WFM and DFM vendors can assume someone else is going to provide it, so neither has it, and the customer needs to provide it. Or they both assume they need to provide it, so you end up with two implementations, etc.

Its purpose makes sense in the context of the SUP, but I think we need to figure out the expectations on this. I don't think it makes sense for this to be an official Margo-supported implementation (I guess a SC decision). I think it probably makes sense to include a minimal implementation of this with the reference implementation, but that is different than Margo providing something that will be supported in any production scenarios.

[matlec]

I share your concerns. The SUP (deliberately) defines MIS as a role, but that doesn't really resolve the deployment gap you're describing :) The WFM/DFM layer seems the right place for this to live: MIS is the identity plane that devices need before they can talk to anything, and the WFM/DFMs are the management planes devices and clients register with. But nothing in the SUP mandates this - and I also don't think this decision should be buried in a SUP.

Whether Margo should provide a production-quality open-source reference implementation of MIS - similar to how CNCF provides SPIRE for SPIFFE - is a question that belongs to the SC. My personal view: SPIRE is arguably why SPIFFE succeeded in practice, and a prod-quality Margo-maintained implementation would have the same effect on adoption.

[samuel-greising]

I agree with @matlec pov on the adoption! The comparison with SPIRE is just perfect. I can offer testing an early solution in an enterprise grade environment with WFM & DFM combination.