]> Intuit

yaronf.ietf@gmail.com

Arm Limited

Ionut.Mihalcea@arm.com

Arm Limited

Yogesh.Deshpande@arm.com

Linaro

thomas.fossati@linaro.org

Nokia

k.tirumaleswar_reddy@nokia.com

Security TLS attestation RATS TLS The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using remote attestation which is a process by which an entity produces Evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enable the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation Evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and to use them mutually. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the SEAT Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Remote Attestation (RA) is the process by which an entity produces evidence about itself that another party can use to evaluate the trustworthiness of that entity. This document describes a series of protocol extensions to the TLS 1.3 handshake that enable the binding of the TLS authentication key to a remote attestation session. This enables an attester, such as a confidential workload running in a Trusted Execution Environment (TEE) , or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. This, in turn, allows for the implementation of authorization policies at the relying parties that are based on stronger security signals. Given the variety of deployed and emerging attestation technologies (e.g., , , ) these extensions have been explicitly designed to be agnostic to the attestation formats. This is achieved by reusing the generic encapsulation defined in for transporting Evidence and Attestation Results payloads in the TLS Attestation handshake message. This specification provides both one-way (server-only) and mutual (client and server) authentication using traditional TLS authentication combined with attestation, and allows the attestation topologies at each peer to be independent of each other. The proposed design supports both background-check and passport topologies, as described in Sections and of . This is detailed in and . The protocol we propose is implemented completely at the TLS level, resulting in several related advantages:

• Implementation is within a single system component.
• Security does not depend on application-level code, which tends to be less secure than widely shared infrastructure components.
• It is easier to reason about the application's security, since the peers' identities and security postures are known as soon as the handshake completes and the TLS connection is established.
• Application code does not need to change. At most, some configuration is needed, similar to the current use of certificate trust stores.

This document does not mandate any particular attestation technology.

Conventions and Terminology The reader is assumed to be familiar with the vocabulary and concepts defined in . The following terms are used in this document:

TLS Identity Key (TIK):

A cryptographic key used by one of the peers to authenticate itself during the TLS handshake. The protocol's security is critically dependent on the provenance, lifetime and protection properties of the TIK. The TIK MUST be the X.509 certificate's end entity key and is maintained and protected by the TEE.

TIK-C, TIK-S:

The TIK that identifies the client or the server, respectively.

TIK-C-ID, TIK-S-ID:

An identifier for TIK-C or respectively, TIK-S. This may be a fingerprint (cryptographic hash) of the public key, but other implementations are possible.

Attestation binder:

A cryptographic value used to bind the TLS handshake to the remote attestation session. May also be referred to as "binder" throughout the document.

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.

Overview The basic functional goal is to link the authenticated key exchange of TLS with an interleaved remote attestation session in such a way that the key used to sign the handshake can be proven to be residing within the boundaries of an attested TEE. The requirement is that the attester can provide Evidence containing the security status of both the signing key and the platform that is hosting it. The associated security goal is to obtain such binding so that no replay, relay or splicing from an adversary is possible. The protocol's security relies on the verifiable binding between the TLS Identity Key, the specific TLS session and the platform state through attestation Evidence or Attestation Results conveyed in the CMW (Conceptual Message Wrapper) payload.

Authentication vs. Attestation The protocol combines platform attestation with X.509 certificate authentication. Attestation when used alone is vulnerable to identity spoofing attacks, in particular when zero-day attacks exist for a class of hardware. (TODO: reference). Therefore it needs to be combined with traditional authentication, which in the case of TLS takes the form of CA-signed certificates. We RECOMMEND that regular applications use authentication and attestation in tandem, to gain the full security guarantees of an authenticated TLS handshake (for the peer/peers being authenticated) as well as guarantees of platform integrity.

Integration into the TLS Handshake The lightweight integration of attestation into the TLS handshake is designed to have minimal impact on the existing TLS security properties. The changes consist of:

• Negotiation extensions: New TLS extensions are added to ClientHello and EncryptedExtensions messages to negotiate the use of attestation and indicate supported attestation formats and verifiers.
• Independent handshake message: A new Attestation handshake message is introduced that carries attestation Evidence or Attestation Results. This message is completely independent of the standard TLS handshake flow and does not interfere with existing handshake messages or their processing.
• Independent key derivation: Key derivation for attestation (see ) ensures independence of the regular TLS key schedule. As a result, attestation processing does not affect the standard TLS key derivation and security properties.

