]> J.P. Morgan Chase

mark.f.novak@jpmchase.com

Sandelman Software Works

Canada mcr+ietf@sandelman.ca

Franhaufer Inst.

Henk.Birkholz@ietf.contact

Security RATS Working Group trustworthy workload identity remote attestation stable workload credentials To be written last There is a large class of "RATS-Unaware" Relying Parties (RUPs) that Attesters nevertheless need to interoperate with. Existing deployed services, which precede the introduction of Remote Attestation, are often difficult to change/update in significant ways due to regulatory and cryptographic review policies. Yet there are significant advantages if clients can be incrementally updated in the trustworthiness of the platform. This document details a protocol by which the trusthworthiness of an Attesters is reviewed as part of the process of it being provided with some form of an Identity Document (a key, or a credential) to authenticate to RUPs. This specification illustrates how the RATS Architecture can be applied to interoperate with RUPs by providing Attesters with such Identity Documents. About This Document Status information for this document may be found at . Discussion of this document takes place on the RATS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Success of a technology is ultimately measured by its adoption. The RATS Architecture requires that RATS Relying Parties understand Attestation Results expressed using standards such as EAT and AR4SI, execute Appraisal Policy for Attestation Results, and have trust in Verifiers. Additionally, there is an unstated assumption present in the RATS Architecture that a change in Evidence may lead to a change in either the Attestation Results or Appraisal Policy for Attestation Results. This requirement may pose a significant adoption blocker. One key requirement for successful deployment of Remote Attestation-capable workloads is minimal blast radius. When a workload is moved from a legacy to a remotely attestable (e.g. Trusted Execution) environment, including Intel SGX, AMD SEV-SNP, ARM TrustZone, that workload can use Remote Attestation to obtain a stable and trustworthy Identity Document while its clients and servers do not notice anything different. For that, a mechanism is required by means of which a Credential Broker, a Key Broker, or a Credential Authority takes on the role of RATS Relying Party. This provides an intermediation between Attestation Results, expressed using formats such as EAT and AR4SI, and the RATS-Unaware Relying Parties whose authentication and authorization policies may precede the introduction of Remotely Attestable Workloads and remain static for long periods of time. For the RATS-Unaware Relying Parties, these adoption barriers are eliminated, as these RUPs are capable of authenticating their clients utilizing appropriate Identity Documents. This includes shared symmetric keys (bearer tokens), credentials including PKIX certificates , JWTs , or WIMSE WITs . In this world, the Attester uses Remote Attestation to obtain from the RATS Relying Party a key, token or credential that is compatible with the RUP. This document details an architecture by which legacy Identity Document Identity Document issuance mechanisms are replaced with identical Identity Documents issued, but with the additional prerequisite of successful Remote Attestation of the workloads in question.

Conventions and Definitions 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. This document uses terms and concepts defined by the WIMSE and RATS architectures, as well as the terms defined by the Trustworthy Workload Identity Special Interest Group at the Confidential Computing Consortium. For a complete glossary, see , & . The definitions of terms like Trustworthy Workload Identity and Workload Credential match those specified by the TWI SIG Definitions .

Broker:

an entity that deals out pre-existing keys or credential. Constrast to a Credential Authority which mints new credentials.

RUP:

The RATS Unaware Party (RUP). A target service that interacts with many clients based upon credentials provided. This is sometimes called the Collaborating Party.

Workload:

defines 'Workload' as "an instance of software executing for a specific purpose". Here we restrict that definition to the portions of the deployed software and its configuration that are subject to Remote Attestation.

Workload Duration:

the lifespan of the workload. While some workloads can be very long lived, but many workloads are created for a brief period of time, often added on demand to support rising demand, and persisting for only minutes to a small fraction of a day.

Workload Owner:

the entity that manages a workload, arranging to provision it with appropriate Workload Credentials before Workload is launched

Workload Credential:

an ephemeral identity document containing an identity and a number of additional claims, that can be short-lived or long-lived, and that is used to access a service

Proof of possession credential:

this is a credential, such as a JWT, that contains no other identity or authorization claims. It is trusted by the RUP due to local policy.

Collaborating Party:

see RUP.

Verifier:

an entity performing the role of Attestation Verification, as documented in

Overview of Mechanism A newly created workload connects to the Credential Broker to obtain a set of credentials to be used to perform it's functions. Within this connection, Evidence is transferred to the Credential Broker to demonstrate the workloads' trusthworthiness. The Credential Broker is acting as a RATS Relying Party, the workload is the Attester. The Credential Broker contacts (using the background check model), a Verifier that it trusts in order to evaluate the Evidence, obtaining an Attestation Result. Figure extends the architecture to show how the workload and credential broker take on the roles of Attester and Relying Party. If the Attestation Result is acceptable, then the Credential Broker provides the set of credentials that the workload needs to accomplish it's task.

