TLS K. Frank Internet-Draft 16 June 2025 Updates: RFC8446, RFC8705, RFC5280, RFC5246, RFC7590 (if approved) Intended status: Standards Track Expires: 18 December 2025 Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages. draft-frank-mtls-via-serverauth-extension-00 Abstract This document aims to standardize the validation of mutual TLS authentication between servers (server-to-server). It outlines recommended validation flows as well as provides practical design recommendations. Basically the EKU id-kp-clientAuth and id-kp- serverAuth get more precisely defined to represent their common understanding by issuing CAs and browsers. id-kp-clientAuth aka. "TLS WWW client authentication" SHOULD mean authentication of a natural or legal entity. id-kp-serverAuth aka. "TLS WWW server authetnication" SHOULD mean authentication of a device. When two id- kp-clientAuth certificates are used this means E2E authentication between two users. Where as two id-kp-serverAuth certificates being used means server-to-server authentication. And one user and one server certificate within one TLS connection means client-to-server (or technically also server-to-client). The term "TLS-Client" SHOULD no longer be used and mean the party sending the initial package while establishing a TLS connection. This helps to avoid design issues moving forward as currently some people thought TLS-Client auth was only ever used in "client-to-server" and never within "server-to-server" context. Which sparked the demand for this document to begin with to keep server-to-server auth with public trusted certificates working. 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/. Frank Expires 18 December 2025 [Page 1] Internet-Draft mtls-via-serverauth-extension June 2025 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 18 December 2025. Copyright Notice Copyright (c) 2025 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Updates to RFC5280: id-kp-serverAuth for mutual Authentication . . . . . . . . . . . . . . . . . . . . . 3 3. Updates to all RFCs using mutual authentication . . . . . . . 3 3.1. Basic scenario . . . . . . . . . . . . . . . . . . . . . 3 3.2. Advanced scenario . . . . . . . . . . . . . . . . . . . . 4 3.3. Validation of a certificates with only EKU serverAuth received by a server from the connection establishing party. . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Contributors and Acknowledgements . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Recently public CAs have stopped issuing certificates with both clientAuth and serverAuth from the common web root of trust because of a change in the Chrome Root Program Policy. Some CAs still issue client auth certificates but only towards invididuals and none towards domain names (dNSNames). But even their usage is questionable as they're no longer issued by the an signing CA within the same trust hirarchy. Furthermore the policy now also states that going forward all certificates containing both clientAuth and Frank Expires 18 December 2025 [Page 2] Internet-Draft mtls-via-serverauth-extension June 2025 serverAuth will be considered invalid. Because of this there are now new challanges for server-to-server usages. This document aims to address this by relaxing the validation requirements for TLS Clientauthentication within the server-to-server usecase. In addition this document also provides some standardized validation flows which formerly weren't formally standardized. 1.1. Terminology 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. The reader should be familiar with the terms defined in [RFC5280] and [RFC8446] 2. Updates to RFC5280: id-kp-serverAuth for mutual Authentication Section 4.2.1.12 of [RFC5280] is extended by: NEW: | "TLS WWW client authentication" SHOULD mean authentication of a | natural or legal entity. "TLS WWW server authetnication" SHOULD | mean authentication of a device e.g. client-to-server or server- | to-server A certificate with either (or both) of these options MAY | be used for either side of a TLS-connection. A server expecting | only end user authentication SHOULD decline id-kp-serverAuth | certificates and one only expecting server-to-server connections | SHOULD decline id-kp-clientAuth certificates. The server SHOULD | validate the certificate it received from the TLS connection | establishing party (TLS-Client) according to draft-frank-mtls-via- | serverAuth-extension. 3. Updates to all RFCs using mutual authentication The following mutual authentication scenarious should be differentiated 3.1. Basic scenario +-----------------+ +----------------+ | Server-A | <====> | Server-B | +-----------------+ +----------------+ Frank Expires 18 December 2025 [Page 3] Internet-Draft mtls-via-serverauth-extension June 2025 Figure 1: Figure 1: Server-to-server Figure 1 shows a minimal deployment with two servers. In the most basic case the authentication is performed between two servers directly. This case can be further split into: * application to application: In this case there is an application on both servers that performs the authentication and use the tls authentication also for authentication within the application itself. E.g. to grant different access rights. * server to server: In this scenario the authentication is performed outside of the application, e.g. using a separate application to wrap the connection or by the webserver without forwarding it to the application itself. This can be seen as adding an additional layer of authentication in cases where the application itself may not support authentication or where a 2nd dedicated factor is desired. It is basically similar to a peer-to-peer VPN like IPSec in transport mode. Where some of these MAY be able to use an internal, private, or enterprise CA this does not apply to all usages. E.g. XMPP servers commonly use mutual TLS but the other parties are not necessarily known beforehand. The same applies to some extend also to SMTP relays between different organizations. The desired level of assurance in these cases is not authentication as in associating a session to a specific user but more generic the same as when a server identifies itself to a end user, to ensure both parties are who they claim to be. e.g. server-a.example.com communicating with server- b.example.com 3.2. Advanced scenario A slightly more advanced usage is when a 3rd server, like a load- balancer is present within the connection. +-----------------+ +----------------+ +----------------+ | Server-A | <====> | Server-B | <====> | Server-C | +-----------------+ +----------------+ +----------------+ Figure 2: Figure 2: Sample Deployment with Load Balancer Figure 2: An extension of Figure 1 with one more server behind Server-B which serves as load balancer. Frank Expires 18 December 2025 [Page 4] Internet-Draft mtls-via-serverauth-extension June 2025 In this setup it can be differentiated between these scenarious: * with application layer authentication: In this case the load balancer uses a mechanism to forward the authentication towards the application. E.g. by passing the connection through as is or by using another standard that is outside of the scope of this document. The goal in this case is almost always to authenticate a user. * without application layer authentication: This usage is basically identical to the basic scenario above and the goal is most of the time to add an additional layer of authetnication. The load- balancer will terminate the TLS connection and establish a separate connection with the backend server. The backend server does not get informed about the presence or state of the mutually authenticated TLS connection at all. This is similar to using IPSec or an HTTPS-proxy. * with mTLS only between load-balancer and backend server: mTLS is used between the load-balancer and the backend. This is commonly used within e.g. a service mesh or where the backend may be spread accross multiple different cloud providers. It also allows a backend server to reject all connections that fail mTLS authentication (e.g. are from either another system within the service mesh, nor from the load-balancer). It also serves as a simpler and more scalable alternative to IP allow lists. * with mTLS only between requestor and load-balancer: In this case the backend server is either only unidirectionally authenticated or may not be authenticated at all. Also the laod-balancer MAY forward information of the client certificate to the application or not. Depending on this it is either the same as the first or the second case above. Such a configuration is commonly used to secure an otherwise insecure application. In such deployments the backend server is commonly isolated and only exposed through a dedicated transfer network to the loadbalancer without any other systems within that network. Even if the application requires an outbound internet connection this almost always allows for selectively binding the insecure listening socket of the application towards only the transfer network and not towards the uplink network used for outbound connections. Depending on the application the load-balancer (or reverse proxy) MAY be installed on the same system as the insecure application. In these cases the transfer network MAY be either a dedicated network namespace, a unix domain socket, or a dummy network interface. Usage of the loopback interface with "127.0.0.1" and "::1" SHOULD be avoided as many legacy applications have special handling for them and therefore MAY expose more control than expected. Frank Expires 18 December 2025 [Page 5] Internet-Draft mtls-via-serverauth-extension June 2025 3.3. Validation of a certificates with only EKU serverAuth received by a server from the connection establishing party. The validation of the TLS certificate received by the connection initiating party is already sufficiently specified within the original RFCs. However the validation of the certificate received from the client by the server is not. Because this document focuses on the server-to-server usage it is possible to specify the validation criteria in more detail: 1. If the received certificate specifies the Extended Key Usage of "clientAuth" any generic application like e.g. a web server SHOULD assume this meaning end user authentication. Without additional configuration it SHOULD reject any otherwise valid certificate that is not issued towards either an individual or organization. Aka. certificates with an FQDN or IP-Address within the CN or SAN section. A more specialized application can decide for itself if it wants to accept either a certificate for a system or an enduser. 2. If the received certificate is otherwise valid, has Extended Key Usage "serverAuth" and is issued towards an entity of type dNSName the receiving server SHOULD perform a forward-confirmed reverse DNS lookup. This discovered FQDN is then used for validating the certificate as if it was a certificate received for an outbound conenction towards that FQDN. 3. If the received certificate is otherwise valid, has Extended Key Usage "serverAuth" and is issued towards an entity of type ipAddress the receiving server MUST use the source IP-Address of the connection to validate the certificate against. 4. A generic application MUST NOT pass authentications using certificates of kind "serverAuth" towards applications. It SHOULD pass authentication for "clientAuth". It MAY allow for a configurable overwrite to be configured to also pass certificates of "serverAuth" towards to the application. 5. Applications SHOULD provide a configuration option to reject all certificates with both clientAuth and serverAuth. 6. A certificate that is issued towards either dNSName or iPAddress as well as any other type is invalid 7. A server performing a forward-confirmed reverse DNS lookup SHOULD also query the relevant CAA, TLSA, SVCB, SRV, CERT, and DNSSEC records. Supporting applications SHOULD check their application specific records as well (e.g. HTTPS, SSHFP, ...). Frank Expires 18 December 2025 [Page 6] Internet-Draft mtls-via-serverauth-extension June 2025 8. In case the certificate is issued towards an entity of type ipAddress the server SHOULD query the reverse lookup zone for these DNS records. It MAY also try to perform a forward- confirmed reverse DNS lookup but it failing because of missing PTR/A/AAAA-RRs SHOULD not fail the entire validation. 9. In case DNSSEC validation fails the forward-confirmed reverse DNS lookup fails. Therefore the certificate validation fails as well. 10. If for a specific DNS zone DNSSEC is not configured at all the validation SHOULD NOT fail. An application however MAY specify a more strict requirement depending on its security requirements. Howver it then MUST allow for a configurable overwrite. 11. If a TLSA record is received it's certificate usage value MUST be honored. Except the zone is not DNSSEC signed then only certificate usage 0 and 1 are honored. When the zone is signature certificate usage 2 and 3 also MUST be honored. See [RFC7671], [RFC7672], and [RFC7673]. 12. For Zeroconf ([RFC6762] and [RFC6763]) domains the DNSSEC requirements MUST be ignored. 13. A configuration option listing domains for which DNSSEC is not evaluated MUST be provided. The default list SHOULD include ".local", ".localhost", and ".onion". It MAY be disabled by default though. 14. Applications SHOULD provide a configuration option to specify a separate dns resolver to be used for only these specific domains and MAY provide a configuration option to use for all others instead of using the DNS resolver of the system. 15. A SRV/SVCB/... record containing the source port SHOULD be considered while evaluating. It's absence is not an error (except when it should be present as determined by DNSSEC). It being present but it not validating doesn't cause the validation to fail either. However it CAN be used while retrieving the TLSA-RR or for the forward-confirmed reverse DNS lookup. See [RFC9460] and the IANA "Underscored and Globally Scoped DNS Node Names" registry from [RFC8552]. e.g. "_8443._tcp.1.2.0.192.in- addr.arpa" or "_8443._tcp.example.com" when "1.2.0.192.in- addr.arpa" is pointing towards "example.com".An application specific to some protocol like e.g. XMPP SHOULD check the associated SRV-RR but MAY also check other less specific ones if applicable. It should be noted that [RFC6762] for SRV records Frank Expires 18 December 2025 [Page 7] Internet-Draft mtls-via-serverauth-extension June 2025 specifies "Port numbers SHOULD NOT be used in place of the symbolic service or protocol names". Therefore even though unlikely it MAY still be used in some rare cases. Some MAY use a SRV record with port numbers for reverse lookups instead of a NAPTR record. 16. Except for the above described extensible reverse lookup and validation of the received mapping the certificate validation is exactly the same as for any certificate the system would have received as a TLS-client for an outbound connection by a server. The retrieved domain name is used as a replacement for the desired remote target server name. 17. Applications MAY ONLY validate the source IP and hostname. However applications SHOULD at least offer the additional validation mechanisms outlined above to validate the source port and service as well. This provides additional security against protocol confusion and binds certificates (e.g. when the TLSA record is specified for the SVCB/SRV record) not just to the host but to the source port and service as well. 4. Contributors and Acknowledgements A special thanks goes to everyone participating in the discussion on the mailing lists as well as Mohamed Boucadair for proofreading, suggested changes, and helping with the submission process itself. 5. References 5.1. Normative References [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5280] 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, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . Frank Expires 18 December 2025 [Page 8] Internet-Draft mtls-via-serverauth-extension June 2025 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 2015, . [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, . [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, . [RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 2015, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . Author's Address Klaus Frank Frank Expires 18 December 2025 [Page 9] Internet-Draft mtls-via-serverauth-extension June 2025 Email: draft-frank-mtls-via-serverauth-extension@frank.fyi Frank Expires 18 December 2025 [Page 10]