]> Openchip & Software Technologies S.L.

enrique.larraia@openchip.com

Openchip & Software Technologies S.L.

akira.tsukamoto@openchip.com

SEAT Working Group This document specifies a mechanism that allows a Relying Party to perform post-handshake remote attestation of a peer over a dedicated TLS connection and binds the resulting Attestation Credential to subsequent, fresh TLS connections to the same attested Target Environment, including connections to different server endpoints hosted within it. Forward Attested TLS decouples when trust is established from when trust is exercised.

Introduction Remote attestation integrated with secure channel establishment () addresses the channel-binding goal of Section 4.1 of by binding attestation Evidence to a specific transport session, so that an appraisal cannot be replayed to a different session or transferred to a different endpoint. The session-binding mechanisms of , intra-handshake attestation in , and post-handshake attestation in bind Evidence to the connection being attested. Per-connection attestation is the right default, but it is a poor fit for deployments with split endpoints within one Target Environment. The component able to perform the attestation exchange (an attestation agent) and the component serving application traffic (an application server) are different TLS endpoints within the same Target Environment. The Serving Endpoint handles its own TLS layer, and modifying that implementation to support attestation is undesirable. Adding per-connection attestation without modifying it requires an inline proxy on the application data path, which adds a hop to every request. Forward Attested TLS addresses this split-endpoint deployment. A Relying Party attests the Target Environment once, over a dedicated attestation connection, using Exported Authenticator-based post-handshake attestation . The artifact it obtains is not merely an appraisal for that connection: it is a Forward Attested Certificate (FAC), a short-lived, self-signed X.509 certificate whose subject key, the Forward Bound Key (fbK), is derived from the attestation connection itself and committed inside the appraised Evidence. Possession and use of the fbK on any later connection therefore demonstrates continuity with the attested Target Environment. The Relying Party caches the exported certificate as the server certificate, and connects to any serving endpoint of the Target Environment using ordinary TLS, until the certificate expires and re-attestation is required. In terms of the Secure Evidence and Attestation Transport (SEAT) architecture, Forward Attested TLS composes post-handshake attestation with a key-continuity mechanism: the session-binding pattern of Section 7 of motivates the binding on the Attestation Connection. The deliberately shared fbK changes the key-confinement assumptions of that architecture and of ; see Sections and . Forward Connections provide key continuity rather than fresh per-connection attestation. The trade-offs are analyzed under . Related SEAT work, besides on which this mechanism builds, includes the security goals and deployment scenarios in , application-layer transport of Exported Authenticators in , and binding attestation across a cooperative TLS-terminating intermediary in . These documents provide context or are complementary to this draft.

Conventions and Terminology 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 when, and only when, they appear in all capitals, as shown here. Lowercase uses retain their ordinary meanings. Remote ATtestation procedureS (RATS) roles and artifacts use the terminology of Section 4 of . SEAT terms use Section 2 of , subject to the shared-key distinction in below. This document additionally defines: Forward Bound Key (fbK): An asymmetric signature key pair derived deterministically by both endpoints of the Attestation Connection from TLS Exported Keying Material. Attestation Connection: The TLS connection between the Relying Party and the Attester's Attestation Endpoint over which the Exported Authenticator exchange is performed. Forward Connection: The TLS connection between the Relying Party and the Attester's Serving Endpoint, established after the Attestation Connection, that presents the Forward Attested Certificate as its server certificate. Attestation Endpoint: The TLS server within the Target Environment that terminates the Attestation Connection and constructs the Exported Authenticator (for example, an attestation sidecar). Serving Endpoint: Any TLS server within the same Target Environment that serves application traffic on subsequent Forward Connections and presents the Forward Attested Certificate. Forward Attested Certificate (FAC): An X.509 certificate whose subject public key is the fbK.

Overview

Endpoint Topology

Forward Attested TLS topology. (1) one-time attestation connection; (2) subsequent application connections. | attestation | | | | component | | attestation | endpoint | | | +-------+--------+ | channel | +----------+----------+ | | | provision | | | provision | | v FAC | | v FAC + fbK | | +----------------+ | (2) | +---------------------+ | | | application |<============|=>| serving | | | | client | | forward | | endpoint(s) | | | +----------------+ | channel | +---------------------+ | | | | | +----------------------+ +---------------------------+ ^ Attesting | Evidence Environment--+ (commits fbK) ]]>

