]>

hannes.tschofenig@gmx.net

Intuit

yaronf.ietf@gmail.com

Arm Limited

Paul.Howard@arm.com

Arm Limited

Ionut.Mihalcea@arm.com

Arm Limited

Yogesh.Deshpande@arm.com

Huawei

arto.niemi@huawei.com

Linaro

thomas.fossati@linaro.org

Security TLS attestation RATS TLS This draft has been withdrawn. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction This draft has been withdrawn. Attestation 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 enables the binding of the TLS authentication key to a remote attestation session. As a result, a peer can use "attestation credentials", consisting of compound platform evidence and key attestation, to authenticate itself to its peer during the setup of the TLS channel. 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 of the attestation formats. This is achieved by reusing the generic encapsulation defined in for transporting evidence and attestation result payloads in the TLS Certificate message. This specification provides both one-way (server-only) and mutual (client and server) authentication using attestation credentials, 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 . In addition, the design supports two ways of identifying the peer: a mode that combines normal X.509 certificate authentication with platform attestation, as well as an attestation-only mode. This document does not mandate any particular attestation technology. Companion documents are expected to define specific attestation mechanisms.

Conventions and Terminology The reader is assumed to be familiar with the vocabulary and concepts defined in , and those 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, see for details.

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.

The term "remote attestation credentials", or "attestation credentials", is used to refer to both attestation evidence and attestation results, when no distinction needs to be made between them. 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. Throughout the document, we will assume the conceptual attester model described in , where TEE attestation is provided by a Platform Attestation Token (PAT) signed by the attester's "attesting environment". Among other security metrics, the PAT contains evidence about the integrity of a "Key Attestation Service" executing within the TEE which issues a Key Attestation Token (KAT) for the TLS handshake signing key (TIK) as described in . The protocol's security relies on the verifiable binding between these two logically separate units of evidence.

Authentication vs. Attestation As noted, the protocol supports either combined platform attestation with X.509 certificate authentication, or attestation only. 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 only use the combined mode, which provides the full security guarantees of an authenticated TLS handshake (for the peer/peers being authenticated) as well as guarantees of platform integrity. The attestation-only mode is included in this document for specialized use cases, including initial provisioning of the TLS stack. In these cases, additional security controls SHOULD be provided, such as hardware-enforced time limitations, or use of platform-level APIs in the case of cloud infrastructure.

TLS Identity Key (TIK) A central property of this protocol is that it binds a peer's identity key, the TIK, to the TLS handshake. This applies to the client's identity (TIK-C), the server's identity (TIK-S) or both. In the standard mode that combines attestation with certificate authentication, the TIK MUST be the X.509 certificate's end entity key. The TIK is maintained and protected by the TEE, and this fact is attested. In the attestation-only mode, the TIK is generated and maintained by the TEE and MUST be used only for TLS handshakes. We RECOMMEND that the TIK be persistent within the TEE. When this is the case, the TIK may be used by (specialized) applications to provide continuity of identity between TLS sessions with the same peer.

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 remote attestation credentials and nonces to be exchanged. The nonces are used for guaranteeing freshness of the exchanged evidence when the background check model is in use. Nonces are not used in the passport model, because the expectation of freshness is more relaxed and is only governed by the lifetime of the signed attestation results. When either the Evidence or the Attestation Results extension is successfully negotiated, the content of the corresponding Certificate message contains a payload that is encoded based on the wrapper defined in . Both JSON and CBOR serializations are allowed in CMW, with the emitter choosing which serialization to use. The attestation payload MUST contain assertions relating to the client's TLS Identity Key (TIK-C), which associate the private key with the attestation information. These assertions may come in the form of a Key Attestation Token (KAT), or of specific claims in an attestation result document. An example of a KAT format utilizing the EAT format can be found in . The relying party can obtain and appraise the remote attestation results either directly from the Certificate message (in the passport model), or by relaying the evidence from the Certificate message to the verifier and receiving the attestation results. Subsequently, the attested key is used to verify the CertificateVerify message. 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 and its public component 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.

Use of Remote Attestation Credentials 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. We use the TLS Identity Key (TIK) which is either a stand-alone key or is identical to the certificate's private key (see ). This key is attested, with attestation being carried in the Certificate message. Following that, the peer being attested proves possession of the private key using the CertificateVerify message. Depending on the use case, the protocol supports peer authentication using attestation only, or using both attestation and a regular public key certificate. The current version of the document assumes the KAT/PAT construct of . Not all platforms support this model, and a document that defines private key attestation for use in TLS Attestation as defined here, must specify how the key is attested using a structure carried by the Certificate message.

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. The TLS server needs to provide a nonce in the EncryptedExtensions message to the TLS client so that the attestation service can feed the nonce into the generation of the evidence. 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 (nonce) | {CertificateRequest}  v                                                   {Certificate}  ^                                           {CertificateVerify}  | Auth                                                    {Finished}  v                                <--------  [Application Data*]      ^ {Certificate} Auth | {CertificateVerify}      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 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}  | 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.

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}      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.

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