This minimal integration approach provides an intuitive explanation of why the addition of attestation does not adversely affect TLS security. The attestation components operate independently, leaving the core TLS handshake protocol and key derivation mechanisms unmodified. Nevertheless, formal validation of these security properties is still required.

Attestation Extensions As typical with new features in TLS, the client indicates support for the new extension in the ClientHello message. The newly introduced extensions allow attestation Evidence or Attestation Results to be exchanged. Freshness of the exchanged Evidence is guaranteed through secret derivation from the TLS main secret and message transcript (see ) when the Background Check Model is in use. In the Passport Model, freshness expectations are more relaxed and are governed by the lifetime of the signed Attestation Results. When either the Evidence or the Attestation Results extension is successfully negotiated, attestation Evidence or Attestation Results are conveyed in an Attestation handshake message (see ). The CMW payload in the Attestation message contains the attestation Evidence or Attestation Results encoded according to . The attestation payload MUST contain assertions relating to the attester's TLS Identity Key (TIK-C for client attester, TIK-S for server attester), which associate the private key with the attestation information. The TEE's signature over the Evidence or AttestationResults within the CMW MUST include an attestation binder derived from the TLS main secret and the message transcript up to ServerHello (see ) and the attester's TLS identity public key, as specified in . The relying party can obtain and appraise the remote Attestation Results either directly from the Attestation message (in the Passport Model), or by relaying the Evidence from the Attestation message to the Verifier and receiving the Attestation Results. Subsequently, the attested key is used to verify the CertificateVerify message, which remains unchanged from baseline TLS. When using the Passport Model, the remote Attestation Results obtained by the attester from its trusted Verifiers can be cached and used for any number of subsequent TLS handshakes, as long as the freshness policy requirements are satisfied. In TLS a client has to demonstrate possession of the private key via the CertificateVerify message, when client-based authentication is requested. This behavior remains unchanged in the current protocol, with the CertificateVerify message proving possession of the TIK. This protocol supports both monolithic and split implementations. In a monolithic implementation, the TLS stack is completely embedded within the TEE. In a split implementation, the TLS stack is located outside the TEE, but any private keys (and in particular, the TIK) only exist within the TEE. In order to support both options, only the TIK's identity, its public component and a short generated binder are ever passed between the Client or Server TLS stack and its Attestation Service. While the two types of implementations offer identical functionality, their security properties often differ, see for more details.

Attestation Handshake Message When attestation is negotiated via the extensions defined in this document, attestation Evidence or Attestation Results are conveyed in a new handshake message type: Attestation. This message carries a CMW (Conceptual Message Wrapper) payload as defined in . The Attestation message structure is defined as follows:

Attestation Handshake Message Structure. ; } Attestation; ]]>

The cmw_payload field contains a CMW structure as defined in . Both JSON and CBOR serializations are allowed in CMW, with the emitter choosing which serialization to use. The CMW payload MUST contain attestation Evidence (in Background Check Model) or Attestation Results (in Passport Model) that binds the TLS Identity Key (TIK) to the platform and workload state. The TEE's signature over the Evidence or AttestationResults within the CMW MUST include:

• A binder derived from the TLS main secret and the message transcript, up to ServerHello, ensuring freshness of the attestation.
• The attester's TLS identity public key (TIK-C for client attester, TIK-S for server attester)

This binding ensures that the attested key is the one used in the TLS handshake and provides freshness guarantees through secret derivation. See for details.

Use of Attestation in the TLS Handshake For both the Passport Model (described in section 5.1 of ) and Background Check Model (described in Section 5.2 of ) the following modes of operation are allowed when used with TLS, namely:

• TLS client is the attester,
• TLS server is the attester, and
• TLS client and server mutually attest towards each other.

We will show the message exchanges of the first two cases in sub-sections below. Mutual authentication via attestation combines these two (non-interfering) flows, including cases where one of the peers uses the Passport Model for its attestation, and the other uses the Background Check Model.

Handshake Overview The handshake defined here is analogous to certificate-based authentication in a regular TLS handshake. The peer being attested first proves possession of the private key using the CertificateVerify message, which remains unchanged from baseline TLS. Following that, the TLS Identity Key (TIK) is bound by the TEE to the attestation credential being carried in a new Attestation handshake message (see ). The attestation Evidence or Attestation Results are conveyed in an Attestation handshake message (see ), which carries a CMW payload as defined in .