Both the Attestation Endpoint and the Serving Endpoint MUST reside within the attested Target Environment: the appraised Evidence speaks for the environment that holds the fbK private key, and every endpoint that presents the FAC exercises that key (see Security Considerations, ).

Protocol Phases

Protocol phases (passport model shown). | | | (certificate_request_context, | | empty cmw_attestation, | | forward_atls_params) | | | | | both sides derive fbK from exporter | (context = certificate_request_context) | | | | | |-- Evidence --------->| | | (commits fbK_pub) | | | | | |<-- Attestation ------| | | Result | | |<-- Exported Authenticator--| | (FAC in Certificate msg,| | cmw_attestation = AR, | | CertificateVerify, | | Finished) | | | validate forward FAC provision FAC + fbK | to serving endpoint | | | | |==== Phase 2: App ==========| | (new TLS channel) | [Application Client] [Serving Endpoint] | (server certificate == FAC) | | |<---- application data ---->| ]]>

The Forward Bound Key (fbK)

Derivation In the Attestation Connection, after the Authenticator Request () has been received, both endpoints derive the fbK private key from TLS Exported Keying Material, using the exporter defined in Section 7.5 of and the certificate_request_context of the authenticator as the exporter context. The derivation uses the HMAC-based Extract-and-Expand Key Derivation Function (HKDF): where HKDF-Expand is defined in Section 2.3 of and uses the hash function of the negotiated cipher suite. L is the length required by the target algorithm, and KeyGen denotes a deterministic mapping from derived bytes to a private key of the selected signature algorithm. Both endpoints MUST agree on the algorithm (). The hash of the fbK public key serves as this document's Attestation Binder; the fbK itself is a shared authentication key. See .

Directionality The exporter label above binds the fbK to the server (responder) role of the attestation connection, satisfying the directional-binder requirement of Section 7. For deployments in which the TLS client is the Attester, the label "EXPORTER-client forward attested tls" MUST be used instead. Evidence produced under one label MUST NOT be accepted for the opposite role. However, the mechanism specified in this draft is best suited to deployments where the TLS server acts as the Attester.

A Deliberately Shared Key Section 2 of defines a Target/TEE-Bound Key (tbK) whose private key is confined to the Target Environment, where TEE denotes a Trusted Execution Environment. The fbK does not satisfy that definition: it is deliberately known to both the Attester and the Relying Party. The fbK derives from Exported Keying Material. This changes what the fbK means. It is not an identity key in the PKI sense. A signature by the fbK proves knowledge of the Attestation Connection's exporter secret, i.e., presence at one of the two ends of that specific channel, not exclusive possession. In this sense, the fbK is closer to a symmetric message authentication code (MAC) key than to an asymmetric signing key. Section 3.4 of distinguishes key binding from assurances about key generation, storage, export, and use. For the fbK, such assurances must account for its deliberate sharing with the Relying Party and provisioning to Serving Endpoints; exclusive TEE confinement is not claimed.

Attestation Connection

TLS Requirements The Attestation Connection MUST use TLS 1.3 . Use with a later TLS version requires a specification of compatible exporter and Exported Authenticator behavior. The requirements of Section 7.2 of apply: the server MUST NOT send NewSessionTicket, the client MUST NOT offer early data, and a client receiving a NewSessionTicket MUST discard it and MUST NOT use it for resumption. The Attestation Connection MUST use a fresh key exchange; it MUST NOT be established by resuming a previously attested connection. The Attestation Endpoint SHOULD authenticate in the handshake with a conventional PKI certificate. This complements attestation, following the compound-authentication and peer-authentication goals in Sections 4.2 and 4.7 of .

Authenticator Request The Relying Party initiates by sending an Authenticator Request (ClientCertificateRequest, ) with:

• a certificate_request_context that is unique within the connection and unpredictable to the peer, and a signature_algorithms extension identifying acceptable TLS 1.3 signature schemes (following );
• an empty cmw_attestation extension, indicating that it can process an Attestation Credential (following );

Additionally, and specific to this draft:

• optionally, a forward_atls_params extension conveying parameters, such as the requested FAC validity period. Its encoding and negotiation remain to be specified.

