Workload Identity in a Multi System Environment (WIMSE) Architecture
draft-ietf-wimse-arch-00

wimse                                                         J. Salowey
Internet-Draft                                                    Venafi
Intended status: Informational                              Y. Rosomakho
Expires: 20 October 2024                                         Zscaler
                                                           H. Tschofenig
                                                           18 April 2024

  Workload Identity in a Multi System Environment (WIMSE) Architecture
                        draft-ietf-wimse-arch-00

Abstract

   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.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Workload Identity in
   Multi System Environments Working Group mailing list
   (wimse@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/wimse/.

   Source for this draft and an issue tracker can be found at
   https://github.com/jsalowey/wimse-arch.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Salowey, et al.          Expires 20 October 2024                [Page 1]
Internet-Draft             WIMSE Architecture                 April 2024

   This Internet-Draft will expire on 20 October 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Workload Identity . . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Bootstrapping Workload Identity . . . . . . . . . . .   4
       3.1.2.  Identity Credentials  . . . . . . . . . . . . . . . .   6
     3.2.  Workload Identity Use Cases . . . . . . . . . . . . . . .   6
       3.2.1.  Basic Service Authentication and Authorization  . . .   6
       3.2.2.  Security Context Establishment and Propagation  . . .   8
       3.2.3.  Delegation and Impersonation  . . . . . . . . . . . .   8
       3.2.4.  Asynchronous and Batch Requests . . . . . . . . . . .   8
       3.2.5.  Cross-boundary Workload Identity  . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     4.1.  Traffic Interception  . . . . . . . . . . . . . . . . . .   9
     4.2.  Information Disclosure  . . . . . . . . . . . . . . . . .  10
     4.3.  Workload Compromise . . . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The increasing prevalence of cloud computing and micro service
   architectures has led to the rise of complex software functions being
   built and deployed as systems composed of workloads, where a workload
   is defined as a running instance of software executing for a specific
   purpose.

Salowey, et al.          Expires 20 October 2024                [Page 2]
Internet-Draft             WIMSE Architecture                 April 2024

   Workloads need to be provisioned with an identity when they are
   started.  Often, additional information needs to be provided, such as
   trust anchors and security context details.  Workload identity
   credential is used to authenticate communications between workloads.
   Workloads make use of identity information and additional context
   information to perform authentication and authorization.

   This architecture considers two ways to express identity information:
   X.509 certificates often used in the TLS layer and JSON Web Tokens
   (JWTs) used at the application layer.  Collectively, these are
   referred to as WIMSE tokens.  The applicability of given token format
   depends on application and security context and will be explored in
   later sections.

   Once the workload is started and has obtained identity information,
   it can start performing its functions.  Once the workload is invoked
   it may require interaction with other workloads.  An example of such
   interaction is shown in [I-D.ietf-oauth-transaction-tokens] where an
   externally-facing endpoint is invoked using conventional
   authorization mechanism, such as an OAuth 2.0 access token.  The
   interaction with other workload may require the security context
   associated with the authorization to be passed along the call chain.

   In the rest of the document we describe terminology and use cases,
   discuss details of the architecture, and discuss threats.

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

   This document uses the following terms:

   *  Workload

   A workload is a running instance of software executing for a specific
   purpose.  Workload typically interacts with other parts of a larger
   system.  A workload may exist for a very short durations of time
   (fraction of a second) and run for a specific purpose such as to
   provide a response to an API request.  Other kinds of workloads may
   execute for a very long duration, such as months or years.  Examples
   include database services and machine learning training jobs.

   *  Security Context

Salowey, et al.          Expires 20 October 2024                [Page 3]
Internet-Draft             WIMSE Architecture                 April 2024

   A security context provides information needed for a workload to
   perform its function.  This information is often used for
   authorization, accounting and auditing purposes and often contains
   information about the request being made.  Some examples include user
   information, software and hardware information or information about
   what processing has already happened for the request.  Different
   pieces of context information may originate from different sources.

   *  Identity Proxy

   Identity proxy is an intermediary that can inspect, replace or
   augment workload identity and security context information.  Identity
   proxy can be a capability of a transparent network service, such as a
   security gateway, or it can be implemented in a service performing
   explicit connection processing, such as an ingress gateway or a
   Content Delivery Network (CDN) service.

   *  Attestation

   Attestation is the function through which a task verifies the
   identity of a separate Workload.  (TBD: sync definition with
   reference RaTS architecture)

3.  Architecture

3.1.  Workload Identity

3.1.1.  Bootstrapping Workload Identity

   A workload needs to obtain its identity early in its lifecycle.  This
   identity is sometimes referred to as the "bottom turtle" on which
   further identity and security context is built.

   Identity bootstrapping often utilizes identity information
   provisioned through mechanisms specific to hosting platforms and
   orchestration services.  This initial bootstrapping information is
   used to obtain specific identity credentials for a workload.  This
   process may use attestation to ensure the workload receives correct
   identity credentials.  An example of a bootstrapping process follows.

   Figure 1 provides an example of software layering at a host running
   workloads.  During startup, workloads bootstrap their identity with
   the help of an agent.  The agent may be associated with one or more
   workloads to help ensure that workloads are provisioned with the
   correct identity.  The agent provides attestation evidence and other
   relevant information to a server.  After obtaining identity
   credentials from the Server it passes them to the workload.  The
   server validates this information and provides the agent with

Salowey, et al.          Expires 20 October 2024                [Page 4]
Internet-Draft             WIMSE Architecture                 April 2024

   identity credentials for the workloads it is associated with.  The
   server can use a variety of internal and external means to validate
   the request against policy.

     +-----------------+
     |     Server      |
     |                 |
     | +-------------+ |
     | | Attestation | |
     | +-------------+ |
     +---------+-------+
             ^ |                              . .
             | | Identity                     | | Workload
             | | Credentials                  | |    to
             | |                              | | Workload
             | |                              | | Communication
     +-------+-+------------------------------+-+-----------+
     |       | |                              v V           |
     |       | v                         +----------------+ |
     |  +----+----------+              +-+--------------+ | |
     |  | Agent         |              | Workloads      | | |
     |  |              <+--------------+>               | | |
     |  |            ^  |  Identity    |  ^             +-+ |
     |  +------------+--+  Credentials +--+-------------+   |
     |               |                    |                 |
     |               |                    | Identity        |
     |   Attestation |                    | Credentials     |
     |               v                    v                 |
     +------------------------------------------------------+
     | Host Operating System and Hardware                   |
     +------------------------------------------------------+

   Figure 1: Host Software Layering in a Workload Identity Architecture.

   How the workload obtains its identity credentials and interacts with
   the agent is subject to different implementations.  Some common
   mechanisms for obtaining this initial identity include:

   *  File System - in this mechanism the identity credential is
      provisioned to the workload via the filesystem.

   *  Local API - the identity credential is provided through an API,
      such as a local domain socket (for example SPIFFE or QEMU guest
      agent) or network API (for example Cloud Provider Metadata
      Server).

   *  Environment Variables - identity credential may also be injected
      into workloads using operating system environment variables.

Salowey, et al.          Expires 20 October 2024                [Page 5]
Internet-Draft             WIMSE Architecture                 April 2024

3.1.2.  Identity Credentials

   The Agent provisions the identity credentials to the workload.  These
   credentials are represented in form of JWT tokens and/or X.509
   certificates.

   JWT bearer tokens are presented to another party as a proof of
   identity.  They are signed to prevent forgery, however since these
   credentials are often not bound to other information it is possible
   that they could be stolen and reused elsewhere.  To reduce some of
   these risks, bearer tokens may have a short lifespan.  Alternatively,
   sender constrained tokens can be used such as TLS session binding.

   X.509 certificate credentials consist of two parts:

   *  a certificate is a signed data structure that contains a public
      key and identity information

   *  a corresponding private key

   The certificate is presented during authentication, however the
   private key is kept secret and only used in cryptographic computation
   to prove that the presenter has access to the private key that
   corresponds to the public key in the certificate.

3.2.  Workload Identity Use Cases

3.2.1.  Basic Service Authentication and Authorization

   One of the most basic use cases for workload identity is
   authentication of one workload to another, such as in the case where
   one service is making a request to another service as part of a
   larger, more complex application.  Following authentication, the
   request to the service offered by the workload it needs to be
   authorized.  Even in this simple case the identity of a workload is
   often composed of many attributes such as:

   *  Trigger Information

   *  Service Name

   *  Instance Name

   *  Role

   *  Environment

   *  Trust Domain

Salowey, et al.          Expires 20 October 2024                [Page 6]
Internet-Draft             WIMSE Architecture                 April 2024

   *  Software Attestation

   *  Hardware Attestation

   These attributes are used for various purposes such as:

   *  ensuring the request is made to the correct service or service
      instance

   *  authorizing access to APIs and resources

   *  providing an audit trail of requests within a system

   *  providing context for other decisions made within a service

   There are several methods defined to perform this authentication.
   Some of the most common include:

   *  TLS authentication of the server using X.509 certificates and
      bearer token, encoded as JWTs.

   *  Mutual TLS authentication using X.509 certificate for both client
      and server.

   *  TLS authentication of the server and HTTP request signing using a
      secret key.

   Figure 2 illustrates the communication between different workloads.
   Two aspects are important to highlight: First, there is a need to
   consider the interaction with workloads that are external to the
   trust domain (sometimes called cross-domain).  Second, the
   interaction does not only occur between workloads that directly
   interact with each other but instead may also take place across
   intermediate workloads (in an end-to-end style).

Salowey, et al.          Expires 20 October 2024                [Page 7]
Internet-Draft             WIMSE Architecture                 April 2024

     +-----------------+
     |     Workload    |
     |    (external)   |
     |       ^         |
     +-------+---------+
             |
             |
     +-------+-------------------------Trust Boundary---------------+
     |       |                                                      |
     |       |                                                      |
     |  +----+------+ Hop-by-  +-----------+ Hop-by-  +-----------+ |
     |  |    v      | Hop      |           | Hop      |           | |
     |  | Workload  | Security | Workload  | Security | Workload  | |
     |  |          <+----------+>         <+----------+>          | |
     |  |           |          |           |          |           | |
     |  |           |          |           |          |           | |
     |  |    O<-----+----------+-----------+----------+---->O     | |
     |  +-----------+   E2E    +-----------+   E2E    +-----------+ |
     |                                                              |
     |                                                              |
     +--------------------------------------------------------------+

               Figure 2: Workload-to-Workload Communication.

3.2.2.  Security Context Establishment and Propagation

   In a typical system of workloads additional information is needed in
   order for the workload to perform its function.  For example, it is
   common for a workload to require information about a user or other
   entity that originated the request.  Other types of information may
   include information about the hardware or software that the workload
   is running or information about what processing and validation has
   already been done to the request.  This type of information is part
   of the security context that the workload uses during authorization,
   accounting and auditing.  This context is propagated and possibly
   augmented from workload to workload using tokens.  Workload identity
   comes into play to ensure that the information in the context can
   only be used by an authorized workload and that the context
   information originated from an authorized workload.

3.2.3.  Delegation and Impersonation

   TBD.

3.2.4.  Asynchronous and Batch Requests

   TBD.

Salowey, et al.          Expires 20 October 2024                [Page 8]
Internet-Draft             WIMSE Architecture                 April 2024

3.2.5.  Cross-boundary Workload Identity

   As workloads often need to communicate across trust boundaries, extra
   care needs to be taken when it comes to identity communication to
   ensure scalability and privacy.  (TODO: align with OAuth cross domain
   identity and authorization)

3.2.5.1.  Egress Identity Generalization

   A workload communicating with a service, or another workload located
   outside the trust boundary may need to provide modified identity
   information.  Detailed identity of internal workload originating the
   communication is relevant inside the trust boundary but could be
   excessive for the outside world and expose potentially sensitive
   internal topology information.

   A security gateway at the edge of a trust boundary can be used to
   validate identity information of the workload, perform context
   specific authorization of the transaction and replace workload
   specific identity with a generalized one for a given trust domain.

3.2.5.2.  Inbound Gateway Identity Validation

   Inbound security gateway is a common design pattern for service
   protection.  This functionality is often found in CDN services, API
   gateways, load balancers, Web Application Firewalls (WAFs) and other
   security solutions.  Workload identity verification of inbound
   requests should be performed as a part of these security services.
   After validation of workload identity, the gateway may either leave
   it unmodified or replace it with its own identity to be validated by
   the destination.

4.  Security Considerations

4.1.  Traffic Interception

   Workloads communicating with applications may face different threats
   to traffic interception in different deployments.  In many
   deployments security controls are deployed for internal
   communications at lower layers to reduce the risk of traffic
   observation and modification for network communications.  When a
   security layer, such as TLS, is deployed in these environments.  TLS
   may be terminated in various places, including the workload itself,
   and in various middleware devices, such as load balancers, gateways,
   proxies, and firewalls.  Therefore, protection is provided only
   between each adjacent pair of TLS endpoints.  There are no guarantees
   of confidentiality, integrity and correct identity passthrough in
   those middleware devices and services.

Salowey, et al.          Expires 20 October 2024                [Page 9]
Internet-Draft             WIMSE Architecture                 April 2024

4.2.  Information Disclosure

   Observation and interception of network traffic is not the only means
   of disclosure in these systems.  Other vectors of information leakage
   is through disclosure in log files and other observability and
   troubleshooting mechanisms.  For example, an application may log the
   contents of HTTP headers containing JWT bearer tokens.  The
   information in these logs may be made available to other systems with
   less stringent access controls, which may result in this token
   falling into an attackers hands who then uses it to compromise a
   system.  This creates privacy risks and potential surface for
   reconnaissance attacks.  If observed tokens can be reused, this also
   may allow attackers to impersonate workloads.

4.3.  Workload Compromise

   Even the most well-designed and implemented workloads may contain
   security flaws that allow an attacker to gain limited or full
   compromise.  For example, a server side request forgery may result in
   the ability for an attacker to force the workload to make requests of
   other parts of a system even though the rest of the workload
   functionality may be unaffected.  An attacker with this advantage may
   be able to utilize privileges of the compromised workload to attack
   other parts of the system.  Therefore it is important that
   communicating workloads apply the principle of least privilege
   through security controls such as authorization.

5.  IANA Considerations

   This document has no IANA actions.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

6.2.  Informative References

Salowey, et al.          Expires 20 October 2024               [Page 10]
Internet-Draft             WIMSE Architecture                 April 2024

   [I-D.ietf-oauth-transaction-tokens]
              Tulshibagwale, A., Fletcher, G., and P. Kasselman,
              "Transaction Tokens", Work in Progress, Internet-Draft,
              draft-ietf-oauth-transaction-tokens-01, 16 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              transaction-tokens-01>.

Acknowledgments

   Todo: Add your name here.

Authors' Addresses

   Joseph Salowey
   Venafi
   Email: joe@salowey.net

   Yaroslav Rosomakho
   Zscaler
   Email: yaroslavros@gmail.com

   Hannes Tschofenig
   Email: hannes.tschofenig@gmx.net

Salowey, et al.          Expires 20 October 2024               [Page 11]