]> Arm Limited

hannes.tschofenig@arm.com

Arm Limited

Thomas.Fossati@arm.com

Arm Limited

Paul.Howard@arm.com

Arm Limited

Ionut.Mihalcea@arm.com

Arm Limited

Yogesh.Deshpande@arm.com

Security TLS attestation RATS TLS Attestation is the process by which an entity produces evidence about itself that another party can use to evaluate the trustworthiness of that entity. In use cases that require the use of remote attestation, such as confidential computing or device onboarding, an attester has to convey evidence or attestation results to a relying party. This information exchange may happen at different layers in the protocol stack. This specification provides a generic way of passing evidence and attestation results in the TLS handshake. Functionality-wise this is accomplished with the help of key attestation.

Introduction The Remote ATtestation ProcedureS (RATS) architecture defines two basic types of topological patterns to communicate between an attester, a relying party, and a verifier, namely the background-check model and the passport model. These two models are fundamentally different and require a different treatment when incorporated into the TLS handshake. For better readability to use different extensions for these two models. The two models can be summarized as follows:

• In the background check model, the attester conveys evidence to the relying party, which then forwards the evidence to the verifier for appraisal; the verifier computes the attestation result and sends it back to the relying party.
• In the passport model, the attester transmits evidence to the verifier directly and receives attestation results, which are then relayed to the relying party. This specification supports both patterns.

Several formats for encoding evidence are available, such as - the Entity Attestation Token (EAT) , - the Trusted Platform Modules (TPMs) , - the Android Key Attestation, and - Apple Key Attestation. Like-wise, there are different encodings available for attestation results. One such encoding, AR4SI is being standardized by the RATS working group. This version of the specification defines how to support the background check model in the TLS handshake, such that the details about the attestation technology are agnostic to the TLS handshake itself. Later versions of the specification will support the passport model as well. To give the peer information that the handshake signing key is properly secured, the associated evidence has to be verified by that peer. Hence, attestation evidence about the security state of the signing key is needed, which is typically associated with evidence about the overall platform state. The platform attestation service ensures that the key attestation service has not been tampered with. The platform attestation service issues the Platform Attestation Token (PAT) and the key attestation service issues the Key Attestation Token (KAT). The security of the protocol critically depends on the verifiable binding between these two logically separate units of evidence. This document does not define how different attestation technologies are encoded. This has either already been done is done accomplished by companion specifications.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .

Overview The Remote Attestation Procedures (RATS) architecture defines two types of interaction models for attestation, namely the passport model and the background check model. The subsections below explain the difference in their interactions. As typical with new features in TLS, the client indicates support for the new extension in the ClientHello. The newly introduced extensions allow evidence and nonces to be exchanged. The nonces are used for guaranteeing freshness of the exchanged evidence. When the evidence extension is successfully negotiated, the content of the Certificate message contains a payload that is encoded based on the wrapper defined in . In TLS a client has to demonstrate possession of the private key via the CertificateVerify message, when client-based authentication is requested. The attestation payload must contain a key attestation token, which associates a private key with the attestation information. An example of a key attestation token format utilizing the EAT-format can be found in . The recipient extracts evidence from the Certificate message and relays it to the verifier to obtain attestation results. Subsequently, the attested key is used to verify the CertificateVerify message.

Use of Evidence with the Background Check Model The background check model is described in Section 5.2 of and allows the following modes of operation when used with TLS, namely

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

We will show the message exchanges of the three cases in sub-sections below.

TLS Client as Attester In this use case the TLS client, as the attester, is challenged by the TLS server to provide evidence. The TLS client is the attester and the the TLS server acts as a relying party. The TLS server needs to provide a nonce in the EncryptedExtensions 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 as Attester 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 ensured that the confidential computing platform is genuine.

TLS Client Providing Evidence to TLS Server.                                                   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] ]]>

Evidence Extension (Background Check Model) This document defines two new extensions, the evidence_request and the evidence_proposal, for use with the background check model. The EvidenceType structure encodes either a media type or as a content format. The media type is a string-based identifier while the content format uses a number. The former is more flexible and does not necessarily require a registration through IANA while the latter is more efficient over-the-wire.

TLS Structure for Evidence. ; }; } EvidenceType; struct { select(ClientOrServerExtension) { case client: EvidenceType supported_evidence_types<1..2^8-1>; opaque nonce<0..2^8-1>; case server: EvidenceType selected_evidence_type; } } evidenceRequestTypeExtension; struct { select(ClientOrServerExtension) { case client: EvidenceType supported_evidence_types<1..2^8-1>; case server: EvidenceType selected_evidence_type; opaque nonce<0..2^8-1>; } } evidenceProposalTypeExtension; ]]>

The Certificate payload is used as a container, as shown in , and follows the model of .

Certificate Message. ; /* payload used to convey evidence */ case attestation: opaque evidence<1..2^24-1>; case X509: opaque cert_data<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 .

