]> Arm

ionut.mihalcea@arm.com

Security SEAT Working Group remote attestation TLS confidential computing IoT RATS This document describes use cases for integrating remote attestation (RA) with secure channel protocols, initially TLS and DTLS. Peer authentication establishes a peer's identity; RA supplies Evidence for appraisal of its state. The document identifies protected decisions and required assurance, describes the attacks and failure modes that threaten them, and derives properties to guide protocol designs in the SEAT working group. These properties address association of attested state with a peer and connection, freshness, re-evaluation, negotiation, and disclosure of attestation material.

Introduction

Establishing Trust in Secure Communications Secure channel protocols, such as Transport Layer Security (TLS), primarily establish trust in a peer's identity. This is typically achieved through mechanisms like a Public Key Infrastructure (PKI), where a trusted Certification Authority (CA) vouches for the binding between a public key and an identifier (e.g., a hostname). However, this model has one key limitation: entity authentication provides no assurance about the peer's state, such as the integrity of its software stack at boot time and during runtime. A compromised endpoint, for instance, can still present a valid X.509 certificate and be considered "trusted" by a client. This gap allows compromised endpoints to maintain network access and the trust of their peers, posing a significant security risk in many environments.

The Role of Remote Attestation Remote Attestation (RA), as described in the RATS architecture , is a mechanism designed to fill this gap. RA allows an entity (the "Attester") to produce verifiable "Evidence" about its current runtime state. This Evidence covers the Attester's security state and can thus include measurements of:

• firmware
• operating system
• application code
• the configuration of its hardware and software security features (e.g., secure boot status and memory isolation).

A "Verifier" appraises this Evidence and produces an Attestation Result. A "Relying Party" uses that result to decide whether the Attester's state is acceptable for a protected operation. The Verifier and Relying Party roles can be performed by the same entity. Composing RA with a secure channel establishment protocol adds a second dimension of trust - trustworthiness - to complement peer authentication. This allows a peer to make authorization decisions based not just on who the other party is, but also on what it is (e.g., an AMD SEV-SNP-based server running in some known datacenter) and whether its state is acceptable.

Purpose and Scope This document presents use cases for composing RA with secure channel protocols in , describes relevant attacks and failure modes in , and derives integration properties in . The use cases include envisioned deployment patterns contributed by SEAT WG participants. The initial focus is TLS 1.3 and DTLS 1.3 . The target audience for this document is the working group members, especially those authoring protocol specifications intended to address the core purpose of the SEAT WG. These protocol specifications should identify the use cases they support and specify the exchanges and checks needed to establish their required assurance. The properties are agnostic to attestation technology. Protocol mechanisms and the contents of appraisal policies () are outside this document's scope. This document aims to guide protocol designers at a security design principle level, agnostic of the operational considerations required to enforce such principles, and without prescribing any specific mechanisms or deployment patterns.

Terminology This document uses the terminology defined in the RATS Architecture , including "Attester", "Relying Party", "Verifier", "Evidence", and "Attestation Results". This document also uses the following terms:

• Attesting and Target Environments: as described in .
• Attested workload: An instance of software executing within a Target Environment, which can obtain remote attestation Evidence or Attestation Results about itself.
• Measurements: as defined in .
• AI agent: An AI agent is a software principal that performs closed-loop cycles using an LLM or other model.
• Credential: as defined in .
• Solution: used in this document to generically reference proposed protocol designs which aim to fulfill the SEAT WG charter.
• Authenticated identity: the identity of a peer as established by the secure channel establishment protocol's authentication (for example, TLS handshake authentication, see ), i.e., an identifier cryptographically bound to the key or credential the peer authenticates with (for example, a certificate subject as in ).

Use Cases The server-as-Attester and client-as-Attester profiles define the two base attestation directions. The remaining profiles add composition, lifecycle, or topology considerations. Application examples can map to several profiles. The Verifier appraises Evidence and produces an Attestation Result (AR). The Relying Party uses the AR and any required authenticated identity for its protected decision. An unacceptable result is rejected; inability to complete required appraisal, validation, association, or freshness checks leaves the decision indeterminate. When policy requires attestation, either outcome blocks the operation. Any non-attested fallback is separate and explicit. Relying Party policy determines when a result is usable and whether it can be reused. Fresh assurance is needed when the result expires, a relevant state change is identified, or a new connection invalidates a required binding. Verifier appraisal can supply applicable validity constraints. Combined profiles can use different Verifiers, trust anchors, policies, timing, and lifetimes. Sharing or coordinating them is a deployment choice.

Server as Attester Before a Protected Operation Scenario and protected decision or asset: A TLS client needs assurance about a TLS server before releasing sensitive data, accepting a result, or sending a high-impact command. TLS and RATS roles: The server is the Attester, the client is the Relying Party, and the Verifier can be separate. Existing TLS authentication: TLS authenticates the server's identity; RA adds information about its Target Environment. Attestation scope: For endpoint attestation, the Target Environment contains the TLS endpoint. The key-component example below has a narrower scope. applies when an intermediary terminates TLS. Required security outcome: The assurance about the server endpoint or its authentication key applies to the connection carrying the protected operation. Limitations: Attestation does not guarantee the server's future state or behavior. Application examples:

• High-Assurance Command Execution An operator sends a critical command to a remote system, such as an industrial controller. The system provides fresh Evidence for appraisal before the command is sent.
• Data Clean Rooms Data providers contribute sensitive data to an attested workload for joint analysis, while data consumers receive only aggregated results. Before sending data or accepting results, they attest that the workload runs authorized code in a Trusted Execution Environment (TEE).
• Securing Control and Management Planes Before an administrator uses a network device's management interface, the client appraises Evidence about the endpoint's state. This avoids exposing network credentials or policy to a compromised interface.
• Attestation of Certificate Private Key A TLS endpoint authenticates with an end-entity certificate whose private key is claimed to be protected by a secure element. This case appraises the key-holding component, which need not run the TLS stack. The required association is with the authentication key (); it does not establish the state of the whole TLS endpoint. describes the key claims and checks. addresses attestation at certificate issuance; this use case needs assurance applicable to the connection.

Client as Attester Before Service Admission Scenario and protected decision or asset: A service needs assurance about a TLS client before granting access or releasing a protected asset. TLS and RATS roles: The client is the Attester and the TLS server is the Relying Party. A separate Verifier can appraise the Evidence, and a separate component can enforce admission, as in the network-access example. Existing TLS authentication: Client attestation works with or without TLS client authentication. Attestation topology and trust boundaries: The Target Environment is the client component being appraised. The service and Verifier can belong to different administrative domains and use different trust anchors. Required security outcome: The Relying Party associates the acceptable state with the client receiving access or the asset. If client authentication is used, both inputs refer to the same endpoint. Limitations: Attestation does not guarantee the client's future state or use of granted access. Acceptable measurements and credential issuance are outside this profile. Application examples:

• Attested Workload and Device Provisioning A workload or device obtains the secrets, configuration, credentials, or policy needed to become operational only after its state is appraised. This includes runtime secret provisioning for an attested workload and onboarding an IoT device without a pre-provisioned authentication credential. For example, a Confidential Container can obtain configuration data or disk keys from a Key Broker Service or Trustee after appraisal of its TEE claims and software measurements. The workload is the Attester; the Trustee is the Relying Party and can also be the Verifier. It also includes injecting a Web PKI credential into a short-lived TEE container: a cluster utility can obtain the certificate and private key before loading them into the container, while the Relying Party obtains current assurance that the intended Target Environment uses the provisioned credential. Credential issuance remains outside SEAT.
• Attestation of Network Functions Before admitting a network device or function to the management plane, the orchestrator appraises Evidence about its state. This gates admission and policy delivery; it does not attest other devices or the traffic path.
• Enterprise Network Access Control An endpoint seeks access through an 802.1X Ethernet port or WPA3-Enterprise access point. With EAP-TLS , the Network Access Server relays the exchange to an EAP/AAA server . That server is the TLS server and Relying Party; it can also perform the Verifier role. The Network Access Server enforces the resulting admission decision. Attestation associates the appraised client with the EAP-TLS exchange. Delivery and enforcement of network authorization are functions of the access system. The admitted traffic does not use the EAP-TLS connection.

Mutual Attestation Before Sensitive Exchange This profile overlays the server-as-Attester and client-as-Attester profiles when both TLS peers need assurance before releasing protected data. The two directions remain independent as described above. Mutual attestation does not require mutual TLS authentication. Required security outcome: In each direction, the acceptable attested state is associated with the peer endpoint that will receive protected data. Operational and failure behavior: A failure in one direction prevents that party's protected release. A successful attestation in only one direction is not mutual attestation. Assumptions, limitations, and non-goals: Mutual attestation does not prove a joint computation correct. The application defines its transaction semantics. Application examples:

• Secure Multi-Party Computation (MPC) Parties compute a function without sharing their local data. The aggregator and clients mutually attest that they run the expected MPC software in trusted environments.
• Platform-to-Platform Workload Migration Workloads can migrate between platforms to maintain service availability. Migration agents authorize and transfer the workload while enforcing policies that prevent migration to a platform with lower security guarantees. The destination and source migration agents attest to each other. Intel TDX Migration Trust Domains (MigTDs) use an attested TLS connection between the source and destination.

Re-Evaluation on Long-Lived or Resumed Connections Scenario and protected decision or asset: A peer needs current assurance before a later operation on a long-lived or resumed connection. TLS and RATS roles: Either endpoint can be the Attester or Relying Party; both can re-attest. Attestation trigger: Re-evaluation can be periodic or occur before a high-impact operation. Required security outcome: The assurance applies to the later operation and connection; earlier or unrelated Evidence cannot be substituted. Retaining TLS state alone does not preserve assurance across a change of endpoint, workload, or intermediary. Operational and failure behavior: An indeterminate re-evaluation does not satisfy a request for new assurance or extend an old result. Operations requiring that assurance wait for the necessary checks, including on resumption. Limitations: Re-attestation cannot protect data already released or constrain future state changes. Application examples:

• Operation-Triggered Attestation for High-Impact Application Operations An application service, such as an AI agent, maintains a (D)TLS connection and later performs a high-impact action. Before that action, its peer obtains fresh, connection-bound Evidence of the current behavior-affecting posture. describes this use case. The attestation can occur over the existing connection without requiring a new TLS handshake.
• AI Governance and Accountability A governance body appraises Evidence from an autonomous AI agent when deciding whether it may act. Runtime attestation follows the risk tiers in .
• Actor Identity Continuity via Longitudinal Trajectory Attestation A TLS peer presents Evidence about the trajectory of an actor whose authenticated identity persists across platforms. The Relying Party attributes the trajectory to that identity and uses each policy-defined interval for a separate authorization decision. The actor is not tied to a particular machine. TRIP provides one example.

Intermediary-Aware Deployment Scenario and protected decision or asset: An intermediary terminates or mediates communication with an attested service. The Relying Party needs assurance about the intermediary or an origin behind it. TLS and RATS roles: The Attester can be an endpoint or intermediary, in either attestation direction. Existing TLS authentication: The TLS authenticated identity represents the connection-terminating peer. That identity alone need not distinguish a proxy from the origin. Attestation scope: The intermediary can be the appraised service boundary. Assurance about an origin behind a separate terminator requires an additional association to that origin. Required security outcome: The appraisal applies to the intended component. Assurance about an origin does not establish assurance about its terminator, or conversely. Operational and failure behavior: An unexpected or indeterminate topology cannot silently replace a policy-required attested path. Limitations: A TLS terminator remains a trust boundary. Application examples:

• Proxy-Fronted Attested Secure Channels An endpoint reaches an application through an operational intermediary. The Relying Party can attest that intermediary or appraise an origin behind a trusted terminator. An untrusted terminator remains a trust boundary.
• Service-Mesh Attestation Service-mesh proxies terminate or mediate TLS for application workloads. A peer obtains fresh Evidence for the relevant proxy so policy can distinguish an expected attested proxy from an unacceptable one.

These profiles identify the decisions that require attestation and the assurance needed to support them. The following attacker model describes attacks and failure modes that can invalidate that assurance. Together, they motivate the integration properties in .

Attacker Model This section models the attacks that may affect the assurances provided by solutions. To allow preservation of these assurances, mitigation avenues are also given. Solutions may devise alternative mitigations, but should thoroughly document how these enforce the desired assurance. The baseline attacker is the Internet Threat Model of , represented by the network attacker below. Other scenarios grant additional capabilities or describe inherited security limits. A solution considers the scenarios relevant to its supported use cases and claimed assurance. Unless stated otherwise, the Relying Party is uncompromised and performs the required protocol and policy checks. The TLS security assumptions in apply. A Target Environment may represent a Trusted Execution Environment (TEE) . For endpoint attestation, the model assumes that the Attester's TLS stack runs within the appraised Target Environment. The key-component case in instead concerns the authentication key. Origin attestation behind a separate terminator requires an additional association ().

Attacker Capabilities The attacks in this section use the following attacker profiles:

• Network attacker: Controls communication between the peers and can observe, inject, modify, drop, delay, reorder, and replay messages. This attacker does not control either endpoint or possess their cryptographic secrets. This closely follows the attacker model of .
• Malicious peer: Controls a TLS endpoint and can deviate arbitrarily from the protocol. The attacker cannot generate Evidence which would be accepted by the Relying Party's appraisal policy. This can be because the endpoint is not running in a Target Environment, or because the Evidence for that Target Environment does not meet the requirements of the appraisal policy. The attacker does not control or compromise an Attesting Environment or its Attestation Key.
• Ephemeral-key attacker: Possesses an endpoint's ephemeral private key used for key establishment in a particular secure-channel handshake. Given the peer's public key share and the handshake transcript, this attacker can derive the connection's handshake and application traffic secrets when the key schedule does not also depend on independent secret keying material unknown to the attacker, such as a PSK. This capability does not, by itself, imply possession of an authentication key or Attestation Key.
• Traffic-secret attacker: Possesses either the handshake and/or the application traffic secrets for a secure connection. Each attack specifies which direction and epoch are relevant. Possession of a traffic secret does not, by itself, imply possession of an authentication key (see below) or Attestation Key.
• Authentication-key attacker: Possesses the private key used by a peer to authenticate itself in a secure connection (e.g., to sign the CertificateVerify message in the TLS 1.3 handshake).
• Attestation-key attacker: Can use an Attestation Key whose credential the Relying Party continues to accept.
• Target-Environment attacker: Can change the state of a Target Environment after Evidence about that environment has been generated.

Structure of Attack Descriptions Each scenario identifies:

• Attacker capabilities: The attacker profiles and any additional capabilities.
• Targeted assurance: The claim the scenario invalidates.
• Preconditions and attack: The conditions, actions, and consequences. Non-adversarial failure modes use Preconditions and event.
• Why validation succeeds: The checks that still pass.
• Mitigation strategy: The required outcome or an inherited limit or deployment dependency, without selecting a protocol mechanism.
• Why optional: The circumstances under which an optional scenario applies.

Evidence Reuse

Per-Connection Evidence Replay Attacker capabilities: A malicious peer retains valid Evidence generated earlier in the current TLS connection. Targeted assurance: Evidence presented in response to a re-attestation request reflects the current state of the Target Environment. Preconditions and attack: Evidence is bound to the TLS connection but not uniquely to an individual attestation exchange. After valid Evidence is accepted, the state of the Target Environment changes and the Relying Party requests new Evidence. The malicious peer retransmits the earlier Evidence in new TLS records, causing the Relying Party to treat the earlier state as current. Why validation succeeds: The Evidence remains authentic and its connection-level binder still matches. TLS record replay protection does not detect the attack because the old Evidence object is retransmitted as new application data. Mitigation strategy: The response is bound to the requested attestation exchange using a mechanism that meets its freshness condition. A request for newly generated Evidence cannot be satisfied by a response prepared before the request, even on the same connection ().

Evidence Relay Attacker capabilities: The attacker, acting as a malicious TLS peer, can establish a TLS connection with a Relying Party and can obtain Evidence that contains the correct binder for the attacker's connection as its challenge value, and which represents a Target Environment. How the attacker obtains such Evidence is not constrained by this model. The attacker does not need to control or collude with the Attesting or Target Environment. Targeted assurance: The Relying Party incorrectly attributes the claims asserted by the Evidence to the TLS endpoint and assumes that the authentication private key has the protection properties asserted by the Evidence. Preconditions and attack: The attacker obtains the binder for its TLS connection with the Relying Party. It then obtains authentic, fresh Evidence about a separate Target Environment in which that binder appears as the challenge value and presents the Evidence to the Relying Party. If the Evidence is accepted, the Relying Party attributes the state of the separate Target Environment to the attacker's endpoint and TLS connection. Why validation succeeds: Proof of possession in CertificateVerify establishes that the peer controls the private key. The Evidence is authentic and fresh, and its challenge value matches the binder expected for the attacker's connection. These checks establish that the Attesting Environment incorporated the correct binder into the Evidence, but not that the evidenced Target Environment is holding the authentication key or the TLS stack that can use it. Mitigation strategy: Acceptance of Evidence establishes that the evidenced Target Environment is associated with the peer participating in the TLS connection being appraised. Merely including the correct connection binder as a challenge value does not establish this association.

Key Substitution Attacker capabilities: A malicious peer controls an authentication private key that was not generated or protected within a TEE, but can obtain valid Evidence claiming the key is protected. Targeted assurance: The authentication private key benefits from the key protection properties asserted by the Evidence. Preconditions and attack: The Relying Party's appraisal policy does not cover the lifecycle of the authentication key. The peer imports the key pair into a TEE, establishes the secure connection by proving possession of its private key and presents valid Evidence about the Target Environment protecting a copy of the key. The Relying Party consequently treats a software-held, exportable, or otherwise unprotected key as though it had the protection properties of the Target Environment. It can then release secrets or authorize operations that it would deny to a peer using such a key. Why validation succeeds: Proof of possession establishes that the peer controls the private key, and Evidence appraisal establishes properties of the Target Environment. Neither check establishes that this particular private key was generated, and is used strictly within that environment. Mitigation strategy: The authentication public key is unambiguously bound to Evidence asserting its relevant generation, storage, export, and use properties, and those assertions are appraised together with the connection authentication.

Evidence Privacy Loss

Under Ephemeral-Key Compromise Attacker capabilities: An ephemeral-key attacker possesses an endpoint's ephemeral key-establishment secret for the handshake and observes the handshake transcript, including the peer's public key share. Targeted assurance: Evidence conveyed during or after the handshake remains confidential from parties other than the connection endpoints. Preconditions and attack: The attacker records the handshake and protected records carrying Evidence. Using the compromised ephemeral private key, the peer's public key share, and the recorded handshake messages, the attacker computes the shared secret and derives the handshake and application traffic secrets. It can then decrypt Evidence protected under those secrets, including Evidence decrypted retrospectively from recorded traffic after the compromise. Why validation succeeds: This is a secure-channel confidentiality failure, not an Evidence-validation failure. The Evidence can remain authentic, fresh, and correctly bound to the connection even though its contents are disclosed. Mitigation strategy: This is a limit of transport protection. A recovery claim requires fresh key-establishment input independent of the compromised secret before further Evidence is sent.