Credential Enrollment Architecture | Verifier +------. | | '-------------------------' | | | | | | Evidence Attestation | | | Results | | | | | | v v .-----+----. .-------------------. | Attester | | Relying Party | |----------|------------enrollment--------->|-------------------| | workload | | credential broker | '-----+----' '-------------------' \ \ authentication .---------------------. `----work-data---------->| RATS Unaware | | Relying Party | | Collaborating Party | '---------------------' RATS-Unaware ^ Authentication | Policy | .--------------+-. | RATS-Unaware | | Relying Party | | Owner | '----------------' ]]>

Types of Credentials There are three kinds of credentials that can be involved. Some workloads might use a few of each.

1. The Credential Broker is also an Identity Provider (IdP), and acts as an Registration Authority (possibly including the Certification Authority). It issues new credentials in the form of PKIX certificates to each trustworthy workload.
2. The Credential Broker is a respository for a credential issued by another Identity Provider (IdP). The Credential Broker has both the private key and the certificate, and it discloses these to trustworthy workloads by encrypting these to an identity that identifies the workload.
3. The Credential Broker is a resposity for a bearer token issued by a Resource Owner, or a Workload Identity Tokens (WITs) defined in Section 3.1 of . The Credential Broker discloses this to trustworthy workloads by encrypting these to an identity that identifies the workload.

The use of a shared private key is unorthodox. This architecture is justified by the need to rapidly scale the number of workers and to recover from hardware or network failures. The alternatives is that external Identity Providers would need to be willing to respond to spikes of hundreds of credential requests within a small period of time. This would look like a denial of service attack, and it may also require additional human authorization for each. The patterns of communication shown in figure are designed specifically such that as few modifications are required to the workload, and no changes to the Collaborating Party are required.

Deployment of Credentials Workloads are expected to include a (virtual) Trusted Platform Module (TPM) (or equivalent) by which they will collect and sign Evidence to be used in the Remote Attestation process. The credential that will be shared by the Credential Broker will be encrypted to a key involved in the Remote Attestation process. The most natural mechanism is to encrypt to a key that is available only to the TPM. The credential are then decrypted by the TPM, and the keypair can then be made available to the workload, while never permitting the workload to ever see the key. In this way, a workload that be designed to do mutual TLS using a client-certificate, and for which the location of the private key can be configured to be in a TPM, can be adapted to the mechanism described in this document without any significant change to the workload itself.

Details of protocol TBD.

Security Considerations All communications between entities (Workload to Credential Authority, Workload to Verifier etc) MUST be secured using mutually authenticated, confidential, and integrity-protected channels (e.g., TLS). In addition to the considerations herein, Verifier, which is a central point of anchor for Trustworthy Workload Identifer MUST follow the security guidance detailed in the "Security and Privacy considerations" as detailed in the RATS Architecture Section and Section of . The credential key MUST always be stored securely at all time, for example in a secure element of the underlying platform running the Workload. There is a risk that a live Workload Migration may render some of the claims about the Workload invalid (e.g., live-migrating a Workload between Germany and France may incorrectly preserve the "Country=Germany" claim, but correctly preserve the "Region=Europe" claim).

Privacy Considerations Remote Attestation of a Workload requires exchange of attestation related messages, for example, Evidence and Attestation Results. This can potentially leak sensitive information about the Workload. Confidentiality: Encryption could be used to prevent unauthorised parties from accessing sensitive information from Evidence or Attestation Results. This is crucial in multi-tenant environments. The Credential Key to be released to a Workload MUST always be encrypted to avoid potential leakage to unauthorised actors.

IANA Considerations This document has no IANA actions (yet).

References Normative References This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. 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. 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. Informative References 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. Arm TU Dresden Linaro Nokia China Mobile This document outlines desirable security goals and use cases for integrating remote attestation (RA) capabilities with secure channel establishment protocols (e.g., TLS and DTLS). Peer authentication in such protocols establishes trust in a peer's network identifiers but provides no assurance regarding the integrity of its underlying software and hardware stack. Remote attestation addresses this gap by enabling a peer to provide verifiable evidence about the current state of the Target Environment. This document specifies a set of essential security goals the protocol solution must have, including cryptographic binding to the secure connection, evidence freshness, and flexibility to support different attestation models. It then explores relevant use cases, such as confidential data collaboration and secure secrets provisioning, to motivate the need for this integration. This document is intended to serve as an input to the design of protocol solutions within the SEAT working group. 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. Zscaler CyberArk This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in digital credentials, including X.509 certificates and security tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. Confidential Computing Consortium Trustworthy Workload Identity SIG n.d.

Acknowledgments