Evidence Extensions (Background Check Model) The EvidenceType structure contains an indicator for the type of credential expected in the Certificate message. The credential can either contain attestation evidence alone, or an X.509 certificate alongside attestation evidence.

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

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

Attestation-only When the chosen evidence type indicates the sole use of attestation for authentication, the Certificate payload is used as a container for attestation evidence, as shown in , and follows the model of .

Certificate Message when using only attestation. ; case X509: opaque cert_data<1..2^24-1>; case attestation: /* payload used to convey evidence */ opaque evidence<1..2^24-1>; }; Extension extensions<0..2^16-1>; } CertificateEntry; struct { opaque certificate_request_context<0..2^8-1>; CertificateEntry certificate_list<0..2^24-1>; } Certificate; ]]>

The encoding of the evidence structure is defined in . When using the Key Attestation Token defined in , the evidence structure consists of the KAT and PAT bundle defined there, and the CMW collection MUST NOT contain any other elements.

Attestation Alongside X.509 Certificates When the chosen evidence type indicates usage of both attestation and PKIX, the X.509 certificate will serve as the main payload in the Certificate message, while the attestation evidence will be carried in the CertificateEntry extension, as shown in .

Certificate Message when using PKIX and attestation. ; case X509: /* X.509 certificate conveyed as usual */ opaque cert_data<1..2^24-1>; }; /* attestation evidence conveyed as an extension, see below */ Extension extensions<0..2^16-1>; } CertificateEntry; struct { opaque certificate_request_context<0..2^8-1>; CertificateEntry certificate_list<0..2^24-1>; } Certificate; struct { ExtensionType extension_type; /* payload used to convey evidence */ opaque extension_data<0..2^16-1>; } Extension; enum { /* other extension types defined in the IANA TLS ExtensionType Value registry */ /* variant used to identify attestation evidence */ attestation_evidence(60), (65535) } ExtensionType; ]]>

The encoding of the evidence structure is defined in . When using the Key Attestation Token defined in , the evidence structure consists of the KAT and PAT bundle defined there, and the CMW collection MUST NOT contain any other elements.

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: VerifierIdentityType selected_verifier; } } resultsRequestTypeExtension; struct { select(Handshake.msg_type) { case client_hello: VerifierIdentityType trusted_verifiers<1..2^8-1>; case server_hello: VerifierIdentityType selected_verifier; } } resultsProposalTypeExtension; ]]>

In the Passport model, both attestation results and an indication of key attestation are sent in a CMW structure within the Certificate message. The exact contents of this structure is TBD.

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* | + evidence_request* | + results_proposal* | + results_request* | {CertificateRequest*} v Params {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} 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, when requested using a CertificateRequest message. The evidence_request extension in the ClientHello message indicates the evidence types the client challenges the server to provide in a subsequent Certificate payload. 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, when challenged using a CertificateRequest message. 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 a subsequent Certificate message. 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. The server MUST also send a CertificateRequest message. If the server does not send a CertificateRequest message or 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 a subsequent Certificate message. With the evidence_request extension in the EncryptedExtensions, the server indicates the evidence type carried in the Certificate message sent by the server. 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 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, when requested using a CertificateRequest 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 a subsequent Certificate payload. 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, when challenged using a CertificateRequest message. If the server wants to request evidence 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 a subsequent Certificate 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. The server MUST also send a CertificateRequest message. If the server does not send a CertificateRequest message or 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 Certificate message sent 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.

Example Use Cases This section includes specific usage scenarios of attested TLS. Both scenarios are based on the background-check validation model.

Cloud Confidential Computing In this example, a confidential workload is executed on computational resources hosted at a cloud service provider. This is a typical scenario for secure, privacy-preserving multiparty computation, including anti-money laundering, drug development in healthcare, contact tracing in pandemic times, Machine Learning (ML) model training, etc. In such scenarios, the users (e.g., the party providing the data input for the computation, the party consuming the computed results, or the party providing a proprietary ML model used in the computation) have two goals:

• Identifying the workload they are interacting with,
• Making sure that the platform on which the workload executes is a Trusted Execution Environment (TEE) with the expected features.