Under Traffic-Secret Compromise Attacker capabilities: A traffic-secret attacker possesses the traffic secret used to protect an attestation exchange on a (D)TLS connection. This capability permits decryption of records protected by that secret, but does not by itself imply control of either endpoint. See for additional discussion of the threat. Targeted assurance: Evidence conveyed inside the secure connection remains private from parties other than the connection endpoints. Preconditions and attack: Attestation Evidence is sent under a compromised handshake or application traffic secret. The attacker observes the protected records and uses the secret to decrypt the Evidence, learning the platform and software details it carries. Why validation succeeds: This is a confidentiality failure rather than an Evidence-validation failure. The Evidence can remain authentic and correctly bound to the connection even though its contents are disclosed. Mitigation strategy: This is a limit of transport protection. A recovery claim requires independent traffic secrets before further Evidence is sent.

State Drift on Long-Lived and Resumed Connections Classification: This is a stale-assurance failure mode. It can result from a Target-Environment attacker, but it can also result from legitimate reconfiguration, software update, or other state change. Targeted assurance: Evidence appraised for a connection remains an adequate basis for decisions made later in that connection or in a resumed connection. Preconditions and event: The Relying Party accepts Evidence during an initial handshake. The Target Environment subsequently changes without new Evidence being requested and verified. Two cases are relevant:

• The original connection remains open and continues to carry sensitive data after the Evidence becomes stale.
• A later connection uses session resumption and omits a new attestation exchange, thereby inheriting an assurance established before the state change.

In either case, communication or authorized operations continue with a Target Environment whose current state has not been appraised. Why validation succeeds: The original Evidence remains authentic, but it no longer describes the current state. The Relying Party has no newer Evidence on which to base its decision. Mitigation strategy: The validity of an appraisal is bounded by an explicit lifetime or by security-relevant events. Continued and resumed connections do not rely on an appraisal beyond that bound without obtaining and appraising new Evidence.

RA Negotiation Downgrade Attacker capabilities: A network attacker can modify messages carrying the peers' RA capabilities or selections. Alternatively, a malicious peer can disregard the RP's request for attestation. Targeted assurance: The use of RA and the selected Evidence format and attestation model reflect the peers' authentic capabilities and configured policies. Preconditions and attack: The RA negotiation is not authenticated as part of the secure-channel transcript or by equivalent protection, or an endpoint permits unprotected fallback. The attacker removes an RA capability, causes fallback to a channel without RA, or alters the selection to one that does not satisfy a peer's configured policy. As a result, the connection completes without required attestation or with attestation parameters that are unacceptable under the policy that would have been applied to the authentic negotiation. Why validation succeeds: The endpoint cannot distinguish the attacker-modified negotiation from the peer's authentic offer or selection. Mitigation strategy: The complete RA negotiation and its outcome are integrity-protected and bound to the secure channel. An endpoint does not silently fall back when its policy requires RA or particular attestation properties.

Compromise of Security-Critical Keys

Authentication Key Compromise and Re-hosting (OPTIONAL) Attacker capabilities: An authentication-key attacker can also operate an endorsed Target Environment that satisfies the Relying Party's appraisal policy. The stolen authentication key is importable into that environment and has not been revoked. This represents a Man-in-the-Middle attack as described in . Targeted assurance: An authenticated peer identity remains associated with an authorized Target Environment instance. Preconditions and attack: The Relying Party accepts any endorsed environment of an expected class rather than a particular authorized instance. The appraisal policy also does not expect the key to have been created in the Target Environment. The attacker imports the stolen authentication key into its own acceptable environment, establishes a new connection using that key, and presents fresh Evidence bound to both its connection and the corresponding authentication public key. The Relying Party then authenticates the attacker as the holder of the stolen identity and accepts the attacker's environment as an authorized host for that authenticated identity. Why validation succeeds: Proof of possession succeeds because the attacker has the authentication private key. The connection binding and public-key binding also succeed because the Evidence describes the attacker's current connection and environment. Evidence appraisal accepts that environment. Mitigation strategy: Instance-specific authorization or a key-protection policy that rejects the imported key can prevent this attack. The integration preserves the associations needed by those policies (). The contents or shape of those policies is outside the scope of solution documents. Why optional: For class-based appraisal (i.e., where the Target Environment is not restricted to a set of known platforms or workload instances), this attack is out of scope as the attacker's posture (acceptable Target Environment that provides an authenticated identity) is what the RP expects to see.

Attestation Key Compromise Attacker capabilities: An Attestation-key attacker can use an Attestation Key whose credential remains accepted by the Relying Party. Targeted assurance: Authenticated Evidence truthfully represents the claims collected from the Target Environment. Preconditions and attack: The compromised Attestation Key is sufficient to authenticate the relevant Evidence claims. The attacker constructs Evidence containing attacker-chosen claims and bindings and signs it with that key. The Relying Party can consequently accept arbitrary asserted platform state, key provenance, or connection associations as authentic. Why validation succeeds: The Evidence signature, connection binding, authentication-public-key binding, and asserted key provenance all verify against attacker-chosen values. Those checks ultimately rely on the compromised Attestation Key. Mitigation strategy: Compromised-key rejection and recovery depend on the attestation trust infrastructure. Valid connection and key bindings do not make forged claims trustworthy.

