]> Linaro

thomas.fossati@linaro.org

TU Dresden

muhammad_usama.sardar@tu-dresden.de

Nokia

Bangalore Karnataka India k.tirumaleswar_reddy@nokia.com

Intuit

yaronf.ietf@gmail.com

University of Applied Sciences Bonn-Rhein-Sieg

Germany Hannes.Tschofenig@gmx.net

Arm Limited

ionut.mihalcea@arm.com

Security TLS 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. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. 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. To streamline attestation in TLS, this document introduces the cmw_attestation extension, which allows attestation credentials to be conveyed directly in the Certificate message during the Exported Authenticator-based post-handshake authentication. This eliminates reliance on real-time certificate issuance from a Certificate Authority (CA), reducing handshake delays while ensuring attestation evidence remains bound to the TLS session. The extension supports both the passport and background check models from the RATS architecture, enhancing flexibility for different deployment scenarios. 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 structured encapsulation of Evidence and Attestation Result payloads, abstracting the underlying attestation technology.

This specification introduces the cmw_attestation extension, enabling attestation evidence to be included directly in the Certificate message during the Exported Authenticator-based post-handshake authentication defined in . This approach enhances flexibility and efficiency, supporting key attestation mechanisms without being restricted to X.509 certificate encoding formats.

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

cmw_attestation Extension It introduces a new TLS extension, cmw_attestation, which enables the inclusion of either Attestation Evidence or Attestation Results in the extensions field associated with the end-entity certificate in the TLS Certificate message. As defined in Section 4.4.2 of , the TLS Certificate message consists of a certificate_list, which is a sequence of CertificateEntry structures. Each CertificateEntry contains a certificate and a set of associated extensions. The cmw_attestation extension MUST appear only in the first CertificateEntry of the Certificate message and applies exclusively to the end-entity certificate. It MUST NOT be included in entries corresponding to intermediate or trust anchor certificates. This design ensures that attestation information is tightly bound to the entity being authenticated. The cmw_attestation extension is defined to be included only in the Certificate message during the Exported Authenticator-based post-handshake authentication. This ensures that attestation credentials is conveyed within the Certificate message without requiring modifications to the X.509 certificate structure. ; } CMWAttestationExtension; ]]> cmw_data: Encapsulates the attestation credentials in a format compatible with CMW. The cmw_data field MUST be encoded using CBOR or JSON (as per ). This approach eliminates the need for real-time certificate issuance from a Certificate Authority (CA) and minimizes handshake delays. Typically, CAs require several seconds to minutes to issue a certificate due to verification steps such as validating subject identity, signing the certificate, and distributing it. These delays introduce latency into the TLS handshake, making real-time certificate generation impractical. The cmw_attestation extension circumvents this issue by embedding attestation data within the Certificate message itself, removing reliance on external certificate issuance processes.

Negotiation of CMWAttestationExtension Clients and servers use the TLS flags extension defined in to indicate support for the functionality defined in this document. We refer to the previously defined "cmw_attestation" extension, and the corresponding flag is called the "CMW_Attestation" flag. The "CMW_Attestation" flag proposed by the client in the ClientHello MUST be acknowledged in the EncryptedExtensions if the server also supports the functionality defined in this document and is configured to use it. If the "CMW_Attestation" flag is not set, servers ignore any of the functionality specified in this document, and attestation credentials cannot be conveyed using "Exported TLS Authenticators".

Usage in Post-Handshake Authentication The cmw_attestation extension is designed to be used exclusively in post-handshake authentication as defined in . It allows attestation credentials to be transmitted in the authenticator (Certificate) message only in response to an authenticator request. This ensures that attestation credentials are provided on demand rather than being included in the initial TLS handshake. To maintain a cryptographic binding between the attestation evidence and the authentication request, the cmw_attestation extension MUST be associated with the certificate_request_context of the corresponding CertificateRequest or ClientCertificateRequest message. This binding ensures that:

• The attestation evidence is specific to the authentication event and cannot be replayed across different TLS sessions.
• The attestation evidence remains tied to the cryptographic context of the TLS session.

Ensuring Compatibility with X.509 Certificate Validation The cmw_attestation extension does not modify or replace X.509 certificate validation mechanisms. It serves as an additional source of authentication data rather than altering the trust model of PKI-based authentication. Specifically:

• Certificate validation (e.g., signature verification, revocation checks) MUST still be performed according to TLS and PKIX .
• The attestation credentials carried in cmw_attestation MUST NOT be used as a substitute for X.509 certificate validation but can be used alongside standard certificate validation for additional security assurances.
• Implementations MAY reject connections where the certificate is valid but the attestation credentials is missing or does not meet security policy.

Applicability to Client and Server Authentication The cmw_attestation extension is applicable to both client and server authentication in Exported Authenticator-based post-handshake authentication. In TLS, one party acts as the relying party, and the other party acts as the attester. Either the client or the server may fulfill these roles depending on the authentication direction. The attester may respond with either:

• Attestation Evidence (Background Check Model):
  • The attester generates Evidence and includes it in the cmw_attestation extension.
  • The relying party forwards the Evidence to an external Verifier for evaluation and waits for an Attestation Result.
  • The relying party grants or denies access, or continues or terminates the TLS session, based on the Verifier's Attestation Result.
• Attestation Result (Passport Model):
  • The attester sends Evidence to a Verifier beforehand.
  • The Verifier issues an Attestation Result to the attester.
  • The attester includes the Attestation Result in the cmw_attestation extension and sends it to the relying party.
  • The relying party validates the Attestation Result directly without needing to contact an external Verifier.

By allowing both Evidence and Attestation Results to be conveyed within cmw_attestation, this mechanism supports flexible attestation workflows depending on the chosen trust model.

Architecture The cmw_attestation extension enables attestation credentials to be included in the Certificate message during Exported Authenticator-based post-handshake authentication, ensuring that attestation remains bound to the TLS session. However, applications using this mechanism still need to negotiate the encoding format (e.g., JOSE or COSE) and specify how attestation credentials are processed. This negotiation can be done via application-layer signaling or predefined profiles. Future specifications may define mechanisms to streamline this negotiation. Upon receipt of a Certificate message containing the cmw_attestation extension, an endpoint MUST take the following steps to validate the attestation credentials:

• Background Check Model:
  • Verify Integrity and Authenticity: The attestation evidence must be cryptographically verified against a known trust anchor, typically provided by the hardware manufacturer.
  • Ensure Certificate Binding and Freshness: The attestation evidence must be explicitly associated with the certificate_request_context in the authenticator request to ensure relevance, freshness, and protection against replay.
  • Evaluate Security Policy Compliance: The attestation evidence must be evaluated against the relying party's security policies to determine if the attesting device and the private key storage meet the required criteria.
• Passport Model:
  • Verify the Attestation Result: The relying party MUST check that the Attestation Result is correctly signed by the issuing authority and that it meets the relying party’s security requirements.

By integrating cmw_attestation directly into the Certificate message during Exported Authenticator-based post-handshake authentication, this approach reduces latency and complexity while maintaining strong security guarantees. 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.

Passport Model with Client as Attester | | | | | | ... time passes ... | | | | | | Authenticator Request | | | (ClientCertificateReq) | | |<-----------------------| | | | | | Sends Evidence | |------------------------------------------------->| | Gets Attestation result | |<-------------------------------------------------| | Exported Authenticator(| | | Certificate with | | | cmw_attestation, | | | CertificateVerify, | | | Finished) | | |----------------------->| | | | Finished | | |<------------------------| ]]>

shows an example using the background-check model.

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

API Requirements for Attestation Support To enable attestation workflows, implementations of the Exported Authenticator API MUST support the following:

1. Authenticator Generation
   • The API MUST support the inclusion of attestation credentials within the Certificate message provided as input.
2. Context Retrieval
   • The certificate_request_context MUST be provided in all cases to ensure proper validation of attestation evidence.
   • The receiving endpoint MUST use the "get context" API to retrieve the certificate_request_context associated with the exported authenticator as attestation-based authentication requires strict enforcement of the request context. This ensures that the freshness of attestation evidence can be verified.
3. Authenticator Validation
   • The API MUST verify that the attestation evidence within the Certificate message is cryptographically valid and bound to the certificate_request_context.

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, 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. This specification assumes that the Hardware Security Module (HSM) or Trusted Execution Environment (TEE) is responsible for generating the key pair and producing either attestation evidence or attestation results, which is included in the Certificate Signing Request (CSR) as defined in . This attestation enables the CA to verify that the private key is securely stored and that the platform meets the required security standards before issuing a certificate.

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 attestation evidence carried in cmw_attestation does not require an additional freshness mechanism, such as a nonce or timestamp, since freshness is inherently provided by the certificate_request_context in the authenticator request. 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 may be re-initiated periodically. In the current protocol, this can be achieved by initiating a new Exported Authenticator-based post-handshake authentication exchange, which will generate a new certificate_request_context to maintain freshness.

IANA Considerations

Updates to IANA Considerations This section defines the necessary updates to the IANA "TLS ExtensionType Values" registry to include the newly introduced cmw_attestation extension.

TLS Extension Type Registration IANA is requested to register the following new extension type in the "TLS ExtensionType Values" registry:

Value	Extension Name	TLS 1.3	DTLS 1.3	Recommended	Reference
TBD	cmw_attestation	Y	Y	Yes	This Document

TLS Flags Extension Registry IANA is requested to add the following entry to the "TLS Flags" extension registry :

• Value: TBD1
• Flag Name: CMW_Attestation
• Messages: CH, EE
• Recommended: Y
• Reference: [This document]

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. Dell Technologies A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8. 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. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] 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. IANA

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.