SpecificationIdentity and Authorization
Identity Security Considerations
MIAF assumes an adversarial network and the possibility of a compromised individual device or service. Its goals are to preserve identity integrity and minimize blast radius; protecting the private keys those identities rest on is the responsibility of the deployment rather than provided by the framework.
This section is scoped to identity. For each threat, it describes the mitigation that MIAF relies on, along with links to the specific rules. Some mitigations are normative framework requirements; others are residual risks carried by the operator's deployment.
Framework Threats
| Threat | Description | Mitigation |
|---|---|---|
| Theft and misuse of a credential | An attacker who obtains a principal's SVID together with its private key authenticates as that principal anywhere its SPIFFE ID is accepted; an X.509-SVID carries no audience restriction confining it to one verifier. | A principal MUST protect its private key (see the private-key-compromise row below); SVIDs SHOULD be short-lived per SVID lifetime guidance to bound the exposure window; and each verifier MUST validate the SVID against the Trust Bundle and authorize the specific SPIFFE ID locally, so a stolen credential reaches only what that identity is granted (see X.509-SVID validation). |
| Private key compromise | An attacker exfiltrates a principal's private key and can then authenticate as that principal until the credential is withdrawn. | A principal protects its private key per deployment policy; MIAF specifies no key-protection mechanism of its own. The operator provisioning playbook's preferred path issues by CSR, which keeps the key on the principal and can bind it to hardware (TPM, secure element, or HSM) where available. Once compromise is known, access is withdrawn via the operator revocation playbook, bounded by short SVID lifetimes. |
| Central key-custody concentration | Where a principal cannot generate its own key pair, the operator generates it centrally (see operator provisioning playbook), concentrating many principals' private keys in one store whose breach exposes all of them at once. | The provisioning playbook's preferred path generates the key on the principal (issuance by CSR), leaving no central copy; where a principal cannot generate its own key pair, the operator generates it centrally and accepts the resulting key-custody concentration risk, protecting the store per deployment policy and treating its breach as private-key compromise (row above). |
| Compromised issuance authority (MIS) | A compromised MIS can mint a valid SVID for any SPIFFE ID in the Trust Domain, impersonating any WFM or client, or issue under a WFM namespace at will. | MIAF concentrates issuance in the MIS by design, so protecting it is an operator PKI-governance responsibility: scope the issuing authority (for example an intermediate CA per the deployment patterns) and protect its signing key per deployment policy. Recovery is Trust Bundle rotation to retire the compromised authority. |
| Initial trust anchor confusion | An attacker causes a principal to trust the wrong HTTPS authority and serves a malicious discovery document or Trust Bundle. | A principal MUST authenticate the first HTTPS retrieval of the discovery document and trustBundleUri per initial trust bootstrap. |
| Trust Bundle substitution or anchor injection | An attacker who compromises a Trust Bundle origin (or its server certificate) injects a trust anchor. Because the SPIFFE bundle is authenticated only by the transport and is not itself signed, every SVID chaining to the injected anchor is then accepted. This applies on every refresh, not only at bootstrap. | A client retrieves the Trust Bundle only over HTTPS validated against its configured initial-trust anchors or pins, on each refresh, per initial trust bootstrap and certificate validation, and MUST fail closed on an empty or unusable bundle per selecting and refreshing the bundle. |
| Trust Bundle rollback | A stale, cached, or replayed Trust Bundle is served to reverse a completed rotation, re-admitting a trust anchor that was removed to revoke a compromise. | A client authenticates every Trust Bundle retrieval, not only the first, per initial trust bootstrap, so a third party cannot substitute an older bundle. The refresh interval overrides HTTP cache freshness, so a cached copy cannot outlive that interval (see selecting and refreshing the bundle). |
| Blocked Trust Bundle refresh | A client cannot refresh its Trust Bundle, because an attacker denies it network access or because the device is intermittently connected or offline by design. The client keeps validating SVIDs against its cached anchors and never learns that an anchor was retired, so a compromised issuing authority under that anchor can keep minting SVIDs the client accepts. Short SVID lifetimes do not help, because the compromised authority can mint fresh ones. | MIAF sets no upper bound on bundle staleness and accepts this residual risk. A client caches its bundle to validate SVIDs while offline (see bundle contents and distribution), so a client that failed closed on a stale bundle would stop validating its WFM during any connectivity outage. The exposure requires the attacker to reach the client and to hold an SVID issued under the retired anchor, and it ends at the next successful refresh. An operator that needs a staleness bound sets one in deployment policy. |
| Reused SPIFFE ID after principal replacement | A principal is decommissioned rather than compromised, so nobody withdraws its SVID, and its SPIFFE ID is reused for the replacement. The retired SVID stays valid until it expires, and its private key may be recoverable from decommissioned or resold hardware, so the retired principal can still authenticate as the shared identity. | An operator assigns a fresh SPIFFE ID to the replacement unless the retired private key is known to be destroyed, per the operator provisioning playbook. While the two share an identity, allowlist removal cannot separate them, so the exposure otherwise lasts until the retired SVID expires (see SVID lifetime guidance). |
| Certificate revocation lag | A revocation event is not propagated promptly. | A deployment relies on the operator revocation playbook and short SVID lifetimes; a verifier SHOULD limit connection lifetime so that a long-lived mTLS session does not extend the lag indefinitely (see session lifetime and re-validation). |
| Service impersonation / MITM | An adversary attempts to impersonate the MIS or another service. | All endpoints MUST use HTTPS with strict certificate validation per the TLS requirements. A client authenticates the MIS trust endpoints against its configured initial-trust anchors or pins, per initial trust bootstrap, since the MIS presents no SVID. For mTLS between principals, a peer MUST verify the presented SVID against the configured Trust Domain and Trust Bundle. |
| Cross-domain trust confusion | A component accepts identities from an unintended Trust Domain. | A verifier MUST determine the Trust Domain from the SPIFFE ID and MUST NOT trust an SVID whose Trust Domain is not the verifier's own. |
| Inadvertent inspection-proxy MITM | An operator-deployed traffic-inspecting proxy intercepts and re-signs Margo mTLS traffic, presenting a substitute certificate to either endpoint. | An operator MUST exempt Margo mTLS endpoints from inspection per traffic-inspecting proxies. Both endpoints MUST validate peer SVIDs against the Trust Bundle and reject a substituted certificate. |
| Forwarded-identity header injection | In a TLS-offload topology, an attacker injects a forged Client-Cert header to impersonate an authenticated caller at the backend. | The proxy MUST remove or overwrite any Client-Cert or Client-Cert-Chain header on incoming requests, and the backend MUST accept a forwarded identity only over the trusted proxy boundary, per traffic-inspecting proxies. |
| Unreliable or manipulated verifier clock | A principal mis-evaluates certificate validity periods because its clock is skewed or unset (a dead RTC battery, no time source at first boot) or because an attacker rewinds it, for example by spoofing an unauthenticated time source on the adversarial network. Rewinding the clock extends the validity window of an expired SVID, defeating the use of expiry as revocation. | SVID validation depends on a trustworthy local time source. A principal SHOULD synchronize time from a trustworthy source before validating certificates, and operators SHOULD account for devices with weak clocks when choosing SVID lifetimes (see SVID lifetime guidance). A deployment that cannot assure clock integrity SHOULD NOT rely on expiry alone for revocation. |
| Handshake identity disclosure on TLS 1.2 fallback | Where an operator enables the optional TLS 1.2 fallback, the mTLS handshake sends the client X.509-SVID in cleartext, so a passive on-path observer can read the peer's SPIFFE ID, and with it its Trust Domain and client relationship. | Default to TLS 1.3, which encrypts the certificate messages, per the TLS requirements. Enable TLS 1.2 only where a deployment requires it, accepting this passive-disclosure risk; when used, TLS 1.2 MUST follow modern security guidance (RFC 9325). |
WFM Identity Profile Threats
WFM and WFM Client identities inherit the framework threats above. The threats below are specific to this profile.
| Threat | Description | Mitigation |
|---|---|---|
| Wrong-WFM impersonation | A WFM Client connects to a WFM whose SVID is validly issued by the Trust Domain but whose wfm-id is not the one that issued the client, so the client authenticates to the wrong WFM. | The WFM Client MUST verify the wfm-id in the WFM's SPIFFE path against the wfm-id in its own SVID before authenticating (see Recognition by the WFM Client). |
| Wrong-WFM-Client acceptance | A WFM accepts an SVID whose wfm-id belongs to a different WFM's namespace, treating the bearer as a client of itself. | The WFM MUST verify the wfm-id in the SPIFFE path against its own namespace before authorizing (see Recognition by the WFM). |
| Unauthorized client within the namespace | A validly issued SVID under a WFM's own namespace (.../wfm/<wfm-id>/client/...) is presented by a party the WFM's operator never authorized; for instance, the MIS issues under the namespace to the wrong principal. | Namespace match alone does not grant access: a WFM MUST admit a caller only if its identity is accepted by the WFM's accepted-client policy (see Authorization). Operators SHOULD also constrain the MIS to issue under a WFM's namespace only to that WFM's authorized clients. |
| Stale accepted-client policy | An entry remains in a WFM's accepted-client policy after the relationship is retired, letting a still-valid credential keep accessing the API. | An operator removes wfm-client-id entries promptly per the revocation row of the lifecycle table. The WFM MAY also deny the request by local policy, surfaced as described in API Requirements and Security, per Authorization. |
| No precise revocation of a compromised WFM | A WFM has no client-side accepted-server allowlist comparable to the WFM's accepted-client policy, so a compromised WFM SVID cannot be revoked precisely: only fleet-wide Trust Bundle rotation or expiry withdraws it, so both the blast radius and the revocation lag are large. | Keep WFM SVIDs short-lived and reissue with the same SPIFFE ID before expiry; use Trust Bundle rotation as the cryptographically enforced revocation path, accepting its fleet-wide scope (see the WFM lifecycle). |
| Non-conformant authentication paths | A WFM exposes an authentication path outside the mTLS model (an unauthenticated onboarding endpoint or an application-layer signature scheme) that an attacker uses to bypass SVID validation. | A WFM MUST authenticate every Management Interface request with mTLS and an X.509-SVID, and MUST reject requests that do not conform per API Requirements and Security. |