Secure Evidence and Attestation Transport (seat) Internet Drafts

      
 Security Goals and Use Cases for Integrating Remote Attestation with Secure Channel Protocols
 
 draft-ietf-seat-use-cases-01.txt
 Date: 15/09/2026
 Authors: Ionut Mihalcea
 Working Group: Secure Evidence and Attestation Transport (seat)
 This document outlines desirable security goals and use cases for integrating remote attestation (RA) capabilities with secure channel establishment protocols (e.g., TLS and DTLS). Peer authentication in such protocols 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 the current state of the Target Environment. This document specifies a set of essential security goals the protocol solution must have, including cryptographic binding to the secure connection, evidence freshness, and flexibility to support different attestation models. It then explores relevant use cases, such as confidential data collaboration and secure secrets provisioning, to motivate the need for this integration. This document is intended to serve as an input to the design of protocol solutions within the SEAT working group.

data-group-menu-data-url="/group/groupmenu.json">

Secure Evidence and Attestation Transport (seat)

WG Name Secure Evidence and Attestation Transport
Acronym seat
Area Security Area (sec)
State Active
Charter charter-ietf-seat-01 Approved
Document dependencies
Additional resources Attested-TLS list archives
EXPAT BOF
Github
Initial proposed charter as SEAL
SEAL list archives
Personnel Chairs Nancy Cam-Winget, Yaroslav Rosomakho
Area Director Deb Cooley
Mailing list Address [email protected]
To subscribe https://mailman3.ietf.org/mailman3/lists/seat.ietf.org/
Archive https://mailarchive.ietf.org/arch/browse/seat
Chat Room address https://zulip.ietf.org/#narrow/stream/seat

Charter for Working Group

Background and motivation

In many scenarios, particularly with the rise of Trusted Execution
Environments (TEEs) and the increasing security demands for IoT devices
and confidential workloads, there is a requirement for some use cases that
utilize protocols such as (D)TLS to also ensure that the peer's state,
expressed as Claims (for example about code, data and configurations),
is validated and when authenticating, also bound to the conventional
authentication (verification of identity).

Remote attestation (RFC9334) addresses this by allowing an entity to
produce Evidence and Attestation Results about its current state. For
example to prove that its software and firmware haven't been tampered
with. Or to prove that a secure boot method is enabled. Or to prove
that cryptographic keys are securely stored within a hardware-protected
environment.

Remote attestation bound to the authenticated TLS connection provides an
additional assurance of trustworthiness that can prevent communication
to a compromised or unauthorized system.

Scope

The Secure Evidence and Attestation Transport (SEAT) WG will document a
set of use cases that protocols such as (D)TLS should be able to support.
It will initially deliver a Standards Track protocol that meets these
use cases and enables peer or mutual attestation for (D)TLS using the
extension and/or exporter features of D(TLS). Mutual attestation will
be supported with and without client TLS authentication to faciliate
anonymous client attestation.

Such a protocol would allow an entity to produce Evidence or an
Attestation Result about itself for another party to evaluate.

Specific scoping:

  • This effort will be restricted to leveraging the (D)TLS 1.3 protocol
    and an attestation binding to a (D)TLS 1.3 connection. (D)TLS
    1.2 and older will not be supported.

  • It will leverage the existing RATS WG documents to ensure
    interoperability with existing and future attestation technologies.

  • The attested (D)TLS protocol extension will focus on attestation with TLS
    server authentication, and with or without TLS client authentication. No
    new TLS authentication mechanisms will be created.

  • The attested (D)TLS protocol extension will not modify the (D)TLS
    protocol itself. It may define (D)TLS extensions to support its goals
    but will not modify, add, or remove any existing protocol messages
    or modify the key schedule.

  • The attested D(TLS) protocol extension will also describe a minimum
    subset of properties that the attested state must convey in order
    to bind the Evidence and Attestation Results to the TLS connection.

  • The attested (D)TLS protocol extension will allow per-connection
    [freshness] (https://www.ietf.org/rfc/rfc9334.html#section-10)
    of Evidence and Attestation Results.

  • The effort will not create solutions that decrease the privacy
    or security properties of generic (D)TLS connections.

The working group will engage with the research community on the
evaluation and formal analysis of the protocol artifacts in parallel
with the specification work.

Dependencies and Liaisons

  • The working group will work closely with the TLS Working Group, the
    RATS working group, and the Confidential Computing Consortium's
    (CCC's) Attestation Special Interest Group (SIG).

  • The working group will engage with research groups regarding
    formal analysis of the working groups's resulting work.

Future work

After the initial Milestones are complete, the WG may recharter to work
on adding attestation to protocols other than (D)TLS, such as IKEv2 or
SSH, provided there is sufficient interest.

Milestones

Order Milestone Associated documents
Last A Standards Track document defining an attested (D)TLS protocol extension supporting remote peer and mutual attestation bound to the (D)TLS connection.
Next A use cases document describing the scenarios that this working group will be targeting in its specification document. This document need not be published as an RFC.