]> Nokia

Bangalore Karnataka India kondtir@gmail.com

Independent

ietf@nritz.com

Security WIMSE attestation workload identity proxy TEE RATS This document extends the WIMSE workload-to-workload authentication architecture with a mechanism for conveying attestation across TLS-terminating proxies, a deployment topology where TLS-layer attestation mechanisms lose their end-to-end security properties.

Introduction Workloads communicate with each other over HTTPS. Securing these workload-to-workload calls requires answering two questions: who is the caller, and can the caller be trusted? The first question is addressed by the WIMSE architecture . The Workload Identity Token (WIT) carries the workload's identity, issued and signed by an Identity Server . The WIT embeds the workload's public key, the Identity Server's assertion that this key belongs to this workload. The WIT alone, however, does not prove that the presenter holds the corresponding private key; any party that intercepts the WIT could replay it. The Workload Proof Token (WPT) closes this gap: it is a short-lived token signed by the workload's private key, bound to a specific HTTPS request and target URL, proving possession of the private key corresponding to the public key in the WIT. Together, the WIT and WPT establish both who the caller is and that the caller is the legitimate holder of that identity. Both travel as HTTP header fields and survive TLS termination at proxies. The second question, whether the caller's platform and key state can be trusted is not addressed by the WIT/WPT mechanism. A workload may have a valid identity and prove possession of its key, yet be running in a compromised environment, with a key that is not hardware-protected, or on a platform whose firmware or software does not meet the relying party's security policy. The SEAT Working Group is developing protocols that add attestation to TLS. introduces new TLS extensions that carry attestation Evidence or Attestation Results intra-handshake. provides post-handshake attestation using TLS Exported Authenticators. Both mechanisms are designed so that Evidence is cryptographically tied to a specific TLS connection. However, this same property is their limitation when TLS does not extend end-to-end to the backend workload, as described in . The attestation binding does not reach the backend, and the backend workload receives no cryptographic evidence of the original caller's platform and key state. Since the WIT and WPT already travel end-to-end as HTTP headers through TLS-terminating proxies, attestation information can travel alongside them in the same way. This document supports both the background check model and the passport model . In both cases, the workload's public key is the binding element across the WIT, WPT, and the attestation information. This requires no changes to TLS, no changes to proxy infrastructure, and no modifications to the WIT or WPT specifications. For the key binding verification to be cryptographically meaningful, the Evidence needs to contain a public-key confirmation claim corresponding to the workload's public key, and claims describing the protection properties of the associated private key. illustrates how a key and key store may be represented in Evidence in Appendix A.1.4, but uses private-use claim labels and does not define standardised key-protection claims. One way to satisfy these requirements is the profile defined in .

Requirements Language 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.

Terminology This document uses terms defined in the WIMSE Architecture and the RATS Architecture .

Workload Identity Token (WIT):

A JWT that represents the identity of a workload and binds a public key to that identity, as defined in .

Workload Proof Token (WPT):

A JWT that provides proof of possession of the private key associated with a WIT, as defined in .

TLS-terminating proxy:

An intermediary that terminates the caller's TLS connection and establishes a new, independent TLS connection to the backend workload.

Workload Evidence (WE):

Attestation Evidence generated by the workload's TEE, signed by the Attestation Key, and carried in the Workload-Evidence HTTP header field as defined in this document. Evidence freshness is provided by using the WPT jti claim as the nonce during Evidence collection.

Workload EAR (WEAR):

An EAT Attestation Result (EAR) generated by a Verifier following appraisal of the workload's Evidence, and carried in the Workload-Attestation-Result HTTP header field as defined in this document. Request binding is provided by using the WPT jti claim as the nonce during Evidence collection, which the Verifier echoes in the eat_nonce claim of the EAR.

Scope This document specifies mechanisms for conveying workload attestation information alongside WIMSE workload-to-workload HTTP requests, supporting both the background check model and the passport model .

The Workload-Evidence Header Field The Workload-Evidence header field carries Evidence generated by the workload's TEE. The Evidence MUST be encapsulated in a CMW (Conceptual Message Wrapper) . The CMW type field identifies the attestation technology and serialization format, providing interoperability at the envelope level without out-of-band negotiation. The Evidence MUST contain:

• a public-key confirmation claim corresponding to the workload's public key, and
• claims describing the protection properties of the associated private key.

One way to satisfy these requirements is the profile defined in . The three header fields form a coherent set, each independently signed by a different authority: The workload's public key is the binding across all three: it is asserted by the Identity Server in the WIT, proven in possession by the WPT, and attested as hardware-protected by the Evidence.

The Workload-Attestation-Result Header Field When the passport model is used, the Workload-Attestation-Result header field carries the EAT Attestation Result (EAR) generated by the Verifier . The EAR MUST contain the ear_verified_attester_key claim. This claim provides the Relying Party with the verified public key of the attester. Because the ear_verified_attester_key claim is represented as a PEM-encoded SPKI or certificate, and the WIT carries the workload's public key as a JWK , implementations MUST convert between the two formats to perform the required cryptographic comparison. The EAR MUST also contain the eat_nonce claim, set to the nonce value extracted from the appraised Evidence. Because the workload uses the WPT jti claim as the Evidence nonce, this value enables the Relying Party to verify that the EAR was produced from Evidence collected for this specific request. Similar to the background check model, the workload's public key acts as the binding element: it is asserted by the Identity Server in the WIT, proven in possession by the WPT, and verified by the Verifier in the EAR.

Protocol Flows