TLS Client and Server Handshake Behavior The high-level message exchange in shows the evidence_proposal and evidence_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 | {CertificateRequest*} v Params {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data] ]]>

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 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 indicates the types of 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 cient is not configured to use the proposed evidence type with the given server. If the client has no evidenence 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 extension defined in this document. In this case, the server returns the EncryptedExtensions without the extensions defined in this document.
• The server supports the extension 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 certificate_request message. If the server wants to request evidence from the client, it MUST include the client_attestation_type 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 certificate_request message. If the server does not send a certificate_request 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.

Background-Check Model Examples

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, etc. In such scenarios, the users (e.g., the party providing the data input for the computation, the consumer of the computed results, 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 kinds of evidence 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 the local API to request the attestation. The returned evidence binds the identity key with the platform identity and security state. The server then signs the handshake transcript with the (attested) identity key, and sends the attestation evidence together with the signature over to the client. The client forwards the attestation evidence to the verifier using the previously established session, obtains the attestation result and checks 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) | | | | | | ) | | | | | +----------------------->| | | | | | ServerHello | | | | | | {...} | | | | | | EncryptedExtensions | | | | | | {...} | | | | | | evidence_request( | | | | | | type(a) | | | | | | ) | | | | | |<-----------------------+ | | | | | | attest_key( | | | | | | nonce, | | | | | | TIK | | | | | | ) | | | | | +-------------->| | | | | | CAB(KAT, PAT) | | | | | |<--------------+ | | | | | sign(TIK,hs) | | | | | +-------------->| | | | | | sig | | | | | |<--------------+ | | | | Certificate(KAT,PAT) | | | | | | 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 example, an IoT is onboarded to a cloud service provider (or to a network operator). In this scenario there is typically no a-priori relationship between the device and the cloud service provider that will remote manage the device. In such scenario, the cloud service provider wants to make sure that the device runs the correct version of firmware, has not been rooted, is 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 with the workload and platform identity and security state. The client then signs the handshake transcript 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 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 | | | | | attest_key( | CertificateVerify | | | | | nonce, | Finished | | | | | TIK |<-----------------------+ | | | | ) | | | | | |<---------------+ | | | | | CAB(KAT, PAT) | | | | | +--------------->| | | | | | sign(TIK,hs) | | | | | |<---------------+ | | | | | sig | | | | | +--------------->| Certificate(KAT,PAT) | | | | | | CertificateVerify(sig) | | | | | | Finished | | | | | +----------------------->| | | | | | | | | | | | | POST /76839A9E | | | | | | Body: { | | | | | | type(a), | | | | | | CAB | | | | | | } | | | | | +------------------>| | | | | | Body: { | | | | | | att-result: AR{} | | | | | | } | | | | | |<------------------+ | | | | +---. | | | | | | | verify AR{} | | | | | |<--' | | | | | +---. | | | | | | | verify sig | | | | | |<--' | | | | | | | | | | | | | | | | | | | | | | | | | | '--+----------------+------------------------+-------------------+---' | application data | |<---------------------->| | | ]]>

Security Considerations TBD.

IANA Considerations

TLS Extensions IANA is asked to allocate two new TLS extensions, evidence_request and evidence_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 entry:

• Value: TBD
• Description: unsupported_evidence
• 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 Intel arm arm This document defines two encapsulation formats for RATS conceptual messages (i.e., evidence, attestation results, endorsements and reference values.) The first format uses a CBOR or JSON array with two members: one for the type, another for the value. The other format wraps the value in a CBOR byte string and prepends a CBOR tag to convey the type information. arm arm arm This document defines an evidence format for key attestation based on the Entity Attestation Token (EAT) format. 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. Informative References Security Theory LLC Qualcomm Technologies Inc. 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 how much it wishes to trust the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. Trusted Computing Group Trusted Computing Group Fraunhofer SIT Microsoft Sandelman Software Works Intel Corporation Huawei Technologies 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. An attempt is made to provide for a model that is neutral toward processor architectures, the content of claims, and protocols. Internet Assigned Numbers Authority Internet Assigned Numbers Authority Cisco Systems Fraunhofer SIT MIT Arm Limited Intel This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party.

History RFC EDITOR: PLEASE REMOVE THE THIS SECTION

draft-fossati-tls-attestation-02

• Focus on the background check model
• Added examples
• Updated introduction
• Moved attestation format-specific content to related drafts.

draft-fossati-tls-attestation-01

• Added details about TPM attestation

draft-fossati-tls-attestation-00

• Initial version

Working Group Information The discussion list for the IETF TLS working group is located at the e-mail address tls@ietf.org. Information on the group and information on how to subscribe to the list is at https://www1.ietf.org/mailman/listinfo/tls Archives of the list can be found at: https://www.ietf.org/mail-archive/web/tls/current/index.html