WIMSE Token Exchange and Translation Protocol
draft-saxe-wimse-token-exchange-and-translation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Dean H. Saxe , George Fletcher , Andrii Deinega | ||
| Last updated | 2024-07-08 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-saxe-wimse-token-exchange-and-translation-00
Workload Identity in Multi System Environments D. H. Saxe
Internet-Draft
Intended status: Informational G. Fletcher
Expires: 9 January 2025 Capital One
A. Deinega
8 July 2024
WIMSE Token Exchange and Translation Protocol
draft-saxe-wimse-token-exchange-and-translation-00
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 9 January 2025 [Page 1]
RFC 1 WIMSE Token Exchange & Translation July 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 9 January 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 . . . . . . . . . . . . . . . . 4
4.2. Lossy Translation . . . . . . . . . . . . . . . . . . . . 5
Saxe, et al. Expires 9 January 2025 [Page 2]
RFC 1 WIMSE Token Exchange & Translation July 2024
5. Token Translation Endpoint . . . . . . . . . . . . . . . . . 5
6. Token Translation Profiles . . . . . . . . . . . . . . . . . 5
7. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Appendices . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Appendix 1 - Non-normative token exchange examples . . . 6
11. Normative References . . . . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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 9 January 2025 [Page 3]
RFC 1 WIMSE Token Exchange & Translation July 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
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.
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.
Saxe, et al. Expires 9 January 2025 [Page 4]
RFC 1 WIMSE Token Exchange & Translation July 2024
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.
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.
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.
Saxe, et al. Expires 9 January 2025 [Page 5]
RFC 1 WIMSE Token Exchange & Translation July 2024
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.
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>.
Saxe, et al. Expires 9 January 2025 [Page 6]
RFC 1 WIMSE Token Exchange & Translation July 2024
[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>.
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
Saxe, et al. Expires 9 January 2025 [Page 7]