Background Check Model Protocol Flow | | Workload-Identity-Token: | | Workload-Proof-Token: | | Workload-Evidence: | | | | Verify WIT | | Verify WPT | | Submit Evidence | | + jti + WIT key | | to Verifier | | Evaluate policy | | | |<------ Response ----------------------| ]]>

Passport Model Protocol Flow In the passport model, the caller obtains the Attestation Result from a Verifier before initiating the request to the backend workload. The caller uses the WPT jti claim as the challenge when requesting the EAR. | | | | Verify Evidence | |<----- Return EAR (w/ key) ------| | | Sign WPT with private key | | | | | |------ HTTPS Request --------------------------------->| | Workload-Identity-Token: | | Workload-Proof-Token: | | Workload-Attestation-Result: | | | | Verify WIT | | Verify WPT | | Verify EAR sig | | Verify key in | | EAR matches WIT | | Evaluate policy | | | |<------ Response --------------------------------------| ]]>

Applicability The Workload-Evidence and Workload-Attestation-Result header fields defined in this document are applicable to both WIMSE application-level protection mechanisms: WPT and HTTP Signatures .

Proxy Behaviour A TLS-terminating proxy MUST forward the Workload-Evidence and Workload-Attestation-Result header fields unchanged toward the backend workload. A proxy MUST NOT strip or modify the Workload-Evidence or Workload-Attestation-Result header fields.

Verification Algorithms The backend workload acts as the Relying Party as defined in and submits Evidence to a Verifier for appraisal. The backend workload MUST first verify the WIT and WPT as defined in . Following this, it MUST perform the steps for either the Background Check Model or the Passport Model, depending on which header is presented. For both models, the request MUST NOT be processed further until all steps have completed successfully. If a backend workload requires attestation by policy, it MUST reject any request that does not include either a valid Workload-Evidence or Workload-Attestation-Result header field with a 403 Forbidden status code. If a request contains both Workload-Evidence and Workload-Attestation-Result header fields, the backend MUST reject the request with 400 Bad Request.

Background Check Model (Workload-Evidence)

1. Extract the Workload-Evidence header field value.
2. Decode the CMW wrapper to determine the Evidence format from the CMW type field.
3. Convert the WIT public key to the format indicated by the CMW type field.
4. Submit the Evidence, the WPT jti, and the converted WIT public key to a Verifier.
5. The Verifier MUST verify that the nonce carried in the Evidence matches the submitted jti.
6. The Verifier MUST verify that the public key in the Evidence matches the submitted WIT public key.
7. Evaluate the returned Attestation Result against local policy.

Passport Model (Workload-Attestation-Result)

1. Extract the Workload-Attestation-Result header field value.
2. Verify the digital signature of the EAR using the Verifier's public key or trust anchor.
3. Verify that the ear_verified_attester_key claim is present in the EAR Appraisal record.
4. Convert the PEM-encoded SPKI or certificate from the ear_verified_attester_key claim and the JWK from the WIT into a common format.
5. Verify that the converted public key from the EAR matches the public key in the WIT.
6. Verify that the eat_nonce claim in the EAR matches the jti claim from the WPT.
7. Evaluate the EAR against local policy.

Security Considerations

Key Binding The security of this mechanism depends on verifying that the public key in the Evidence matches the public key in the WIT. This ensures the Evidence is about the same key that the WPT proves possession of. One way to satisfy the key binding requirements is the profile defined in .

Stripping Attack A malicious proxy may strip the Workload-Evidence or Workload-Attestation-Result header fields. Backend workloads that require attestation by policy MUST reject requests lacking the required valid Workload-Evidence or Workload-Attestation-Result header field with a 403 Forbidden status code.

IANA Considerations This document requests registration of the following HTTP header fields in the "HTTP Field Names" registry:

Field Name:

Workload-Evidence

Status:

permanent

Specification Document:

This document

Field Name:

Workload-Attestation-Result

Status:

permanent

Specification Document:

This document

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. This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). 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. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. CyberArk Zscaler University of Applied Sciences Bonn-Rhein-Sieg The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Ping Identity CyberArk Defakto Security Intuit Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. Ping Identity Defakto Security The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-level proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains. Fraunhofer SIT Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. Nokia University of the Bundeswehr Munich Linaro Arm Limited This document defines an Entity Attestation Token (EAT) profile and a new EAT claim that convey the subject public key and its protection properties within attestation evidence. Combined with protocol-level proof of possession from the surrounding protocol, this establishes a cryptographic binding between a private key and an attested execution environment. The subject public key is conveyed using the EAT cnf claim defined in [RFC8747] and [RFC7800], and freshness uses the EAT eat_nonce claim defined in [RFC9711]. The proof of possession of the subject key is obtained from the surrounding protocol, such as TLS certificate-based authentication or CSR signature verification. Because the EAT is signed by a hardware-backed Attestation Key (AK), successful verification of the EAT signature together with protocol-level proof of possession establishes a cryptographic binding between the private key and the attested platform state. This mechanism addresses key substitution attacks that arise when attestation evidence and the certificate private keys are validated independently. Linaro Cisco Arm Limited Fraunhofer SIT This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. Informative References Intuit Arm Limited Arm Limited Linaro Nokia 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 remote 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 TLS extensions that enable 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 to use them mutually. TU Dresden Linaro 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 [RFC9261]. 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. CyberArk Intuit The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT).

Acknowledgements The authors would like to thank Thomas Fossati and Ionut Mihalcea for the review and comments, and the SEAT Working Group participants for discussions that motivated this work.

Document History

Version -00

• Initial version