| Internet-Draft | High-Assurance Transition Finality | September 2026 |
| Das | Expires 19 March 2027 | [Page] |
Modern infrastructure increasingly allows memory, accelerators, device interfaces, storage regions, and other resources to move dynamically between hosts, tenants, virtual machines, and security domains. Existing mechanisms can authenticate devices, attest software and firmware state, protect communication, and authorize resource operations. However, these properties do not necessarily establish that the exact resource transition that becomes effective is still the transition that was evaluated and authorized.¶
This distinction becomes security-critical when a change in addressability, ownership, routing, or device assignment itself exposes protected state. For example, a dynamically reassigned memory extent may become accessible to a new tenant even though the device is authentic and the transport is protected, if sanitization, ownership state, allocation generation, destination binding, or other required conditions are no longer valid at the moment of reassignment.¶
This document describes an execution-finality model in which a proposed transition remains non-effective until a protected enforcement boundary verifies the concrete operation immediately before effectuation. Authorization is bound to the exact resource, source, destination, generation, security state, freshness conditions, and required preconditions, with replay and alternate-path protections.¶
The problem is particularly relevant to high-assurance AI and composable-compute environments, including NVIDIA NVLink-based confidential multi-GPU systems, Arm Confidential Compute Architecture (CCA) and Realm Management Extension (RME) systems, UALink accelerator fabrics, CXL pooled-memory systems, and confidential- computing deployments operated by cloud providers. These names identify published industry directions and alignment points; they are not assertions that any named implementation is vulnerable or non-conformant.¶
The model complements attestation, confidential computing, secure transport, and device-assignment mechanisms rather than replacing them. Its central security invariant is that a trusted component does not, by itself, imply a trusted transition.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Infrastructure security commonly establishes the trustworthiness of components. A verifier may determine that a device possesses an expected identity, that firmware measurements correspond to an acceptable state, that a protected channel exists, or that a requesting principal is authorized. Remote attestation architectures such as RATS explicitly separate Attesters, Verifiers, and Relying Parties and define how evidence can support appraisal and trust decisions [RFC9334].¶
These properties remain necessary. They do not necessarily establish that the exact physical or logical transition that is about to occur remains the transition that was evaluated.¶
This distinction becomes important as infrastructure becomes composable. Memory can be added to or released from a host at runtime. Accelerators and device interfaces can move among workloads. Storage regions can be remapped. Network or I/O state can be reconfigured without moving the resource itself. In each case, security ultimately depends on a transition between two states.¶
Previous State New State
Resource R Resource R
controlled by A --------> controlled by B
inaccessible to B addressable by B
Authentication can establish properties of A, B, or R. The problem addressed by this document is the arrow: whether the exact transition that creates the new consequence is still authorized when it becomes effective.¶
The core requirement is therefore: a security-critical transition remains non-effective until the concrete transition that is about to become effective has been checked against the transition that was authorized.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Consider a multi-tenant AI infrastructure using dynamically assignable memory. Tenant A operates a workload containing valuable model state. Some pages associated with the workload reside in a dynamically managed memory resource. Eventually the workload terminates and an extent, E42, is released for later use by another host.¶
The example is intentionally not a claim that CXL lacks residual-data protections. CXL 4.0 includes Trusted Execution Environment Security Protocol requirements for Dynamic Capacity. In particular, its Dynamic Capacity security requirements state that before capacity is added to a host, including after release from a different host, the relevant memory is overwritten or cryptographically cleared and the trusted-execution state is reset [CXL4]. The scenario below instead illustrates the cross-layer failure that occurs if an implementation, integration, stale management state, replay, or alternate effectuation path causes new addressability to become effective without the required precondition being current and binding at the effectuation boundary.¶
Tenant A
|
| uses
v
+-----------+
| Memory E42|
| State S |
+-----------+
|
| release
v
+----------------+
| SANITIZE / |
| STATE RESET |
+----------------+
|
X ordering, replay, stale-state,
| or alternate-path failure
v
+-----------+
| Host B |
| maps E42 |
+-----------+
|
v
residual state becomes observable
The important point is not that Tenant A sends a file to Tenant B. The security consequence is created by changing who can address the resource. A memory read still transfers cache-line data over the interconnect, but the previous tenant did not transmit or authorize an application payload for the new tenant. The disclosure is created by a state transition in addressability.¶
The same structure applies to other resources: a GPU partition can become visible to another workload; a device interface can be attached to a different VM; a DMA mapping can become active; a storage namespace can be remapped; or a network rule can become externally active.¶
Security systems commonly contain logically distinct stages such as authentication, attestation, policy evaluation, authorization, configuration, and external effect. Security reasoning often concentrates on the earlier stages while the consequential state change occurs later and may be performed by different components.¶
Request
|
v
Authentication
|
v
Attestation
|
v
Policy Evaluation
|
v
Authorization
|
| security-relevant state may change here
| ----------------------------------------
v
Configuration
|
v
External Effect
Between authorization and effectuation, security-relevant state may change. A resource can be substituted, a destination can change, an authorization can become stale, sanitization can remain incomplete, ownership or generation can advance, policy can be revoked, or a previously valid operation can be replayed.¶
The problem can therefore be stated as follows: authorization of a requested operation is not necessarily equivalent to authorization of the concrete operation that ultimately becomes effective.¶
SPDM provides messages and procedures for hardware identity authentication, measurement of firmware identities, key exchange, and protected sessions [SPDM]. These are important inputs to a resource-transition decision.¶
A valid attestation can establish that a device or environment has an acceptable identity or measured state. It does not, by itself, prove that a particular resource extent is still owned by the expected source, that a required sanitize operation has completed, that the destination has not changed, that a generation number is current, or that an authorization has not already been consumed.¶
PCIe Integrity and Data Encryption provides confidentiality, integrity, and replay protection for protected Transaction Layer Packets [PCIE-IDE]. This protects communication in transit. A cryptographically protected request can nevertheless represent a stale, mis-bound, or no-longer-authorized operation.¶
TDISP defines mechanisms for establishing a trust relationship with a device, securing the interconnect, and trusted attach/detach of a device interface to a trusted VM [TDISP]. The model in this document is complementary: it asks what invariant applies at the boundary where a specific resource transition first becomes effective.¶
The design goal is to bind authorization to the concrete transition that will create a protected consequence, and to verify that binding at a non-bypassable or equivalently protected effectuation boundary.¶
This document does not replace remote attestation, SPDM, IDE, TDISP, CXL security, confidential computing, hypervisor isolation, IOMMU protection, or existing access control. Those mechanisms may provide evidence, isolation, transport protection, or enforcement used by the model.¶
This document also does not require one physical implementation point. The final enforcement function can be implemented in hardware, firmware, a hypervisor, device logic, a switch, an operating-system security boundary, or a combination, provided the protected consequence cannot be produced through an unmediated alternate path.¶
Candidate Transition: A proposed security-relevant state change that has been prepared but has not yet been allowed to create its protected consequence.¶
Non-Effective State: A condition in which preparation and validation may occur, but the requester does not yet possess the means required to create the protected consequence.¶
Transition Descriptor: A canonical representation of the exact resource transition to which authorization is bound.¶
Validation Evidence: Protected evidence used to establish that a Candidate Transition satisfies required conditions. Attestation Evidence or an Attestation Result as used in RATS can be among these inputs [RFC9334].¶
Execution Handle: A narrowly scoped authorization bound to a specific validated Transition Descriptor and its execution constraints. Possession of the handle is not intended to provide unconstrained bearer authority for a different transition.¶
Final Enforcement Boundary: The protected boundary controlling the operation that first makes the Candidate Transition externally effective. The term identifies a functional role, not a required physical device or software component.¶
Let a transition T contain the security-relevant parameters shown below. The field set is illustrative; a concrete binding can add or remove fields according to the resource type and threat model.¶
T = (r, s, d, o, g, q, p, n, tau)
r = resource identifier
s = source security domain
d = destination security domain
o = operation
g = resource generation or epoch
q = required security state
p = policy state or policy version
n = nonce or unique transition identifier
tau = freshness or validity constraint
¶
A canonical transition digest can be constructed as follows, where Encode is deterministic and H is a cryptographic hash appropriate to the deployment.¶
D_T = H(Encode(T))
¶
Authorization A is bound to that transition digest and to validation evidence and execution constraints.¶
A = Protect(D_T, Evidence, Constraints)
¶
The required semantic property is that authorization for T does not silently become authorization for a security-relevant T-prime that differs from T.¶
A(T) does not imply A(T') when T' != T
¶
Immediately before effectuation, the Final Enforcement Boundary evaluates a predicate Phi over the concrete transition, current protected state, authorization, and evidence.¶
Phi(T, S, A, E) =
ExactBinding
AND FreshnessValid
AND OwnershipValid
AND GenerationValid
AND PolicyStillValid
AND RequiredSecurityStateValid
AND RequiredSanitizationComplete
AND AuthorizationUseValid
AND EffectuationPathAuthorized
¶
The fundamental safety invariant is:¶
Effective(T) => Phi(T, S, A, E) = TRUE
¶
It is insufficient that the transition was valid at some earlier time. Where mutable state is security relevant, the enforcement boundary MUST establish a protected correspondence between the state that was validated and the state that exists immediately before effectuation.¶
A deployment MAY collapse internal states, but it MUST preserve the property that a Candidate Transition cannot create the protected consequence before final verification.¶
+-----------+
| PROPOSED |
+-----------+
|
| validate
v
+-----------+
| VALIDATED |
+-----------+
|
| issue exact bounded authority
v
+----------------+
| NON-EFFECTIVE |
| READY |
+----------------+
|
| final verification
| + protected consume
v
+-----------+
| EFFECTIVE |
+-----------+
any failed required check ---> REJECTED
The system constructs a Candidate Transition and a canonical Transition Descriptor. Preparation MUST NOT itself create the protected consequence.¶
The system evaluates policy and obtains the evidence required by the resource transition. Evidence can include attestation results, current ownership, lifecycle state, sanitization state, resource generation, destination authorization, or other protected state.¶
At the Final Enforcement Boundary, the system reconstructs or observes the concrete transition that is about to become effective, verifies its correspondence with the authorized transition, verifies required current state, consumes or bounds the authorization according to its allowed-use semantics, and only then permits effectuation.¶
The following pseudocode is non-normative and intentionally independent of a particular cryptographic token format.¶
function prepare_transition(resource, source, destination, operation):
T.resource = resource.id
T.source = source.id
T.destination = destination.id
T.operation = operation
T.generation = protected_generation(resource)
T.securityState = required_security_state(resource)
T.policyVersion = current_policy_version()
T.nonce = secure_random()
T.expiry = current_time() + MAX_WINDOW
return canonical_encode(T)
function validate_transition(T):
if not authenticated(T.source):
return DENY
if not authorized_destination(T.destination):
return DENY
if current_owner(T.resource) != T.source:
return DENY
if current_generation(T.resource) != T.generation:
return DENY
evidence = collect_required_evidence(T)
if not policy_accepts(T, evidence):
return DENY
return issue_execution_handle(
digest = HASH(T),
generation = T.generation,
expiry = T.expiry,
nonce = T.nonce,
constraints = policy_constraints(T))
function finalize_transition(observed_T, handle):
begin_protected_finality_section()
if handle.expired:
reject()
if handle.consumed:
reject()
if HASH(observed_T) != handle.digest:
reject()
if current_generation(observed_T.resource) != observed_T.generation:
reject()
if current_owner(observed_T.resource) != observed_T.source:
reject()
if not required_security_state_holds(observed_T):
reject()
if not sanitization_complete_if_required(observed_T):
reject()
if not current_policy_allows(observed_T):
reject()
protected_consume(handle)
make_transition_effective(observed_T)
commit_protected_finality_section()
return SUCCESS
¶
The relationship between authorization consumption and hardware or system state change requires atomicity, idempotence, protected journaling, monotonic generations, or equivalent crash-consistency semantics. A failure between those operations MUST NOT create replayable authority or an effective transition that cannot be reconciled with protected state.¶
+--------------------+
| Requester / |
| Orchestrator |
+---------+----------+
|
| propose T
v
+--------------------+
| Candidate |
| Transition |
| no external effect |
+---------+----------+
|
v
+--------------------+ +------------------+
| Policy / Evidence |<------| Attestation / |
| Validator | | device evidence |
+---------+----------+ +------------------+
|
| exact-transition authorization
v
+--------------------+
| Non-Effective |
| Ready State |
+---------+----------+
|
v
=====================================================
FINAL ENFORCEMENT BOUNDARY
=====================================================
|
| exact resource / destination
| generation / freshness
| policy / security state
| replay / required preconditions
v
+-----------+
| ALL TRUE? |
+-----+-----+
/ \
no yes
| |
v v
REJECT PROTECTED COMMIT
|
v
EXTERNAL EFFECT
Components above the boundary can calculate, recommend, attest, validate, or prepare an operation. They do not independently possess authority to create the protected consequence unless they also satisfy the Final Enforcement Boundary role.¶
Assume an attacker captures a previously valid authorization issued when resource E42 had generation 7802. Protected current state records generation 7814. Because the authorized generation and current generation do not correspond, finalization fails even if the captured object remains cryptographically authentic.¶
Authorization is issued for E42. Malware substitutes E43 after policy evaluation. Exact transition binding causes the observed descriptor to differ from the authorized descriptor, and the transition is rejected.¶
Authorization is issued for destination Host B. An intermediary changes the destination to Host C. Because destination identity is security relevant, the resulting transition no longer matches the authorized transition and is rejected.¶
The resource, source, and destination are correct, but required sanitization or security-state reset has not completed. The finality predicate is false and addressability MUST NOT change.¶
Where an Execution Handle is single-use, protected consumption of that handle makes a repeated attempt invalid. More generally, the implementation MUST enforce the handle's authorized use count or equivalent bounded-use semantics.¶
A broad authorization such as "Host B may acquire memory" leaves several security-relevant dimensions unresolved. It may not identify the exact physical extent, previous owner, sanitize operation, allocation epoch, security state, or permitted number of executions.¶
An execution-finality binding instead seeks to make authorization specific to the concrete transition. The desired property is that possession of authorization for T does not enable a different T-prime merely by changing parameters after validation.¶
For T' != T:
Pr[ Finalize(T', A_T) = SUCCESS ] <= epsilon
where epsilon is negligible under the assumed cryptographic and
enforcement security model.
¶
Exact binding is insufficient if another mechanism can directly produce the same protected consequence without passing through the finality check.¶
+--> Finality Check --> Effect
|
Request ----------+
|
+---------------------> Effect
bypass
Every mechanism capable of producing the protected consequence MUST either pass through the Final Enforcement Boundary or enforce an equivalent invariant. This property may require hardware, firmware, hypervisor, device, switch, kernel, or other privileged enforcement depending on the protected resource.¶
Two transitions can race for the same resource. If T1 assigns E42 to B and T2 assigns E42 to C, both MUST NOT succeed for the same exclusive resource generation. A successful state transition SHOULD advance a protected generation, epoch, or equivalent version so a competing authorization bound to the previous state becomes stale.¶
generation(E42) = g
Success(T1, g) => generation(E42) = g + 1
therefore, for mutually exclusive T2:
Success(T1, g) => Failure(T2, g)
¶
The same invariant can apply when the protected consequence is accelerator assignment, device-interface assignment, DMA authority, storage-namespace remapping, network forwarding activation, or another transition where control or visibility changes between security domains.¶
GPU slice: Tenant A -> Tenant B
Device interface: Host A -> confidential VM B
DMA region: unmapped -> device-readable
Storage namespace: Tenant A -> Tenant B
Network state: candidate -> externally active
¶
The concrete enforcement mechanism differs by resource. The shared principle is that computation, attestation, or policy approval does not itself create authority for a different or stale consequence.¶
This section identifies published industry directions to which the execution-finality model may be relevant. The examples are alignment points, not findings that the named technologies are insecure, non-conformant, or missing their documented protections. In particular, this document does not assume that a fabric forms one unrestricted trust zone merely because it provides fast peer communication. Existing access-control, confidential-computing, link-protection, and isolation mechanisms remain part of the security model.¶
Modern AI fabrics intentionally make accelerator-to-accelerator communication less dependent on host-CPU mediation. NVIDIA's CUDA Compute Fabric Transport documentation describes unicast and multicast memory-sharing APIs that can map remote GPU physical memory into a local virtual address space; once a peer allocation is mapped and given access rights, kernels can access it using load and store operations [NVIDIA-CFT]. NVIDIA also documents multi-GPU confidential-computing configurations in which NVLink and NVSwitch participate in a protected system and in which GPU and switch attestation are part of the trust-establishment workflow [NVIDIA-PPCIE].¶
UALink is likewise designed as a low-latency, high-bandwidth scale-up interconnect for AI accelerators. The UALink Consortium describes direct load, store, and atomic operations between accelerators, and the UALink 1.0 specification defines UALinkSec to protect tenant traffic, including confidentiality and optional integrity with replay protection in supported confidential-computing deployments [UALINK1].¶
These capabilities motivate, but do not prove, a need for an additional transition invariant. Where an accelerator fabric already authenticates endpoints, protects the link, and applies mapping or access rights, execution finality asks a narrower question: whether authority for a consequential operation is bound to the exact resource, destination, generation, and current security state that will be made effective. For example, authorization to map or move one region need not become reusable authority for a different region, destination, epoch, or later operation.¶
This document therefore does not describe a "picosecond firewall" and does not assign a universal timing target. A hardware implementation can place final checks near an effectuation point, but achievable latency depends on the interconnect, protocol, implementation technology, and predicates being checked. Performance claims require measurement in a concrete implementation.¶
Model weights and inference state are security-sensitive assets in commercial AI infrastructure. Microsoft describes Confidential AI as protecting data and models throughout the AI lifecycle and specifically notes that protecting model weights can be critical where model training is resource-intensive or the weights embody sensitive model intellectual property [AZURE-CONF-AI]. AWS describes architectures that use attested isolated execution and key release to protect proprietary model weights [AWS-NITRO-AI]. Google Cloud similarly recommends Confidential Computing for GPUs where sensitive training data or model parameters require protection while in use [GOOGLE-CONF-AI].¶
Runtime state can also be substantial and mobile. NVIDIA describes the LLM KV cache as GPU-resident intermediate attention state derived from prior tokens, and documents distributed KV-cache management and remote sharing across heterogeneous environments [NVIDIA-KVCACHE]. This document does not assert that a particular cloud or accelerator implementation exposes such state across tenants. The relevance is that as weights, buffers, mappings, and runtime caches become more dynamically placed or shared, the lifecycle transitions governing who can address them become security sensitive in their own right.¶
Execution finality can complement encryption and attestation by binding a specific release, mapping, copy, reassignment, or key-use decision to the concrete asset and current security domain at effectuation time. It is not a substitute for memory isolation, confidential computing, access control, or secure erasure.¶
Some hardware or firmware security failures depend on a protected state transition occurring while a prerequisite is stale, incomplete, reordered, or observable through an unintended path. The finality model can serve as a compensating invariant for that class of failure when the consequential transition remains controllable: the operation stays non-effective until the required protected predicates are true, and stale generation or ownership state causes rejection.¶
This scope is intentionally narrower than claiming to "fix unpatchable silicon". Execution finality does not, by itself, solve speculative-execution vulnerabilities, arbitrary microarchitectural side channels, analog leakage, Rowhammer-class faults, or any defect that leaks information without traversing a controlled effectuation path. It can reduce exposure only where the attack depends on a transition that the protected boundary can actually mediate. The residual limitations are discussed further in Section 22.11.¶
CXL Dynamic Capacity provides a concrete example of why resource transitions deserve explicit security semantics. CXL 4.0 permits memory capacity to be added to or released from hosts at runtime and, for Dynamic Capacity used with its trusted-execution security mechanisms, requires memory to be overwritten or cryptographically cleared and trusted- execution state to be reset before capacity released by one host is added to another [CXL4]. CXL also specifies multi-host considerations intended to prevent simultaneous transactions to the same device-physical-address range.¶
The execution-finality model aligns with those requirements rather than replacing them. A binding for pooled memory can make sanitization and revocation explicit predicates of the final transition. For resource r, old domain A, new domain B, and generation g, an illustrative invariant is:¶
SafeReassign(r,A,B,g) =>
ResidualContentCleared(r,g)
AND OldReferencesRevoked(A,r,g)
AND CurrentOwner(r,g) = A
AND DestinationBound(B,r,g+1)
AND SingleUseAuthorization(r,A,B,g)
AND NoBypassPath(r)
¶
"ResidualContentCleared" is intentionally defined by the underlying memory/security technology rather than by this document. "OldReferencesRevoked" means that mappings, capabilities, decoder state, DMA authority, or other references that would let the old security domain continue to exercise the protected access have been invalidated to the extent required by the concrete binding. These terms provide a protocol-independent way to express the preconditions; they do not redefine CXL's own conformance requirements.¶
The relevance to cloud and confidential-computing infrastructure is not based on an assertion that Microsoft Azure, AWS, Google Cloud, NVIDIA, Arm, or another named platform is vulnerable to the motivating attack. Their published material instead demonstrates that protection of model weights, data in use, accelerator state, isolated execution, and attestation is already an industrial priority [AZURE-CONF-AI] [AWS-NITRO-AI] [GOOGLE-CONF-AI] [NVIDIA-PPCIE] [ARM-CCA]. Arm CCA, for example, provides Realm-based confidential computing with attestation and dynamic assignment of protected memory resources. The proposed model is intended to compose with such mechanisms by constraining the last security-sensitive transition rather than replacing the mechanisms that establish confidential execution or platform trust.¶
This document is an individual submission intended to expose the proposed invariant to adversarial technical review. Corrections are explicitly invited, including corrections to the descriptions of CXL, PCIe, SPDM, NVLink, UALink, confidential-computing systems, or other cited technologies. Brand and consortium names are used only to identify published mechanisms and possible alignment points, not to allege defects or non-conformance.¶
Review is particularly requested on the following questions:¶
A useful negative result is also welcome: if a cited deployment already guarantees the invariant in Section 8 across all relevant effectuation paths, documenting that fact would narrow the problem space and improve this work.¶
The RATS architecture defines roles and information flows for remote attestation [RFC9334]. This document does not redefine Evidence, Attestation Results, Verifiers, or Relying Parties. Attestation output can be used as Validation Evidence. The additional question addressed here is whether the exact transition that consumes that evidence remains bound to current protected state at effectuation.¶
A related individual submission applies execution-finality concepts more directly to attestation-bound authorization [DAS-RATS-EF]. This document narrows the motivating problem to security-critical resource transitions and composable interconnects.¶
SPDM provides device authentication, measurement, key exchange, and secured messaging capabilities [SPDM]. Those properties can supply identity, measurement, and session evidence. Execution finality does not replace SPDM; it constrains how such evidence is connected to a concrete resource transition.¶
PCIe IDE protects Transaction Layer Packets for confidentiality, integrity, and replay resistance [PCIE-IDE]. TDISP defines trusted device-interface assignment functions including trusted attach and detach [TDISP]. These mechanisms address transport and device-assignment security. The abstract model here focuses on exact transition binding and final verification of mutable resource state immediately before the protected consequence becomes effective.¶
CXL is used as a motivating example because Dynamic Capacity makes resource reassignment explicit and because CXL 4.0 already defines security requirements for clearing memory and resetting trusted-execution state when capacity is added to a host after release from another host [CXL4]. The proposal in this document should therefore be read as a general finality invariant that can complement such protocol requirements, not as a claim that CXL omits the sanitize-before-reassignment requirement.¶
The problem intersects remote attestation, authorization, secure channels, workload identity, capability use, TOCTOU resistance, replay prevention, and cross-layer security. The RATS Working Group is directly relevant to the attestation portion of the problem [RATS-WG]. The Security Area Open Meeting (SAAG) provides a cross-area forum for security discussion [SAAG]. This document does not claim a specific Working Group adoption path.¶
The finality role need not be a single physical component. It can be distributed across a device, host, switch, hypervisor, kernel, security processor, or other protected subsystem. What matters is that all paths capable of creating the protected consequence satisfy the invariant in Section 8.¶
Rechecking mutable state on the effectuation path introduces work. Deployments can reduce hot-path cost through protected caches, prevalidated evidence, local generation counters, or precomputed policy artifacts. Such optimization MUST NOT make stale precomputation independently sufficient to create the protected consequence.¶
If a required protected predicate cannot be established, high-consequence deployments SHOULD keep the Candidate Transition non-effective. Missing evidence, stale generation, indeterminate sanitization state, unavailable replay state, or conflicting ownership information SHOULD NOT silently become permission to proceed.¶
The security of this model depends on the completeness of the protected effectuation path. A correct Transition Descriptor and a valid Execution Handle do not provide the intended property if an attacker can create the same consequence through an unmediated alternate path.¶
The requester is not assumed to be trustworthy. It can construct malicious or inconsistent Candidate Transitions. The protected consequence therefore MUST NOT depend solely on requester-supplied claims about resource identity, ownership, generation, destination, sanitization, or current policy state.¶
If an orchestrator can directly control every protected state variable and can also make the resource transition effective, compromise of that orchestrator can defeat the model. Deployments that seek protection from a compromised orchestrator SHOULD ensure that security-critical resource identity, current generation, ownership, and effectuation parameters are independently observable or protected at the Final Enforcement Boundary.¶
Compromise of an authoritative validator can produce unauthorized Execution Handles. Higher-assurance deployments MAY use hardware-rooted enforcement, multiple independent validators, threshold authorization, independent policy appraisal, or equivalent mechanisms appropriate to the threat model.¶
Mutable state can change after validation. Implementations SHOULD use generation values, epochs, freshness constraints, monotonic counters, protected continuity, or equivalent mechanisms so that a transition authorized against state S cannot silently execute against materially different state S-prime.¶
Execution Handles and protected transition state SHOULD resist replay, rollback, snapshot restoration, stale-epoch completion, and cross-resource or cross-domain reuse. A cryptographically authentic old authorization is not sufficient if its bound state is no longer current.¶
Transition Descriptors MUST have an unambiguous representation before hashing, signing, or MAC protection. A concrete binding MUST define whether any distinct encodings are semantically equivalent. Attackers MUST NOT be able to create a security-relevant parameter change that is ignored by authorization binding.¶
Every path that can create the protected consequence MUST pass through the Final Enforcement Boundary or provide an equivalent enforcement invariant. Debug interfaces, emergency control paths, firmware commands, alternate management planes, recovery tooling, direct device access, and privileged host interfaces require explicit analysis.¶
Authorization consumption and effectuation can span multiple components. A crash between those steps MUST NOT leave replayable authority or an untracked effective transition. Implementations SHOULD use atomic state changes, idempotent recovery, protected journals, monotonic generations, or equivalent mechanisms.¶
Valid attestation evidence can become stale relative to mutable resource state. A verifier or relying party SHOULD distinguish evidence about comparatively static component identity or measurement from evidence about rapidly changing resource ownership, mapping, generation, and sanitization state.¶
Failure to establish a required predicate SHOULD keep high-consequence transitions non-effective. Such fail-closed behavior can be abused for denial of service. Availability engineering is therefore necessary, but recovery mechanisms MUST NOT introduce a permissive bypass around the required finality checks.¶
The motivating example concerns residual data after reassignment, but the model does not claim to eliminate all side channels, inferential leakage, microarchitectural leakage, or implementation defects. Those threats require their own mitigations. The property defined here is narrower: the protected resource transition must not become effective unless its required current preconditions hold.¶
Transition Descriptors and receipts can reveal tenant identifiers, workload relationships, resource topology, timing, security-domain membership, and allocation patterns. Implementations SHOULD minimize retained information and SHOULD avoid exposing raw tenant or resource identifiers beyond what is required for enforcement and audit. Pseudonymous identifiers, keyed commitments, selective disclosure, or other privacy-preserving representations MAY be used when compatible with the enforcement requirement.¶
This document presently requests no IANA actions.¶
Composable infrastructure changes the security object. Trust in a device, workload, or protected channel is not always sufficient when the consequential event is a dynamic transition in resource ownership, visibility, mapping, or authority.¶
Attestation can establish evidence about trusted state. Secure transport can protect a request in transit. Access control can authorize a class of operations. Execution finality adds a separate invariant: the exact transition that becomes effective must still correspond to the transition whose security conditions were evaluated.¶
In short, a trusted component does not necessarily imply a trusted transition.¶