Network Working Group T. Fossati Internet-Draft Linaro Intended status: Standards Track M. U. Sardar Expires: 4 September 2025 TU Dresden Y. Sheffer Intuit H. Tschofenig H-BRS I. Mihalcea Arm Limited 3 March 2025 Remote Attestation with Exported Authenticators draft-fossati-tls-exported-attestation-00 Abstract 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 This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://hannestschofenig.github.io/exported-attestation/draft- fossati-tls-exported-attestation.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- fossati-tls-exported-attestation/. Discussion of this document takes place on the tls Working Group mailing list (mailto:tls@ietf.org), which is archived at https://datatracker.ietf.org/wg/tls/about/. Subscribe at https://www.ietf.org/mailman/listinfo/tls/. Source for this draft and an issue tracker can be found at https://github.com/https://github.com/hannestschofenig/exported- attestation. Fossati, et al. Expires 4 September 2025 [Page 1] Internet-Draft Application Layer Attestation March 2025 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 September 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4.1. Using the TLS Connection . . . . . . . . . . . . . . . . 7 4.2. Evidence Freshness . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Fossati, et al. Expires 4 September 2025 [Page 2] Internet-Draft Application Layer Attestation March 2025 1. 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 [RFC9334] 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 [RFC9334]: 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 [RFC9261]: 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) [I-D.ietf-rats-msg-wrap]: CMW provides a convenient encapsulation of Evidence and Attestation Result payloads thereby provide an abstraction of the Fossati, et al. Expires 4 September 2025 [Page 3] Internet-Draft Application Layer Attestation March 2025 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. 2. 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 [RFC2119] [RFC8174] 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. 3. 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: Fossati, et al. Expires 4 September 2025 [Page 4] Internet-Draft Application Layer Attestation March 2025 * 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 Section 5 of [RFC9261] 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. Figure 1 shows the passport model while Figure 2 illustrates the background-check model. For a specific instantiation of this passport model see the integration of the attested CSR [I-D.ietf-lamps-csr-attestation] into the CMP protocol [I-D.ietf-lamps-attestation-freshness]. Client Server CA/Verifier | | | | Regular TLS Handshake | | | (Server-only auth) | | |<---------------------->| | | | | | ... time passes ... | | | | | | Authenticator Request | | | (ClientCertificateReq) | | |<-----------------------| | | | | | Certificate Management Protocol (+CSR) | | (Evidence requested) | |<------------------------------------------------>| | | | | Certificate (with Attestation Result) | |<-------------------------------------------------| | | | | Exported Authenticator | | | (Authenticator with | | | Attestation Result) | | |----------------------->| | | | | Fossati, et al. Expires 4 September 2025 [Page 5] Internet-Draft Application Layer Attestation March 2025 Figure 1: Passport Model with Client as Attester Figure 2 shows an example using the background-check model. Client Attester Server Verifier | | | | | Regular TLS Handshake (Server-only auth) | | |<------------------------------------------>| | | | | | | ... time passes ... | | | | | | | Authenticator Request (ClientCertReq), Nonce | |<-------------------------------------------| | | | | | | Request Evidence | | | |------------------>| | | | Key Attestation | | | | as Evidence | | | |<------------------| | | | Exported Authenticator | | | (Authenticator with Evidence) | | |------------------------------------------->| | | | | Send Evidence | | | |----------------->| | | | Attestation | | | | Result | | | |<-----------------| | | | | Figure 2: Background Check Model with a Separate Client-Side Attester 4. 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. Fossati, et al. Expires 4 September 2025 [Page 6] Internet-Draft Application Layer Attestation March 2025 4.1. 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. 4.2. 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. 5. IANA Considerations TBD: Request a new entry in the "TLS Certificate Types" to carry a CMW. 6. References 6.1. Normative References [I-D.ietf-rats-msg-wrap] Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-12, 28 February 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Fossati, et al. Expires 4 September 2025 [Page 7] Internet-Draft Application Layer Attestation March 2025 [RFC9261] Sullivan, N., "Exported Authenticators in TLS", RFC 9261, DOI 10.17487/RFC9261, July 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . 6.2. Informative References [I-D.ietf-lamps-attestation-freshness] Tschofenig, H. and H. Brockhaus, "Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST)", Work in Progress, Internet-Draft, draft-ietf-lamps-attestation- freshness-03, 5 November 2024, . [I-D.ietf-lamps-csr-attestation] Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M., and N. Smith, "Use of Remote Attestation with Certification Signing Requests", Work in Progress, Internet-Draft, draft-ietf-lamps-csr-attestation-17, 2 March 2025, . Appendix A. 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. Authors' Addresses Thomas Fossati Linaro Email: thomas.fossati@linaro.org Muhammad Usama Sardar TU Dresden Email: muhammad_usama.sardar@tu-dresden.de Fossati, et al. Expires 4 September 2025 [Page 8] Internet-Draft Application Layer Attestation March 2025 Yaron Sheffer Intuit Email: yaronf.ietf@gmail.com Hannes Tschofenig University of Applied Sciences Bonn-Rhein-Sieg Germany Email: Hannes.Tschofenig@gmx.net Ionut Mihalcea Arm Limited Email: ionut.mihalcea@arm.com Fossati, et al. Expires 4 September 2025 [Page 9]