A convenient arrangement is to verify that the two requirements are met at the same time that the secure channel is established. The protocol flow, alongside all the involved actors, is captured in where the TLS client is the user (the relying party) while the TLS server is co-located with the TEE-hosted confidential workload (the attester). The flow starts with the client initiating a verification session with a trusted verifier. The verifier returns the evidence types it understands and a nonce that will be used to challenge the attester. The client starts the TLS handshake with the server by supplying the attestation-related parameters it has obtained from the verifier. If the server supports one of the offered evidence types, it will echo it in the specular extension and proceed by invoking a local API (represented by attest_key(...) in the figure below) to request attestation using the nonce supplied by the verifier. The returned evidence binds the identity key (TIK-S) with the platform identity and security state, packaged into a CAB. The server then signs a transcript hash with the (attested) identity key, and sends the attestation evidence and the signature in the Certificate and the CertificateVerify messages respectively. The transcript hash, denoted hs in the figure below, follows the Transcript-Hash definition from . The client forwards the attestation evidence to the verifier using the previously established session, obtains the attestation result (AR) and checks whether it is acceptable according to its local policy. If so, it proceeds and verifies the handshake signature using the corresponding public key (for example, using the PoP key in the KAT evidence ). The attestation evidence verification combined with the verification of the CertificateVerify signature provide confirmation that the presented cryptographic identity is bound to the workload and platform identity, and that the workload and platform are trustworthy. Therefore, after the handshake is finalized, the client can trust the workload on the other side of the established secure channel to provide the required confidential computing properties.

Example Exchange with Server as Attester. | | | | | | | .--+-----------. | | | | TLS handshake | | | | +--+------------+-------+------------------------+---------------+---. | | | ClientHello | | | | | | {...} | | | | | | evidence_request( | | | | | | nonce, | | | | | | types(a,b,c) | | | | | | ) | | | | | +----------------------->| | | | | | | attest_key( | | | | | | nonce, | | | | | | TIK-S-ID | | | | | | ) | | | | | +-------------->| | | | | | CAB(KAT, PAT) | | | | | |<--------------+ | | | | ServerHello | | | | | | {...} | | | | | | EncryptedExtensions | | | | | | {...} | | | | | | evidence_request( | | | | | | type(a) | | | | | | ) | | | | | | Certificate(KAT,PAT) | | | | | |<-----------------------+ | | | | | |sign(TIK-S-ID,hs) | | | | +-------------->| | | | | | sig | | | | | |<--------------+ | | | | CertificateVerify(sig) | | | | | | Finished | | | | | |<-----------------------+ | | | | POST /76839A9E | | | | | | Body: { | | | | | | type(a), | | | | | | CAB | | | | | | } | | | | | |<-------------------+ | | | | | Body: { | | | | | | att-result: AR{} | | | | | | } | | | | | +------------------->| | | | | | +---. | | | | | | | verify AR{} | | | | | |<--' | | | | | +---. | | | | | | | verify sig | | | | | |<--' | | | | | | Finished | | | | | +----------------------->| | | | | | | | | '-+--------------------+------------------------+---------------+---' | application data | |<---------------------->| | | ]]>

IoT Device Onboarding In this scenario, an IoT device is connected to a remote device management entity, which could be a cloud service provider or a network operator. We assume that, initially, the remote device management entity does not trust the device. The device management entity's responsibility is to guarantee that the device is running the intended software version, has not been tampered with, and is not being emulated or cloned. The protocol flow is shown in where the client is the attester while the server is the relying party. The flow starts with the client initiating a TLS exchange with the TLS server operated by the cloud service provider. The client indicates what evidence types it supports. The server obtains a nonce from the verifier, in real-time or from a reserved nonce range, and returns it to the client alongside the selected evidence type. Since the evidence will be returned in the Certificate message the server has to request mutual authentication via the CertificateRequest message. The client, when receiving the EncryptedExtension with the evidence_proposal, will proceed by invoking a local API to request the attestation. The returned evidence binds the identity key (TIK-C) with the workload and platform identity and security state, packaged into a CAB. The client then signs a transcript hash of the handshake context and the client's Certificate message with the (attested) identity key, and sends the evidence together with the signature over to the server. The server forwards the attestation evidence to the verifier, obtains the attestation result and checks that it is acceptable according to its local policy. The evidence verification combined with the verification of the CertificateVerify signature provide confirmation that the presented cryptographic identity is bound to the platform identity, and that the platform is trustworthy. If successful, the server proceeds with the application layer protocol exchange. If, for some reason, the attestation result is not satisfactory the TLS server will terminate the exchange.

