SEAT Working Group I. Mihalcea, Ed. Internet-Draft Arm Intended status: Informational 2 November 2026 Expires: 6 May 2027 Security Goals and Use Cases for Integrating Remote Attestation with Secure Channel Protocols draft-ietf-seat-use-cases-02 Abstract 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. Status of This Memo 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 6 May 2027. Copyright Notice 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 Mihalcea Expires 6 May 2027 [Page 1] Internet-Draft SEAT Use Cases November 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Establishing Trust in Secure Communications . . . . . . . 3 1.2. The Role of Remote Attestation . . . . . . . . . . . . . 3 1.3. Purpose and Scope . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Server as Attester Before a Protected Operation . . . . . 5 3.2. Client as Attester Before Service Admission . . . . . . . 7 3.3. Mutual Attestation Before Sensitive Exchange . . . . . . 8 3.4. Re-Evaluation on Long-Lived or Resumed Connections . . . 9 3.5. Intermediary-Aware Deployment . . . . . . . . . . . . . . 10 4. Attacker Model . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Attacker Capabilities . . . . . . . . . . . . . . . . . . 12 4.2. Structure of Attack Descriptions . . . . . . . . . . . . 13 4.3. Evidence Reuse . . . . . . . . . . . . . . . . . . . . . 13 4.3.1. Per-Connection Evidence Replay . . . . . . . . . . . 13 4.3.2. Evidence Relay . . . . . . . . . . . . . . . . . . . 14 4.4. Key Substitution . . . . . . . . . . . . . . . . . . . . 15 4.5. Evidence Privacy Loss . . . . . . . . . . . . . . . . . . 15 4.5.1. Under Ephemeral-Key Compromise . . . . . . . . . . . 16 4.5.2. Under Traffic-Secret Compromise . . . . . . . . . . . 16 4.6. State Drift on Long-Lived and Resumed Connections . . . . 17 4.7. RA Negotiation Downgrade . . . . . . . . . . . . . . . . 18 4.8. Compromise of Security-Critical Keys . . . . . . . . . . 18 4.8.1. Authentication Key Compromise and Re-hosting (OPTIONAL) . . . . . . . . . . . . . . . . . . . . . 18 4.8.2. Attestation Key Compromise . . . . . . . . . . . . . 19 5. Properties of RA and TLS Integration . . . . . . . . . . . . 20 5.1. Attestation Status Before a Protected Decision . . . . . 21 5.2. Association of Attested State with the TLS Endpoint and Connection . . . . . . . . . . . . . . . . . . . . . . . 22 5.3. Association with Authenticated Peer Identity . . . . . . 22 5.4. Association with Authentication-Key Properties . . . . . 23 5.5. Freshness for an Attestation Exchange . . . . . . . . . . 23 5.6. Appraisal Lifetime and Re-Evaluation . . . . . . . . . . 23 5.7. Protected Negotiation and Policy-Respecting Fallback . . 24 5.8. Independent Attestation Directions . . . . . . . . . . . 24 5.9. Explicit Endpoint and Origin Boundaries . . . . . . . . . 24 5.10. Confidentiality and Disclosure of Attestation Material . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 Mihalcea Expires 6 May 2027 [Page 2] Internet-Draft SEAT Use Cases November 2026 8. Informative References . . . . . . . . . . . . . . . . . . . 26 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction 1.1. 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. 1.2. The Role of Remote Attestation Remote Attestation (RA), as described in the RATS architecture [RFC9334], 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. Mihalcea Expires 6 May 2027 [Page 3] Internet-Draft SEAT Use Cases November 2026 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. 1.3. Purpose and Scope This document presents use cases for composing RA with secure channel protocols in Section 3, describes relevant attacks and failure modes in Section 4, and derives integration properties in Section 5. The use cases include envisioned deployment patterns contributed by SEAT WG participants. The initial focus is TLS 1.3 [RFC9846] and DTLS 1.3 [I-D.ietf-tls-rfc9147bis]. 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 (Section 8.5 of [RFC9334]) 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. 2. Terminology This document uses the terminology defined in the RATS Architecture [RFC9334], including "Attester", "Relying Party", "Verifier", "Evidence", and "Attestation Results". This document also uses the following terms: * Attesting and Target Environments: as described in Section 3.1 of [RFC9334]. * Attested workload: An instance of software executing within a Target Environment, which can obtain remote attestation Evidence or Attestation Results about itself. Mihalcea Expires 6 May 2027 [Page 4] Internet-Draft SEAT Use Cases November 2026 * Measurements: as defined in [I-D.draft-ietf-rats-eat-measured-component]. * AI agent: An AI agent is a software principal that performs closed-loop cycles using an LLM or other model. * Credential: as defined in [RFC4949]. * 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 Appendix F.1 of [RFC9846]), i.e., an identifier cryptographically bound to the key or credential the peer authenticates with (for example, a certificate subject as in [RFC9525]). 3. 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. 3.1. 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. Mihalcea Expires 6 May 2027 [Page 5] Internet-Draft SEAT Use Cases November 2026 *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. Section 3.5 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* Mihalcea Expires 6 May 2027 [Page 6] Internet-Draft SEAT Use Cases November 2026 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 (Section 5.4); it does not establish the state of the whole TLS endpoint. [I-D.draft-reddy-rats-key-binding] describes the key claims and checks. [I-D.draft-ietf-rats-pkix-key-attestation] addresses attestation at certificate issuance; this use case needs assurance applicable to the connection. 3.2. 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* Mihalcea Expires 6 May 2027 [Page 7] Internet-Draft SEAT Use Cases November 2026 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 [CoCo-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 [RFC9190], the Network Access Server relays the exchange to an EAP/AAA server [RFC3579]. 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. 3.3. 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. Mihalcea Expires 6 May 2027 [Page 8] Internet-Draft SEAT Use Cases November 2026 *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) [MigTD] use an attested TLS connection between the source and destination. 3.4. 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. Mihalcea Expires 6 May 2027 [Page 9] Internet-Draft SEAT Use Cases November 2026 *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. [I-D.jiang-seat-dynamic-attestation] 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 Section 2.2 of [I-D.aylward-aiga-2]. * *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 [I-D.ayerbe-trip-protocol] provides one example. 3.5. 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. Mihalcea Expires 6 May 2027 [Page 10] Internet-Draft SEAT Use Cases November 2026 *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 Section 5. 4. 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. Mihalcea Expires 6 May 2027 [Page 11] Internet-Draft SEAT Use Cases November 2026 The baseline attacker is the Internet Threat Model of [RFC3552], 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 Appendix F of [RFC9846] apply. A Target Environment may represent a Trusted Execution Environment (TEE) [RFC9397]. For endpoint attestation, the model assumes that the Attester's TLS stack runs within the appraised Target Environment. The key-component case in Section 3.1, Paragraph 8.4.1 instead concerns the authentication key. Origin attestation behind a separate terminator requires an additional association (Section 3.5). 4.1. 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 [RFC3552]. * *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. Mihalcea Expires 6 May 2027 [Page 12] Internet-Draft SEAT Use Cases November 2026 * *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. 4.2. 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. 4.3. Evidence Reuse 4.3.1. Per-Connection Evidence Replay *Attacker capabilities:* A malicious peer retains valid Evidence generated earlier in the current TLS connection. Mihalcea Expires 6 May 2027 [Page 13] Internet-Draft SEAT Use Cases November 2026 *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 (Section 5.5). 4.3.2. 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 Mihalcea Expires 6 May 2027 [Page 14] Internet-Draft SEAT Use Cases November 2026 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. 4.4. 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. 4.5. Evidence Privacy Loss Mihalcea Expires 6 May 2027 [Page 15] Internet-Draft SEAT Use Cases November 2026 4.5.1. 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. 4.5.2. 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 [I-D.ietf-tls-extended-key-update] 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. Mihalcea Expires 6 May 2027 [Page 16] Internet-Draft SEAT Use Cases November 2026 *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. 4.6. 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. Mihalcea Expires 6 May 2027 [Page 17] Internet-Draft SEAT Use Cases November 2026 4.7. 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. 4.8. Compromise of Security-Critical Keys 4.8.1. 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 Section 3.3.5 of [RFC3552]. *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 Mihalcea Expires 6 May 2027 [Page 18] Internet-Draft SEAT Use Cases November 2026 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 (Section 5.4). 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. 4.8.2. 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. Mihalcea Expires 6 May 2027 [Page 19] Internet-Draft SEAT Use Cases November 2026 5. Properties of RA and TLS Integration The use cases in Section 3 and attacks in Section 4 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 Section 3, Paragraph 2 apply throughout. Table 1 shows which attacks and use cases motivate each property. A dash indicates that no attack scenario in Section 4, or no use case in Section 3, is directly associated with the property. The Attestation Key compromise scenario (Section 4.8.2) maps to no property: its mitigation depends on the attestation trust infrastructure and is outside what an integration can establish (Section 6). Mihalcea Expires 6 May 2027 [Page 20] Internet-Draft SEAT Use Cases November 2026 +==================================+===============+==============+ | Property | Attacks | Use cases | +==================================+===============+==============+ | Attestation Status Before a | - | Section 3.1, | | Protected Decision (Section 5.1) | | Section 3.2, | | | | Section 3.4 | +----------------------------------+---------------+--------------+ | Endpoint and Connection | Section 4.3.2 | Section 3.1, | | Association (Section 5.2) | | Section 3.2 | +----------------------------------+---------------+--------------+ | Peer Identity Association | - | Section 3.1, | | (Section 5.3) | | Section 3.2 | +----------------------------------+---------------+--------------+ | Authentication-Key Properties | Section 4.4, | Section 3.1 | | (Section 5.4) | Section 4.8.1 | | +----------------------------------+---------------+--------------+ | Exchange Freshness (Section 5.5) | Section 4.3.1 | Section 3.4 | +----------------------------------+---------------+--------------+ | Appraisal Lifetime and Re- | Section 4.6 | Section 3.4 | | Evaluation (Section 5.6) | | | +----------------------------------+---------------+--------------+ | Protected Negotiation | Section 4.7 | - | | (Section 5.7) | | | +----------------------------------+---------------+--------------+ | Independent Attestation | - | Section 3.3 | | Directions (Section 5.8) | | | +----------------------------------+---------------+--------------+ | Endpoint and Origin Boundaries | - | Section 3.5 | | (Section 5.9) | | | +----------------------------------+---------------+--------------+ | Confidentiality and Disclosure | Section | - | | (Section 5.10) | 4.5.1, | | | | Section 4.5.2 | | +----------------------------------+---------------+--------------+ Table 1: Origin of the Properties 5.1. Attestation Status Before a Protected Decision For Section 3.1, Section 3.2, and later decisions under Section 3.4, 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; Mihalcea Expires 6 May 2027 [Page 21] Internet-Draft SEAT Use Cases November 2026 Completion of TLS alone does not establish successful attestation. Failure to complete a check required for the decision leaves it indeterminate. Result reuse follows Section 5.6. 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 Section 5.7. 5.2. Association of Attested State with the TLS Endpoint and Connection For endpoint attestation in Section 3.1 and Section 3.2, 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 (Section 4.3.2). 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 Section 5.6. Attestation of a key-holding component uses Section 5.4 and does not by itself establish the state of the TLS endpoint. Origin attestation behind a separate terminator uses Section 5.9. 5.3. 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 (Section 3.1 and Section 3.2). 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. Mihalcea Expires 6 May 2027 [Page 22] Internet-Draft SEAT Use Cases November 2026 5.4. Association with Authentication-Key Properties For Section 3.1, Paragraph 8.4.1, 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 (Section 4.4); 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 Section 3.2, Paragraph 8.1.1, are supplied by the attestation mechanisms and deployment. 5.5. Freshness for an Attestation Exchange A solution specifies how Evidence or an Attestation Result conveyed in an attestation exchange satisfies its freshness requirements (Section 4.3.1 and Section 3.4). 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 Section 5.6. Exchange freshness does not itself establish that the measurements are fresh; see Section 10 of [RFC9334]. 5.6. Appraisal Lifetime and Re-Evaluation For decisions that reuse a result, a solution makes its applicable validity constraints available. Solutions supporting Section 3.4 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 (Section 4.6). 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. Mihalcea Expires 6 May 2027 [Page 23] Internet-Draft SEAT Use Cases November 2026 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 Appendix F.5 of [RFC9846] apply. Result lifetimes and periodic re- evaluation intervals remain policy choices. 5.7. 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 (Section 4.7). 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. 5.8. Independent Attestation Directions For Section 3.3 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. 5.9. Explicit Endpoint and Origin Boundaries A solution supporting Section 3.5 identifies the appraised component and the scope of its assurance. Attestation of the TLS terminator uses Section 5.2. 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. Mihalcea Expires 6 May 2027 [Page 24] Internet-Draft SEAT Use Cases November 2026 5.10. 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 4.2, 4.3, 4.4 and 4.5 of [I-D.ounsworth-rats-privacy-framework]). 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 Section 4.5.1 or Section 4.5.2 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. 6. Security Considerations The properties in Section 5 depend on the security assumptions of TLS and the attestation mechanisms used. The security considerations in Appendix F of [RFC9846] and the RATS security and privacy considerations in Sections 11 and 12 of [RFC9334] apply. Bindings cannot establish the truth of claims forged under an accepted, compromised Attestation Key (Section 4.8.2). Solutions honor rejection of unusable credentials or results and apply Section 5.1. Invalidation affecting an existing result also affects its reuse under Section 5.6. The key-exposure scenarios in Section 4.5.1 and Section 4.5.2 describe inherited confidentiality limits. Recovery claims require the protection described in Section 5.10; attestation alone does not repair compromised TLS secrets. Mihalcea Expires 6 May 2027 [Page 25] Internet-Draft SEAT Use Cases November 2026 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 Section 5.10. Omitting TLS client authentication does not make identifying Evidence anonymous. 7. IANA Considerations This document has no IANA actions. 8. Informative References [CoCo-Trustee] "Trustee", n.d., . [I-D.ayerbe-trip-protocol] Posada, C. A., Sardar, M. U., and S. Nikolaichuk, "TRIP: Trajectory-based Recognition of Identity Proof", Work in Progress, Internet-Draft, draft-ayerbe-trip-protocol-05, 29 October 2026, . [I-D.aylward-aiga-2] Aylward, E. R., "AI Governance and Accountability Protocol (AIGA)", Work in Progress, Internet-Draft, draft-aylward- aiga-2-00, 26 January 2026, . [I-D.draft-ietf-rats-eat-measured-component] Frost, S., Fossati, T., Tschofenig, H., and H. Birkholz, "Entity Attestation Token (EAT) Measured Component", Work in Progress, Internet-Draft, draft-ietf-rats-eat-measured- component-12, 20 February 2026, . [I-D.draft-ietf-rats-pkix-key-attestation] Fiset, J., Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M., and N. Smith, "Evidence Encoding for Hardware Security Modules", Work in Progress, Internet-Draft, draft-ietf-rats-pkix-key-attestation-08, 30 October 2026, . Mihalcea Expires 6 May 2027 [Page 26] Internet-Draft SEAT Use Cases November 2026 [I-D.draft-reddy-rats-key-binding] Reddy.K, T., Tschofenig, H., Fossati, T., Mihalcea, I., and H. Birkholz, "Key Attestation for Entity Attestation Tokens (EAT)", Work in Progress, Internet-Draft, draft- reddy-rats-key-binding-02, 15 August 2026, . [I-D.ietf-tls-extended-key-update] Tschofenig, H., Reddy.K, T., Tüxen, M., Fries, S., and Y. Rosomakho, "Extended Key Update for Transport Layer Security (TLS) 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-extended-key-update-14, 2 November 2026, . [I-D.ietf-tls-rfc9147bis] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- rfc9147bis-02, 6 July 2026, . [I-D.jiang-seat-dynamic-attestation] Jiang, Y. and Wangdonghui, "Dynamic Attestation for AI Agent Communication", Work in Progress, Internet-Draft, draft-jiang-seat-dynamic-attestation-00, 13 November 2025, . [I-D.ounsworth-rats-privacy-framework] Ounsworth, M., Tschofenig, H., and G. Lehmann, "Privacy Framework for Remote ATtestation procedureS", Work in Progress, Internet-Draft, draft-ounsworth-rats-privacy- framework-00, 18 June 2026, . [MigTD] "Intel TDX Migration TD", n.d., . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . Mihalcea Expires 6 May 2027 [Page 27] Internet-Draft SEAT Use Cases November 2026 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, DOI 10.17487/RFC3579, September 2003, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3", RFC 9190, DOI 10.17487/RFC9190, February 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9397] Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, "Trusted Execution Environment Provisioning (TEEP) Architecture", RFC 9397, DOI 10.17487/RFC9397, July 2023, . [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, . 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. Mihalcea Expires 6 May 2027 [Page 28] Internet-Draft SEAT Use Cases November 2026 Author's Address Ionuț Mihalcea (editor) Arm Email: ionut.mihalcea@arm.com Mihalcea Expires 6 May 2027 [Page 29]