Attestation Binder Upon receiving the Authenticator Request, the Attester derives the fbK () and causes its Attesting Environment to produce Evidence that commits to the Attestation Connection. The Evidence MUST include the hash of the fbK public key. This hash is the Attestation Binder for Forward Attested TLS. TLS session binding. This binding addresses the channel-binding goal in Section 4.1 of . The fbK is derived from the TLS exporter using the certificate_request_context as its context. It is therefore bound to both the Attestation Connection and the specific Authenticator Request. The exporter MUST use exporter_secret , not the early exporter secret. This technique builds upon the binder defined in Section 5.1 of .

Forward Attested Certificate (FAC) The Attester generates the FAC as an X.509 v3 certificate using the certificate fields defined in Section 4 of . It is self-signed with the fbK private key. Certificates backed by a Certification Authority (CA) may also be explored. Relevant fields to populate include:

• SubjectPublicKeyInfo: the fbK public key;
• subjectAltName: dNSName entries for the Serving Endpoint names. Name matching follows Section 6 of . This does not by itself make a self-signed FAC trusted by an unmodified TLS client; the client must be configured to trust the cached FAC as specified in ;
• notBefore: the current time; notAfter: notBefore plus the minimum of the Relying Party's requested validity period and the remaining validity of the Attestation Credential;
• OPTIONAL id-pe-cmw X.509 extension carrying a copy of the Attestation Credential, encoded as specified in Section 4.4 of . This is distinct from the TLS cmw_attestation extension carried in the Exported Authenticator (Section 3 of ).

Validation On receiving the Exported Authenticator, the Relying Party MUST independently derive the fbK public key from its own side of the Attestation Connection, using the certificate_request_context it sent in the request (), and verify that it equals the FAC subject public key. The Relying Party should also check that the validity period matches the one it requested. The Relying Party MUST also validate the Exported Authenticator under Sections 5.2.4 and 7.4 of , verify the binding of the appraised Attestation Credential to the expected fbK, and evaluate the appraisal outcome according to the applicable RATS conveyance model (Section 5 of and Section 3.4 of ).

Forward Connection Validation of the Attestation Connection MUST complete () before any application data is sent over any connection whose trust derives from it.

Relying Party Caching The Relying Party caches the validated FAC, indexed by the Serving Endpoint identity, together with its validity period and the appraisal outcome. On a Forward Connection to a Serving Endpoint, the Relying Party MUST authenticate the server using the cached FAC as the trusted anchor. Forward Connections use TLS 1.3 . Session resumption MAY be used only while the cached appraisal and FAC remain acceptable and the resumed session is associated with that validated FAC.

Re-Attestation Expiry of the FAC or Relying Party policy (e.g. an operator signal) triggers a new attestation exchange over a fresh Attestation Connection, producing a fresh fbK and FAC. These lifetime and event bounds address state drift and the need for periodic or on-demand attestation discussed in Sections 3.6 and 4.8.1 of . Serving Endpoints SHOULD support reloading their TLS credentials without disrupting established connections, so that re-attestation (which yields a new fbK and FAC) does not interrupt service.

Security Considerations Mapping the following security considerations against the Attacker Model from remains to be completed.

Attestation Connection The following are specific to the Attestation Connection. Session Binding. The Attestation Credential is bound to the Attestation Connection via the fbK public key, as discussed in . TEE binding. Unlike the independently generated identity key combined with an exporter binder in Section 5.1 of , the fbK itself is exporter-derived. With the Attestation Endpoint's TLS stack running inside the attested Target Environment, the fbK is bound to that endpoint by construction and therefore to the TEE. Key Exfiltration. Section 7.1 of requires platform and software assurances beyond cryptographic key binding. This design assumes that the Attestation Endpoint, the provisioning path, and all Serving Endpoints protect the fbK. Key Substitution. Section 3.4 of describes the key-substitution threat. Even without key exfiltration, a malicious host could try to have a genuine Attesting Environment produce Evidence while the certificate key is attacker-chosen. The Relying Party must both derive the expected fbK and verify that the appraised Attestation Credential commits to that key (). Evidence Freshness. Sections 3.3.1 and 4.4 of motivate freshness for each attestation exchange. Section 7.4 of analyzes freshness for its own binder construction. The fbK construction generalizes that construction, and therefore the same rationale for freshness applies to this draft.

