Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

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 25 April 2024.¶

Copyright Notice

Copyright (c) 2023 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

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 we suggest 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) [I-D.ietf-rats-eat],¶

• the Trusted Platform Modules (TPMs) [TPM1.2] [TPM2.0],¶

• the Android Key Attestation, and¶

• Apple Key Attestation.¶

Likewise, there are different encodings available for attestation results. One such encoding, AR4SI [I-D.ietf-rats-ar4si] is being standardized by the RATS working group.¶

This specification supports both the background check and passport model, during TLS Handshake. In background check model the details about the attestation technology are agnostic to TLS handshake itself. Similarly, in the passport model, the details about the attestation results encoding and trust relationships are agnostic to the TLS handshake.¶

To give the peer information that the handshake signing key is properly secured, the associated attestation result has to be appraised by the peer. This must be the case when either of the two remote attestation topologies is used. Hence, the attestation evidence (to be appraised by the verifier) must contain the security state of the signing key as well as the overall platform. 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 is accomplished by companion specifications.¶

2. Conventions and Terminology

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 reader is assumed to be familiar with the vocabulary and concepts defined in [RFC9334], and those in [I-D.bft-rats-kat].¶

"Remote attestation evidence" is more succintly referred to as "evidence", and "remote attestation results" is more succintly referred to as "attestation results" throughout this document. "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 RFC 2119 [RFC2119].¶

3. Overview

The Remote Attestation Procedures (RATS) architecture [RFC9334] 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 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.¶

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 [I-D.ftbs-rats-msg-wrap].¶

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 assertions relating to the client's TLS Identity Key (TIK), 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 [I-D.bft-rats-kat].¶

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

4. Use of Remote Attestation Credentials in the TLS Handshake

For both the passport model (described in section 5.1 of [RFC9334]) and background check model (described in Section 5.2 of [RFC9334]) 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.¶

       Client                                           Server

Key  ^ ClientHello
Exch | + evidence_proposal
     | + key_share*
     | + signature_algorithms*
     v                         -------->
                                                  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]

       Client                                           Server

Key  ^ ClientHello
Exch | + evidence_request
     |   (nonce)
     | + key_share*
     | + signature_algorithms*
     v                         -------->
                                                  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]

       Client                                           Server

Key  ^ ClientHello
Exch | + results_proposal
     | + key_share*
     | + signature_algorithms*
     v                         -------->
                                                  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]

       Client                                           Server

Key  ^ ClientHello
Exch | + results_request
     | + key_share*
     | + signature_algorithms*
     v                         -------->
                                                  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]

5. Evidence Extensions (Background Check Model)

The EvidenceType structure also 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.¶

   enum { NUMERIC(0), STRING(1) } encodingType;
   enum { ATTESTATION(0), CERT_ATTESTATION(1) } credentialType;

   struct {
        encodingType type;
        credentialType cred_type;
        select (encodingType) {
            case NUMERIC:
              uint16 content_format;
            case STRING:
               opaque media_type<0..2^16-1>;
        };
   } 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;

      struct {
          select (certificate_type) {
              case RawPublicKey:
                /* From RFC 7250 ASN.1_subjectPublicKeyInfo */
                opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;

                /* 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;

      struct {
          select (certificate_type) {
              case RawPublicKey:
                /* From RFC 7250 ASN.1_subjectPublicKeyInfo */
                opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;

              /* X.509 certificate conveyed as usual */
              case X509:
                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;

attestation_channel_binder = {
  &(nonce: 1) => bstr .size (8..64)
  &(ik_pub_fingerprint: 2) => bstr .size (16..64)
  &(channel_binder: 3) => bstr .size (16..64)
}

TLS-Early-Exporter(label, context_value, key_length) =
       HKDF-Expand-Label(
              Derive-Secret(early_exporter_master_secret, label, ""),
              "exporter", Hash(context_value), key_length)

channel_binder = TLS-Early-Exporter(label = "attestation-binder",
                                    context_value = "", key_length = 32)

6. Attestation Results Extensions (Passport Model)

   struct {
        opaque verifier_identity<0..2^16-1>;
   } VerifierIdentityType;

   struct {
           select(ClientOrServerExtension) {
               case client:
                 VerifierIdentityType trusted_verifiers<1..2^8-1>;

               case server:
                 VerifierIdentityType selected_verifier;
           }
   } resultsRequestTypeExtension;

   struct {
           select(ClientOrServerExtension) {
               case client:
                 VerifierIdentityType trusted_verifiers<1..2^8-1>;

               case server:
                 VerifierIdentityType selected_verifier;
           }
   } resultsProposalTypeExtension;

7. TLS Client and Server Handshake Behavior

The high-level message exchange in Figure 11 shows the evidence_proposal, evidence_request, results_proposal, and results_request extensions added to the ClientHello and the EncryptedExtensions messages.¶

       Client                                           Server

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     | + pre_shared_key*
     | + evidence_proposal*
     | + evidence_request*
     | + results_proposal*
     v + results_request*
     -------->
                                                  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]

8. Background-Check Model Examples

9. Security Considerations

TBD.¶

10. IANA Considerations

Appendix A. 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 [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 [DICE-Layering]).¶

     • Third party CA-issued certificates (e.g., ACME Device Attestation [I-D.acme-device-attest]): 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 signalling via existing methods, e.g. using a policy OID in the end-entity certificate.¶

   • Implicit signalling, 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 Section 5.2.¶

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 Section 5.1. A possible instantiation of the KAT is described in [I-D.bft-rats-kat].¶

Appendix B. Cross-protocol Binding Mechanism

Note: This section describes a protocol-agnostic mechanism which is used in the context of TLS within the body of the draft. The mechanism might, in the future, be spun out into its own document.¶

One of the issues that must be addressed when using remote attestation as an authentication mechanism is the binding to the outer protocol (i.e., the protocol requiring authentication). For every instance of the combined protocol, the remote attestation credentials must be verifiably linked to the outer protocol. The main reason for this requirement is security: a lack of binding can result in the attestation credentials being relayed.¶

If the attestation credentials can be enhanced freely and in a verifiable way, the binding can be performed by inserting the relevant data as new claims. If the ways of enhancing the attestation credentials are more restricted, ad-hoc solutions can be devised which address the issue. For example, many roots of trust only allow a small amount (32-64 bytes) of user-provided data which will be included in the attestation token. If more data must be included, it must therefore be compressed. In this case, the problem is compounded by the need to also include a challenge value coming from the relying party. The verification steps also become more complex, as the binding data must be returned from the verifier and checked by the relying party.¶

However, regardless of how the binding and verification are performed, similar but distinct approaches need to be taken for every protocol into which remote attestation is embedded, as the type or semantics of the binding data could differ. A more standardised way of tackling this issue would therefore be beneficial. This appendix presents a solution to this problem, in the context of attestation evidence.¶

attestation_channel_binder = {
  &(nonce: 1) => bstr .size (8..64)
  &(ik_pub_fingerprint: 2) => bstr .size 32
  &(session_key_binder: 3) => bstr .size 32
}

Appendix C. History

RFC EDITOR: PLEASE REMOVE THIS SECTION¶

Appendix D. 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¶

Authors' Addresses