



SEAT Working Group                                           I. Mihalcea
Internet-Draft                                                       Arm
Intended status: Informational                              M. U. Sardar
Expires: 23 July 2026                                         TU Dresden
                                                              T. Fossati
                                                                  Linaro
                                                                T. Reddy
                                                                   Nokia
                                                                Y. Jiang
                                                                        
                                                                 M. Chen
                                                            China Mobile
                                                         19 January 2026


Use Cases and Properties for Integrating Remote Attestation with Secure
                           Channel Protocols
                    draft-mihalcea-seat-use-cases-01

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



Mihalcea, et al.          Expires 23 July 2026                  [Page 1]

Internet-Draft               SEAT Use Cases                 January 2026


   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 23 July 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  . . . . . . . . . . . . . . . . . . . . . . . .   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 . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Secure Provisioning and High-Assurance Operations . . . .   5
     3.2.  Confidential Data Collaboration . . . . . . . . . . . . .   5
     3.3.  Network Infrastructure Integrity  . . . . . . . . . . . .   6
     3.4.  Operation-Triggered Attestation for High-Impact Application
           Operations  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.5.  Attestation of Certificate Private Key  . . . . . . . . .   7
     3.6.  Platform-to-platform communication  . . . . . . . . . . .   8
   4.  Integration Properties  . . . . . . . . . . . . . . . . . . .   8
     4.1.  Cryptographic Binding to Communication Channel  . . . . .   8
     4.2.  Cryptographic Binding to Machine Identifier . . . . . . .   9
     4.3.  Attestation Credential Freshness  . . . . . . . . . . . .   9
     4.4.  Negotiation and Capability Discovery  . . . . . . . . . .   9
     4.5.  Attestation Model Flexibility . . . . . . . . . . . . . .   9
     4.6.  Interaction with Peer Authentication  . . . . . . . . . .   9
     4.7.  Runtime Attestation . . . . . . . . . . . . . . . . . . .  10
     4.8.  Privacy Preservation  . . . . . . . . . . . . . . . . . .  10
     4.9.  Performance and Efficiency  . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11



Mihalcea, et al.          Expires 23 July 2026                  [Page 2]

Internet-Draft               SEAT Use Cases                 January 2026


   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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.







Mihalcea, et al.          Expires 23 July 2026                  [Page 3]

Internet-Draft               SEAT Use Cases                 January 2026


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.  Use Cases

   This section provides the concrete motivation for the WG's work by
   describing specific use cases.  For each case, the scenario, actors,
   and specific security guarantees needed from RA are described.





Mihalcea, et al.          Expires 23 July 2026                  [Page 4]

Internet-Draft               SEAT Use Cases                 January 2026


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.





Mihalcea, et al.          Expires 23 July 2026                  [Page 5]

Internet-Draft               SEAT Use Cases                 January 2026


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





Mihalcea, et al.          Expires 23 July 2026                  [Page 6]

Internet-Draft               SEAT Use Cases                 January 2026


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




Mihalcea, et al.          Expires 23 July 2026                  [Page 7]

Internet-Draft               SEAT Use Cases                 January 2026


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



Mihalcea, et al.          Expires 23 July 2026                  [Page 8]

Internet-Draft               SEAT Use Cases                 January 2026


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.










Mihalcea, et al.          Expires 23 July 2026                  [Page 9]

Internet-Draft               SEAT Use Cases                 January 2026


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:





Mihalcea, et al.          Expires 23 July 2026                 [Page 10]

Internet-Draft               SEAT Use Cases                 January 2026


   *  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.  References

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





Mihalcea, et al.          Expires 23 July 2026                 [Page 11]

Internet-Draft               SEAT Use Cases                 January 2026


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

Acknowledgments

   TODO

Authors' Addresses

   Ionuț Mihalcea
   Arm
   Email: ionut.mihalcea@arm.com


   Muhammad Usama Sardar
   TU Dresden
   Email: muhammad_usama.sardar@tu-dresden.de



Mihalcea, et al.          Expires 23 July 2026                 [Page 12]

Internet-Draft               SEAT Use Cases                 January 2026


   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


































Mihalcea, et al.          Expires 23 July 2026                 [Page 13]
