Workload Authentication Using Mutual TLS
draft-ietf-wimse-mutual-tls-03
| Document | Type | Active Internet-Draft (wimse WG) | |
|---|---|---|---|
| Authors | Joseph A. Salowey , Yaroslav Rosomakho | ||
| Last updated | 2026-10-24 | ||
| Replaces | draft-ietf-wimse-s2s-protocol | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-wimse-mutual-tls-03
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,
<https://www.rfc-editor.org/rfc/rfc5280>.
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[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>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/rfc/rfc9846>.
[TLS-IDENTITY]
Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/rfc/rfc9525>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
workload-creds-02>.
[WIMSE-ID] Rosomakho, Y. and J. A. Salowey, "Workload Identifier",
Work in Progress, Internet-Draft, draft-ietf-wimse-
identifier-04, 23 October 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
identifier-04>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-08>.
[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, <https://datatracker.ietf.org/doc/html/
draft-ietf-wimse-http-signature-08>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
wpt-02>.
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]