Workload Identity in Multi System Environments                D. H. Saxe
Internet-Draft                                                          
Intended status: Informational                               G. Fletcher
Expires: 24 April 2025                                       Capital One
                                                              A. Deinega
                                                                        
                                                            K. McCracken
                                                                  Google
                                                         21 October 2024


             WIMSE Token Exchange and Translation Protocol
           draft-saxe-wimse-token-exchange-and-translation-01

Abstract

   The specification defines the processes of token exchange and token
   translation for workloads.  Token exchange is introduced in
   [RFC8693], allowing the exchange of access tokens, OpenID Connect ID
   Tokens, and SAML assertions for new OAuth access tokens.  However,
   for workloads, there exist a broad array of input and output token
   types which must be considered beyond the input types supported by
   [RFC8693].  These token types include, but are not limited to, SPIFFE
   SVIDs, x.509 certificates, Kerberos service tickets, Amazon sigv4A,
   macaroons, <...>.  Further, these tokens may be encoded in formats
   including JWT OAuth 2.0 Acesss Tokens [RFC9068], CWT [RFC8392], and
   protocol buffers (protobufs).  Given the variety and complexity of
   input and output token types and encoding, a strict token exchange
   that maintains all of the contextual information from the input token
   to the output token may not be possible.  We define these non-RFC8693
   use cases with potentially lossy conversions as "token translation"
   (e.g. information may be lost in translation).  In this document we
   describe a workload profile for token exchange, using the mechanisms
   in [RFC8693], and a new set of translations between arbitrary token
   types.  Additionally, we define mechanisms to enrich tokens during
   translation to support the use cases defined in (todo: add link to
   use cases doc).

About This Document

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

   The latest revision of this draft can be found at
   https://deansaxe.github.io/wimse-token-exchange-and-translation/
   draft-saxe-wimse-token-exchange-and-translation.html.  Status
   information for this document may be found at
   https://datatracker.ietf.org/doc/draft-saxe-wimse-token-exchange-and-
   translation/.



Saxe, et al.              Expires 24 April 2025                 [Page 1]

RFC 1              WIMSE Token Exchange & Translation       October 2024


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

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

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

   This Internet-Draft will expire on 24 April 2025.

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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Token Context Enrichment  . . . . . . . . . . . . . . . .   5
     4.2.  Lossy Translation . . . . . . . . . . . . . . . . . . . .   5



Saxe, et al.              Expires 24 April 2025                 [Page 2]

RFC 1              WIMSE Token Exchange & Translation       October 2024


   5.  Token Translation Endpoint  . . . . . . . . . . . . . . . . .   5
   6.  Token Translation Profiles  . . . . . . . . . . . . . . . . .   6
     6.1.  X.509 Certificate to Access Token Profile . . . . . . . .   6
   7.  Conventions and Definitions . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   10. Appendices  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Appendix 1 - Non-normative token exchange examples . . .  11
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   This specification defines a protocol for converting from one
   security token to another with support for both lossless and lossy
   conversions.  We refer to the lossless exchange as "token exchange"
   following the model defined in OAuth 2.0 Token Exchange [RFC8693].
   In this document we profile [RFC8693] to enable OAuth token exchange
   for workloads where the output is an OAuth Access Token or Refresh
   Token where no data is lost during the exchange.  "Token translation"
   describes all other conversions, including those where data loss may
   occur during conversion.  The terms Security Token, Security Token
   Service (STS), delegation, and impersonation are used in this
   document following the definitions in [RFC8693].

   Within the realm of workload identities, there are numerous types of
   security tokens that are commonly used including SPIFFE SVIDs, OAuth
   2.0 Bearer Access Tokens [RFC6750], and x.509 certificates.
   Additionally, security tokens are encoded in multiple formats such as
   JSON, CBOR, and protobufs.  In order to provide a mechanism for
   interoperability between different workloads we require the ability
   to convert from one token type or encoding to another for use across
   disparate systems.

   In addition to translating security tokens between different types
   and formats, workload identity systems must be able to support
   changing the cryptographic properties of tokens, embedding tokens in
   one another, change the embedded context in a token, change the
   validity constraints, change or add subjects to the token, or add
   sender constraints.  This set of use cases for token exchange and
   translation are further described in https://github.com/yaroslavros/
   wimse-tokentranslation-requirements/blob/main/draft-rosomakho-wimse-
   tokentranslation-requirements.md. (todo: replace with a link to the
   ID once published.)






