]> Linaro

thomas.fossati@linaro.org

TU Dresden

muhammad_usama.sardar@tu-dresden.de

Intuit

yaronf.ietf@gmail.com

University of Applied Sciences Bonn-Rhein-Sieg

Germany Hannes.Tschofenig@gmx.net

Arm Limited

ionut.mihalcea@arm.com

Attestation TLS Key Attestation Exported Authenticators This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in RFC 9261. This approach falls into the category of post-handshake attestation by exchanging payloads in the application layer protocol while binding the remote attestation to the underlying communication channel. This document supports both the passport and background check models from the RATS architecture. 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 tls Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction There is a growing need to demonstrate to a remote party that cryptographic keys are stored in a secure element, the device is in a known good state, secure boot has been enabled, and that low-level software and firmware have not been tampered with. Remote attestation provides this capability. More technically, an Attester produces a signed collection of Claims that constitute Evidence about its running environment(s). A Relying Party may consult an Attestation Result produced by a Verifier that has appraised the Evidence to make policy decisions regarding the trustworthiness of the Target Environment being assessed. This is, in essence, what RFC 9334 defines. At the time of writing, several standard and proprietary remote attestation technologies are in use. This specification aims to remain as technology-agnostic as possible concerning implemented remote attestation technologies. As a result, this document focuses on the conveyance of Evidence and Attestation Results as part of the payloads defined by Exported Authenticators. The end-entity certificate is associated with key material that serves as an Attestation Key, which acts as Evidence originating from the Attester. This document builds upon three foundational specifications:

• RATS (Remote Attestation Procedures) Architecture : RFC 9334 defines how remote attestation systems establish trust between parties by exchanging Evidence and Attestation Results. These interactions can follow different models, such as the passport or the background check model, depending on the order of data flow in the system.
• TLS Exported Authenticators : RFC 9261 offers bi-directional, post-handshake authentication. Once a TLS connection is established, both peers can send an authenticator request message at any point after the handshake. This message from the server and the client uses the CertificateRequest and the ClientCertificateRequest messages, respectively. The peer receiving the authenticator request message can respond with an Authenticator consisting of Certificate, CertificateVerify, and Finished messages. These messages can then be validated by the other peer.
• RATS Conceptual Messages Wrapper (CMW) : CMW provides a convenient encapsulation of Evidence and Attestation Result payloads thereby provide an abstraction of the utilized attestation technology. This specification reuses exported authenticators to carry Evidence and/or Attestation Results wrapped via the CMW. While exported authenticators traditionally deal with certificates, in this document, we use them for key attestation. Consequently, this mechanism applies specifically to remote attestation technologies that offer key attestation, though the encoding format is not restricted to X.509 certificates.

Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals as shown here. The reader is assumed to be familiar with the vocabulary and concepts defined in RFC 9334 and RFC 9261. We use the term REMOTE_ATTESTATION payload to refer to the opaque token generated by the TLS Exported Authenticator implementation. The content is opaque to the application layer protocol but, of course, not to the TLS Exported Authenticator implementation.

Architecture Designers of application layer protocols need to define payload formats for conveying exported authenticators that contain remote Evidence. They must also provide mechanisms to inform both communication partners of their ability to exchange Evidence and Attestation Results via this specification. This capability can be specified in a profile of this document or dynamically negotiated during protocol exchanges. A future version of this specification will provide more details. The Exported Authenticator API defined in RFC 9261 accepts a request, a set of certificates, and supporting information as input. The output is an opaque token that serves as the REMOTE_ATTESTATION payload. Upon receipt of a REMOTE_ATTESTATION payload, an endpoint that supports "secondary certificates" MUST take the following steps to validate the contained token:

• Use the get context API to retrieve the certificate_request_context that was used to generate the authenticator (if any). Since the certificate_request_context for spontaneous server certificates is chosen by the server, its usage is implementation-dependent (see for more details).
• Use the validate API to confirm the authenticator's validity with respect to the generated request (if any). If validation fails, this SHOULD be treated as a connection error. Upon successful validation, the endpoint can conduct further checks to ensure the certificate's acceptability.

In the following examples, the server possesses an identity certificate, while the client is not authenticated during the initial TLS exchange. shows the passport model while illustrates the background-check model. For a specific instantiation of this passport model see the integration of the attested CSR into the CMP protocol .