Properties of RA and TLS Integration The use cases in and attacks in motivate the properties below. A solution identifies the profiles and attestation models it supports, and specifies the protocol behavior and checks that establish the applicable properties. These include the bindings, exchange outcomes, and lifecycle transitions needed to use attestation in a protected decision. The properties apply whether the Attester conveys Evidence or an Attestation Result. Solutions preserve the association between the appraisal result, the appraised subject, and the relevant connection and exchange. The common decision rules in apply throughout. shows which attacks and use cases motivate each property. A dash indicates that no attack scenario in , or no use case in , is directly associated with the property. The Attestation Key compromise scenario () maps to no property: its mitigation depends on the attestation trust infrastructure and is outside what an integration can establish (). Origin of the Properties

Property	Attacks	Use cases
Attestation Status Before a Protected Decision ()	-	, ,
Endpoint and Connection Association ()		,
Peer Identity Association ()	-	,
Authentication-Key Properties ()	,
Exchange Freshness ()
Appraisal Lifetime and Re-Evaluation ()
Protected Negotiation ()		-
Independent Attestation Directions ()	-
Endpoint and Origin Boundaries ()	-
Confidentiality and Disclosure ()	,	-

Attestation Status Before a Protected Decision For , , and later decisions under , a solution specifies:

• successful, rejected, and incomplete exchange outcomes;
• how the applicable Attestation Result or the outcomes of association and freshness checks are made available to the Relying Party;

Completion of TLS alone does not establish successful attestation. Failure to complete a check required for the decision leaves it indeterminate. Result reuse follows . Neither rejection nor an indeterminate decision permits an operation requiring attestation; any fallback to operations without attestation is explicit and policy-permitted, as described in .

Association of Attested State with the TLS Endpoint and Connection For endpoint attestation in and , a solution specifies how its checks establish a cryptographically supported association between the appraised Target Environment and the peer endpoint of the relevant TLS connection. Authentic, fresh Evidence from an unrelated environment cannot establish that association merely by containing the expected connection binder (). When protected data or operations use that connection, the association applies to the connection carrying them. In admission use cases such as network access, it applies to the TLS exchange supporting the admission decision; enforcement of the resulting authorization is orthogonal to establishment of the association. Failure to establish the required association leaves the decision indeterminate. A solution supporting session resumption specifies how the association with the appraised Target Environment is retained or re-established for the resumed connection. Successful TLS resumption alone does not establish that the peer is still the appraised environment or that its state remains acceptable. The solution specifies the checks needed to reuse prior assurance and when fresh attestation is required, subject to . Attestation of a key-holding component uses and does not by itself establish the state of the TLS endpoint. Origin attestation behind a separate terminator uses .

Association with Authenticated Peer Identity When a protected decision relies on authenticated peer identity, a solution specifies how the authenticated identity and appraised state are associated with the same peer endpoint and connection ( and ). It preserves the configured TLS authentication; attestation does not satisfy a separate requirement for identity authentication. Solutions supporting client attestation should permit it with and without TLS client authentication.

Association with Authentication-Key Properties For , a solution specifies how the appraised public key is matched to the key used by TLS authentication and which authentication modes it supports. Holding a copy of a key in an appraised environment does not establish its generation, storage, export, or use properties (); those require the applicable attestation claims and appraisal. The solution specifies what key association is retained or re-established on resumption. A resumed connection can authenticate with a PSK without exercising the original certificate private key. Unsupported modes cannot satisfy a decision requiring that key assurance. Key-protection claims and policies, including permitted import in , are supplied by the attestation mechanisms and deployment.

Freshness for an Attestation Exchange A solution specifies how Evidence or an Attestation Result conveyed in an attestation exchange satisfies its freshness requirements ( and ). If an exchange requires Evidence generated after its initiation, neither earlier Evidence nor an Attestation Result based on earlier Evidence satisfies that requirement. Solutions specify the context and acceptance rules for their chosen freshness mechanism. A valid connection binding alone may not establish freshness. Policy-permitted reuse follows . Exchange freshness does not itself establish that the measurements are fresh; see .

Appraisal Lifetime and Re-Evaluation For decisions that reuse a result, a solution makes its applicable validity constraints available. Solutions supporting specify how re-attestation is requested on an existing connection and how its outcome updates attestation status. An incomplete re-evaluation does not extend an old result or satisfy a request requiring new assurance (). A solution supporting resumption specifies what attestation context is retained, invalidated, or re-established and which checks precede its use on the resumed connection. Retaining TLS state alone does not transfer assurance to a changed endpoint, workload, or intermediary, or extend a result's validity. If early data is supported, the solution specifies whether attestation-dependent operations can use it and what assurance is available before release or processing. The early-data rules in apply. Result lifetimes and periodic re-evaluation intervals remain policy choices.