Saxe, et al.              Expires 24 April 2025                 [Page 3]

RFC 1              WIMSE Token Exchange & Translation       October 2024


2.  Notational Conventions

   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.

3.  Terminology

   TODO: Define terms used by this specification

   *  authorization server [RFC6749
      (https://datatracker.ietf.org/doc/html/rfc6749)]

   The server issuing access tokens to the client after successfully
   authenticating the resource owner and obtaining authorization.

   *  workload [draft-ietf-wimse-arch
      (https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch)]

   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.

   *  token

   An integrity-protected string denoting a lifetime and specific
   attributes of a security context.  In the context of WIMSE, the token
   denotes attributes of a _workload_ security context.

4.  Overview

   Token translation fills a gap that development teams must solve for
   themselves today without standardized mechanisms.  For example, a
   common SPIFFE use case is to have a Kubernetes workload assume an AWS
   IAM role to access an S3 bucket.  This is accomplished by creating an
   OpenID Provider (OP) in the Kubernetes cluster and configuring AWS
   IAM as a Relying Party (RP) to obtain an ID token from the SPIFFE
   service.  Using the id token, AWS STS AssumeRoleWithWebIdentity
   generates temporary sigV4 credentials for AWS allowing the workload
   to assume an AWS role and any permissions assigned to that role.
   Similar mechanisms have been designed to support multiple cloud
   providers in the absence of standardized protocols.



Saxe, et al.              Expires 24 April 2025                 [Page 4]

RFC 1              WIMSE Token Exchange & Translation       October 2024


   Token translation accounts for different token types, formats,
   encodings, and encyryption allowing for translation between most, but
   not all, token types using token translation profiles.  This protocol
   does not define the specifics of token translation between arbitrary
   token types.  Profiles must be defined to describe token translations
   between different token types, including any loss of context during
   translation.  Where the input and output token are of the same type
   and the conversion is lossless, the protocol defined within this
   document is sufficient to meet the use cases defined in "USE CASES
   DOC".  Not all token input/output pairs are expected to be profiled.

4.1.  Token Context Enrichment

   TODO - what context do we enrich tokens with during translation?
   Embedding tokens, attestations, assertions, validity, change/add
   subject, sender constraints.  This doc can give specific guidance on
   adding context to a scoped set of token types that are common.  Maybe
   a reference to the use cases is sufficient, along with a short
   description of any fields that the translation endpoint MUST add to a
   newly issued token.

4.2.  Lossy Translation

   TODO - define what we mean by lossy.  What's lost?  Does this mean
   that some token translations lose valuable information?  TODO -
   provide a specific lossy scenario and use case.

   Translation may be lossless, such as when exchanging an input token
   for an output token of the same format, or lossy when exchanging an
   input token for an output token of a different format.  An example of
   lossy translation is detailed in the example above.  In this case,
   the aud claim of the id token maps to the AWS IAM role used to create
   the AWS temporary credentials.  The aud (if no azp claim is present),
   sub, and amr claims are mapped to STS Session Keys with the same
   name.  Other claims in the id token are dropped, resulting in an loss
   of context.

   Lossy translation may impact downstream systems.  Implementers must
   be aware of the risks of lost context through token translation.

5.  Token Translation Endpoint

   TODO - Define a new translation endpoint.








Saxe, et al.              Expires 24 April 2025                 [Page 5]

RFC 1              WIMSE Token Exchange & Translation       October 2024


6.  Token Translation Profiles

   TODO - this draft does not define normative specs for translating
   from arbitrary format to another arbitrary format.  Profiles
   describing specific token translations must be developed and their
   names (possibly?) registered with IANA.  Profiles will define any
   losses that may occur during translation and the risks associated
   with the loss of context.  Not all token pairs can be translated,
   some may only be translatable in one direction.

6.1.  X.509 Certificate to Access Token Profile

   In [draft-ietf-wimse-arch (https://datatracker.ietf.org/doc/html/
   draft-ietf-wimse-arch)], Workloads may be issued Identity Credentials
   in the form of X.509 Certificates [RFC5280
   (https://datatracker.ietf.org/doc/html/rfc5280)], for Workload-to-
   Workload communication over mututal TLS (mTLS).  Workload Agents must
   request the X.509 Certificate Credentials by undergoing Attestation
   against both the local Host Operating System and Hardware, and a
   remote Server with access to a Certificate Authority (CA).  If the
   Server confirms sufficient evidence has been presented for
   Attestation, the Workload is issued X.509 Certificates identifying
   it.  The identity is conveyed in a URI Subject Aleternative Name
   (SAN) within the X.509 Certificate.

   Authorization servers issue OAuth 2.0 Access Tokens to client
   applications.  If the resource owner has granted sufficient
   privileges to a protected resource, the issued access token can be
   used to access protected resources on resource servers.

   The Workloads possessing X.509 Certificate Identity Credentials may
   operate in an environment that is isolated from the security domain
   of a protected resource.  In the case where the protected resource is
   protected by an external OAuth 2.0 Authorization Server, X.509
   Certificate-to-Access Token exchange may be configured.  The Trust
   across the isolated security domains must first be established.
   Relying parties must describe, via secure configurations, a mapping
   that crosses the security domains from the X.509 certificate
   authority(ies) to the OAuth 2.0 authorization server.  The
   specification for authenticating the relying party and for the format
   of the configurations are out of scope of this specification.  The
   following configurations MAY be registered by a relying party at the
   OAuth 2.0 authorization server:








Saxe, et al.              Expires 24 April 2025                 [Page 6]

RFC 1              WIMSE Token Exchange & Translation       October 2024


   1.  A set of one or more Trust Anchors MUST be configured for the
       relying party at the OAuth 2.0 authorization server, representing
       authoritative entities with a public key and associated data, as
       defined in [RFC6024 (https://datatracker.ietf.org/doc/html/
       rfc6024)].  These configurations MUST be represented as X.509 CA
       certificates in either DER or PEM format.

   2.  A set of intermediate entities with public key and associated
       data, expressed as X.509 CA certificates in either DER or PEM
       format, MAY be configured for the relying party at the OAuth 2.0
       authorization server.  The intermediate CA certificates are for
       the purposes of certificate chain path building in scenarios
       where clients cannot or may not provide these intermediate
       certificates during mTLS handshakes.

   3.  A mapping MUST describe the certificate attribute(s) used to
       select and or construct the subject claim in the OAuth 2.0 access
       tokens.  Possible X.509 certificate properties include the
       following:

       *  subject's common name (CN)

       *  first subject alternative names (SAN) DNS Name entry

       *  first subject alternative names (SAN) URI entry

   4.  A set of conditions MAY be defined to constrain the client
       certificates that SHALL be accepted.  An example might be a
       constraint that the certificate's first SAN URI entry must start
       with spiffe://example.com/foo, or that the certificate's first
       SAN DNS Name entry must end with .example.com.

   5.  A mapping MAY describe additional certificate attributes that may
       be encoded in the issued OAuth 2.0 access tokens to be
       interpreted as part of access policy decisions.  These MAY
       include any of the following properties

       *  hex-encoded serial number

       *  subject DN common name

       *  subject DN organization name

       *  subject DN subject organization unit

       *  issuer DN common name

       *  issuer DN organization name



Saxe, et al.              Expires 24 April 2025                 [Page 7]

RFC 1              WIMSE Token Exchange & Translation       October 2024


       *  issuer DN organization unit

       *  the first subject alternative name (SAN) of type DNS name

       *  the first subject alternative name (SAN) of type URI

   Compatible OAuth 2.0 Authorization Servers supporting this token
   exchange profile MUST supports mTLS.  After the relying party has
   registered an X.509 Certificate federation profile with the OAuth 2.0
   authorization server, in order to obtain access tokens, Workloads
   MUST present their X.509 Certificates during mTLS handshakes to
   establish a connection to the OAuth 2.0 Authorization Server.
   Workloads MUST then send a request to token endpoint, in the manner
   described in [RFC8693 (https://datatracker.ietf.org/doc/html/
   rfc8693)].  The access token request is sent with the following
   properties:

   *  grant_type: REQUIRED.  The value urn:ietf:params:oauth:grant-
      type:token-exchange indicates that a token exchange is being
      performed.

   *  resource: OPTIONAL.  A URI that indicates the target service or
      resource where the client intends to use the requested security
      token.

   *  audience: REQUIRED for this Profile.  A URI or other unique
      identifier for the relying party, assigned by the OAuth 2.0
      Authorization Server.

   *  scope: OPTIONAL.  A list of space-delimited, case-sensitive
      strings, as defined in Section 3.3
      (https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) of
      [RFC6749 (https://datatracker.ietf.org/doc/html/rfc6749)], that
      allow the client to specify the desired scope of the requested
      security token in the context of the service or resource where the
      token will be used.

   *  requested_token_type: urn:ietf:params:oauth:token-
      type:access_token

   *  subject_token: TBD.  While this field is listed as REQUIRED for
      token exchange in Section 2.1
      (https://datatracker.ietf.org/doc/html/rfc8693#name-request) of
      [RFC8693 (https://datatracker.ietf.org/doc/html/rfc8693)], in this
      case supplying the subject token again may be redundant, since it
      was already conveyed during the mTLS handshake.  It is unclear
      whether repeating it here adds additional value.  If supplied, it
      introduces the possibility that the client sends the wrong value,



Saxe, et al.              Expires 24 April 2025                 [Page 8]

RFC 1              WIMSE Token Exchange & Translation       October 2024


      complicating client integration.  It adds network overhead of a
      few KB, which could grow larger for longer certificate chains.  It
      might be best to mark this as: OPTIONAL.  The Workload's X.509
      Certificate chain.  The X.509 Certificate chain MUST chain to a
      previously-configured Trust Anchor certificate for the relying
      party, either directly or through one of the previously-configured
      Intermediate CA path-building certificates.  This field MUST be
      expressed as a PEM-encoded certificate chain with newline
      characters removed.

   *  subject_token_type: urn:ietf:params:oauth:token-type:mtls

   The request MAY ONLY be accepted if the X.509 Certificate used during
   mTLS chain to a previously-configured Trust Anchor via a certificate
   path that may include previously-configured intermediate CA
   certificates.  The previously-configured subject claim selector must
   be provide a non-blank string from the certificate.  The previously-
   configured conditions must accept the X.509 Certificate.

   The response document contains the following properties (per [RFC8693
   (https://datatracker.ietf.org/doc/html/rfc8693)]):

   *  access_token: REQUIRED.  The security token issued by the
      authorization server in response to the token exchange request.

   *  issued_token_type: REQUIRED.  Must be urn:ietf:params:oauth:token-
      type:access_token for this Profile.

   *  token_type: REQUIRED.  Must be bearer for this Profile.

   *  expires_in: RECOMMENDED.  The validity lifetime, in seconds, of
      the token issued by the authorization server.

   *  scope: OPTIONAL if the scope of the issued security token is
      identical to the scope requested by the client; otherwise, it is
      REQUIRED.

   *  refresh_token: MUST NOT be returned for this Profile.

   The X.509 Certificate-to-Access Token Exchange Profile MUST NOT relax
   the validity constraint of the input security context.  The returned
   Access Token MUST NOT have a not before claim that preceeds the
   notBefore constraint of the X.509 Certificate used.  The returned
   Access Token MUST NOT have an expiration time claim that exceeds the
   notAfter constraint of the X.509 Certificate used.






Saxe, et al.              Expires 24 April 2025                 [Page 9]

RFC 1              WIMSE Token Exchange & Translation       October 2024


   To mitigate the impact of Access Token theft, it is RECOMMENDED that
   the returned Access Token be sender-constrained.  The Authorization
   Server MAY bind the Access Token to the X.509 Certificate that was
   used to obtain it, in the manner described in Section 3
   (https://datatracker.ietf.org/doc/html/rfc8705#name-mutual-tls-
   client-certifica) of [RFC8705 (https://datatracker.ietf.org/doc/html/
   rfc8705)].  Based on authentication policy, Resource Servers MAY
   enforce that an Access Token bound to an X.509 Certificate CAN NOT be
   used to access any protected resources, unless the same X.509
   Certificate was used during the mTLS handshake to the Resource
   Server.

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

8.  Security Considerations

   As countermeasures against replay attacks and various forms of
   misuse, an authorization server performing token exchange - MUST
   ensure a client (whether it is an OAuth client or a workload) is
   allowed to perform such operation. - SHOULD ensure that a provided
   security token allows to perform such operation on it. - SHOULD
   ensure it itseld, as an AS, is the intended audience of a token being
   exchanged.  It is typical for self-contained tokens to include the
   aud claim (an array of strings) representing their intended audience
   (other types of tokens provide other means for the same). - a value
   in the subject_token_type parameter MUST correspond to an actual type
   of a security token provided in the subject_token parameter
   ([RFC8693]).  These countermeasures become even more significant when
   an entity issuing security tokens and an AS performing exchange of
   them reside in different security domains.

   An extra care should be taken for tokens that can be passed around
   using the front channel, and for those tokens that do not explicitly
   define their type.  Examples here would be OpenID Connect ID Token,
   and various assertions represented as JWTs.

   TODO Security - data loss in token translation may impact authZ
   decisions.  Be careful when allowing multiple token translations
   since losses may grow over each step of translation.






Saxe, et al.              Expires 24 April 2025                [Page 10]

RFC 1              WIMSE Token Exchange & Translation       October 2024


   Embedding input tokens into output tokens can reduce this risk by
   allowing more complete context, at the risk of expanding the token
   size beyond what is practical.

9.  IANA Considerations

   This document has no IANA actions.

10.  Appendices

10.1.  Appendix 1 - Non-normative token exchange examples

11.  Normative References

   [OIDC]     Sakimura, N., Bradley, J., Jones, M., Medeiros, B. de.,
              and C. Mortimore, "OpenID Connect Core 1.0 incorporating
              errata set 2", November 2014,
              <https://openid.net/specs/openid-connect-core-1_0.html>.

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

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750,
              DOI 10.17487/RFC6750, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6750>.

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

   [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
              "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
              May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

   [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
              and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
              DOI 10.17487/RFC8693, January 2020,
              <https://www.rfc-editor.org/rfc/rfc8693>.

   [RFC9068]  Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
              Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
              2021, <https://www.rfc-editor.org/rfc/rfc9068>.






Saxe, et al.              Expires 24 April 2025                [Page 11]

RFC 1              WIMSE Token Exchange & Translation       October 2024


Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Dean H. Saxe
   Email: dean@thesax.es


   George Fletcher
   Capital One
   Email: george.fletcher@capitalone.com


   Andrii Deinega
   Email: andrii.deinega@gmail.com


   Ken McCracken
   Google
   Email: kenmccracken@google.com





























Saxe, et al.              Expires 24 April 2025                [Page 12]