Integration of Remote Attestation with Key Negotiation and Distribution

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 8 January 2026.¶

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

Remote attestation is a security mechanism based on trusted hardware (e.g., TPM, TEE), allowing remote verifiers to cryptographically verify the integrity of the target device's software configuration, hardware state, and runtime environment. Hence, remote attestation can effectively prove the overall security state of the endpoint. Secure channel protocols (e.g., TLS, QUIC, IPSec, SSH) establish end-to-end (E2E) secure channels based on the authentication of the endpoint's legitimate identity and secure key negotiation, ensuring the security of network communication. By organically combining remote attestation protocols with secure channel protocols and establishing cryptographic binding between them, it is possible to achieve a logical binding of endpoint security and network security, ensuring dual verification and protection of the identity and state of the endpoint in secure connections. Attested TLS [I-D.fossati-tls-attestation] [I-D.fossati-tls-exported-attestation] is currently an important related work in the industry, and other similar works include binding remote attestation with credential issuance (e.g., certificates [I-D.ietf-lamps-csr-attestation], OAuth tokens, etc.) to achieve security enhancement.¶

However, in some scenarios, the above binding may not be possible. For example:¶

• Scenario 1: When tenants in a public cloud/compute cluster deploy workloads, they need to first verify their runtime environment's security through remote attestation before requesting Key Management Service (KMS) to assign application-layer data keys to the Virtual Machine (VM)/compute node where the workload resides. At this point, these keys are used for application-layer data encryption, such as file encryption or disk encryption, and are not used for any secure channel protocols. For example, to protect model parameters from leakage and tampering, model weights and other parameters need to be encrypted before model loading and transmitted to a Trusted Execution Environment (TEE). At this time, it is necessary to ensure that only the TEE has the key and decrypts it.¶

• Scenario 2: The end user/client accesses the online TEE computing environment, submits his data for business processing or large model inference, and needs to ensure the security of the entire computing environment through remote attestation before establishing a secure connection. At this point, there are multiple options for the secure channel protocol that can be established, such as TLS, IPSec, QUIC, OHTTP, etc. The user may only need to complete E2E key negotiation based on remote attestation. As for which secure protocol or application layer encryption the negotiated key is used for, and how it is used, there can be various implementation methods.¶

In summary, considering the diversity of remote attestation application scenarios and the limitations or complexity of combining with security protocols, this draft proposes a lightweight security enhancement scheme based on remote attestation—key negotiation integrated into remote attestation. By organically integrating the key steps of E2E key negotiation into the remote attestation process, the following can be achieved:¶

• The key distribution of KMS or E2E key negotiation can be automatically completed based on remote attestation, improving the security of key negotiation;¶

• The keys negotiated automatically can be flexibly applied in various ways, whether for secure protocols or application layer encryption;¶

• Compared to the complete and systematic implementation of Attested TLS, a more lightweight implementation can be provided.¶

2. Integration Scheme

The current specification is based on passport model of RATS. Future versions of specification will include the background-check model. We present two integration schemes:¶

        .------------.
        |            | 2. Compare Evidence
        |  Verifier  | against appraisal policy
        |            |
        '--------+---'
            ^    |
1. Evidence |    | 3. Attestation
            |    | Result
            |    v
        .---+--------.                .-------------.
        |            +--------------->|   Relying   | 5. Compare Attestation
        |  Attester  |4. Attestation  |    Party    | Result against
        |            |   Result       |    & KMS    | appraisal policy
        '------------' + SK/ASK/ESK   '-------------' + Distribute Keys

SK：Symmetric Key
ASK：Asymmetric Key
ESK：Encrypted Symmetric Key

       .------------.
       |            | 4. Compare Evidence
       |  Verifier  | against appraisal policy
       |            |
       '--------+---'
           ^    |
3 Evidence |    | 5. Attestation
           |    | Result
           |    v     1. Attestation
      .---+--------. Request + pubC.-------------.
      |  Attester  <-------------->|   Relying   | 7. Compare Attestation
      |  & Server  | 6.Attestation |    Party    | Result against
      |            | Result        |    & Client | appraisal policy
      '------------' + pubS        '-------------' + SK = privC * pubS
    2. SK = privS * pubC

SK：Symmetric Key
(privC,pubC): Client's ECDHE key pair
(privS,pubS): Server's ECDHE key pair

3. Use of Negotiated Keys in Different Security Protocols

Through the above process, key negotiation/distribution is completed during the remote attestation process, and is synchronized based on the results of the remote attestation. If the negotiated key is used for application layer encryption, its specific usage is strongly related to the application and can be very flexible. When the key is used for the security protocols, such as TLS, IPSec, etc., there are at least the following binding methods:¶

• TLS: The negotiated key can be used as a pre-shared key for subsequent TLS handshakes; the key can also be used as an externally imported shared key to participate in TLS Hybrid key exchange [I-D.ietf-tls-hybrid-design];¶

• IPSec: The negotiated key can be used as a pre-shared key for subsequent IKEv2 handshakes; or the key can be directly used as a session key for data plane encryption and integrity protection in IPSec ESP; or the key can also be used as Post-quantum Preshared Keys (PPKs) [RFC8784] to achieve binding with the IPSec protocol.¶

4. Remote Attestation Protocol and Message Extensions

This section describes how to extend RATS protocol and message to incorporate key negotiation into the remote attestation process.¶

TBD¶

5. Security Considerations

Risk of relay attacks needs to be evaluated in the design.¶

TBD¶

6. Privacy Considerations

TBD¶

7. IANA Considerations

TBD¶

8. References

Authors' Addresses