Protected Negotiation and Policy-Respecting Fallback A solution specifies its RA capability and parameter negotiation, including any format or attestation-model selection, and how the complete negotiation and outcome are integrity-protected and bound to the connection (). Peers validate that protection before relying on an unambiguous selection. The solution specifies behavior when required attestation is omitted, unavailable, or unacceptable. Such outcomes cannot satisfy a policy requiring RA or particular attestation properties. Any non-attested fallback is an explicit, policy-permitted choice. Negotiation cannot compel a peer to attest or prevent denial of service.

Independent Attestation Directions For or other combinations of the base profiles, a solution specifies how exchanges, results, and negotiated state are associated with their Attester, Relying Party, and attestation direction. Success in one direction cannot satisfy the other direction's requirements. Each direction's protected release depends on its own successful appraisal and decision. Mutual attestation may not require mutual TLS authentication.

Explicit Endpoint and Origin Boundaries A solution supporting identifies the appraised component and the scope of its assurance. Attestation of the TLS terminator uses . A solution claiming assurance about an origin behind a separate terminator specifies or references the additional association to that origin, its validation, and the trust placed in the terminator. Assurance about an origin and assurance about its terminator are not interchangeable. A solution that cannot establish the required association cannot claim origin assurance. Support for arbitrary termination topologies is not required.

Confidentiality and Disclosure of Attestation Material When restricted disclosure is supported, the solution specifies how disclosure is limited to authorized recipients, including any recipient authentication or attestation required before disclosure, and identifies the mechanisms and recipient-key trust assumptions on which this protection depends. This covers initial and post-handshake exchanges, terminators, and separate Verifiers. It also identifies disclosures from negotiation data. The solution states the limits of its protection, including disclosure to unauthenticated peers and active attackers before later validation fails. Neither transport encryption nor recipient authentication prevents a recipient from redistributing Claims. If restricted disclosure is supported, the solution specifies or references the mechanisms and recipient-key trust assumptions (Sections , , and of ). Where Evidence is opaque to the Relying Party, the solution specifies how the Relying Party obtains authenticated assurance that the required connection and key bindings have been validated. Any recovery claim under or specifies the protection mechanism, the attackers it covers, and which checks precede release under independent secrets. Detection after release does not protect material already disclosed.

Security Considerations The properties in depend on the security assumptions of TLS and the attestation mechanisms used. The security considerations in and the RATS security and privacy considerations in Sections and of apply. Bindings cannot establish the truth of claims forged under an accepted, compromised Attestation Key (). Solutions honor rejection of unusable credentials or results and apply . Invalidation affecting an existing result also affects its reuse under . The key-exposure scenarios in and describe inherited confidentiality limits. Recovery claims require the protection described in ; attestation alone does not repair compromised TLS secrets. Attestation material can disclose platform, workload, or user identifiers. A separate Verifier in a Background Check exchange can also learn which Relying Party requests appraisal and when. Solutions account for disclosures introduced by message placement, negotiation, and Verifier interactions as described in . Omitting TLS client authentication does not make identifying Evidence anonymous.

IANA Considerations This document has no IANA actions.

