]> Palo Alto Networks

joe@salowey.net

Zscaler

yaroslavros@gmail.com

Applications and Real-Time Workload Identity in Multi System Environments workload identity The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document profiles a workload authentication based on X.509 workload identity certificates using mutual TLS (mTLS). About This Document The latest revision of this draft can be found at . 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 This document defines authentication and authorization in the context of interaction between two workloads. This is the core component of the WIMSE architecture . This document focuses on using X.509 workload identity certificates as defined in to authenticate the communication between workloads using TLS. The use of TLS for authentication is widely deployed, however it may not be applicable to all environments. For example, some deployments may lack the PKI infrastructure necessary to manage certificates or inter-service communication consists of multiple separate TLS hops. For these cases, other options based on Workload Identity Tokens (WIT) as defined in may be more appropriate since they are not based on X.509 certificates and are communicated at the application layer rather than the transport layer.

Deployment Architecture and Message Flow Refer to for the deployment architecture which is common to all protection options.

Conventions and Definitions All terminology in this document follows . 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.

Using Mutual TLS for Workload-to-Workload Authentication As noted in the introduction, for many deployments, transport-level protection of application traffic using TLS is ideal.

The Workload Identity Certificate Workload identity certificates are X.509 certificates that carry workload identifiers as described in .

Workload Identity Certificate Validation Workload Identity Certificates may be used to authenticate both the server and client side of the connections. When validating a Workload Identity Certificate, the relying party MUST use the trust anchors configured for the trust domain in the workload identity to validate the peer's certificate. Other PKIX path validation rules apply. Workloads acting as TLS clients and servers MUST validate that the trust domain portion of the Workload Identity Certificate matches the expected trust domain for the other side of the connection. Servers wishing to use the Workload Identity Certificate for authorizing the client MUST require client certificate authentication in the TLS handshake. Other methods of post handshake authentication are not specified by this document. Workload Identity Certificates used by TLS servers SHOULD have the id-kp-serverAuth extended key usage field set and Workload Identity Certificates used by TLS clients SHOULD have the id-kp-clientAuth extended key usage field set. A certificate that is used for both client and server connections may have both fields set. This specification does not make any other requirements beyond on the contents of Workload Identity Certificates or on the certification authorities that issue workload certificates.

Server Name Validation If a WIMSE client connects to a server using a DNS hostname, the server SHOULD present a certificate containing a matching DNS Subject Alternative Name (DNS-ID), and the client MUST perform standard TLS server identity validation as specified in . In deployments that use Workload Identity Certificates, successful DNS hostname validation authenticates the server endpoint, while the workload identifier provides an additional identity that can be used for workload-specific authorization and policy decisions. Some deployments may not use DNS names for server discovery. In such cases, the client MUST be configured with sufficient information to determine the expected workload identity of the server and MUST validate that identity before accepting the connection. The host portion of the workload identifier is NOT treated as a hostname as specified in , but rather as a trust domain. The server identity is encoded in the path portion of the workload identifier in a deployment-specific way. Validation of the workload identity may consist of an exact match of the trust domain and path, or may follow deployment-specific rules. The path portion of the workload identifier MUST always be interpreted within the context of the trust domain. In most cases it is preferable to validate the entire workload identifier; see for additional implementation guidance.

Client Authorization Using the Workload Identity The server application retrieves the workload identifier from the client certificate's URI subjectAltName (see ), which in turn is obtained from the TLS layer. The identifier is used in authorization, accounting and auditing. For example, the full workload identifier may be matched against ACLs to authorize actions requested by the peer and the identifier may be included in log messages to associate actions to the client workload for audit purposes. A deployment may specify other authorization policies based on the specific details of how the workload identifier is constructed. The path portion of the workload identifier MUST always be considered in the scope of the trust domain. See for additional security implications of workload identifiers.

IANA Considerations This document does not include any IANA considerations.

Security Considerations This document relies on the security properties of TLS , PKIX path validation , and workload identity certificate validation as described in . Implementations MUST validate the peer certificate chain, the applicable extended key usage, and the workload identifier according to the rules in this document before using the authenticated identity for authorization decisions. Workload identifiers are meaningful only within the scope of their trust domain. Authorization policies MUST NOT evaluate only the path or other sub-components of a workload identifier without also considering the trust domain and the trust anchor used to validate the certificate. Failure to bind the workload identifier to the expected trust domain and configured trust anchor can allow one trust domain to impersonate workloads from another domain. When a server is identified by a DNS hostname, clients SHOULD authenticate the server using standard TLS DNS hostname validation as specified in . Workload identity validation complements, rather than replaces, DNS-based server authentication by providing an authenticated workload identity for authorization decisions. Only deployments that do not rely on DNS-based server identification should authenticate the server solely using its workload identity. Accepting any certificate issued by a trusted workload CA without validating that it represents the intended server workload would allow mis-issued or otherwise valid certificates for other workloads to be used for impersonation. Client authentication is based on the workload identity certificate presented by the TLS client. A server performing mTLS authentication MUST validate the client certificate chain, the associated trust domain, and the workload identifier before using that identity for authorization, accounting, or auditing. Accepting any valid client certificate from a trusted CA without checking whether the authenticated workload is authorized for the requested action can allow unintended workloads to gain access. Workload identity certificates are often issued to dynamic or short-lived workloads. Deployments SHOULD use certificate lifetimes that are appropriate for the workload environment and SHOULD provide timely revocation or replacement mechanisms when workload identity, authorization, or runtime state changes. Long-lived certificates increase the impact of private key compromise and stale authorization decisions. Private keys associated with workload identity certificates MUST be protected against disclosure and unauthorized use. In particular, deployments MUST NOT share private keys across unrelated workload instances. Where possible, private keys SHOULD be generated and held in the workload runtime environment or a dedicated key protection mechanism, rather than distributed over the network. This document specifies authentication at the TLS layer. If application traffic traverses intermediaries, gateways, service meshes, or other middleboxes that terminate and re-establish TLS, the application endpoint might not be directly authenticated to the peer workload. In such deployments, authorization decisions need to account for where TLS is terminated and whether the authenticated certificate represents the peer workload, an intermediary, or another delegated entity. Where end-to-end workload authentication context is required across such boundaries, deployments SHOULD use an application-layer WIMSE protection mechanism in addition to TLS-layer server authentication. Client certificate authentication exposes the client workload identity to the TLS server during the handshake. Deployments should consider whether disclosure of workload identifiers to servers, intermediaries, or logs is acceptable for their threat model. Workload identifiers included in certificates and audit records should avoid embedding unnecessary sensitive information. Authorization decisions based on workload identity need to be made using the authenticated identity obtained from the validated certificate, not from unauthenticated application-layer metadata such as HTTP headers. Application-layer identity assertions can be useful for logging or context, but they MUST NOT override the identity established by mutual TLS unless protected and authorized by another mechanism.

References Normative References Ping Identity CyberArk Defakto Security Intuit Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. 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. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. Independent This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. Informative References CyberArk Zscaler University of Applied Sciences Bonn-Rhein-Sieg 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 software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information.

Document History RFC Editor: please remove before publication.

draft-ietf-wimse-mutual-tls-02

• Improved Server Name Validation section

draft-ietf-wimse-mutual-tls-01

• Added security considerations

draft-ietf-wimse-mutual-tls-00

• Initial version, extracted from the draft-ietf-wimse-s2s-protocol-07 S2s draft with minimal edits.
• added security consideration for Server Name Validation

Acknowledgments We thank Yaron Sheffer, Arndt Schwenkschuster, Brian Campbell, and Daniel Feldman for their contributions to earlier versions of this document.