J.P. Morgan Chase

mark.f.novak@jpmchase.com

Arm

Yogesh.Deshpande@arm.com

Franhaufer Inst.

Henk.Birkholz@ietf.contact

Security RATS Working Group trustworthy workload identity remote attestation stable workload credentials Trustworthy Workloads are workloads that operate in environments that provide isolation of data in use. This document describes how Trustworthy Workloads can acquire credentials containing stable identifiers, upon proving the trust in the environments in which they operate via Remote Attestation. 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 .

Introduction As organisations move more workloads into untrusted or shared environments, protection of data in use becomes increasingly important. One way of isolating data in use is Confidential Computing: executing a workload (for example an AI model, database process or financial service) inside a hardware-based, remotely attested Trusted Execution Environment (TEE). Workloads operating in such environments need stable and trustworthy identifiers to communicate over the network to the external world. Often such identifiers are provided to them via Credential Authorities upon ascertaining trust in the environments in which these workloads operate. The standard practice to establish trust in the operating environment is through Remote Attestation. This draft specifies how a Workload operating in Confidential Computing Environment can obtain trustworthy, stable, and workload-bound credentials using Remote Attestation.

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 .

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 Identifier:

a stable construct around which Relying Parties can form long-lived Workload authorization policies.

Workload Identity:

the definition of Workload Identity is identical to the definition of the same term by : "a combination of three basic building blocks: trust domain, Workload Identifier and identity credentials.

Workload Credential:

an ephemeral identity document containing the Workload Identifier and a number of additional claims, that can be short-lived or long-lived, and that is used to represent and prove Workload Identity to a Relying Party.

Stable Workload Identity, Stable Authorization Policy:

a Workload Identity or Authorization Policy is considered Stable if it remains constant in the face of software and hardware changes (updates and rollbacks), so long as those updates and rollbacks are authorized, i.e., comply with the policy of what consitutes the allowed version(s) of the software and hardware in question.

Credential Authority:

an entity trusted to issue Workload Credentials

Bound Workload Credential:

a Workload Credential is considered Bound if it can only be used in conjunction with a secret Credential Key that only a Workload authorized for the use of that Key can obtain, either by generating and certifying it, or by retrieving it from a secure Key Store.

Workload Owner:

an entity tasked with specifying policies concerning what Workload composition is considered valid for the purposes of issuing Workload Credentials

Verifier:

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

Available Options When dealing with a client Workload that is running inside a remotely attested Trusted Execution Environment, the goal of having a Relying Party having a Stable authorization policy and utilizing industry-standard mechanisms for authorization can be achieved by issuing Credentials in a relying party-friendly format, such as those specified by . Such Credentials may take the form of x.509 certificates or Workload Identity Tokens (WITs) defined in Section 3.1 of . A Workload can start using the Credential for authentication and authorization once it has two items in its possession: the public portion - the Workload Credential itself, and the secret Credential Key necessary to utilize this Credential. A Stable authorization policy can only be achieved if Workloads can have Stable identities. The decision about what constitutes a trustworthy Workload and a trustworthy configuration is a composition verification, with multiple entities providing Reference Values for the components they vouch for. For the issued Workload Identity to be Stable in addition to Trustworthy, a mapping must be performed between these Reference Values and the issued Identities. In a typical enterprise, Stable authorization policies are expressed in terms of business- rather than technology-oriented concepts, e.g., "Payroll Application", "Located in Germany", "Cleared for handling Personally Identifiable Information", etc. This contrasts with what RATS has historically thought of as Attestation Results, which may relate to the hardware manufacturer, firmware and software versions, etc. In some implementations, a Credential is precomputed, and the Credential Key is obtained from a Key Store following successful Remote Attestation. In other implementations, the Workload generates its own Credential Key and uses Remote Attestation to certify it. Within the RATS Architecture, either of these options can be accomplished in one of three ways:

1. The Workload supplies Evidence to a Verifier and obtains from it Attestation Results. It then provides these Attestation Results to the Credential Authority in exchange for a Credential.
2. The Verifier contacts the Credential Authority on the Workload's behalf, and the Attestation Results obtained from the Verifier are (or contain) the Credentials for that Workload.
3. The Credential Authority contacts the Verifier on the Workload's behalf, and the Credential Authority constructs the Credential using the Attestation Results received from the Verifier.

In either case, the detailed information about the Workload's composition conveyed to the Verifier using RATS "Evidence" is mapped to Stable, technology-agnostic, business-oriented claims about the Workload by invoking a new architectural building block called a Claims Mapper, described below. These three options can be visualised at a high level as shown below. E: Evidence AR: Attestation Results CR: Credential Request C: Credential

Variant 1 Credential | | Workload | 4:C | Authority | | <---------+ | +----+-----+ +------------+ | |5:C +----v-----+ | Relying | | Party | +----------+ ]]>

Variant 2 Credential | | Verifier | 3:C | Authority | | <--------+ | +--^------+--+ +------------+ | | 1:E| |4:AR (incl. C) +--+------v--+ | | | Workload | | | +-----+------+ | |5:C +-----v------+ | Relying | | Party | +------------+ ]]>

