]> Zscaler

yrosomakho@zscaler.com

Amazon Web Services

deansaxe@amazon.com

Intuit

idimaster@gmail.com

Applications and Real-Time Workload Identity in Multi System Environments Token Translation Requirements This document outlines the requirements for workload token translation within the context of the Workload Identity in Multi System Environments (WIMSE). Token translation may be required for interoperability between workloads or for complying with security requirements of multi-system environments. This requirement document considers various aspects of token translation, such as changes in token format, content encoding, cryptographic properties, and context embedding. Additionally, this document raises security considerations to be addressed by specific token translation implementations, including replay attacks, access control, and privacy concerns. About This Document Status information for this document may be found at . Discussion of this document takes place on the Workload Identity in Multi System Environments Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Inter-workload communications rely on tokens for identification, authentication and authorization. These tokens are available in various formats including Oauth 2.0 bearer tokens, X.509 certificates, SPIFFE JWT-SVID and many others. Some of these token formats have encoding variants, offer flexible cryptographic options to address confidentiality and integrity requirements and may embed additional contextual information in various formats. This document outlines the requirements for token translations that can apply within a given token format or across token formats and defines security considerations to be addressed by specific implementations of token translation.

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

Token Translation Requirements Token translation involves transforming a token from one format or set of characteristics to another. The following requirements must be considered for effective token translation:

Token Format Change The translation service must support converting tokens from one format to another (e.g., from Oauth 2.0 Bearer Token to X.509 client certificate).

Token Encoding Change Some token formats support multiple encodings of subject and context. Token translation process must support changes to these encodings were relevant.

Changes to Cryptographic Properties of the Token Some token format support various cryptographic algorithms for digital signatures, hashing and encryption. Specific cryptographic requirements can be defined by capabilities of communicating workloads and identity proxies, inherent security of communication channels and relevant regulatory compliance. Token translation process must facilitate changes in the relevant cryptographic algorithms.

Embedding One Token in Another Certain token formats have flexibility to embed another token in the same or different format. The translation service must enable such embedding to facilitate nested authentication or delegation.

Change of Embedded Context in Token The translation service must support modifications to the embedded context within a token including attestation and assertions.

Change of Validity Constraint of the Token The translation service must allow changes to the validity constraints of a token, such as the expiration time, scope or audience.

Changing or Adding Subjects of the Token The translation service must support altering or adding subjects within the token to reflect different entities or roles.

Adding Sender Constraint to the Token The translation service must enable the addition of sender constraints to restrict who can use or forward the token.

Token Translation Mechanisms Token translation can be initiated by either the workload itself or an identity proxy. Multiple aspects of translation processes can occur simultaneously or be chained together to meet the needs of complex scenarios. Translation can also be a subject of authorization restrictions in context of impersonation or delegation.

Security Considerations The following considerations must be addressed by the token translation process.

Replay attacks Token translation process must address concern of replay attacks to ensure that unauthorised parties cannot steal and reuse workload tokens.

Access control Token translation process must have relevant authentication and authorization mechanisms to ensure required level of access control.

Privilege Escalation Token translation process must provide required validation and comply to least privilege principles to prevent unauthorized privilege escalation through token translation.

Prevention of Abuse of Token Translation Service Token translation process must consider protection of token translation service against denial of service and other abusing attacks.

Auditability Token translation process must support detailed logging options of all token translation activities to support auditing and forensic analysis.

Privacy Considerations Token translation process performed for cross-domain use cases needs to consider generalization of identity to limit exposure of internal topology of a given domain. In addition to that, token translation process must consider confidentiality of sensitive information such as identity subject and context included in the token.

IANA Considerations This document has no IANA actions.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments TODO acknowledge.