TLS Client Authenticating Using Evidence In this use case, the TLS server (acting as a relying party) challenges the TLS client (as the attester) to provide Evidence. A session-specific value is derived (see ) which incorporates randomness from both client and server, and this value is fed into the generation of the Evidence. The client sends the Evidence in an Attestation handshake message after the CertificateVerify message. The TLS server, when receiving the Evidence, will have to contact the Verifier (which is not shown in the diagram). An example of this flow can be found in device onboarding where the client initiates the communication with cloud infrastructure to get credentials, firmware and other configuration data provisioned to the device. For the server to consider the device genuine it needs to present Evidence.

TLS Client Providing Evidence to TLS Server. ServerHello ^ Key + key_share* | Exch v {EncryptedExtensions} ^ Server + evidence_proposal | Params {CertificateRequest} v {Certificate} ^ {CertificateVerify} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate} Auth | {CertificateVerify} | {Attestation} v {Finished} --------> [Application Data] <-------> [Application Data] ]]>

TLS Server Authenticating Using Evidence In this use case the TLS client challenges the TLS server to present Evidence. The TLS server acts as an attester while the TLS client is the relying party. The server sends the Evidence in an Attestation handshake message after the CertificateVerify message. The TLS client, when receiving the Evidence, will have to contact the Verifier (which is not shown in the diagram). An example of this flow can be found in confidential computing where a compute workload is only submitted to the server infrastructure once the client/user is assured that the confidential computing platform is genuine.

TLS Server Providing Evidence to TLS Client. ServerHello ^ Key + key_share* | Exch v {EncryptedExtensions} ^ Server + evidence_request | Params {CertificateRequest} v {Certificate} ^ {CertificateVerify} | {Attestation} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate} Auth | {CertificateVerify} v {Finished} --------> [Application Data] <-------> [Application Data] ]]>

TLS Client Authenticating Using Attestation Results In this use case the TLS client, as the attester, provides Attestation Results to the TLS server. The TLS client is the attester and the TLS server acts as a relying party. Prior to delivering its Certificate message, the client must contact the Verifier (not shown in the diagram) to receive the Attestation Results that it will use as credentials. The client sends the Attestation Results in an Attestation handshake message after the CertificateVerify message.

TLS Client Providing Results to TLS Server. ServerHello ^ Key + key_share* | Exch v {EncryptedExtensions} ^ Server + results_proposal | Params {CertificateRequest} v {Certificate} ^ {CertificateVerify} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate} Auth | {CertificateVerify} | {Attestation} v {Finished} --------> [Application Data] <-------> [Application Data] ]]>

TLS Server Authenticating Using Attestation Results In this use case the TLS client, as the relying party, requests Attestation Results from the TLS server. Prior to delivering its Certificate message, the server must contact the Verifier (not shown in the diagram) to receive the Attestation Results that it will use as credentials. The server sends the Attestation Results in an Attestation handshake message after the CertificateVerify message.

TLS Server Providing Attestation Results to TLS Client. ServerHello ^ Key + key_share* | Exch v {EncryptedExtensions} ^ Server + results_request | Params {CertificateRequest} v {Certificate} ^ {CertificateVerify} | {Attestation} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate} Auth | {CertificateVerify} v {Finished} --------> [Application Data] <-------> [Application Data] ]]>

Cryptographic Operations This section defines the key derivation for attestation, which operates independently from the regular TLS key schedule as described in . The attestation key derivation uses HKDF to derive attestation-specific secrets from the TLS main secret. Two attestation main secrets are derived: one for the client (c_attest_main) and one for the server (s_attest_main). The key derivation follows this structure:

Attestation Key Schedule. HKDF-Extract = Handshake Secret | v Derive-Secret(., "derived", "") | v 0 ---> HKDF-Extract = Main Secret | +-----> Derive-Secret(., "c attestation main", | ClientHello...ServerHello) | = c_attest_main | +-----> Derive-Secret(., "s attestation main", ClientHello...ServerHello) = s_attest_main ]]>