Variant 3 Credential | | Workload | 4:C | Authority | | <---------+ | +-----+-----+ +------------+ | |5:C +-----v-----+ | Relying | | Party | +-----------+ ]]> From the Workload's perspective, Variant 1 carries with it an extra network roundtrip (the first roundtrip being the workload exchanging "Evidence" for "Attestation Results"). It is the only option available to the Workload for using existing Verifier implementations that make no changes associated with this proposal. This option does however introduce additional latency and reliability costs inherent in an extra roundtrip. Variants 2 and 3 do not require the Workload to perform an extra roundtrip, and thus do not carry the additional performance costs or reliability risks. Several distinct options are possible. In all cases, the Credential is generated and signed by a Credential Authority. The difference is in how the Workload obtains these Credentials. The main pivots are:

1. Where the Credential Key is generated (Key Source):
   1. Inside the Workload Instance
   2. Inside a secure Key Store such as a Hardware Security Module (HSM), by the Workload Owner
2. Where the Workload gets its Credential from (Credential Source):
   1. The Verifier
   2. The Credential Authority (e.g., a Certificate Authority, a Security Token Service, or similar)
   3. The Workload Owner (via the Control Plane)

Note that it is safe to receive the Credential from an untrusted source such as the Control Plane, because it is public. The only requirement is that the obtained Credential matches the Credential Key, which MUST always be obtained securely and only by an authorized Workload instance. Further, under pivot 2.i, the order of interactions involved in Credential generation might differ:

1. A Workload invokes the Verifier which collaborates with the Credential Authority to compute and return Credentials, returning these Credentials inside the Attestation Results, or
2. A Workload invokes the Verifier, obtains from it the Attestation Results, and forwards these Attestation Results to the Credential Authority inside a Credential Request to get the Credential.

Claims Mapper In order to convert Evidence that the Workload collects about itself into business-centric Claims about the Workload, a new architectural building block is required: a Claims Mapper. The inputs to the Claims Mapper depend on the Credential Issuance Mechanism, several of which are discussed in the following sections. In some cases, the business-centric output claims are generated from the Evidence submitted to the Verifier by the Workload, and in other cases - from the Attestation Results computed by the Verifier upon examining the Evidence. In all cases, the decisions on 1) whether to accept the inputs as valid and 2) which claims to emit based on these inputs are going to be made by the Claims Mapper Policy, which is governed by the Workload Owner. Whenever a new version of the Workload is rolled out, the corresponding updated Claims Mapper Policy must be put in place.

Credential Acquisition Mechanisms This set of variants results in several distinct Credential Acquisition Mechanisms (CAMs), some of which are listed in the table below:

CAM	Key Source	Credential Source	Description
A	Workload	Verifier	A Proof-of-Possession of the Credential Key is included in the Evidence submitted by the Workload Instance to the Verifier. The Verifier first appraises the Evidence. It then invokes the Claims Mapper to map this Evidence to Claims about the Workload. Finally, it contacts the Credential Authority to compute a Credential based on this Credential Key, and returns it to the Workload Instance as part of Attestation Results.
B	Workload	Credential Authority	A Proof-of-Possession of the Credential Key is included in the Evidence submitted by the Workload Instance to the Verifier, and also in the Attestation Results returned by the Verifier. The Workload Instance sends the Attestation Results obtained from the Verifier to the Credential Authority. Credential Authority invokes the Claims Mapper to map the Attestation Results to Claims about the Workload Instance. It then computes and returns to the Workload Instance a Credential based on these Claims.
C	Workload	Credential Authority	A Proof-of-Possession of the Credential Key is included in a Credential Request submitted by the Workload to the Credential Authority alongside Evidence destined for the Verifier. Credential Authority handles the Credential Request by contacting the Verifier on the Workload's behalf, supplying the Evidence from the Credential Request. The Verifier responds with Attestation Results. The Credential Authority invokes the Claims Mapper to convert the Attestation Results to Claims about the Workload. It then computes and returns to the Workload Instance a Credential based on these Claims.
D	Key Store	Workload Owner	The Workload Owner uses the Claims Mapper to create the Claims about the Workload and the associated Key Release Policy, specifying the expected Attestation Results needed to obtain the Credential Key. The Workload Owner then interacts with the Key Store to generate the Credential Key, the Credential and set the Key Release Policy. It then makes the Credential available to the Workload. The Workload obtains the Credential Key from the Key Store after completing Remote Attestation.

These options are illustrated below with sequence diagrams.

Mechanism A | | | (Evidence) | Appraise Evidence | | +-----------+ | | |<----------+ | | | Invoke Claims Mapper | | +-----------+ to compute Claims | +<----------+ | │ | Request Credential | │ | (Credential Req+ Claims) | │ +--------------------------->+ │ | Create & Sign Credential | | | +-------------+ | | +------------>+ │ | | │ | Return Credential | │ Return Credential +<---------------------------+ | in Attestation Results | | +<-----------------------+ | +------+-------+ +-------+------+ +------------+-----------+ | Workload | | Verifier | | Credential Authority | +--------------+ +--------------+ +------------------------+ ]]>

