Workload Identity in Multi System Environments J. Salowey Internet-Draft Palo Alto Networks Intended status: Standards Track Y. Rosomakho Expires: 27 April 2027 Zscaler 24 October 2026 Workload Authentication Using Mutual TLS draft-ietf-wimse-mutual-tls-03 Abstract 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 workload authentication based on X.509 Workload Identity Certificates using mutual TLS (mTLS). 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://ietf-wg- wimse.github.io/draft-ietf-wimse-s2s-protocol/draft-ietf-wimsemutual- tls.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-wimse-mutual-tls/. 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/ietf-wg-wimse/draft-ietf-wimse-s2s-protocol. 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/. Salowey & Rosomakho Expires 27 April 2027 [Page 1] Internet-Draft Workload MTLS October 2026 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 27 April 2027. Copyright Notice Copyright (c) 2026 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 1.1. Deployment Architecture and Message Flow . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Using Mutual TLS for Workload-to-Workload Authentication . . 3 3.1. The Workload Identity Certificate . . . . . . . . . . . . 4 3.2. Workload Identity Certificate Validation . . . . . . . . 4 3.2.1. Server Name Validation . . . . . . . . . . . . . . . 5 3.3. Client Authorization Using the Workload Identity . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5.1. Certificate and Identity Validation . . . . . . . . . . . 6 5.2. Certificate and Private Key Management . . . . . . . . . 7 5.3. TLS Termination at Intermediaries . . . . . . . . . . . . 8 5.4. Application-Layer Identity Assertions . . . . . . . . . . 8 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Document History . . . . . . . . . . . . . . . . . . 10 A.1. draft-ietf-wimse-mutual-tls-03 . . . . . . . . . . . . . 10 A.2. draft-ietf-wimse-mutual-tls-02 . . . . . . . . . . . . . 10 A.3. draft-ietf-wimse-mutual-tls-01 . . . . . . . . . . . . . 10 A.4. draft-ietf-wimse-mutual-tls-00 . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Salowey & Rosomakho Expires 27 April 2027 [Page 2] Internet-Draft Workload MTLS October 2026 1. Introduction This document defines authentication and authorization in the context of interaction between two workloads. This is the core component of the WIMSE architecture [WIMSE-ARCH]. This document focuses on using X.509 Workload Identity Certificates as defined in Section 6.1 of [WIMSE-CREDS] 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 Public Key Infrastructure (PKI) 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 Section 5 of [WIMSE-CREDS] 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. 1.1. Deployment Architecture and Message Flow Refer to Section 1.2 of [WIMSE-CREDS] for the deployment architecture which is common to all authentication mechanisms. 2. Conventions and Definitions This document uses the terminology defined in [WIMSE-ARCH]. The terms "Workload Identifier" and "trust domain" are defined in Section 3 of [WIMSE-ID], and "Workload Identity Certificate" is defined in Section 6.1 of [WIMSE-CREDS]. 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. 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. This document describes using WIMSE certificates to authenticate a TLS connection. In the case of mutual TLS either the client or the server or both client and server may present WIMSE certificates. Salowey & Rosomakho Expires 27 April 2027 [Page 3] Internet-Draft Workload MTLS October 2026 3.1. The Workload Identity Certificate Workload Identity Certificates are X.509 certificates that carry Workload Identifiers as described in Section 6.1 of [WIMSE-CREDS]. 3.2. Workload Identity Certificate Validation Workload Identity Certificates may be used to authenticate both the server and client side of the connection. When validating a Workload Identity Certificate, the relying party MUST use a locally configured mapping from trust domains to trust anchors, provisioned as described in Section 3 of [WIMSE-CREDS]. The peer's certificate MUST be rejected unless its certification path validates to a trust anchor configured for the trust domain in its Workload Identifier. The Workload Identifier MUST NOT be treated as authenticated until this validation succeeds. The relying party MUST perform certification path validation in accordance with Section 6 of [INET-X509-PROFILE]. Workloads acting as TLS clients or servers MUST validate that the trust domain portion of the Workload Identifier in the Workload Identity Certificate matches the expected trust domain for the other side of the connection. Certificate revocation status MUST be determined as specified in Section 6.1.3 of [INET-X509-PROFILE]. The mechanism used to determine that status is deployment-specific and may use CRLs, OCSP, or out-of-band information. 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 (Section 4.2.1.12 of [INET-X509-PROFILE]) 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 [INET-X509-PROFILE] and [WIMSE-CREDS] on the contents of Workload Identity Certificates or on the certification authorities that issue workload certificates. Salowey & Rosomakho Expires 27 April 2027 [Page 4] Internet-Draft Workload MTLS October 2026 3.2.1. Server Name Validation A WIMSE server intended to be accessed using a DNS hostname SHOULD present a certificate containing a matching DNS Subject Alternative Name (DNS-ID). A WIMSE client connecting to a server using a DNS hostname MUST perform standard TLS server identity validation as specified in Section 6.3 of [TLS-IDENTITY]. When connecting to a server based on its DNS hostname, the client MUST reject the connection if the server's certificate does not contain a matching DNS-ID, even if Workload Identifier validation succeeds. A WIMSE client that expects to connect to a server with a WIMSE certificate MUST validate that the WIMSE identifier of the server is appropriate for the server it is attempting to connect. Since the structure of a WIMSE identifier is deployment specific the validation is deployment specific, but the client MUST at least verify that the trust domain of the WIMSE identifier matches the trust domain of the server it intends to connect to. Some deployments may require the identification of servers by their WIMSE identifier. In such cases, the client MUST be configured with sufficient information to determine the expected Workload Identifier of the server and the client MUST validate the Workload Identifier in the server's certificate against that expectation before accepting the connection. The Workload Identifier can be used for additional workload-specific authorization and policy decisions. Connecting directly to an IP address does not require an IP address subjectAltName when the client authenticates the server using its expected Workload Identifier. If the client additionally requires authentication of the server's IP address, it MUST validate a matching iPAddress subjectAltName (IP-ID) as specified in Section 6.4 of [TLS-IDENTITY]. If no matching IP-ID is present, the client MUST reject the connection, even if Workload Identifier validation succeeds. The authority part of a URI that is a Workload Identifier is NOT treated as a hostname as otherwise specified in Section 6.3 of [TLS-IDENTITY], but rather as a trust domain as specified in Section 4.3 of [WIMSE-ID]. The server identity is encoded in the path portion of the Workload Identifier in a deployment-specific way. Salowey & Rosomakho Expires 27 April 2027 [Page 5] Internet-Draft Workload MTLS October 2026 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 Section 1.3 of [WIMSE-CREDS] for additional implementation guidance. 3.3. Client Authorization Using the Workload Identity The server application retrieves the Workload Identifier from the client certificate's URI subjectAltName (see [WIMSE-CREDS]), which in turn is obtained from the TLS layer. The certificate MUST contain exactly one URI subjectAltName carrying a Workload Identifier, as specified in Section 6.1 of [WIMSE-CREDS]. Certificates containing zero or multiple such entries MUST be rejected. 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 with 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 of the Workload Identifier. See Section 1.3 of [WIMSE-CREDS] for additional security implications of Workload Identifiers. 4. IANA Considerations This document does not include any IANA considerations. 5. Security Considerations 5.1. Certificate and Identity Validation This document relies on the security properties of TLS [TLS], PKIX path validation (Section 6 of [INET-X509-PROFILE]), and Workload Identity Certificate validation as described in Section 6.1 of [WIMSE-CREDS]. Implementations MUST validate the peer certificate chain, the applicable extended key usage (if present), 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 Salowey & Rosomakho Expires 27 April 2027 [Page 6] Internet-Draft Workload MTLS October 2026 the certificate. Failure to bind the Workload Identifier to the proper trust domain and its configured trust anchor can allow one trust domain to impersonate workloads from another domain. When a client identifies a server by a DNS hostname, clients MUST authenticate the server using standard TLS DNS hostname validation as specified in [TLS-IDENTITY]. When a client expects to connect to a server identified by a WIMSE identity then it MUST validate that the WIMSE identifier of the server according to domain specific policy as defined in Section 3.2.1. 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. 5.2. Certificate and Private Key Management 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. Compromise of the private key corresponding to a trust anchor can enable impersonation for as long as that anchor remains trusted, regardless of leaf certificate lifetimes. Trust-anchor provisioning and lifecycle considerations, including lifetime and rotation, are discussed in Section 3 of [WIMSE-CREDS] and Section 9.3.1 of [WIMSE-CREDS]. 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. Salowey & Rosomakho Expires 27 April 2027 [Page 7] Internet-Draft Workload MTLS October 2026 5.3. TLS Termination at Intermediaries 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 authentication mechanism, such as [WIMSE-HTTPSIG] or [WIMSE-WPT], in addition to TLS-layer server authentication. 5.4. Application-Layer Identity Assertions Authorization decisions based on workload identity MUST 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. 6. Privacy Considerations 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. 7. References 7.1. Normative References [INET-X509-PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . Salowey & Rosomakho Expires 27 April 2027 [Page 8] Internet-Draft Workload MTLS October 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, . [TLS-IDENTITY] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, . [WIMSE-CREDS] Campbell, B., Salowey, J. A., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft- ietf-wimse-workload-creds-02, 2 July 2026, . [WIMSE-ID] Rosomakho, Y. and J. A. Salowey, "Workload Identifier", Work in Progress, Internet-Draft, draft-ietf-wimse- identifier-04, 23 October 2026, . 7.2. Informative References [WIMSE-ARCH] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-08, 6 July 2026, . [WIMSE-HTTPSIG] Salowey, J. A. and Y. Sheffer, "WIMSE Workload-to-Workload Authentication with HTTP Signatures", Work in Progress, Internet-Draft, draft-ietf-wimse-http-signature-08, 20 October 2026, . Salowey & Rosomakho Expires 27 April 2027 [Page 9] Internet-Draft Workload MTLS October 2026 [WIMSE-WPT] Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof Token", Work in Progress, Internet-Draft, draft-ietf- wimse-wpt-02, 27 August 2026, . Appendix A. Document History // RFC Editor: please remove before publication. A.1. draft-ietf-wimse-mutual-tls-03 * Editorial: consistent capitalization of the defined terms "Workload Identifier" and "Workload Identity Certificate". A.2. draft-ietf-wimse-mutual-tls-02 * Improved Server Name Validation section A.3. draft-ietf-wimse-mutual-tls-01 * Added security considerations A.4. 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. Authors' Addresses Joe Salowey Palo Alto Networks Email: joe@salowey.net Yaroslav Rosomakho Zscaler Email: yaroslavros@gmail.com Salowey & Rosomakho Expires 27 April 2027 [Page 10]