Internet Engineering Task Force (IETF) K. McCracken Request for Comments: 1 Google Category: Informational 3 December 2024 ISSN: 2070-1721 WIMSE x.509 to Access Token Exchange Profile Abstract TODO Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc1. 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. Notational Conventions 3. Terminology 4. Overview 4.1. X.509 Certificate to Access Token Profile 5. Conventions and Definitions 6. Security Considerations 7. IANA Considerations 8. Appendices 8.1. Appendix 1 - Non-normative token exchange examples 9. Normative References Acknowledgments Author's Address 1. Introduction TODO 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 TODO 4.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: 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 * 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 support 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: MUST be urn:ietf:params:oauth:token- type:access_token for this token exchange profile. * subject_token: REQUIRED. Either the fixed string mtls_client_certificate or an X.509 Certificate Chain value. Whether conveyed by-reference to mTLS using mtls_client_certificate or as an X.509 Certificate Chain value, the Authorization Server MUST validate that the X.509 Certificate chain can be validated by a path 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. - The value mtls_client_certificate instructs the Authorization Server to obtain the subject token from the client's mTLS Certificate message, as defined in Section 2 (https://datatracker.ietf.org/doc/html/rfc8446#section-2) of [RFC8446 (https://datatracker.ietf.org/doc/html/rfc8446)]. - Any value other than mtls_client_certificate MUST be parsed as an X.509 Certificate Chain for this token exchange profile. The X.509 Certificate chain MUST be formatted as described in the "x5c" (X.509 Certificate Chain) Header Parameter in Section 4.1.6 (https://www.rfc-editor.org/rfc/ rfc7515.html#section-4.1.6) of [RFC7515 (https://www.rfc- editor.org/rfc/rfc7515.html)]. The leaf X.509 Certificate used in the subject_token MUST match the leaf X.509 Certificate used during mTLS.* subject_token_type: MUST be urn:ietf:params:oauth:token-type:mtls for this token exchange profile. The request MUST 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 select 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. 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. 5. 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. 6. Security Considerations TODO 7. IANA Considerations This document has no IANA actions. 8. Appendices 8.1. Appendix 1 - Non-normative token exchange examples 9. 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [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, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . Acknowledgments TODO acknowledge. Author's Address Ken McCracken Google Email: kenmccracken@google.com