Internet-Draft RATS Key Negotiation Integration July 2025
Xia, et al. Expires 8 January 2026 [Page]
Workgroup:
Remote ATtestation ProcedureS
Internet-Draft:
draft-xia-rats-key-negotiation-integration-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
L. Xia
Huawei Technologies
W. Jiang
Huawei Technologies
M. U. Sardar
TU Dresden
H. Birkholz
Fraunhofer SIT
J. Zhang
Huawei Technologies France S.A.S.U.
H. Labiod
Huawei Technologies France S.A.S.U.

Integration of Remote Attestation with Key Negotiation and Distribution

Abstract

This draft proposes a lightweight security enhancement scheme based on remote attestation—key negotiation integrated into remote attestation. Organically integrating the main steps of end-to-end key negotiation into the remote attestation process may provide more security and flexibility.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at https://datatracker.ietf.org/doc/draft-xia-rats-key-negotiation-integration/.

Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (mailto:rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Subscribe at https://www.ietf.org/mailman/listinfo/rats/.

Source for this draft and an issue tracker can be found at https://github.com/ietf-rats/draft-xia-rats-key-negotiation-integration.

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.

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:

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:

1.1. Requirements Notation

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.

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.1. Key Distribution Based on KMS Integrated with Remote Attestation

The KMS mechanism on public cloud networks includes the root of trust, secure channels between Attester and KMS, full lifecycle management of keys (including key generation, storage, rotation, and destruction), hierarchical encryption architecture (such as Envelope Encryption), and access control mechanisms. There are two cases here:

  • Attester generates keys to be distributed to other applications via KMS.

  • Attester obtains keys from the KMS.

So KMS enables applications to generate/obtain their own application-layer encryption symmetric/asymmetric keys and distribute these keys between the required applications. Furthermore, the method of integrating key distribution into the remote attestation interaction process is shown in the following diagram:

        .------------.
        |            | 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
Figure 1: Key Distribution Based on KMS Integrated with Remote Attestation

In the standard remote attestation process described above, the Attester can generate and provide/request the Attester's application layer SK/ASK/ESK keys in the result returned to the KMS. SK MUST be conveyed over a secure channel. The KMS can generate or distribute these keys accordingly. During key rotation, the KMS can proactively trigger the above process to complete the update and rotation of the new and old keys.

2.2. Integrating E2E Key Negotiation Into Remote Attestation

The current main implementation mechanism for E2E key negotiation is DHE and ECDHE. Taking ECDHE as an example, the method of integrating it into remote attestation is shown in the following figure:

       .------------.
       |            | 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
Figure 2: Integrating E2E Key Negotiation Into Remote Attestation

In the standard remote attestation process described above, the Client includes the public key pubC from its dynamically generated ECDHE key pair (privC, pubC) in the remote attestation request message, while retaining its private key privC. Upon receiving pubC, the Server can compute the symmetric key SK using its private key privS from its dynamically generated ECDHE key pair (privS, pubS). After completing the remote attestation with the Verifier, the Server includes its pubS in the Attestation Result returned to the Client. Once the Client verifies the Attestation Result, it can compute the symmetric key SK using pubS and its own private key privC, thereby completing both the remote attestation and ECDHE key agreement.

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:

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

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8784]
Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, "Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security", RFC 8784, DOI 10.17487/RFC8784, , <https://www.rfc-editor.org/rfc/rfc8784>.

8.2. Informative References

[I-D.fossati-tls-attestation]
Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I., Deshpande, Y., Niemi, A., and T. Fossati, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati-tls-attestation-09, , <https://datatracker.ietf.org/doc/html/draft-fossati-tls-attestation-09>.
[I-D.fossati-tls-exported-attestation]
Fossati, T., Sardar, M. U., Reddy.K, T., Sheffer, Y., Tschofenig, H., and I. Mihalcea, "Remote Attestation with Exported Authenticators", Work in Progress, Internet-Draft, draft-fossati-tls-exported-attestation-02, , <https://datatracker.ietf.org/doc/html/draft-fossati-tls-exported-attestation-02>.
[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-19, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-19>.
[I-D.ietf-tls-hybrid-design]
Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key exchange in TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-hybrid-design-13, , <https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-13>.

Authors' Addresses

Liang Xia
Huawei Technologies
Weiyu Jiang
Huawei Technologies
Muhammad Usama Sardar
TU Dresden
Henk Birkholz
Fraunhofer SIT
Jun Zhang
Huawei Technologies France S.A.S.U.
Houda Labiod
Huawei Technologies France S.A.S.U.