The attestation main secrets (c_attest_main and s_attest_main) are derived from the TLS main secret using Derive-Secret as defined in , with the labels "c attestation main" and "s attestation main" respectively, and the handshake transcript up to and including ServerHello as the context. The client's attestation binder (c_attest_binder) that will be signed by the TEE is derived by applying HKDF-Expand-Label to c_attest_main with the label "attestation" and the client's TLS public key as the context: Similarly, the server's attestation binder (s_attest_binder) is derived from s_attest_main: The attestation binder is derived independently by both the attester and the peer. The attester incorporates this attestation binder into the Evidence. Upon receipt of the Attestation handshake message, the peer will have to derive the expected attestation binder using the same inputs and verify that the computed attestation binder matches the one in the Evidence. If this verification fails, the peer will treat the attestation as invalid. This verification ensures that the Evidence is bound to the specific TLS session and TLS public key being attested.

Binding the TIK to the TEE This specification assumes that the TIK private key corresponding to the end-entity certificate used in the TLS handshake is generated inside a TEE and never leaves it. A platform could instead generate the TIK private key outside the TEE and compute the CertificateVerify signature using that external key. A relying party cannot detect this attack unless additional safeguards are in place. This risk is particularly relevant in split deployments, where the TLS stack does not reside inside the TEE. In such architectures, attesting the TEE alone does not prove that the TIK private key used by the TLS endpoint was generated, is stored, or is controlled by the TEE. To address this, the Evidence MUST include the TIK public key (TIK_pub). The relying party MUST verify that the TIK_pub included in the Evidence matches the public key presented in the TLS Certificate message. This binds the attestation Evidence to the TLS identity used for authentication. Without this binding, a non-TEE TLS endpoint can obtain Evidence from a separate TLS endpoint that genuinely runs inside a TEE and relay that Evidence to the relying party while executing the TLS handshake itself. If the Evidence only attests that a TLS stack is running in a TEE, the relying party cannot determine whether the attested TLS stack is the one that actually performed the handshake. Binding the Evidence to the TIK public key prevents this relay attack. The proposed binding ensures that the relying party does not establish a TLS session with a TLS endpoint whose TIK is not generated and controlled by the TEE. It does not attempt to protect the confidentiality of the TLS main secret in split deployments, where the TLS stack executes in the rich OS and remains susceptible to compromise.

The TLS Stack's Interface to the TEE When the TEE signs the Evidence or Attestation Results, it also binds them to the TLS Identity public key and the TLS session. TEE implementations differ, and some only allow a single user-provided challenge value to be added to the Evidence with no associated checks. Therefore we adopt a defense-in-depth approach:

• Separate attesting applications within the same TEE SHOULD NOT be capable of impersonating each other via Evidence or Attestation Results. Therefore, if multiple applications are expected to use attestation credentials, evidence/AR generation APIs SHOULD reflect identifiers for the calling contexts into the generated credential. These identifiers can be reflected as separate claims in the credential, or can be measured as part of more generic claims. A Relying Party SHOULD be capable of differentiating between the attesting applications based on their credentials.
• The RP SHOULD NOT base its trust decision only on the Attester's trust root. It SHOULD also ensure that the entire attested software stack is endorsed.
• The TEE itself, when possible, SHOULD generate the attestation secret by running the derivation operations defined in , and, if it holds the TIK, SHOULD validate the public key. The attestation secret can be generated by the TEE only if TLS is running inside the TEE.

DTLS Considerations The Attestation message MUST be handled using the existing DTLS handshake mechanisms for fragmentation, ordering, and retransmission to ensure reliable delivery. Note that Attestation messages typically exceed 1,500 bytes in size. This means that the message will be split into multiple DTLS records, increasing the latency of handshake completion. This is particularly the case over channels where reordering and loss are more common due to factors such as routing transients, intermittent connectivity or mobility. In DTLS, handshake messages that do not solicit a response are acknowledged using the DTLS ACK message. Because the Attestation handshake message does not elicit a response, the receiving peer MUST send a DTLS ACK upon receipt of the Attestation message. This ACK confirms only that the message was received; it does not indicate that attestation appraisal has completed. Once the attester receives the ACK, it MUST stop retransmitting the Attestation message. The receiving peer performs attestation appraisal asynchronously and applies its authorization policy once appraisal results become available.

After The Initial Handshake This section covers protocol behavior after the initial handshake, including session resumption, reattestation and the interaction between them.

