SEAT Working Group I. Mihalcea Internet-Draft Arm Intended status: Informational M. U. Sardar Expires: 3 September 2026 TU Dresden T. Fossati Linaro T. Reddy Nokia Y. Jiang M. Chen China Mobile 2 March 2026 Use Cases and Properties for Integrating Remote Attestation with Secure Channel Protocols draft-mihalcea-seat-use-cases-latest Abstract This document outlines use cases and desirable properties for integrating remote attestation (RA) capabilities with secure channel establishment protocols, with an initial focus on Transport Layer Security (TLS) v1.3 Handshake. Traditional peer authentication in TLS establishes trust in a peer's network identifiers but provides no assurance regarding the integrity of its underlying software and hardware stack. Remote attestation addresses this gap by enabling a peer to provide verifiable evidence about its current state, including the state of its trusted computing base (TCB). This document explores specific use cases, such as confidential data collaboration and secure secrets provisioning, to motivate the need for this integration. From these use cases, it specifies a set of essential properties the protocol solution must have, including cryptographic binding to the TLS connection, evidence freshness, and flexibility to support different attestation models. This document is intended to serve as an input to the design of protocol solutions within the SEAT working group. 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 3 September 2026. 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 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 1.1. Establishing Trust in Secure Communications 1.2. The Role of Remote Attestation 1.3. Purpose and Scope 2. Terminology 3. Integration Use-Cases 3.1. Temporal Integration Patterns 3.1.1. In-Band Handshake Attestation 3.1.2. Immediate Post-Handshake Attestation 3.1.3. Deferred and Periodic Runtime Attestation 3.2. Topological Integration Patterns 3.2.1. Unidirectional Attestation 3.2.2. Mutual Attestation 3.3. Authentication Integration Patterns 3.3.1. Composite Authentication 3.3.2. Anonymous Trust Establishment 4. Integration Properties 4.1. Cryptographic Binding to Communication Channel 4.2. Cryptographic Binding to Machine Identifier 4.3. Attestation Credential Freshness 4.4. Negotiation and Capability Discovery 4.5. Attestation Model Flexibility 4.6. Interaction with Peer Authentication 4.7. Runtime Attestation 4.8. Privacy Preservation 4.9. Performance and Efficiency 5. Security Considerations 6. IANA Considerations 7. Informative References Acknowledgments Authors' Addresses 1. Introduction 1.1. Establishing Trust in Secure Communications Traditional 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 a core limitation: identity authentication provides no assurance about the peer's internal state or the integrity of its software stack. A compromised server, 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 TCB, and can thus include measurements of its firmware, operating system, and application code, as well as the configuration of its hardware and software security features (e.g., secure boot status, memory isolation). A "Relying Party" can then use this Evidence, often with the help of a trusted "Verifier", to appraise the Attester's trustworthiness. By integrating RA into a secure channel establishment protocol, a second dimension of trust—trustworthiness—is added to complement regular 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 The purpose of this document is to outline the key use cases that motivate the integration of RA with secure channel protocols and to establish a set of essential properties for such an integration. The initial focus is on TLS 1.3 and its datagram-oriented variant, DTLS 1.3. This document is intended as an input to the design of protocol solutions within the SEAT working group. It defines the "why" and the "what" (the requirements), but not the "how" (the protocol specification itself). A key goal is to define requirements for a solution that is agnostic to any specific attestation technology (e.g., Trusted Platform Modules (TPMs), Intel TDX, AMD SEV, Arm CCA). 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: * Trusted Computing Base (TCB) of a device: all security-relevant components: hardware, firmware, software, and their respective configurations. * Confidential Workload: as defined in [I-D.draft-ccc-wimse-twi-extensions]. * Measurements: as defined in [I-D.draft-ietf-rats-eat-measured-component]. * AI agent: An AI agent is a software principal (typically long- running) that performs closed-loop "perceive -> plan -> act" cycles using an LLM or other model, and invokes external tools/ APIs that may read sensitive data or change system/network state. Its configuration (e.g., model choice, tool enablement, prompt template) can change independently of the binary/image and usually more frequently than typical platform TCB updates [AI-agents]. 3. Integration Use-Cases To design robust protocols integrating Remote Attestation (RA) with secure channel establishment (such as TLS 1.3 or DTLS 1.3), the required primitives must be categorized based on their architectural interaction with the underlying protocols. This section categorizes the required primitives based on temporal (when attestation occurs relative to the secure channel state machine), topological (who attests), and authentication (how integration with authentication is handled) characteristics. Application-layer business cases are given as examples of these underlying architectural requirements. 3.1. Temporal Integration Patterns Temporal integration defines the precise state machine phase where the protocol produces, transmits, and verifies RA credentials. It differentiates between transport-layer gating and application-layer gating. 3.1.1. In-Band Handshake Attestation Definition: Attestation credentials are exchanged concurrently with the secure channel establishment. Verification of these credentials is a strict prerequisite for the completion of the transport key schedule and the transition to the application data phase. Protocol Requirements: * The secure channel handshake must support the encapsulation of RA credentials (e.g., via TLS extensions). * The transport state machine must halt or cleanly abort (e.g., via a defined fatal alert) if verification fails. * Attestation credentials must be cryptographically bound to the handshake transcript to prevent relay attacks. Instantiation Examples: * Attested Certificate Keys: A server that claims its TLS private key is sealed in a secure element proves that claim inside the initial handshake before the client allows application data keys to be derived. * Runtime Secret Provisioning (shared with Section 3.1.2): A secrets manager relies on an authenticated and attested secure channel as a pre-requisite for releasing credentials or cryptographic keys. * Confidential Data Collaboration (shared with Section 3.1.2): Data may only be sent to or accepted from peers that have proven they're running acceptable software. * Network Infrastructure Integrity (shared with Section 3.1.2): A VNF must attest its secure boot state to an orchestrator before the orchestrator allocates application-layer state or transmits sensitive routing configurations. 3.1.2. Immediate Post-Handshake Attestation Definition: The secure channel is fully established without modification to its core handshake. Immediately following establishment, attestation credential is exchanged over the encrypted channel before any functional application data is permitted to flow. Protocol Requirements: * The transport handshake remains standard. * Cryptographic binding relies on deriving material from the established transport channel (e.g., utilizing TLS Exported Authenticators [RFC9261]) to prove the credential originates from the terminating endpoint. * Application-layer state machines must enforce a blocking phase during which only attestation payloads are processed. Alternatively, the secure channel protocol must be wrapped in a shim layer which enforces this in-between state, before relinquishing control the connection to the application layer. Instantiation Examples: * Legacy Transport Compatibility: A deployment requires attestation but traverses middleboxes or uses TLS libraries that do not support custom handshake extensions. The application layer handles the RA exchange immediately after the standard TLS Finished message using Exporters to bind the credential to the channel. 3.1.3. Deferred and Periodic Runtime Attestation Definition: The exchange of attestation credentials occurs asynchronously after the initial secure channel, when application sessions are established and active. Protocol Requirements: * Mechanisms to trigger an attestation request asynchronously over an active connection. * Cryptographic binding of the runtime Attestaiton credentials to the existing channel state. * Execution must not disrupt or pause the concurrent multiplexing of application data streams. Instantiation Examples: * Operation-Triggered Attestation: An AI agent connected to a remote API must provide fresh credentials of its state before the API authorizes a high-privilege action. * Confidential Data Collaboration: A data provider requests re- attestation from the confidential analytics service before uploading each new dataset or model update to ensure authorized code and policy remain in place. * High-Assurance Command Execution: An operator connects to a management plane, then requests fresh exporter-bound credentials over the encrypted channel before sending critical commands. 3.2. Topological Integration Patterns Topological integration dictates the directionality of the trust evaluation and defines which peer acts as the Attester and which acts as the Relying Party. 3.2.1. Unidirectional Attestation Definition: Only one peer (either the client or the server) provides attestation credentials to the other peer. Protocol Requirements: * The protocol must support asymmetric payload capabilities where the Attester can transmit potentially large credentials, while the Relying Party requires only the capacity to parse and appraise (or forward to a Verifier). * Downgrade protection to ensure an active attacker cannot suppress the Relying Party's demand for attestation credentials. Instantiation Examples: * Client Attestation: A bare-metal device connecting to a cloud provider proves its TCB state to the cloud provider, but the device inherently trusts the cloud provider's standard TLS certificate. * Server Attestation: A client connects to an untrusted edge computing node and requires the edge node to prove it is running an authorized software stack. * Secrets Provisioning: A confidential workload or IoT device attests to a secrets management service before the service releases credentials needed to bootstrap the device. * Administrative Control Access: An operator's client requests attestation from a network device's management endpoint before issuing credential changes, while the device is satisfied with standard PKI validation of the client. 3.2.2. Mutual Attestation Definition: Both the client and the server simultaneously exchange and verify each other's attestation credentials. Protocol Requirements: * Bidirectional exchange mechanisms that do not create state machine deadlocks. * Prevention of cross-protocol attacks, ensuring that the Attestation credential provided by Peer A is cryptographically bound to Peer A's specific role (client or server) in the session. Instantiation Examples: * Platform-to-Platform Migration: In confidential computing, a workload migrating between two hardware nodes requires mutual assurance. The destination attests it can securely host the workload; the source attests the workload's legitimate origin. * Confidential Data Collaboration (MPC): Clients connecting to a secure aggregator must mutually attest to ensure all parties are running untampered multiparty computation algorithms. * Data Clean Rooms: Data providers and the confidential analytics service mutually attest to verify both sides are running the authorized code and policies before any combined dataset is processed. 3.3. Authentication Integration Patterns Authentication integration dictates how the attestation credentials relates to traditional authentication models (e.g., PKI). 3.3.1. Composite Authentication Definition: Attestation credential is utilized strictly to augment standard authentication mechanisms. The channel requires proof of private key possession and proof of the operational environment securing that key. Protocol Requirements: * The credentials must explicitly cover the security state of the hardware module or platform holding the connection's authentication private key. * The protocol must cryptographically bind the standard authentication checks (e.g., TLS CertificateVerify signature verification) with the attestation credentials. Instantiation Examples: * Attestation of Certificate Private Key: A Relying Party requires assurance that the peer's TLS private key is non-exportable and resides in a hardware-backed secure element, augmenting the standard X.509 validation path. * Network Infrastructure Integrity: A router or firewall proves that the TLS key used on its management interface is sealed to a secure element on a measured platform before it is allowed to join the control plane. * High-Assurance Operations: A service that will later issue high- impact commands proves during channel setup that its authentication key is bound to an attested module so relying parties can trust subsequent privileged actions. 3.3.2. Anonymous Trust Establishment Definition: The secure channel is established based solely on attestation credentials, without relying on long-term stable identifiers such as PKI-based credentials. Protocol Requirements: * Support for authentication frameworks where PKI is absent. * Strict privacy preservation (e.g., encryption of the attestation payload) to prevent hardware identifiers from acting as persistent tracking vectors. Instantiation Examples: * Zero-Touch Device Onboarding: A newly manufactured device connects to a network without an X.509 certificate. The channel is authenticated entirely via the device proving its hardware genuineness (e.g., via a DICE chain), bootstrapping initial trust prior to standard network identity assignment. 4. Integration Properties This section provides a list of desirable properties for designs that integrate RA into secure channel protocols. Proposed integration protocols should make it clear which of these properties are fulfilled, and how. 4.1. Cryptographic Binding to Communication Channel The attestation Evidence or Attestation Result is cryptographically bound to the specific secure channel instance (e.g., the TLS connection). This prevents replay and relay attacks where an attacker presents valid, but old or unrelated Evidence from a different connection or context. This binding is paramount for all use cases. 4.2. Cryptographic Binding to Machine Identifier Evidence should be cryptographically bound to the identifier provided to the machine by the infrastructure provider to prevent diversion attacks [Meeting-122-TLS-Slides]. 4.3. Attestation Credential Freshness The Relying Party is able to verify that the Evidence or Attestation Result it receives was freshly generated by the Attester for the current connection. State is transient, and credentials from a previous connection may no longer be valid. See Section 10 of [RFC9334] for more details about freshness in the context of RA. 4.4. Negotiation and Capability Discovery Peers have a secure mechanism to discover each other's support for RA, the specific attestation formats they can produce or consume, and the attestation models they support. This enables interoperability and allows for graceful fallback for endpoints that do not support RA. 4.5. Attestation Model Flexibility The solution supports both the Background Check and Passport models as defined in the RATS architecture [RFC9334]. The Background Check model is essential for use cases requiring maximum freshness, while the Passport model is better suited for performance, scalability, and scenarios where the Verifier may be offline or unreachable by the Relying Party. 4.6. Interaction with Peer Authentication The solution supports using RA in conjunction with traditional PKI- based authentication (e.g., X.509 certificates). This provides two independent pillars of trust: trustworthiness (from RA) and identity (from PKI). The solution may also support RA as the sole method of authentication in constrained use cases, such as device onboarding, where a device has no stable, long-term identity yet. This latter option could have a negative impact on the security of the overall design, warranting additional security considerations. 4.7. Runtime Attestation Evidence collected at certificate issuance or during the initial secure channel establishment reflects only the Target Environment’s state at that moment. It cannot guarantee that the Target Environment remains trustworthy for the lifetime of the certificate or even for the duration of the TLS session. As a result, such static evidence is insufficient in environments where the Target Environment may change state after the connection is established and the connection is long-lived. Runtime attestation closes this gap by enabling the Relying Party (RP) to request new attestation evidence once the TLS connection has been established, or periodically during long-lived connections if necessary. This may be the case when the target environment has attributes that can change during the connection, affecting its trustworthiness. Such changes cannot be detected using evidence collected earlier. For example, the evidence may include dynamic parameters such as runtime configuration flags (e.g., FIPS mode), where a device may enter or exit an approved mode, or measurements of critical system files. 4.8. Privacy Preservation The solution must not degrade the privacy of a standard TLS connection. Evidence can contain highly specific, unique information about a device's hardware and software, which could be used as an advanced tracking mechanism, following a user across different connections and services. The design must consider how to minimize this leakage, especially when a third-party Verifier is involved in the protocol exchange. 4.9. Performance and Efficiency The introduction of attestation should not add prohibitive latency or overhead to the connection establishment process. To be widely adopted, the solution must be practical. While some overhead is unavoidable, multiple additional round-trips or very large payloads in the initial handshake should be minimized. 5. Security Considerations This document describes use cases and integration properties. The security of any protocol designed to fulfill these properties will depend on its specific mechanisms. However, any solution must address the following high-level considerations: * Replay and Relay Protection: The requirements for cryptographic binding and freshness are critical. Failure to bind attestation credentials tightly to the current connection would allow an adversary to replay or relay old or stolen, yet valid credentials from a compromised system, completely undermining the security goals. * Verifier Trust and Privacy: In the Background Check model, the Relying Party communicates with a Verifier. This reveals to the Verifier that the Relying Party is communicating with the Attester. Depending on the scenario, this could leak sensitive information about business relationships or user activity. Solutions should consider mechanisms to minimize the data revealed to the Verifier. * Downgrade Attacks: The negotiation of attestation capabilities must be secure. An active attacker must not be able to trick two parties that both support attestation into negotiating a connection without it. * Evidence Semantics: This document does not define attestation appraisal policies. However, a Relying Party must be careful when interpreting Attestation Results. A "valid" attestation only means the Evidence is authentic and correctly signed; it does not automatically mean the underlying system is "secure". The Relying Party must have a clear policy for what measurements, software versions, and security configurations are acceptable. 6. IANA Considerations This document has no IANA actions. 7. Informative References [AI-agents] Kapoor, S., Stroebl, B., Siegel, Z. S., Nadgir, N., and A. Narayanan, "AI agents that matter", July 2024, . [I-D.draft-ccc-wimse-twi-extensions] Novak, M., Deshpande, Y., and H. Birkholz, "WIMSE Extensions for Trustworthy Workload Identity", Work in Progress, Internet-Draft, draft-ccc-wimse-twi-extensions- 01, 5 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, . [Meeting-122-TLS-Slides] Sardar, M. U., Moustafa, M., and T. Aura, "Identity Crisis in Attested TLS for Confidential Computing", March 2025, . [MigTD] "Intel TDX Migration TD", n.d., . [RFC9261] Sullivan, N., "Exported Authenticators in TLS", RFC 9261, DOI 10.17487/RFC9261, July 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, . Acknowledgments TODO Authors' Addresses Ionuț Mihalcea Arm Email: ionut.mihalcea@arm.com Muhammad Usama Sardar TU Dresden Email: muhammad_usama.sardar@tu-dresden.de Thomas Fossati Linaro Email: thomas.fossati@linaro.org Tirumaleswar Reddy Nokia Email: kondtir@gmail.com Yuning Jiang Email: jiangyuning2@h-partners.com Meiling Chen China Mobile Email: chenmeiling@chinamobile.com