Use Cases and Properties for Integrating Remote Attestation with Secure Channel Protocols

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).¶

3.1. Secure Provisioning and High-Assurance Operations

Goal: Ensure the integrity of workloads and devices when bootstrapping their identity or receiving critical commands.¶

Use case: Runtime Secret Provisioning: A confidential workload starts in a generic state and needs to fetch secrets (e.g., API keys, database credentials, encryption keys) to become operational.¶

• Requirement: The workload must attest its runtime state (TEE genuineness, software measurements) to a secrets management service. The service will only release the secrets after successful verification, ensuring they are delivered exclusively to a trustworthy environment. This use-case also covers secure device onboarding for IoT devices that lack a pre-provisioned identity.¶

Use case: High-Assurance Command Execution: An operator sends a critical command to a remote system (e.g., an industrial controller, a financial transaction processor).¶

• Requirement: The system must provide fresh attestation Evidence to the operator to prove its integrity before the command is dispatched. This prevents commands from being executed on a compromised system.¶

3.2. Confidential Data Collaboration

Goal: Enable multiple parties to collaborate on sensitive, combined datasets without exposing raw data to each other or to the infrastructure operator.¶

Use case: Data Clean Rooms: Multiple data providers contribute sensitive data to a confidential workload for joint analysis. Data consumers receive aggregated insights without ever accessing the raw, combined dataset.¶

• Requirement: Before sending data, each data provider must attest the confidential workload to verify it is running the authorized analysis code in a secure Trusted Execution Environment (TEE). Similarly, data consumers must attest the workload to trust the integrity of the results.¶

Use case: Secure Multi-Party Computation (MPC): Distributed parties collaboratively compute a function (e.g., train a machine learning model) without sharing their local data.¶

• Requirement: The central aggregator, as well as each participating client, must be able to mutually attest to ensure all parties are running the correct, untampered MPC algorithm in a trusted environment.¶

3.3. Network Infrastructure Integrity

Goal: Verify the integrity of network devices that form the foundation of communication.¶

Use case: Attestation of Network Functions: A router, switch, or firewall joins a network's management plane. A Virtualized Network Function (VNF) is instantiated on a generic server.¶

• Requirement: The network orchestrator must verify the device's integrity (e.g., secure boot enabled, running signed OS and firmware) before allowing it to join the network and receive policy. This prevents a compromised router from misdirecting traffic or a malicious VNF from inspecting sensitive packets.¶

Use case: Securing Control and Management Planes: An administrator connects to a network device's management interface.¶

• Requirement: The administrator's client must verify the integrity of the management endpoint on the network device to ensure they are not connecting to a compromised interface that could steal credentials or manipulate the device.¶

3.4. Operation-Triggered Attestation for High-Impact Application Operations

Goal: Ensure the integrity of application services at operation time, when security posture may change after initial channel establishment.¶

Use case: High-Assurance Operation Execution in Dynamic Application Services: An application service instance (e.g., AI agent) or confidential computing environment (which could host an AI agent) maintains a (D)TLS connection with a peer and must execute a high-impact action (e.g., payment initiation, configuration change, privileged command).¶

• Requirement 1: Before executing a high-impact operation over the existing connection, the peer must present fresh, connection-bound attestation evidence reflecting the current behavior-affecting posture (e.g., enabled capabilities, policy configuration, runtime permissions).¶

• Requirement 2: The mechanism should support lightweight, dynamic attestation within the existing connection, without necessarily requiring a full new TLS handshake, so that behavior-affecting posture changes are visible to relying parties when required by local policy.¶

3.5. Attestation of Certificate Private Key

A TLS endpoint authenticates itself using an end-entity certificate whose corresponding private key is claimed to be protected by a secure element. While standard TLS authentication verifies possession of the private key, it provides no assurance about where or how that key is stored and used.¶

In this scenario, the peer acting as the Relying Party requires additional assurance that the private key associated with the end-entity certificate used to authenticate the TLS connection is generated, stored, and used within an attested cryptographic module. In addition to verifying possession of the private key via the TLS handshake, the Relying Party seeks attestation evidence that the key is non-exportable, remains bound to the cryptographic module, and that the module is operating in an expected security configuration at the time the TLS connection is established.¶

Remote attestation is used to provide Evidence about the cryptographic module where the private key used for TLS authentication is stored. The Evidence may include claims about the security properties of the cryptographic module. To prevent replay attacks, this Evidence has to be fresh and tied to the current TLS connection. Replayed Evidence could otherwise be used to falsely assert key protection properties that no longer hold.¶

• Requirement: The Attester must be able to produce Evidence that demonstrates that the private key used for secure channel authentication:¶

  • is generated and stored within a specific cryptographic module or secure element,¶

  • is protected against export or software extraction¶

  • is attested using fresh Evidence that is bound to the current TLS connection.¶

The Relying Party uses this Evidence, potentially with the assistance of a Verifier, to determine whether the key protection properties satisfy its local security policy.¶

The approach described in [I-D.draft-ietf-rats-pkix-key-attestation] addresses this use case partially by providing attestation of the cryptographic module and associated private key at certificate issuance time, reflecting their state when the certificate is enrolled. This model does not provide guarantees about the continued state of the module at connection establishment or during the lifetime of the TLS session.¶

3.6. Platform-to-platform communication

Goal: Allow platforms to establish a trustworthy secure channel with each other.¶

Use case: Migration of workloads (confidential workloads in particular) between different platforms. Migration is occasionally required in order to maintain uptime for the hosted services across periods of scheduled downtime for the hosting platform. Having remote attestation-enforced policies for such migration events provides guarantees that the services will not be exposed to lower security guarantees when migrating. Migration is typically performed by trusted, low-level components (migration agents) on both source and destination platforms, which perform the authorization checks and handle the data migration.¶

• Requirement: The migration agent on the destination platform typically acts as attester, proving its state for its peer on the source platform (where the workload initially resides).¶

• Example: Intel TDX offers migration capabilities via its Migration TD (MigTD) [MigTD]. Peer MigTDs on the initiating and target platforms set up an attested TLS connection to perform the migration over.¶

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.¶

7.1. Normative References

[I-D.draft-ietf-rats-pkix-key-attestation]

Ounsworth, M., Fiset, J., Tschofenig, H., Birkholz, H., Wiseman, M., and N. Smith, "PKIX Evidence for Remote Attestation of Hardware Security Modules", Work in Progress, Internet-Draft, draft-ietf-rats-pkix-key-attestation-02, 10 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-pkix-key-attestation-02>.

7.2. Informative References

[AI-agents]

Kapoor, S., Stroebl, B., Siegel, Z. S., Nadgir, N., and A. Narayanan, "AI agents that matter", July 2024, <https://arxiv.org/abs/2407.01502>.

[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, <https://datatracker.ietf.org/doc/html/draft-ccc-wimse-twi-extensions-01>.

[I-D.draft-ietf-rats-eat-measured-component]

Frost, S., Fossati, T., Tschofenig, H., and H. Birkholz, "EAT Measured Component", Work in Progress, Internet-Draft, draft-ietf-rats-eat-measured-component-10, 12 January 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-measured-component-10>.

[Meeting-122-TLS-Slides]

Sardar, M. U., Moustafa, M., and T. Aura, "Identity Crisis in Attested TLS for Confidential Computing", March 2025, <https://datatracker.ietf.org/meeting/122/materials/slides-122-tls-identity-crisis-00>.

[MigTD]

"Intel TDX Migration TD", n.d., <https://github.com/intel/MigTD>.

[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, <https://www.rfc-editor.org/rfc/rfc9334>.