Session Resumption TLS 1.3 supports session resumption using Pre-Shared Keys (PSK) as defined in . When using attestation, session resumption works normally when reattestation is not required. If client reattestation is required according to local policy (e.g., based on timing since the last attestation or changes in attestation state), session resumption MUST be rejected. The decision to reject resumption is per local policy and may depend on the timing of the resumption attempt relative to the required reattestation period. When resumption is rejected, the client MUST initiate a full handshake with attestation to obtain fresh attestation Evidence or Attestation Results. The rationale for rejecting resumption when reattestation is required is that attestation state may have changed since the original handshake, and fresh verification is needed to ensure the peer's platform and workload remain in a trustworthy state. If the client wishes to retain a long-running connection, it SHOULD perform reattestation periodically, as per local policy.

Reattestation Over time, attestation Evidence or Attestation Results may become stale and require refresh. Long-lived TLS connections require updated assurance that the peer continues to operate in a trustworthy state. This document therefore supports reattestation, in which either peer MAY request fresh Evidence at any time post-handshake. The attester MUST generate evidence using a freshly derived attestation_binder. Reattestation is tied to the completion of an Extended Key Update (EKU) exchange . TLS peers that require reattestation MUST support EKU, since reattestation depends on the key schedule update defined in the EKU draft. The first two messages of an EKU exchange introduce fresh key-exchange input and make Main Secret N+1 available to both peers. The Attestation message MUST be sent immediately before the attestor sends its EKU(new_key_update) message. Once Main Secret N+1 is available (after the first two EKU messages), the attester derives a new attestation_binder from Main Secret N+1, using the concatenation of the EKU request and response messages and its TLS identity public key as context. The receiving peer, however, MUST NOT process the Attestation until the EKU exchange and the authenticated transition step have completed. This ensures that attestation bound to Main Secret N+1 is accepted only after both peers have confirmed that they share the same updated key state. For a client attester: For a server attester: Including the EKU request and response messages ensures that the resulting attestation binder is bound to the specific EKU exchange and therefore reflects fresh key-exchange entropy introduced by EKU. After deriving the fresh attestation_binder, the attester:

1. generates fresh Evidence using the new attestation_binder and
2. sends a new Attestation handshake message containing the updated CMW payload.

The TLS peer validates the attestation by deriving and verifying the attestation binder as specified in . Reattestation uses the Attestation formats that were negotiated during the initial handshake, there is no re-negotiation at this stage. The decision to initiate reattestation is per local policy and may be based on factors such as elapsed time since the last attestation, changes in platform state, or security policy requirements.

Negotiating This Protocol This section defines the TLS extensions used to negotiate the use of attestation in the TLS handshake. Two models are supported: the Background Check Model, where Evidence is exchanged and verified during the handshake, and the Passport Model, where pre-verified Evidence in the form of Attestation Results are presented. The extensions defined here allow peers to indicate their support for attestation and negotiate which attestation format and Verifier to use. Can we simplify this structure: remove the dual request/proposal, and unify the evidence+AR to a single negotiation extension. But also express Passport mode with and without freshness.

Evidence Extensions (Background Check Model) The EvidenceType structure contains an indicator for the type of Evidence expected in the Attestation handshake message. The Evidence contained in the CMW payload is sent in the Attestation handshake message (see ).

TLS Extension Structure for Evidence. ; }; } EvidenceType; struct { select(Handshake.msg_type) { case client_hello: EvidenceType supported_evidence_types<1..2^8-1>; case server_hello: case encrypted_extensions: EvidenceType selected_evidence_type; } } evidenceRequestTypeExtension; struct { select(Handshake.msg_type) { case client_hello: EvidenceType supported_evidence_types<1..2^8-1>; case server_hello: case encrypted_extensions: EvidenceType selected_evidence_type; } } evidenceProposalTypeExtension; ]]>

Values for media_type are defined in . Values for content_format are defined in .

Attestation Results Extensions (Passport Model)

TLS Extension Structure for Attestation Results. ; } VerifierIdentityType; struct { select(Handshake.msg_type) { case client_hello: VerifierIdentityType trusted_verifiers<1..2^8-1>; case server_hello: case encrypted_extensions: VerifierIdentityType selected_verifier; } } resultsRequestTypeExtension; struct { select(Handshake.msg_type) { case client_hello: VerifierIdentityType trusted_verifiers<1..2^8-1>; case server_hello: case encrypted_extensions: VerifierIdentityType selected_verifier; } } resultsProposalTypeExtension; ]]>

In the Passport Model, Attestation Results are sent in an Attestation handshake message (see ) containing a CMW structure. The CMW structure is defined in .