Informative References All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This memo provides information for the Internet community. This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE. Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. Arm Linaro University of Applied Sciences Bonn-Rhein-Sieg Fraunhofer SIT The term "measured component" refers to an object within the attester's target environment whose state can be sampled and typically digested using a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document provides the information model for the "measured component" and two associated data models. This separation is intentional: the JSON and CBOR serializations, coupled with the media types and associated Constrained Application Protocol (CoAP) Content-Formats, enable the immediate use of the semantics within the Entity Attestation Token (EAT) framework. Meanwhile, the information model can be reused in future specifications to provide additional serializations, for example, using ASN.1. n.d. Independent University of the Bundeswehr Munich Google, Inc. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. Siemens Nokia Münster Univ. of Applied Sciences Siemens Zscaler TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys (typically a private key with a corresponding certificate) are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post- compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh execution of the key exchange negotiated during the initial handshake within an active session to support post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. Cryptic Forest Software University of the Bundeswehr Munich University of Applied Sciences Bonn-Rhein-Sieg This document extends the RATS Architecture to consider "coercive uses of RATS" where a malicious Verifier or Relying Party uses RATS protocols to extract sensitive information from an Attester or a victim Verifier that it would not otherwise be inclined to disclose. This over-disclosure can include revealing sensitive measurements, stable identifiers, device fingerprints, vendor information, or conclusions derived from Evidence. This document defines a privacy framework for Remote Attestation that identifies this threat surfaces; classifies claims produced by Attesters and Presenters; restricts sensitive Evidence disclosure to authorized Trusted Verifiers using confidentiality protection; and describes privacy- preserving Attestation Results based on data minimization, Selective Disclosure, and Zero-Knowledge Proofs. This document specifies the AI Governance and Accountability (AIGA) Protocol, a practical, economically viable, and technically enforceable framework for governing autonomous AI agents. AIGA is designed to address real-world deployment constraints, adversarial agent scenarios, and economic incentive alignment. The protocol is founded on a Tiered Risk-Based Governance model, applying proportional oversight to agents based on their capabilities. All agents are governed by an Immutable Kernel Architecture which provides a non-modifiable Trusted Computing Base (TCB) for enforcing policy. This is combined with Action-Based Authorization, where critical operations require real-time approval. To solve the single-point-of-failure problem, the protocol uses a Federated Authority Network of regional, cross-validating hubs and provides a Network-Level Quarantine Protocol for enforcement. The entire framework is designed around Economic Incentive Alignment, making compliance the most economically rational choice for operators. For high-assurance (T3-T4) scenarios, AIGA specifies advanced, redundant mechanisms including Multi-Vendor TEE Attestation (M-TACE), AI "Warden Triumvirate" Triage, Human Review Board (HRB) Multi- Signature, Peer Consensus Failsafe & Identity Rotation, and Double Ratchet Cryptography. Crypto4A Inc. Cryptic Forest Software University of the Bundeswehr Munich Fraunhofer SIT This document specifies a vendor-agnostic format for Evidence produced and verified within a PKIX context. The Evidence produced this way includes claims collected about a cryptographic module, such as a Hardware Security Module (HSM), and elements found within it such as cryptographic keys. One scenario envisaged is that the state information about the cryptographic module can be securely presented to a remote operator or auditor in a vendor-agnostic verifiable format. A more complex scenario would be to submit this Evidence to a Certification Authority to aid in determining whether the storage properties of this key meet the requirements of a given certificate profile. Nokia University of the Bundeswehr Munich Linaro Arm Limited Fraunhofer SIT This document defines an Entity Attestation Token (EAT) profile and a new EAT claim that convey the subject public key and its protection properties within attestation evidence. Combined with protocol-level proof of possession from the surrounding protocol, this establishes a cryptographic binding between a private key and an attested execution environment. The subject public key is conveyed using the EAT cnf claim defined in [RFC8747] and [RFC7800], and freshness uses the EAT eat_nonce claim defined in [RFC9711]. The proof of possession of the subject key is obtained from the surrounding protocol, such as TLS certificate-based authentication or CSR signature verification. Because the EAT is signed by a hardware-backed Attestation Key (AK), successful verification of the EAT signature together with protocol-level proof of possession establishes a cryptographic binding between the private key and the attested platform state. This mechanism addresses key substitution attacks that arise when attestation evidence and the certificate private keys are validated independently. This document describes a use case for conveying remote attestation information in association with Transport Layer Security (TLS) sessions in the context of AI agent communication. It focuses on long-lived secure channel sessions where an AI agent runtime posture, covering the platform Trusted Computing Base (TCB), agent manifest (models, tools and policies) and committed runtime context, can change frequently and unpredictably. The document highlights requirements for dynamic attestation so that relying parties can base authorization decisions on the current runtime posture of the communicating agent. ULISSY s.r.l. TU Dresden The Capital Index This document specifies the Trajectory-based Recognition of Identity Proof (TRIP) protocol, a decentralized mechanism for establishing claims of physical-world presence through cryptographically signed, spatially quantized location attestations called "breadcrumbs." Breadcrumbs are chained into an append-only log, bundled into verifiable epochs, and distilled into a Trajectory Identity Token (TIT) that serves as a persistent pseudonymous identifier. The protocol employs a Criticality Engine, a statistical anomaly detector informed by complex-systems research, to distinguish biological movement from synthetic trajectories. Power Spectral Density (PSD) analysis of the displacement series yields a scaling exponent alpha that captures long-range temporal correlation in movement. A six-component Hamiltonian energy function scores each breadcrumb against the identity's learned behavioral profile in real time. This revision (-05) reframes the statistical core of the Criticality Engine in light of empirical validation against human-mobility data: the PSD scaling exponent alpha is specified as a per-deployment- calibrated scored feature rather than a fixed classification gate; the fixed [0.30, 0.80] "biological" band is withdrawn in favor of calibrated ranges; the asserted Levy-PSD bridge is replaced by a statement of the independence of the step-size and temporal- correlation features; and a new validation section reports separation results and methodology. The cryptographic chain, RATS mapping, Active Verification Protocol, and privacy model are unchanged from -04. TRIP is designed to be transport-agnostic and operates independently of any particular naming system, blockchain, or application layer. n.d.

Acknowledgments We would like to thank Muhammad Usama Sardar, Thomas Fossati, Tirumaleswar Reddy, Yuning Jiang, and Meiling Chen for their work on establishing this document and enabling its adoption. We would like to thank Camilo Ayerbe Posada, Chengxin Huang, Eric Rescorla, Hannes Tschofenig, Haowen Song, Henk Birkholz, Ira McDonald, Mark Novak, Markus Rudy, Michael Richardson, Nathanael Ritz, Paul Wouters, Serhii Nikolaichuk, Songbo Bu, Steve Luo, Waqas Nawaz, Yaron Sheffer, Yaroslav Rosomakho, Ayoub Benaissa, Iman Schrock, Katapulta Pultalowska, Ned Smith, Sophie Schmieg for their reviews and feedback.