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 Paul Wouters
Mailing list Address seat@ietf.org
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.