TLS Client and Server Handshake Behavior The high-level message exchange in shows the evidence_proposal, evidence_request, results_proposal, and results_request extensions added to the ClientHello and the EncryptedExtensions messages.

Attestation Message Overview. ServerHello ^ Key + key_share* | Exch + pre_shared_key* v {EncryptedExtensions} ^ Server + evidence_proposal* | Params + evidence_request* | + results_proposal* | + results_request* | {CertificateRequest*} v {Certificate*} ^ {CertificateVerify*} | {Attestation*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} | {Attestation*} v {Finished} --------> [Application Data] <-------> [Application Data] ]]>

Background Check Model

Client Hello To indicate the support for passing Evidence in TLS following the Background Check Model, clients include the evidence_proposal and/or the evidence_request extensions in the ClientHello. The evidence_proposal extension in the ClientHello message indicates the Evidence types the client is able to provide to the server. The evidence_request extension in the ClientHello message indicates the Evidence types the client challenges the server to provide in an Attestation handshake message. The evidence_proposal and evidence_request extensions sent in the ClientHello each carry a list of supported Evidence types, sorted by preference. When the client supports only one Evidence type, it is a list containing a single element. The client MUST omit Evidence types from the evidence_proposal extension in the ClientHello if it cannot respond to a request from the server to present a proposed Evidence type, or if the client is not configured to use the proposed Evidence type with the given server. If the client has no Evidence types to send in the ClientHello it MUST omit the evidence_proposal extension in the ClientHello. The client MUST omit Evidence types from the evidence_request extension in the ClientHello if it is not able to pass the indicated verification type to a Verifier. If the client does not act as a relying party with regards to Evidence processing (as defined in the RATS architecture) then the client MUST omit the evidence_request extension from the ClientHello.

Server Hello If the server receives a ClientHello that contains the evidence_proposal extension and/or the evidence_request extension, then three outcomes are possible:

• The server does not support the extensions defined in this document. In this case, the server returns the EncryptedExtensions without the extensions defined in this document.
• The server supports the extensions defined in this document, but it does not have any Evidence type in common with the client. Then, the server terminates the session with a fatal alert of type "unsupported_evidence".
• The server supports the extensions defined in this document and has at least one Evidence type in common with the client. In this case, the processing rules described below are followed.

The evidence_proposal extension in the ClientHello indicates the Evidence types the client is able to provide to the server. If the server wants to request Evidence from the client, it MUST include the evidence_proposal extension in the EncryptedExtensions. This evidence_proposal extension in the EncryptedExtensions then indicates what Evidence format the client is requested to provide in an Attestation handshake message sent after the CertificateVerify message. The Evidence contained in the CMW payload MUST include a binder derived from the TLS main secret and the message transcript up to ServerHello (see ) in the TEE's signature, along with the client's TLS identity public key (TIK-C). The value conveyed in the evidence_proposal extension by the server MUST be selected from one of the values provided in the evidence_proposal extension sent in the ClientHello. If none of the Evidence types supported by the client (as indicated in the evidence_proposal extension in the ClientHello) match the server-supported Evidence types, then the evidence_proposal extension in the ServerHello MUST be omitted. The evidence_request extension in the ClientHello indicates what types of Evidence the client can challenge the server to return in an Attestation handshake message. With the evidence_request extension in the EncryptedExtensions, the server indicates the Evidence type carried in the Attestation handshake message sent after the CertificateVerify by the server. The Evidence contained in the CMW payload MUST include a binder derived from the TLS main secret and the message transcript up to ServerHello (see ) in the TEE's signature, along with the server's TLS identity public key (TIK-S). The Evidence type in the evidence_request extension MUST contain a single value selected from the evidence_request extension in the ClientHello.

Passport Model The results_proposal and results_request extensions are used to negotiate the protocol defined in this document, and in particular to negotiate the Verifier identities supported by each peer. These extensions are included in the ClientHello and ServerHello messages.