Mechanism B + | │ (Evidence) Appraise Evidence | | +------------+ | | +<-----------+ | │ | Compute Attestation | | | Results | | +------------+ | | +<-----------+ | | Return | | │ Attestation Results | | +<-----------------------+ | │ Create Credential Req. | | | (incl. Credential Key | | +------------+ Pop & AR) | | +<-----------+ | | │ Request Credential (Cre|dential Request) | | +------------------------+--------------------------->+ | | Invoke Claims Mapper to | │ |convert Attestation Results | │ | to Credential Attributes | | | +-------------+ | | +------------>| │ | Create & Sign Credential | | | +-------------+ | | +------------>| | | Return Credential | │<-----------------------+----------------------------+ +------+-------+ +-------+------+ +------------+-----------+ | Workload | | Verifier | | Credential Authority | +------+-------+ +--------------+ +------------------------+ ]]>

Mechanism C + │ │ (Credential Request) | Request Attestation | | | (Evidence from | | | Credential Request) | │ +--------------------------->+ │ | Appraise Evidence | | | +-------------+ | | +------------>+ │ | Compute Attestation Results| | | +-------------+ | | +------------>+ │ | Return Attestation Results | │ +<---------------------------+ | | Invoke Claims Mapper to | | | compute Claims from AR | | +------------+ | | +<-----------+ | │ | Create & Sign Credential | | +------------+ | | +<-----------+ | │ Return Credential | | +<----------------------------+ | +------+-------+ +------------+-----------+ +-------+------+ | Workload | | Credential Authority | | Verifier | +------+-------+ +------------+-----------+ +-------+------+ ]]>

Mechanisms D Mechanism D consists of a "Credential Provisioning" phase followed by the "Credential Acquisition" phase.

Credential Provisioning Phase + │ │ │ │ Generate and Store Credential Key | | | and Key Release Policy | | | +------------+ | | | +<-----------+ | │ Return Public Portion of Credential Key | | | or Credential Key Identifier | | +<------------------------------------------+ │ │ Create Credential Request │ │ +----------------------+------------------->+ │ │ | │ Create Credential Request and │ | │ Sign with Private Credential Key | | +------------+ | | | +<-----------+ | │ Return Credential Request | │ +<---------------------+--------------------+ │ │ Request Credential (Credential Request, Workload Identity, Credential Attributes) +----------------------+--------------------------------------------->+ │ │ Create and Sign Credential | | │ | +-------------+ | │ | +------------>+ │ │ | Return Credential | +<---------------------+--------------------+-------------------------+ | Provide Workload with Credential | │ +--------------------->+ | | +---------+--------+ +------+------+ +------+------+ +-----------+------------+ | Workload Owner | | Workload │ | Key Store | | Credential Authority | +------------------+ +-------------+ +-------------+ +------------------------+ ]]>

Credential Acquisition Phase + │ │ (Evidence) | Appraise Evidence | | +------------+ | | +<-----------+ | │ │ Compute Attestation | | +------------+ Results | | +<-----------+ | │ Return | | | Attestation Results | | | (incl. Encryption Key) | | +<-----------------------+ │ │ Request Credential Key (Attestation Results) | +----------------------------------------------->+ │ Validate Attestation Results | │ against Credential Key Release Policy | | | +-------------+ | | +------------>+ │ Encrypt Credential Key to Encryption Key | | | +-------------+ | | +------------>+ │ Return Encrypted Credential Key │ +<-----------------------+-----------------------+ │ Decrypt Credential Key | | +------------+ | | +<-----------+ | | +------+-------+ +-------+------+ +-------+-----------+ | Workload | | Verifier | | Key Store | +------+-------+ +-------+------+ +-------+-----------+ ]]>

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).

Pivacy 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.

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. 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. 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 a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Confidential Computing Consortium Trustworthy Workload Identity SIG n.d. Confidential Computing Consortium Trustworthy Workload Identity SIG n.d. Confidential Computing Consortium Trustworthy Workload Identity SIG n.d. IETF n.d.

Acknowledgments The following persons, in no specific order, contributed to the work directly, participated in design team meetings, or provided valuable comments during the review of this document. Pieter Kasselman (SPIRL), Arieal Feldman (Google), Mateusz Bronk (Intel), Manu Fontaine (Hushmesh Inc.), Benedict Lau (EQTY Lab), Zvonko Kaiser (NVIDIA), David Quigley (Intel), Sal Kimmich (GadflyAI), Alex Dalton (Shielded Technologies), Eric Wolfe (Mainsail Industries), Nicolae Paladi(Canary Bit), Mark Gentry (JPMorgan Chase), Jag Raman (Oracle), Brian Hugenbruch (IBM), Jens Alberts (Fr0ntierX), Mira Spina (MITRE) and John Suykerbuyk.