| Internet-Draft | SEAT Architecture | October 2026 |
| Ritz, et al. | Expires 3 May 2027 | [Page] |
This document defines an architectural framework for composing Remote ATtestation procedureS (RATS) with Secure Evidence and Attestation Transport (SEAT). The document establishes normalized terminology for SEAT, aligns RATS roles to transport endpoints, outlines topological patterns for attestation delivery timing, and characterizes the abstract cryptographic pattern by which Evidence is bound to a given transport connection.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://tls-attestation.github.io/seat-architecture/draft-seat-architecture.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-many-seat-architecture/.¶
Source for this draft and an issue tracker can be found at https://github.com/tls-attestation/seat-architecture.¶
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 May 2027.¶
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.¶
"Cryptography without system integrity is like investing in an armored car to carry money between a customer living in a cardboard box and a person doing business on a park bench."¶
— Gene Spafford¶
Traditional secure channel protocols, such as those based on authenticated key exchange (AKE), primarily establish trust in a peer's cryptographic identity. This is typically achieved through mechanisms like Public Key Infrastructure (PKI), where a trusted Certification Authority (CA) vouches for the binding between a public key and an identifier such as a hostname (e.g., [RFC9525]).¶
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.¶
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 security state, and can thus include measurements of its firmware, operating system, 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 is added to complement regular peer authentication: trustworthiness. This allows a Relying Party to make authorization decisions based not just on the Attester's cryptographic identity, but also on what its security capabilities are (e.g., whether it is a Confidential Computing-capable server) and whether its security state is acceptable.¶
This document is intended as an input to the design of protocol solutions within the SEAT working group. One primary goal is to define operational considerations that remain agnostic to any specific attestation technology (e.g., Trusted Platform Modules (TPMs), Intel TDX, AMD SEV, Arm CCA, etc.).¶
For the scope of this architecture, the term "transport" is used interchangeably with "secure transport" to refer to secure channel establishment protocols such as TLS [RFC9846] and LAKE [RFC9528].¶
The use cases motivating this architecture are defined in [I-D.ietf-seat-use-cases]. Readers are directed there to review the security property goals and various deployment scenarios that the protocol work in the SEAT working group is expected to satisfy.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terms are used in this document. Terms defined in [RFC9334] are used with the meanings established there; the definitions below extend or specialize those terms for the transport context.¶
This document adopts terms of art such as intra- and post-
as coined by [NIEME2021].¶
TSK):An asymmetric key pair whose private key is used to authenticate the
Attester’s transport endpoint (for example, signing the TLS CertificateVerify
message). Evidence produced by the Attesting Environment MUST include a
binding to the TSK. It is RECOMMENDED that the TSK be generated and
maintained exclusively within the Target Environment (e.g., a TEE).¶
AEK):The asymmetric key used by the Attesting Environment
to sign Evidence. The Verifier trusts the AEK through an
Endorsement chain that typically roots in a hardware manufacturer
or a device‑specific CA. The AEK is used solely for attestation
and is distinct from any key used for transport authentication.¶
ARK):The asymmetric key used by a Verifier to sign
Attestation Results. The Relying Party must possess the
corresponding trust anchor for the ARK so that it can verify
the integrity and authenticity of received Attestation Results.¶
The identity of a peer as established by the secure channel establishment protocol's authentication (for example, TLS handshake authentication, see Appendix F.1 of [RFC9846]). I.e., a name cryptographically bound to the key or credential the peer authenticates with (for example, a certificate subject as in [RFC9525]).¶
How authenticated identity and those credentials are issued is outside the scope of this document. For some additional discussion of adjacent work related to RA and identity, see Appendix B.¶
The attestation payload conveyed by the Attester to the Relying Party across the transport connection. Depending on the RATS conveyance model in use, this payload consists of either Evidence (Background-Check Model) or an Attestation Result (Passport Model). Where a statement applies specifically to one but not the other, this document uses the more specific term.¶
While Evidence is exclusively generated by the Attester and Attestation Results are generated by a Verifier, in the SEAT transport context, the Attestation Credential is always presented by the Attester directly to the Relying Party over the secure channel.¶
A transport session in which at least one endpoint has produced Evidence that has been appraised, and in which that Evidence is cryptographically bound to the session such that the appraisal cannot be replayed to a different session or transferred to a different endpoint.¶
The temporal relationship between Evidence conveyance and connection establishment time. This document defines two timing models: Intra-Handshake Attestation and Post- Handshake Attestation. See Section 5.¶
The point at which an Attester's Claims are signed to produce Evidence. Depending on the internal workings of the Attester, the Evidence reflects the reported state at the time the underlying Claims were collected and may not represent a snapshot of state at the exact moment of signing the evidence. In all cases, it makes no representation about the Attester's state at any later time.¶
The point at which a transport handshake completes and the session becomes usable for application data exchange.¶
The period from Connection Establishment Time until the session is torn down. Post-handshake re- attestation operates during the Lifetime of Connection, allowing Evidence to reflect the Attester's current state rather than its state at Connection Establishment Time.¶
The production and appraisal of fresh Evidence during an established session's Lifetime of Connection.¶
The interval during transport connection establishment in which Evidence is conveyed within the handshake messages themselves, prior to the transition to application data exchange.¶
The interval following connection establishment in which Evidence is conveyed to the Relying Party using post-handshake protocol mechanisms (e.g., Exported Authenticators or application-layer exchanges).¶
A value, uniquely determined by a specific transport session, from which Attestation Binders are derived. A Session Binding Value may be public or secret depending on the topology; what is required is that it cannot be known before the session is initiated. See Section 6.5.1.¶
A cryptographic value derived from a Session Binding Value and committed to by the Attesting Environment into its Evidence payload. This value binds the Evidence to a specific session guaranteed under typical cryptographic assumptions.¶
The point in the protocol at which an Attestation Binder is included in a protocol message. A binder may be computed and transmitted before peer authentication is complete.¶
The protocol mechanism by which the integrity of a transmitted Attestation Binder is established. Depending on the Attestation Timing Model, this may be achieved via a MAC that authenticates the handshake transcript (e.g., the TLS Finished message), or through post-handshake cryptographic binding (e.g., Exported Authenticators).¶
A deployment topology in which the Attesting Environment and the transport stack reside in different execution contexts (vertical seperation). The transport stack is in the Target Environment; the Attesting Environment (e.g., a TEE) must receive the attestation binder input — typically a handshake transcript hash or exported key — from the transport stack via a trusted interface.¶
A deployment topology in which multiple distinct transport endpoints reside within the same Target Environment (horizontal separation). An attestation endpoint manages attestation exchanges, while one or more separate serving endpoints terminate application data channels.¶
TODO: Explore security outcomes and operational considerations for proposed Multi-Endpoint Deployment topologies.¶
The SEAT architecture maps the roles defined in [RFC9334] to standard transport protocol entities. The subsections below describe each role and its specific character in the transport context.¶
The overarching goal for SEAT is to establish an attested channel between an Attester and a Relying Party (or between two endpoints acting mutually in both roles). Figure 1 shows the transport and RATS roles that are involved in achieving this goal, and how they interact.¶
The Attester produces Evidence about its current state for consumption by a Verifier. In the transport context, the Attester is a network endpoint — either the Client or the Server — that possesses an Attesting Environment (such as a Trusted Execution Environment) capable of securely collecting Claims and signing them with an attestation key.¶
The Attester's transport stack provides the attestation binder input to the Attesting Environment so that Evidence can be bound to the specific session. In a Split Deployment, the transport stack is in the Target Environment and the interface between the transport stack and the Attesting Environment is a security-critical boundary. See Section 8.¶
In mutual attestation deployments, both the Client and the Server simultaneously act as Attesters. Each endpoint's Attesting Environment independently generates Evidence bound to the session.¶
The Relying Party consumes an Attestation Result and uses it to make authorization decisions about the transport connection. In the transport context, the Relying Party is typically the endpoint opposite the Attester — the Server when the Client attests, or the Client when the Server attests.¶
The Verifier appraises the validity of Evidence and produces Attestation Results, as defined in Section 4 of [RFC9334].¶
The appraisal is driven by an Appraisal Policy for Evidence, a set of rules that determines which Endorsements and Reference Values are required, which Claims must be present, and under what conditions Evidence is considered acceptable.¶
The Appraisal Policy may be configured as part of the Verifier’s trust anchors or supplied by a Relying Party in a deployment-specific manner. When Attestation Results are produced, they reflect the outcome of applying that policy.¶
Integrating Remote Attestation with secure transport requires a clean separation of concerns between transport state and platform appraisal. The transport protocol maintains channel confidentiality, message integrity, and session uniqueness, but remains agnostic to internal platform measurement formats (see Section 6.1).¶
Conversely, the RATS layer collects and appraises Evidence, relying on the transport layer to anchor that appraisal to a specific connection (see [RFC9334]).¶
An Attested Channel requires the Relying Party to evaluate orthogonal dimensions of trust, each rooting in a distinct cryptographic anchor:¶
The Transport Anchor (Identity): The trust anchor (typically a WebPKI
or enterprise CA) that vouches for the binding between the peer's
Authenticated Identity and its Transport Signing Key (TSK).¶
The Attestation Anchor (Posture): The trust anchor (typically a
hardware manufacturer root, device-specific CA, or configured
Verifier key) that vouches for the integrity of the Attesting
Environment and its Attesting Environment Key (AEK).¶
Such anchors operate independently. For example, a CA issuing the transport certificate is generally unaware of the platform's hardware state, and the hardware manufacturer issuing the attestation endorsement is unaware of the application-level identity the platform is hosting.¶
When attestation is negotiated, the transport stack supplies two inputs across
the boundary to the Attesting Environment: a session-unique Session Binding
Value and the public component of the Transport Signing Key (TSK)
(see Section 2 and Section 6.5.1).¶
The Attesting Environment commits both parameters into its Evidence payload.
This asserts that the attested execution state is bound to the endpoint
controlling TSK on that active session.¶
Figure 2 illustrates how Evidence and Attestation Results flow under the two conveyance models.¶
How Evidence reaches the Verifier follows one of the two RATS conveyance models (Section 5 of [RFC9334]):¶
The Relying Party conveys the Attester's Evidence to the Verifier and receives Attestation Results in return. The Verifier may be co-located with the Relying Party, appraising Evidence inline, for example during an intra-handshake exchange that requires a real-time result before the connection is finalized or operated as a remote service (see Section 5.2 of [RFC9334] and Figure 2).¶
The Attester conveys its Evidence to a remote Verifier, obtains Attestation Results, and presents those Results to the Relying Party (see Section 5.1 of [RFC9334] and Figure 2).¶
A transport session achieves the status of an Attested Channel only when the cryptographic binder is evaluated as a strict, non-optional invariant by the appraisal engine (see Section 2).¶
Appraisal interfaces must not treat session challenges as optional filters. If a verification interface permits an empty, null, or zero-length session challenge to proceed without failure, or if an unconfigured Verifier evaluates platform state and signatures while skipping the equality assertion against session context, the channel binding guarantee fails silently. Under such conditions, the system evaluates platform execution state in the abstract, but fails to prove that the platform is attached to the live communication session.¶
To preserve the integrity of an Attested Channel, appraisal implementations must enforce fail-closed semantics (see Section 6.4):¶
Mandatory Challenge Presence: The appraisal engine must treat the presence of a non-empty, well-formed Session Binding Value as a prerequisite for successful verification (see Section 6.5.1).¶
Complete Parameter Matching: The comparison between the connection-derived binder and the value committed within the Attestation Credential must be evaluated as a strict equality check.¶
Terminal Abort: If an incoming credential omits the binder, presents an unparseable challenge structure, or fails the equality comparison, the appraisal engine must report a terminal verification failure, prompting the transport layer to terminate the session (see Section 6.4).¶
This section describes the trust relationships required to establish an Attested Channel. The general trust model described in Section 7 of [RFC9334] applies; the subsections below specialise it for the transport context.¶
TODO: Explore security outcomes and options when using a non-confidential TSK as seen discussed in this open SEAT use case proposal (see [UC-PR-56]).¶
In the transport context, establishing an Attested Channel requires
demonstrating key provenance: proving that the private Transport Signing
Key (TSK) used for channel authentication is physically confined within
an authorized Target Environment. This relies on an unbroken
chain of trust spanning the platform supply chain to the active transport
session:¶
Because the TSK (rooted in the Transport Anchor) and the AEK (rooted in the
Attestation Anchor) originate in orthogonal trust domains, committing to the
TSK within signed Evidence cryptographically binds them. This assures the
Verifier and Relying Party that the transport identity is not merely valid,
but physically resident within the attested Target Environment.¶
The Relying Party must have a trust relationship with the Verifier commensurate with the sensitivity of the authorization decision. This reliance requires the Relying Party to trust both the Verifier's cryptographic signature and the Verifier's Appraisal Policy.¶
In the co-located Verifier deployment, this relationship is implicit: the Verifier's logic is part of the Relying Party's own implementation. In the remote Verifier deployment, the Relying Party must authenticate the Verifier and confirm that the Verifier's Appraisal Policy for Evidence is consistent with the Relying Party's own requirements before accepting any Attestation Credentials.¶
The Relying Party evaluates both trust domains jointly. It validates the
TSK against its Transport Anchor to confirm the peer's identity (for
example, by verifying the reference identifier per [RFC9525]), evaluates
the Attestation Credential against its Attestation Anchor to confirm
platform integrity and TSK residency, and verifies the session binder to
confirm they are co-located.¶
This binder confirms that the Attestation Credential is bound to the current session — ensuring it has not been replayed from a different session or transferred from a different endpoint.¶
This assurance is provided by the session binding mechanism described in Section 6.5.1; the check may be performed by the Relying Party itself or delegated to the Verifier, but it cannot be pre-computed independently of the session.¶
Only when all elements satisfy their respective trust anchors does the session achieve the status of an Attested Channel.¶
The timing and conveyance of Attestation Credentials relative to the transport handshake define the two Attestation Timing Models used in this architecture.¶
Depending on the approach, an Attestation Credential may be conveyed during the Intra-Handshake Window or during the Post-Handshake Window, utilizing either native transport protocol extensions or application-level framing.¶
If the credential is Evidence, the Relying Party acts as or forwards it to a Verifier to appraise the Evidence. If the credential is an Attestation Result, the Relying Party evaluates it against its own Appraisal Policy for Attestation Results.¶
In both cases, an authorization decision must be made before the transport state machine permits application data to flow.¶
An Attestation Credential is conveyed by the Attester during the transport connection establishment to the Relying Party within the handshake messages themselves, prior to the transition to application data exchange. Upon receipt, the Relying Party processes the Attestation Credential.¶
The Relying Party, which may be deployed with a co-located Verifier, appraises the Evidence in real time and makes an authorization decision before the transport state machine permits application data to flow.¶
An Attestation Credential is conveyed by the Attester after transport connection establishment to the Relying Party. Conveyance may occur within the transport layer using post-handshake protocol mechanisms utilizing either native transport protocol extensions or above the transport layer within application protocols.¶
The Attestation Binder is derived after initial handshake completion, tying the Attestation Credential to the established session context.¶
Regardless of whether post-handshake conveyance is implemented directly within the transport stack or localized in an application-level wrapper (such as a sidecar proxy), authorization policies must dictate which data exchanges are required to stall until the attestation procedure completes successfully.¶
Protocol specifications building on this architecture MAY support one or both timing models.¶
When designing solutions, it is important to distinguish the timing model used for conveyance (Intra-Handshake vs. Post-Handshake) from the lifecycle event being satisfied (initial trust establishment vs. re-attestation). Initial attestation can be performed using either timing model: Intra-Handshake mechanisms can establish baseline trust during connection setup, or Post-Handshake mechanisms can be used to withhold application data exchange immediately after connection establishment.¶
Re-attestation, by definition, occurs during the Lifetime of Connection. A comprehensive solution might combine both models — using Intra-Handshake for initial trust and Post-Handshake for re-attestation — or it might rely entirely on Post-Handshake mechanisms to handle both initial session trust and ongoing periodic re-attestation.¶
This document introduces several operational and manageability considerations for deploying attested secure channels.¶
Designing and evaluating an attested transport protocol requires a precise distinction between the cryptographic guarantees provided by the transport design and the operational assumptions required of the surrounding deployment.¶
The SEAT protocol layer provides channel and key binding:¶
Deriving a Session Binding Value that commits to two-sided session randomness (see Section 6.5.1).¶
Binding the Transport Signing Key (TSK) to the attested execution
environment, evaluated at appraisal time (see Section 8).¶
Injecting the Session Binding Value into the attestation challenge (see Section 4).¶
Ensuring that Evidence presented on one transport session cannot be relayed or replayed on a different session (see Section 6.5.1).¶
Under its stated cryptographic assumptions, SEAT guarantees session co-presence: the entity completing transport authentication is the entity possessing the attested platform state.¶
However, the overall security of an attested connection depends on operational and appraisal layers that sit outside the transport protocol. Failures at these external layers result in operational breakdowns in prerequisite trust domains:¶
Appraisal Engine Mechanics: If an appraisal library contains implementation flaws - such as permitting an empty, null, or uninspected challenge parameter to bypass verification. (see Section 4.4).¶
Policy Specification: If an operator configures an appraisal policy that accepts unmeasured container images, outdated firmware, or loose software digests, the verifier will faithfully certify an unapproved workload (see Section 4 of [RFC9334] and [I-D.ietf-seat-use-cases]).¶
Destination Identity Validation: Transport binding proves that an enclave is present, not that it is the destination the client intended to reach. If a relying party validates a genuine hardware quote but omits matching the peer's presented identity against the intended reference identity (see Section 1.1 of [RFC9525], the connection is vulnerable to diversion attacks.¶
Protocol designers, implementers, operators, and users must consider the specific security goals and requirements for any given deployment and understand the corresponding attacker models that may apply, such as the potential threat and impact of network attackers or malicious peers. See Section 3 of [I-D.ietf-seat-use-cases] to review these considerations and their remedies.¶
For an architectural overview of additional security-related concerns for attested transport channels, see Section 8.¶
Deploying SEAT protocols requires resolving a core topological trade-off between the Background-Check and Passport conveyance models (see Figure 2). While protocol mechanisms determine how messages are framed on the wire, the operational profile of the transport channel is governed by where and when Evidence is appraised.¶
For short-lived or latency-sensitive connections, the Passport model can minimize setup latency by allowing local evaluation of pre-appraised credentials during channel establishment. For persistent, long-lived connections, periodic re-attestation over the established Attested Channel accommodates dynamic platform evolution; the conveyance model determines whether the appraisal is synchronous (Background Check) or asynchronous (Passport).¶
The conveyance models differ in where Evidence is disclosed and when appraisal occurs (see Section 5 of [RFC9334]); both require withholding application data until the initial appraisal completes (see Section 4.4).¶
This section outlines a number of operational challenges that operators and implementers of SEAT protocols may encounter when deploying the Background-Check conveyance model.¶
Conveying raw Evidence directly to the Relying Party may expose granular hardware topology, silicon identity keys, and platform patch state to the peer. Protecting this sensitive platform state requires due care to avoid unnecessary information disclosure (see Section 7).¶
By contrast, the Passport model discloses raw measurements exclusively to an authorized Verifier out-of-band. This may make it operationally simpler to present a minimized Attestation Result that asserts policy conformance without disclosing underlying hardware metrics. Where the Background-Check model is used, implementations may mitigate exposure by decoupling static platform endorsements from ephemeral session binders, or by evaluating manufacturer PKIs out-of-band.¶
Attestation Evidence reflects a point-in-time observation of platform state, which can introduce an operational Time-of-Check to Time-of-Use (TOCTOU) gap over long-running connections (see Section 6.7). While platform-enforced hardware latches protect boot-time state, assurances regarding unlatched software components may drift as execution continues.¶
In the Passport model, freshness is governed by explicit validity windows; however, tight lifetimes risk mid-session expiration while longer lifetimes increase exposure to unobserved state changes. Deployments can address this tension by isolating long-lived baseline manifests from lightweight session-binding proofs.¶
Adapting to runtime state evolution or appraisal context drift can be addressed via periodic re-attestation (see Section 6.6.3). In the Background-Check model, executing continuous appraisal directly over the active Attested Channel incurs synchronous round trips to an available Verifier, introducing potential for pipeline stalls or transport timeouts.¶
Under the Passport model, re-attestation occurs asynchronously out-of-band: the Attester fetches an updated Attestation Result and ingests it via standard transport mechanisms without blocking channel execution. Where continuous background checks are necessary, separating target state monitoring from asynchronous context drift tracking can help reduce active channel friction.¶
In the Background-Check model, the Relying Party must withhold application data while performing a synchronous appraisal query to an available Verifier. This verification fan-out latency compounds channel setup delays, which increases communication timeouts in lossy or distributed networks.¶
Furthermore, uncompressed platform Evidence may exceed network Path MTU limits, causing datagram fragmentation and connection aborts. On datagram-based transports packet drops cannot generally be recovered selectively at the transport layer, meaning lost fragments can precipitate full-message retransmissions and session aborts rather than mere latency delays [IAB-WORKSHOP26].¶
To mitigate these transport reliability challenges, implementations can evaluate compact proofs (see [PLANTS-WG]) or distribute heavy reference manifests out-of-band to keep on-wire payloads within standard Path MTU limits.¶
When remote attestation occurs within the Intra-Handshake Window, the transport handshake withholds progression to application data exchange until the Attestation Result is available: application data exchange has not yet begun. A Verifier rejection, or a Relying Party policy rejection of an otherwise valid Attestation Result, MUST result in a fatal error consistent with the transport protocol's existing handshake-failure handling.¶
It is RECOMMENDED that the failure mode be interpretable by the application as a remote-attestation-related fault. Remote attestation specificity provides greater flexibility to apply application-layer policies, and assists in auditing and general debugging.¶
Failure handling in the Post-Handshake Window depends on whether the appraisal relates to the initial attestation event or to a subsequent re-attestation.¶
For an initial attestation event using the Post-Handshake model, authorization policies withhold application data exchange until the attestation procedure completes successfully; thus, application data has not yet begun to flow. A failure at this stage prevents the initial authorization to exchange application data.¶
When Re-attestation fails during the Lifetime of Connection, the transport session is already established and application data has already been flowing. Section 1-2 of [RFC9334] allows a failed Attester appraisal to result in reduced access or privileges rather than outright rejection. Depending on whether enforcement is handled by the transport stack or the application, the Appraisal Policy determines whether the underlying transport session is torn down or restricted to an authorized subset of data streams.¶
Failure handling of Re-attestation does not retroactively protect application data already exchanged prior to the failed appraisal; it bounds further exposure going forward.¶
Regardless of which timing model is used or which transport protocol is in use, a correctly bound attested channel requires that three conditions hold in sequence.¶
The first condition is Session Binding Value establishment. The endpoints must derive or obtain a shared, session-specific Session Binding Value from which Attestation Binders can be derived. The Session Binding Value is bound to the specific session instance by construction, and may be public (for example, a handshake transcript) or secret (for example, an exporter-derived value).¶
The second condition is directional Binder derivation. From the Session Binding Value, the protocol derives distinct Attestation Binders for the initiator and the responder. The binders are directional: the initiator's binder cannot be substituted for the responder's and vice versa. This ensures that Evidence produced by one endpoint cannot satisfy the verification requirement for the opposite endpoint, even within the same session.¶
The third condition is channel binding to an Attestation Credential. The Attesting Environment signs its directional Attestation Binder into its Evidence payload, committing that Evidence to this specific session.¶
For this condition to hold when using the Passport model, the Verifier must propagate this binding into the resulting Attestation Result, ensuring the final Attestation Credential presented to the Relying Party remains committed to the specific transport session.¶
The above conditions aim to mitigate two primary attack vectors:¶
Replay Across Sessions: Because the Session Binding Value is unique to the session, an Attestation Credential committed to a binder derived from it cannot be presented in a different session. Where the Session Binding Value is secret, only the session participants can derive it. Where it is public, for example, a handshake transcript, its uniqueness follows from the ephemeral keying material that the transport establishes per session, so the transcript, and hence the binder, cannot recur across sessions.¶
Key Substitution: A valid Attestation Credential
produced by a genuine attested execution environment is presented while
the TSK (Subject Key) used for authentication was not generated or protected
within that environment. Session binding alone does not bind the
Subject Key to the attested environment; this is handled at the RATS
layer, as discussed under Key Non-exportability in
Section 8.¶
The Attestation Credential itself plays a critical role in verifying that these three session binding conditions have been successfully achieved. Beyond the cryptographic inclusion of the Attestation Binder, strict requirements for the internal structure and the application of logical safeguards protecting the Attestation Credential are necessary to provide assurance that the Attestation Credential could not have been generated through alternative means such as side-channel exploits.¶
When all three conditions are met, the channel-binding check may be performed either by the Relying Party itself or by the Verifier. As a session participant, the Relying Party holds the Session Binding Value and can compute the binder locally and MAY send it to the Verifier which compares it with the binder in the Evidence, avoiding the need for the Relying Party to decode the Evidence first.¶
If the Relying Party is directly consuming Evidence (Background-Check model), it rejects Evidence whose binder does not match. If the Relying Party is consuming an Attestation Result (Passport model) and expects per-session freshness (see Section 6.6.1), it MUST reject the Attestation Result if it cannot affirmatively evaluate that the Verifier explicitly tied the Attestation Result to the current session's Attestation Binder.¶
The freshness of Evidence is critical to its value as a trustworthiness signal. In the transport context, freshness has several distinct scopes that must be addressed separately.¶
Per-session freshness ensures that Evidence is bound to the specific session being evaluated and cannot be replayed from a prior session. This property is addressed directly by the session binding mechanism of Section 6.5.1. The Session Binding Value is specific to the session and cannot be known before the session is initiated, providing nonce-style freshness in the sense of [RFC9334] Section 10. Evidence committed to an Attestation Binder derived from the Session Binding Value is therefore intrinsically fresh with respect to the session: a replay from a different session will carry an Attestation Binder derived from a different Session Binding Value, and appraisal will fail.¶
Session resumption introduces a specific freshness consideration. When a transport session is resumed, a previously obtained Attestation Credential may no longer reflect the Attester's current state.¶
Initial attestation at Connection Establishment Time addresses the architectural invariants the Relying Party's policy requires before application data may flow. Re-attestation addresses the dynamic reality that established sessions may outlast the validity of a single trust assessment. Protocol specifications building on this architecture SHOULD treat these as distinct concerns.¶
Per-session freshness ensures Evidence cannot be replayed across sessions but does not address changes in the Attester's state during the Lifetime of Connection, nor does it prevent replay of previously presented Evidence within the same session. Protocol specifications supporting re-attestation must require fresh Evidence generation bound to an updated session challenge (e.g., using Extended Key Update [I-D.ietf-tls-extended-key-update] or an epoch-specific transport exporter).¶
A Relying Party MAY require Re-attestation before continuing to transmit sensitive data to a peer whose trust assessment has expired or whose deployment environment may have changed in ways material to its policy.¶
Re-attestation does not retroactively protect data transmitted before a state change occurred. It bounds further exposure by conditioning continued sensitive data transmission on a current trust assessment. Whether to terminate a session upon re-attestation failure or continue with reduced privilege is a matter of Relying Party policy; see Section 6.4.¶
Remote attestation provides a point-in-time observation of the target platform's security state. Additionally, the point-in-time when the claims representing the Attester's state are collected is also necessarily earlier than when the Evidence is signed. The interval between Claim Collection Time, Evidence Generation Time and subsequent application data exchange introduces a theoretical Time-of-Check to Time-of-Use (TOCTOU) gap (see Section 2).¶
In typical attestation architectures (see exceptions below), this gap is bounded by hardware-and platform-enforced immutability critical sections:¶
Hardware-Latched State: Sensitive platform state, including secure boot measurements and platform configuration, is cryptographically latched into write-once hardware registers hardware registers that cannot be altered without resetting the platform.¶
Memory Isolation: Memory encryption and access-control boundaries prevent an untrusted host (as well as peer enclaves) from altering enclave memory during execution.¶
Durable logs or deferred updates: Critical software updates either require an instance restart that resets the measurement latch, or otherwise provide an append-only log bound to an extend-only measurement latch (such as when live firmware updates are supported by the platform). It must be possible for the Relying Party to assess whether a critical software update can happen without the Attester being terminated.¶
Point-in-time measurements therefore provide durable security assurances for properties governed by platform immutability latches.¶
Over long-running sessions, operational risk arises from two distinct sources:¶
Target State Evolution: Internal modifications to the platform's active security state during execution, such as live firmware updates advancing a security version number (SVN) or appending to the firmware activity log.¶
Appraisal Context Drift: External changes to the evaluation environment independent of the target platform, including endorsement credential revocation, updated reference value manifests (e.g., CoRIM), or revised appraisal policies deprecating previously acceptable states in response to newly disclosed vulnerabilities.¶
Periodic re-attestation during the connection lifetime addresses both factors by capturing fresh evidence of the target's current operational state and confirming that the established session remains aligned with current appraisal criteria (see Section 6.6.3).¶
The Evidence payload carries Claims about the Attester's state and is the most privacy-sensitive artifact in the protocol. It is RECOMMENDED that Evidence payloads be encrypted to a key held exclusively by the intended recipient (typically the Verifier), so that the Evidence content is disclosed only to that recipient and not to the Relying Party or to other parties on the path.¶
The complementary control for the Relying Party surface is minimization: the Attestation Results returned to the Relying Party SHOULD NOT re-expose sensitive Claims that were protected in any encrypted Evidence. A framework for consistent handling of sensitive Evidence across RATS roles, including claim classification, Trusted Verifier management, and Attestation Credential minimization, is provided in [I-D.ounsworth-rats-privacy-framework].¶
The transport connection discloses metadata — IP addresses, server name indications, and connection timing — that is visible to passive network observers. This disclosure is inherent to the transport protocol and is not specific to the attestation layer.¶
When the same attestation signing key is used across multiple sessions, any party with access to Evidence from more than one of those sessions can correlate the sessions to the same Attesting Environment. This linkability consideration is particularly relevant for client Attesters where privacy of individual connections is a concern.¶
The SEAT architecture supports deployments where a client Attester attests to the trustworthiness of its Attesting Environment without presenting a TLS client identity certificate, enabling anonymous client attestation. In this deployment, the Relying Party's appraisal policy applies to the client's hardware and software state rather than to a disclosed identity.¶
The IAB has issued a statement cautioning that using client attestation as a barrier to access for otherwise open protocols and services risks undermining Internet openness [IAB-Attestation-Risks]. The statement distinguishes services with intentionally restricted access — for which client attestation is recognized as a valuable security measure — from openly accessible services, for which imposing hardware or software requirements on participating implementations is inappropriate. SEAT is scoped to the former category: the use cases motivating this work involve confidential workloads, enterprise-controlled environments, and TEE-backed services where access is explicitly conditioned on verified platform state.¶
The IAB statement further identifies the disclosure of vendor- specific hardware and software information as a distinct risk: attestation evidence that reveals which specific implementations are in use can restrict access and enable tracking in ways that undermine the open internet. Protocol designs building on this architecture should minimize vendor-specific claim disclosure consistent with the Attestation Credential minimization controls described in this section and in [I-D.ounsworth-rats-privacy-framework].¶
This section enumerates the security properties and considerations of the SEAT architecture. Security goals state outcomes the architecture is designed to achieve; they carry no normative mandates. Security properties state technical characteristics the protocol is expected to exhibit and may carry normative requirements. Implementations MUST also consider the Security Considerations of [RFC9334] and of any protocol specification that instantiates this architecture.¶
Cryptographic Session Binding and Relay Prevention. An Attestation Credential presented on a session MUST be cryptographically bound to that session and to the endpoint role in which it is presented. This is achieved by binding the Attestation Credential to an Attestation Binder derived from a Session Binding Value that is specific to the session and cannot be known before the session is initiated. Consequently, a valid Attestation Credential from one session cannot satisfy a Verifier or Relying Party on a different session or from a different endpoint; a replay carries a Binder derived from a different Session Binding Value and MUST be rejected. See Section 6.5.1.¶
Split-Deployments. Because a compromised host could attempt to
use the Attesting Environment as a signing oracle by substituting
the attestation binder input, the architecture relies on
cryptographic binding rather than continuous state monitoring.
The Attesting Environment MUST bind the Attestation Credential
to the private identity key (TSK) it holds to authenticate a connection
(for example, by including a hash of the associated public key in the
signed payload).¶
The Relying Party then verifies that this claim matches the identity key presented in the transport handshake, preventing an untrusted host from successfully substituting the binder.¶
Key Non-exportability (informative). The specific concern of
demonstrating that the Subject Key (TSK) used for transport authentication
is physically confined within the attested execution environment is
addressed at the RATS layer by [I-D.reddy-rats-key-binding] and is
not re-specified here.¶
Evidence Freshness. Evidence reflects the Attester's state at or near the Evidence Generation Time for the session in which it is presented. Per-session freshness ensures Evidence from a prior session cannot be replayed against a new one. When re-attestation occurs during a session's Lifetime of Connection, the re-attestation Evidence reflects the Attester's state at the time of re-attestation, not at Connection Establishment Time.¶
Evidence Confidentiality. Evidence payloads SHOULD be protected by object-level encryption to a key held exclusively by the intended recipient. See [I-D.ounsworth-rats-privacy-framework].¶
Session Resumption. When a transport session is resumed, a previously obtained Attestation Credential may no longer reflect the Attester's current state. Attestation from a prior session does not carry over to a resumed session.¶
Directional Endpoint Binding. Distinct Attestation Binders MUST be derived for the initiator and the responder from the same Session Binding Value using distinct inputs. Evidence produced by one endpoint MUST NOT satisfy the verification requirement for the opposite endpoint. See Section 6.5.1.¶
Transmission and Verification Anchor Soundness. An Attestation Binder may be included in a transport message before peer authentication is complete (the Transmission Anchor). Implementations MUST ensure the transport protocol's integrity guarantee covers the message carrying the Attestation Binder; for example, the TLS 1.3 handshake MAC (the Verification Anchor) retroactively guarantees the Binder's integrity at handshake completion.¶
Downgrade Prevention. Two endpoints that both support attestation cannot be caused by an active adversary to negotiate a connection without it. The negotiation of attestation capabilities is protected against suppression.¶
Dynamic Verification Code Integrity. When client-side attestation verification logic is dynamically delivered by the endpoint under appraisal (such as browser-based JavaScript), a circular trust dependency exists. Unless the client's execution environment enforces an independent, orthogonal guarantee of code integrity and binary transparency, application-layer attestation cannot provide security assurance, as the Attester may serve malicious code that bypasses cryptographic validation.¶
The following adopts the attacker model of Section 3 of [I-D.ietf-seat-use-cases] and evaluates security goals that are broadly inherited from the Security Considerations extending the broader RATS ecosystem. See Section 12 of [RFC9334].¶
Attacker capabilities: A network attacker or untrusted intermediary that can obtain or induce valid encrypted Evidence envelopes constructed against the current connection challenge. The attacker does not possess the Verifier's private decryption key, the Attestation Key, or the peer authentication key.¶
Targeted assurance: The Evidence evaluated by the Verifier corresponds strictly to the encrypted payload conveyed across the secure channel.¶
Preconditions and attack: When a Relying Party is restricted from handling claims directly, Evidence may be encrypted for an external Verifier to protect claim privacy (see Section 11 of [RFC9334]), leaving the Relying Party as a blind forwarder. The attacker intercepts the encrypted Evidence envelope and substitutes a different valid envelope constructed against the same connection challenge. The Relying Party forwards the substituted envelope to the Verifier, which decrypts it and returns an Attestation Result confirming valid Evidence for that challenge. The Relying Party completes the connection, falsely attributing the substituted posture to the peer.¶
Why validation succeeds: The Relying Party cannot inspect inner claims. Verifier appraisal succeeds because the substituted payload contains valid signatures and matches the expected challenge. Standard channel authentication confirms control of the identity key, but remains cryptographically uncoupled from the inner Evidence.¶
Mitigation strategy: The Relying Party computes a cryptographic commitment directly over the opaque encrypted Evidence bytes on the wire, and the Verifier binds this commitment into the signed Attestation Result, establishing transitive cryptographic closure between the channel transcript and the appraised payload.¶
This document has no IANA actions.¶
The Timing Models of Section 5 describe when an Attestation Credential is conveyed relative to connection establishment. This section describes two structural implementation examples by which a transport protocol conveys an Attestation Credential to the Relying Party without requiring the transport specification itself to encode RATS semantics.¶
Depending on the conveyance model, the Relying Party either forwards Evidence to a Verifier to receive an authorization decision (Background-Check Model) or validates an Attestation Result directly (Passport Model). This section describes two in-band structural implementations (Extension-Based and Structured Payload Conveyance).¶
In this pattern, the transport protocol's existing identity or authentication structures (such as an X.509 certificate extension, or a comparable protocol-specific extension point) are reused to carry an Attestation Credential. The transport stack itself remains unaware of [RFC9334] semantics: it recognizes only that an extension it is configured to process is present, and delegates interpretation of the extension's contents to an external callback.¶
The transport state machine suspends progress at the point the extension is processed, invokes the callback with the extension payload, and resumes or aborts the handshake based on the callback's return value. The callback interface is transport-external: it need not be specified by the transport protocol itself, only supported by it as an extension point.¶
Cryptographic binding of Evidence to a per-connection session can be achieved in TLS 1.3 {RFC9846}} as follows:¶
Binder Derivation: The server computes the binder over the
ClientHello...ServerHello transcript checkpoint, binding it
directly to the hash of the server's public key.¶
Evidence Transmission: The Evidence containing this binder
is conveyed within a dedicated Remote Attestation extension of
the Certificate message.¶
Cumulative Transcript Incorporation: The Certificate message
(carrying the Evidence and binder) becomes an immutable input into
the running handshake transcript.¶
Transcript Sealing and Key Derivation: That cumulative transcript
is signed by CertificateVerify and authenticated by the Finished
MAC. The very same transcript snapshot directly derives the
application traffic keys.¶
In this pattern, the transport protocol defines a dedicated, opaque field for authorization-related data as part of its handshake or key-exchange messages, distinct from the identity structures used for peer authentication. The Attestation Credential, and any associated attestation-specific protocol elements, are carried within this field.¶
The transport stack extracts the field's contents and passes them to an adjacent component responsible for [RFC9334] semantics, without needing to parse or understand the contents themselves. As in Extension-Based Conveyance, the transport state machine halts pending the outcome of this processing. The distinction between the two patterns is where the extension point is anchored: an existing identity structure being overloaded (Extension-Based Conveyance) versus a field purpose-defined by the transport protocol for authorization data (Structured Payload Conveyance).¶
Both patterns satisfy the requirement that an Attestation Credential be conveyed prior to the transition to application data exchange; the choice between them depends on the target transport protocol's extension model and is otherwise architecturally equivalent from an [RFC9334] perspective.¶
The SEAT WG is not the only WG within the IETF composing [RFC9334] Remote Attestation with established IETF building blocks. Beyond the LAKE WG's own RA draft [I-D.ietf-lake-ra], another promiment example is the Automated Certificate Management Environment (ACME) WG and their adopted protocol extension ACME RATS [I-D.ietf-acme-rats].¶
The ACME protocol [RFC8555] is designed to allow a CA and an applicant to automate the process of verification and issuance of Public Key Infrastructure X.509 (PKIX) certificates. An applicant requests a given identifier to appear in the certificate, and the ACME server provides a list of proof-of-control challenges. The ACME RATS extension defines a specialized RA challenge answered with a RATS Conceptual Message Wrapper (CMW) [RFC9999] capable of carrying Evidence, Endorsements, or an Attestation Result in any RATS-supported format. This enables ACME RATS to provide a general, RATS-ecosystem-native framework for conveying supplemental trust and posture information, decoupled from certificate identifiers. The extension also includes a property where the applicatant can fetch an encryption public key that it can use for encrypting the remote- attestation (CMW) challenge response (see Section 2.2.1 of [I-D.ietf-acme-rats]).¶
In operation, an X.509 certificate enhanced with RA such as [I-D.ietf-lamps-csr-attestation] or obtained through ACME RATS represents a textbook example of the RATS Passport conveyance model. However, such a certificate has a fixed validity period. If a Certificate Authority signs a standard 90-day certificate based on a boot-time measurement and a host later falls out of conformance with its expected security state 3 days later, then without continuous revocation mechanisms, a standard TLS 1.3 implementation will still accept the certicate, representing a significant TOCTOU risk (see Section 6.7).¶
A complimentary approach in addressing these kinds of TOCTOU risks may be addressed by deploying a dedicated protocol solution such as Attested TLS. For example, executing an in-band attestation exchange during TLS establishment allows the relying party to request a real-time, connection-bound re-evaluation of Attester's security state against current appraisal policy. This would work as a form of reattestation (see Section 6.6.3) and enables reassessment of a given platform without having to reissue the identity certificate.¶
The authors wish to thank all SEAT WG participants for their thoughtful input and contributions that have helped influence this document.¶
Terminology: Introduced TSK, capitalized key identifiers (AEK, ARK),
and defined Authenticated Identity.¶
Architecture: Defined the RATS/SEAT interface with fail-closed semantics, formalized compound authorization and key provenance, and refreshed core diagrams.¶
Timing Models: Clarified post-handshake conveyance mechanisms within the transport layer (e.g., Exported Authenticators) alongside application framing, and decoupled conveyance timing from connection lifecycle events (initial trust establishment vs. periodic re-attestation).¶
Operations: Added a dedicated section detailing operational scope, trust boundaries, and attestation credential lifecycles; documented operational trade-offs and challenges under the Background-Check model and refined post-handshake failure handling to distinguish initial attestation gating from mid-connection re-attestation.¶
Security: Added threat models covering unauthorized credential hosting and blind envelope substitution under encrypted Evidence.¶
Appendices: Added TLS 1.3 session binding transcript derivation, comparative analysis with ACME RATS, and an out-of-band appraisal integration pattern using pre-cached Attestation Results.¶
Editorial: Added Yuxuan Song as co-author, updated affiliations, and revised references (including PLANTS-WG and IAB PQWS citations).¶
Initial version¶