[saag] FW: [secdir] [new-work] WG Review: Workload Identity in Multi System Environments (wimse)

[Roman Danyliw <[e-mail]>]

Raising visibility that the security-adjacent WIMSE BOF at IETF 118 is now community review on forming a WG until 2024-03-04.  See below or https://mailarchive.ietf.org/arch/msg/ietf-announce/PAuVMopE2Bai6cli4zYodkWxIzA/.

Roman

-----Original Message-----
From: secdir <[e-mail]> On Behalf Of The IESG
Sent: Monday, February 26, 2024 12:14 PM
To: [e-mail]
Subject: [secdir] [new-work] WG Review: Workload Identity in Multi System Environments (wimse)

Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe.


A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list ([e-mail]) by 2024-03-04.

Workload Identity in Multi System Environments (wimse)
-----------------------------------------------------------------------
Current status: BOF WG

Chairs:
  Joseph Salowey <[e-mail]>
  Yaron Sheffer <[e-mail]>

Assigned Area Director:
  Murray Kucherawy <[e-mail]>

Applications and Real-Time Area Directors:
  Murray Kucherawy <[e-mail]>
  Francesca Palombini <[e-mail]>

Technical advisors:
  Paul Wouters <[e-mail]>

Mailing list:
  Address: [e-mail]
  To subscribe: https://www.ietf.org/mailman/listinfo/wimse
  Archive: https://mailarchive.ietf.org/arch/browse/wimse/

Group page: https://datatracker.ietf.org/group/wimse/

Charter: https://datatracker.ietf.org/doc/charter-ietf-wimse/

Background & Motivation

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 working group will focus on the unique identity and access management aspects of workloads at runtime and their execution context, particularly focusing on the propagation, representation, and processing of workload identities. Though the following items are relevant to the context of workloads, these items are not workloads and this working group will not define:

* Static software identities and provenance, such as software bill of materials (SBOM)

* Personal identities

* Deployment chains

* Supply chain management

The rise of diverse service platforms and the drive for business flexibility, cost-efficiency, resilience, and compliance make maintaining least privilege access for workloads increasingly complex. As a result of the adoption of microservice architectures, services are composed of multiple workloads that need to authenticate to each other while making authorization decisions based on the original caller, their context, and the actions of other workloads that acted on a transaction. These workloads are often distributed across trust boundaries, without a single centralized controller managing the different identities or authorization policies.

Workloads are often associated with complex context, including user identity, software origin, and hardware-based attestation. Communicating this context involves a unique set of challenges across different scenarios including multi-hop, long-lived and asynchronous transactions.

While several standards and open-source projects offer foundational elements for secure workload identity, there remains a lack of clarity in their interoperation and combination. These technologies (specifically: OAuth, JWT, and SPIFFE) have been combined in a variety of ways in practice, but the solutions have existed in relative isolation. This ambiguity can lead to inconsistencies, interoperability issues, and potential security vulnerabilities.

Goals

The Workload Identity in Multi-Service Environments (WIMSE) working group is chartered to address the challenges associated with implementing fine-grained, least privilege access control for workloads deployed across multiple service platforms, spanning both public and private clouds. The work will build on existing standards, open source projects, and community practices, focusing on combining them in a coherent manner to address multi-service workload identity use cases such as those identified in the Workload Identity Use Cases I-D (draft-gilman-wimse-use-cases).

The goal of the WIMSE working group is to identify, articulate, and bridge the gaps and ambiguities in workload identity problems and define solutions across a diverse set of platforms and deployments, building on various protocols used in workload environments.  The WG will standardize solutions (as proposed standard) and document existing or best practices (as informational or BCP) per the Program of Work.

While recognizing that the broader workload ecosystem uses a variety of application protocols (e.g., gRPC, Kafka and GraphQL), the WG will focus on only specific REST-based technologies using HTTP. WIMSE will also serve as a standing venue to discuss operational experience and requirements with workload identity.  These discussions need not be restricted to technologies currently in scope to this charter.

Dependencies and Liaisons

The WIMSE working group will closely collaborate with:

* Other IETF working groups that address topics related to identity, authentication, and authorization, including, but not limited to, OAuth, SCIM, SCITT, and RATS.

* The Cloud Native Computing Foundation (CNCF), particularly with regard to the SPIFFE/SPIRE project.

* The OpenID Foundation.

Program of Work

The WIMSE WG will focus on the following program of work:

* [I] WIMSE architecture: The group will develop a document that defines common terminology, discusses workload attestation and identity, specifies a threat model, and defines a set of architectural components and several compositions of those components. The document will describe 2-3 scenarios and for each of them, it will identify key points needed for interoperability.

* [PS] Securing service-to-service traffic: a JOSE-based WIMSE token solution to protect a chain of HTTP/REST calls, within and across trust domains. The document should support identification of microservices and cryptographic binding of the token to the caller’s identity and optionally, binding to the transaction. It should support associating context with the token, including but not limited to user identity, platform attestation, and SBOM artifacts.
This deliverable includes both a token format and its usage, including binding to the caller’s identity.

* [PS] Token issuance: A document describing a method for local issuance of WIMSE tokens where the local issuer operates with limited authority. The local issuer can be the workload itself or another workload deployed nearby.

* [PS] Token exchange: Specify a protocol for exchanging an incoming token of one format for a workload-specific WIMSE token at security boundaries (possibly based on RFC 8693). Additionally, this token exchange will require specifying as proposed standard  a small set of token exchange profiles (mapping of claims) between existing and new WIMSE token formats.

* [I or BCP] Document and make recommendations based on operational experience to existing token distribution practices for workloads.

Milestones:

  Nov 2024 - Submit informational document describing considerations for
  filesystem-based JWT delivery in Kubernetes to the IESG

  Mar 2025 - Submit proposed standard for a JOSE-based WIMSE token solution
  to protect a chain of HTTP/REST calls for workloads to the IESG

  Mar 2025 - Submit proposed standard document specifying a token exchange
  profile that maps claims from SPIFFE-identified services to OAuth-protected
  resources, and vice versa to the IESG

  Mar 2025 - Submit a proposed standard for a token exchange profile mapping
  the JWT BCP [RFC9068] to the JOSE-based WIMSE token to the IESG

  Nov 2025 - Submit a protocol as proposed standard for exchanging an
  incoming token of one format for a workload-specific token at security
  boundaries to the IESG

  Jul 2026 - Submit informational document describing the WIMSE architecture
  to the IESG



_______________________________________________
new-work mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/new-work
_______________________________________________
secdir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdir
wiki: https://wiki.ietf.org/group/secdir/SecDirReview