Passport Model with Client as Attester | | | | | | ... time passes ... | | | | | | Authenticator Request | | | (ClientCertificateReq) | | |<-----------------------| | | | | | Certificate Management Protocol (+CSR) | | (Evidence requested) | |<------------------------------------------------>| | | | | Certificate (with Attestation Result) | |<-------------------------------------------------| | | | | Exported Authenticator | | | (Authenticator with | | | Attestation Result) | | |----------------------->| | | | | ]]>

shows an example using the background-check model.

Background Check Model with a Separate Client-Side Attester | | | | | | | ... time passes ... | | | | | | | Authenticator Request (ClientCertReq), Nonce | |<-------------------------------------------| | | | | | | Request Evidence | | | |------------------>| | | | Key Attestation | | | | as Evidence | | | |<------------------| | | | Exported Authenticator | | | (Authenticator with Evidence) | | |------------------------------------------->| | | | | Send Evidence | | | |----------------->| | | | Attestation | | | | Result | | | |<-----------------| | | | | ]]>

Security Considerations This document inherits the security considerations of RFC 9261 and RFC 9334. The integrity of the exported authenticators must be guaranteed, and any failure in validating Evidence SHOULD be treated as a fatal error in the communication channel. Additionally, in order to benefit from remote attestation, it is recommended that Evidence MUST be protected using dedicated attestation keys chaining back to a trust anchor. This trust anchor will typically be provided by the hardware manufacturer.

Using the TLS Connection Remote attestation in this document occurs within the context of a TLS handshake, and the TLS connection remains valid after this process. Care must be taken when handling this TLS connection, as both the client and server must agree that remote attestation was successfully completed before exchanging data with the attested party. Session resumption presents special challenges since it happens at the TLS level, which is not aware of the application-level Authenticator. The application (or the modified TLS library) must ensure that a resumed session has already completed remote attestation before the session can be used normally, and race conditions are possible.

Evidence Freshness The evidence presented in this protocol is valid only at the time it is generated and presented. To ensure that the attested peer remains in a secure state, remote attestation must be re-initiated periodically. With the current protocol, this requires a new post-handshake authentication protocol run to be started.

IANA Considerations TBD: Request a new entry in the "TLS Certificate Types" to carry a CMW.

References Normative References 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. This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. 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. Fraunhofer SIT Intel Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC This document defines a conceptual message wrapper (CMW) format - an encapsulation method applicable to any RATS conceptual message, such as Evidence, Attestation Results, Endorsements, and Reference Values. It also describes a collection type that aggregates one or more CMWs into a single message. In addition, this document specifies a corresponding CBOR tag, JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) claims, and an X.509 extension. These mechanisms enable the embedding of enveloped conceptual messages into CBOR-based protocols, web APIs, and PKIX protocols. Moreover, a Media Type and a CoAP Content-Format are defined for transporting CMWs over HTTP, MIME, CoAP, and other Internet protocols. Informative References Entrust Limited Siemens Fraunhofer SIT Beyond Identity Intel Corporation A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer trustworthy claims about the platform generating the certification request and the environment associated with the corresponding private key, such as whether the private key resides on a hardware security module. This specification defines an attribute and an extension that allow for conveyance of Evidence and Attestation Results in Certificate Signing Requests (CSRs), such as PKCS#10 or Certificate Request Message Format (CRMF) payloads. This provides an elegant and automatable mechanism for transporting Evidence to a Certification Authority. Including Evidence and Attestation Results along with a CSR can help to improve the assessment of the security posture for the private key, and can help the Certification Authority to assess whether it satisfies the requested certificate profile. Siemens Siemens When an end entity includes attestation Evidence in a Certificate Signing Request (CSR), it may be necessary to demonstrate the freshness of the provided Evidence. Current attestation technology commonly achieves this using nonces. This document outlines the process through which nonces are supplied to the end entity by an RA/CA for inclusion in Evidence, leveraging the Certificate Management Protocol (CMP) and Enrollment over Secure Transport (EST)

Acknowledgements We would like to thank Chris Patton for his proposal to explore RFC 9261 for attested TLS. We would also like to thank Paul Howard and Yogesh Deshpande for their input.