]> Huawei Technologies

frank.xialiang@huawei.com

Huawei Technologies

jiangweiyu1@huawei.com

TU Dresden

muhammad_usama.sardar@tu-dresden.de

Fraunhofer SIT

henk.birkholz@ietf.contact

Huawei Technologies France S.A.S.U.

junzhang1@huawei.com

Huawei Technologies France S.A.S.U.

houda.labiod@huawei.com

Security Remote ATtestation ProcedureS RATS attestation key negotiation 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 Status information for this document may be found at . Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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 is currently an important related work in the industry, and other similar works include binding remote attestation with credential issuance (e.g., certificates , 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.

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 when, and only when, they appear in all capitals, as shown here.

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:

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:

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

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.

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:

Integrating E2E Key Negotiation Into Remote Attestation | 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 ]]>

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.

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 ;
• 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) to achieve binding with the IPSec protocol.

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

Security Considerations Risk of relay attacks needs to be evaluated in the design. TBD

Privacy Considerations TBD

IANA Considerations TBD

References Normative References 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. The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys. Informative References Intuit Arm Limited Arm Limited Arm Limited Huawei Linaro The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using attestation which is a process by which an entity produces evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enables the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and mutually. Linaro TU Dresden Nokia Intuit University of Applied Sciences Bonn-Rhein-Sieg Arm Limited 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. Entrust Limited Siemens Fraunhofer SIT 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. University of Waterloo Cisco Systems University of Haifa and Meta Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design.