Dear TLS WG, Tiru, Rifaat, Hannes and I would like to bring to your attention a new proposal: Supplemental Authentication in TLS 1.3 (draft-rosomakho-tls-supplemental-auth).
The draft defines a mechanism allowing a TLS endpoint to present one or more additional certificate-based authentication statements after its Finished message and before sending application data or other post-handshake TLS messages. The mechanism reuses the existing TLS 1.3 Certificate/CertificateVerify/Finished message structure. The driving use case is supporting multiple identities within the same TLS connection. Specifically, TLS VPN clients often need to present both a device certificate and a user certificate, with both identities bound to the same connection but serving different authorization purposes. We also expect the mechanism may be useful for other scenarios, including: - workload identity, where a server may need to present both a regular hostname certificate and a WIMSE/SPIFFE workload identity certificate; - PQ/T transition, where multiple certificate chains may need to be presented during migration; - attestation, where additional certificate-based evidence may need to be associated with the TLS connection; - other cases where multiple certificate-based authentication statements need to be bound to a single TLS connection. The draft is motivated in part by the practical limitations of TLS 1.3 post-handshake authentication, which applies only to clients and is not generally usable in protocols such as HTTP/2 and QUIC. Supplemental authentication requires the additional authentication flights to occur before the sender transmits application data or other post-handshake TLS messages providing applications with all the context upfront. At the same time, the proposed approach does not modify the TLS 1.3 key schedule and does not require changes to application protocols. Any constructive feedback, suggestions and questions are very welcome! Thank you. Best regards, Yaroslav ---------- Forwarded message --------- A new version of Internet-Draft draft-rosomakho-tls-supplemental-auth-00.txt has been successfully submitted by Yaroslav Rosomakho and posted to the IETF repository. Name: draft-rosomakho-tls-supplemental-auth Revision: 00 Title: Supplemental Authentication in TLS 1.3 Date: 2026-06-25 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/archive/id/draft-rosomakho-tls-supplemental-auth-00.txt Status: https://datatracker.ietf.org/doc/draft-rosomakho-tls-supplemental-auth/ HTML: https://www.ietf.org/archive/id/draft-rosomakho-tls-supplemental-auth-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-rosomakho-tls-supplemental-auth Abstract: TLS 1.3 allows endpoints to authenticate using certificates during the handshake and supports optional post-handshake client authentication. However, some deployments require presenting additional certificate-based authentication statements bound to the same TLS connection, such as separate device and user identities, attestation evidence, or multiple certificate chains during cryptographic transitions. This document defines Supplemental Authentication for TLS 1.3, a mechanism that allows endpoints to present additional certificate authentication messages after the handshake while preserving the authentication semantics of TLS 1.3. Supplemental authentication reuses the existing Certificate, CertificateVerify, and Finished message structure and allows endpoints to exchange one or more additional certificate-based authentication statements before sending application data or other post-handshake TLS messages. The IETF Secretariat -- This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