Example Exchange with Client as Attester. | | | | | | | | | | + | ServerHello | POST /newSession | | | | | {...} +------------------>| | | | | | 201 Created | | | | | | Location: /76839 | | | | | | Body: { | | | | | | nonce, | | | | | EncryptedExtensions | types(a,b,c) | | | | | {...} | } | | | | | evidence_proposal( |<------------------+ | | | | nonce, | | | | | | type(a) | | | | | | ) | | | | | | CertificateRequest | | | | | | Certificate | | | | | | CertificateVerify | | | | | attest_key( | Finished | | | | | nonce, |<-----------------------+ | | | | TIK-C-ID | | | | | | ) | | | | | |<---------------+ | | | | | | | | | | | CAB(KAT, PAT) | | | | | +--------------->| Certificate(KAT,PAT) | | | | | +----------------------->| | | | |sign(TIK-C-ID,hs) | | | | |<---------------+ | | | | | sig | CertificateVerify(sig) | | | | +--------------->| Finished | | | | | +----------------------->| | | | | | | | | | | | | POST /76839A9E | | | | | | Body: { | | | | | | type(a), | | | | | | CAB | | | | | | } | | | | | +------------------>| | | | | | Body: { | | | | | | att-result: AR{} | | | | | | } | | | | | |<------------------+ | | | | +---. | | | | | | | verify AR{} | | | | | |<--' | | | | | +---. | | | | | | | verify sig | | | | | |<--' | | | | | | | | | | | | | | | | | | | | | | | | | | '--+----------------+------------------------+-------------------+---' | application data | |<---------------------->| | | ]]>

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.

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 Certificate Types IANA is requested to allocate a new value in the "TLS Certificate Types" subregistry of the "Transport Layer Security (TLS) Extensions" registry , as follows:

• Value: TBD2
• Description: Attestation
• Reference: [This document]

References Normative References 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. 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 and 6066, and obsoletes RFCs 5077, 5246, and 6961. 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. 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. 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. arm Linaro This document defines an evidence format for key attestation based on the Entity Attestation Token (EAT). Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-kat. 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. 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

Design Rationale: X.509 and Attestation Usage Variants The inclusion of attestation results and evidence as part of the TLS handshake offers the relying party information about the state of the system and its cryptographic keys, but lacks the means to specify a stable endpoint identifier. While it is possible to solve this problem by including an identifier as part of the attestation result, some use cases require the use of a public key infrastructure (PKI). It is therefore important to consider the possible approaches for conveying X.509 certificates and attestation within a single handshake. In general, the following combinations of X.509 and attestation usage are possible:

1. X.509 certificates only: In this case no attestation is exchanged in the TLS handshake. Authentication relies on PKI alone, i.e. TLS with X.509 certificates.
2. X.509 certificates containing attestation extension: The X.509 certificates in the Certificate message carry attestation as part of the X.509 certificate extensions. Several proposals exist that enable this functionality:
   • Custom X.509 extension:
     • Attester-issued certificates (e.g., RA-TLS ): The attester acts as a certification authority (CA) and includes the attestation evidence within an X.509 extension.
     • DICE defines extensions that include attestation information in the "Embedded CA" certificates (See Section 8.1.1.1 of ).
     • Third party CA-issued certificates (e.g., ACME Device Attestation ): Remote attestation is performed between the third party CA and the attester prior to certificate issuance, after which the CA adds an extension indicating that the certificate key has fulfilled some verification policy.
   • Explicit signaling via existing methods, e.g. using a policy OID in the end-entity certificate.
   • Implicit signaling, e.g. via the issuer name.
3. X.509 certificates alongside a PAT: This use case assumes that a keypair with a corresponding certificate already exists and that the owner wishes to continue using it. As a consequence, there is no cryptographic linkage between the certificate and the PAT. This approach is described in .
4. X.509 certificates alongside the PAT and KAT: The addition of key attestation implies that the TLS identity key must have been generated and stored securely by the attested platform. Unlike in variant (3), the certificate, the KAT, and the PAT must be cryptographically linked. This variant is currently not addressed in this document.
5. Combined PAT/KAT: With this variant the attestation token carries information pertaining to both platform and key. No X.509 certificate is transmitted during the handshake. This approach is currently not addressed in this document.
6. PAT alongside KAT: This variant is similar to (5) with the exception that the key and the platform attestations are stored in separate tokens, cryptographically linked together. This approach is covered by this document in . A possible instantiation of the KAT is described in .