Client Hello To indicate the support for passing Attestation Results in TLS following the Passport Model, clients include the results_proposal and/or the results_request extensions in the ClientHello message. The results_proposal extension in the ClientHello message indicates the Verifier identities from which the client can relay Attestation Results. The client sends the Attestation Results in an Attestation handshake message after the CertificateVerify message. The results_request extension in the ClientHello message indicates the Verifier identities from which the client expects the server to provide Attestation Results in an Attestation handshake message sent after the CertificateVerify. The results_proposal and results_request extensions sent in the ClientHello each carry a list of supported Verifier identities, sorted by preference. When the client supports only one Verifier, it is a list containing a single element. The client MUST omit Verifier identities from the results_proposal extension in the ClientHello if it cannot respond to a request from the server to present Attestation Results from a proposed Verifier, or if the client is not configured to relay the Results from the proposed Verifier with the given server. If the client has no Verifier identities to send in the ClientHello it MUST omit the results_proposal extension in the ClientHello. The client MUST omit Verifier identities from the results_request extension in the ClientHello if it is not configured to trust Attestation Results issued by said verifiers. If the client does not act as a relying party with regards to the processing of Attestation Results (as defined in the RATS architecture) then the client MUST omit the results_request extension from the ClientHello.

Server Hello If the server receives a ClientHello that contains the results_proposal extension and/or the results_request extension, then three outcomes are possible:

• The server does not support the extensions defined in this document. In this case, the server returns the EncryptedExtensions without the extensions defined in this document.
• The server supports the extensions defined in this document, but it does not have any trusted Verifiers in common with the client. Then, the server terminates the session with a fatal alert of type "unsupported_verifiers".
• The server supports the extensions defined in this document and has at least one trusted Verifier in common with the client. In this case, the processing rules described below are followed.

The results_proposal extension in the ClientHello indicates the Verifier identities from which the client is able to provide Attestation Results to the server. If the server wants to request Attestation Results from the client, it MUST include the results_proposal extension in the EncryptedExtensions. This results_proposal extension in the EncryptedExtensions then indicates what Verifier the client is requested to provide Attestation Results from in an Attestation handshake message sent after the CertificateVerify message. The value conveyed in the results_proposal extension by the server MUST be selected from one of the values provided in the results_proposal extension sent in the ClientHello. If none of the Verifier identities proposed by the client (as indicated in the results_proposal extension in the ClientHello) match the server-trusted Verifiers, then the results_proposal extension in the ServerHello MUST be omitted. The results_request extension in the ClientHello indicates what Verifiers the client trusts as issuers of Attestation Results for the server. With the results_request extension in the EncryptedExtensions, the server indicates the identity of the Verifier who issued the Attestation Results carried in the Attestation handshake message sent after the CertificateVerify by the server. The Verifier identity in the results_request extension MUST contain a single value selected from the results_request extension in the ClientHello.

Security Considerations TBD.

Security Guarantees We note that as a pure cryptographic protocol, attested TLS as-is only guarantees that the Identity Key is known by the TEE. A number of additional guarantees must be provided by the platform and/or the TLS stack, and the overall security level depends on their existence and quality of assurance:

• The Identity Key is generated by the TEE.
• The Identity Key is never exported or leaked outside the TEE.
• The TLS protocol, whether implemented by the TEE or outside the TEE, is implemented correctly and (for example) does not leak any session key material.

These properties may be explicitly promised ("attested") by the platform, or they can be assured in other ways such as by providing source code, reproducible builds, formal verification etc. The exact mechanisms are out of scope of this document.

Freshness Guarantees TODO: Discuss freshness guarantees provided by secret derivation from the TLS main secret and message transcript. Differences between Background Check and Passport mode.

Security of Reattestation After Extended Key Update Reattestation relies on the assumption that both peers have derived the same Main Secret N+1 during the preceding EKU exchange. EKU by itself does not guarantee that the peers transitioned to a consistent key state in the presence of an active attacker. Deployments that require stronger guarantees will have use an authenticated transition mechanism discussed in (e.g., post-handshake client authentication or Exported Authenticators) to detect key-schedule divergence before relying on reattestation results.

Privacy Considerations In this section, we are assuming that the Attester is a TLS client, representing an individual person. We are concerned about the potential leakage of privacy sensitive information about that person, such as the correlation of different connections initiated by them. In background-check mode, the Verifier not only has access to detailed information about the Attester's TCB through Evidence, but it also knows the exact time and the party with whom the secure channel establishment is attempted (i.e., the RP). The privacy implications are similar to online OCSP . While the RP may trust the Verifier not to disclose any information it receives, the same cannot be assumed for the Attester, which generally has no prior relationship with the Verifier. Some ways to address this include:

• Client-side redaction of privacy-sensitive evidence claims,
• Using selective disclosure (e.g., SD-JWT with EAT ),
• Co-locating the Verifier role with the RP,
• Utilizing privacy-preserving attestation schemes (e.g., DAA ), or
• Utilizing Attesters manufactured with group identities (e.g., ).