Forward Connection The following are specific to the Forward Connection. Key Continuity. The state-drift risk described in Sections 3.6 and 4.8 of also applies to reuse across Forward Connections. A subsequent Forward Connection is bound to the Attestation Credential through key continuity: the Serving Endpoint proves possession of the fbK private key. Compromise of the Target Environment after attestation allows the adversary to use the fbK until expiry or detection. Relying Parties SHOULD use short FAC validity periods to limit the time for which compromised credentials remain usable. Shorter validity periods require more frequent re-attestation. Longer validity periods reduce re-attestation frequency but increase this exposure. Non-transferability. The Relying Party also derives the fbK, so the binding in this draft does not imply exclusive possession by the TEE. The guarantees are nonetheless non-transferable: they hold for the Relying Party that participated in the Attestation Connection, and for no one else. The Relying Party cannot use the FAC or an fbK signature to convince a third party (e.g. another Relying Party) of anything (it could have produced them itself). Resumption. The prohibition on resumption and early data applies to the Attestation Connection only, for the reasons given in Section 7.2 of . Forward Connections carry no fresh per-connection attestation semantics; their resumption remains subject to . Multiple Relying Parties. Where multiple independent Relying Parties access the same Target Environment, each MUST establish its own Attestation Connection, yielding its own fbK and FAC. Serving Endpoints therefore need to present different credentials to different Relying Parties (e.g., per-client virtual endpoints or credential selection based on Server Name Indication (SNI)), or the deployment must scope one Target Environment instance per Relying Party. Cross-protocol use of the fbK. The permitted signing uses are the Exported Authenticator CertificateVerify , the FAC self-signature, and CertificateVerify in certificate-authenticated Forward Connections (Section 4.5.2 of ). Implementations MUST NOT reuse the fbK for other purposes.

Privacy Considerations Section 4.9 of establishes the privacy-preservation goal, including the risk of tracking through identifying attestation claims. The privacy considerations of Section 9 and Section 8 apply. The following considerations are specific to Forward Attested TLS.

• Correlation across Relying Parties. Each Relying Party establishes its own Attestation Connection and receives a distinct fbK and FAC. The fbK therefore provides no common key identifier across Relying Parties. Other FAC fields or embedded Attestation Credentials can still identify the same Target Environment; distinct fbKs alone do not make these credentials unlinkable.
• Correlation through reuse. Repeated presentations of a FAC are linkable to parties that obtain them. Reusing a FAC across Serving Endpoints also reveals their association with that credential. Re-attestation changes the fbK, but persistent certificate fields or embedded claims can link successive FACs.

IANA Considerations TBD.

References Normative References Informative References

Deployment Example This mechanism was designed for a confidential AI serving system built on the Confidential Containers (CoCo) framework. The mapping to this document's roles is:

• Target Environment: a Confidential VM (CVM) hosting an OpenAI-compatible large language model (LLM) inference server (vLLM) and its guest-components.
• Attestation Endpoint: a sidecar (atls-sidecar) in the same pod, reached via SNI through a TLS-passthrough gateway, so that TLS terminates only inside the CVM.
• Serving Endpoint: the unmodified vLLM server, reached using a different SNI value through the same gateway. After a successful exchange, the sidecar writes the FAC and fbK key to a shared volume and the server reloads its TLS credential.
• Attesting Environment / Verifier: the CoCo guest-components Attestation Agent and the CoCo Trustee Attestation Service, operating in the passport model. The Attestation Result is an Entity Attestation Token (EAT) Attestation Result (EAR). The fbK binding requirement of is satisfied by using the fbK public key as the TEE pubkey in the challenge-response session key of the Trustee protocol (RCAR), whose runtime data, including the TEE pubkey, is hashed into the hardware report and reflected verbatim into the EAR's annotated-evidence claims.
• Relying Party: An external consumer/client ("Data Owner"): an attest-check tool establishes the Attestation Connection and caches the FAC. An ordinary OpenAI client performs subsequent TLS Forward Connections.

The forward attestation optimization removes two inline proxies (one per side) and a per-connection attestation round trip from the inference path, reducing it to a single ordinary TLS connection to the inference server.