The latter two also have the property of hiding the peer's identity from the RP. Note that the equivalent of OCSP "stapling" involves using a passport topology where the Verifier's involvement is unrelated to the TLS session. Due to the inherent asymmetry of the TLS protocol, if the Attester acts as the TLS server, a malicious TLS client could potentially retrieve sensitive information from attestation Evidence without the client's trustworthiness first being established by the server.

IANA Considerations

TLS Extensions IANA is asked to allocate four new TLS extensions, evidence_request, evidence_proposal, results_request, results_proposal, from the "TLS ExtensionType Values" subregistry of the "Transport Layer Security (TLS) Extensions" registry . These extensions are used in the ClientHello and the EncryptedExtensions messages. The values carried in these extensions are taken from TBD.

TLS Alerts IANA is requested to allocate a value in the "TLS Alerts" subregistry of the "Transport Layer Security (TLS) Parameters" registry and populate it with the following entries:

• Value: TBD1
• Description: unsupported_evidence
• DTLS-OK: Y
• Reference: [This document]
• Comment:
• Value: TBD2
• Description: unsupported_verifiers
• DTLS-OK: Y
• Reference: [This document]
• Comment:

TLS Handshake Message Types IANA is requested to allocate a new value in the "TLS HandshakeType" registry of the "Transport Layer Security (TLS) Parameters" registry , as follows:

• Value: TBD
• Description: attestation
• DTLS-OK: Y
• Reference: [This document]
• Comment: Used to carry attestation Evidence or Attestation Results in the TLS handshake

Acknowledgements We would like to thank Paul Howard, Arto Niemi, and Hannes Tschofenig for their contributions to earlier versions of this document.

References Normative References Independent This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. Fraunhofer SIT Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Siemens Münster Univ. of Applied Sciences Nokia Siemens Zscaler TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post-compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh Diffie-Hellman exchange within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. Apple, Inc. Google LLC Apple, Inc. Apple, Inc. The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. Informative References This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Intuit Arm Limited Arm Limited Arm Limited Huawei Linaro The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using attestation which is a process by which an entity produces evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enables the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and mutually. Security Theory LLC Mediatek USA Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. Fraunhofer SIT University of Surrey University of Surrey Ubitech Microsoft This document maps the concept of Direct Anonymous Attestation (DAA) to the Remote Attestation Procedures (RATS) Architecture. The protocol entity DAA Issuer is introduced and its mapping with existing RATS roles in DAA protocol steps is specified. Authlete Keio University Ping Identity This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. Broadcom Arm Limited Microsoft Amazon A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE. Trusted Computing Group Trusted Computing Group IANA IANA IANA IANA This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. Trusted Computing Group

Document History

draft-fossati-seat-early-attestation-00 Initial version of draft-fossati-seat-early-attestation. This version represents a major architectural change from . The key changes include:

• Removed certificate extension mechanism for conveying attestation Evidence
• Introduced new Attestation handshake message for carrying CMW (Conceptual Message Wrapper) payload
• Attestation message sent after CertificateVerify when server is attester
• Attestation message sent after CertificateVerify message when client is attester
• Removed use cases section
• Removed KAT (Key Attestation Token) and PAT (Platform Attestation Token) references, using CMW directly
• Nonces (client and server) and attester's TLS identity public key are included in TEE-signed Evidence/AttestationResults within CMW
• CertificateVerify remains unchanged from baseline TLS (no proof-of-possession needed)
• Added session resumption discussion (resumption MUST be rejected if reattestation is required per local policy)
• Added reattestation

Design Rationale This appendix explains the rationale for introducing a dedicated Attestation handshake message, instead of embedding attestation in an extension inside the TLS Certificate message. That approach fails to meet key security, and privacy requirements.

Requires Certificate Authentication TLS 1.3 supports authentication modes where no Certificate message is sent:

• PSK-based authentication
• PAKE-based authentication

A design that relies on a Certificate message extension cannot operate in these cases. In contrast, a dedicated Attestation handshake message works regardless of authentication mode, making it compatible with the full TLS authentication spectrum.

Reattestation Not Fully Supported TLS allows Post-Handshake client authentication but provides no mechanism for Post-Handshake server authentication. As a result, a design that embeds attestation inside the Certificate message would allow only the client and not the server to refresh its attestation. This is insufficient for deployments that require periodic server reattestation.