Supplemental Authentication in TLS 1.3
draft-rosomakho-tls-supplemental-auth-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yaroslav Rosomakho , Tirumaleswar Reddy.K , Rifaat Shekh-Yusef , Hannes Tschofenig | ||
| Last updated | 2026-06-25 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rosomakho-tls-supplemental-auth-00
Transport Layer Security Y. Rosomakho
Internet-Draft Zscaler
Intended status: Standards Track T. Reddy
Expires: 27 December 2026 Nokia
R. Shekh-Yusef
Ciena
H. Tschofenig
UniBw M.
25 June 2026
Supplemental Authentication in TLS 1.3
draft-rosomakho-tls-supplemental-auth-00
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.
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://yaroslavros.github.io/tls-supplemental-auth/draft-rosomakho-
tls-supplemental-auth.html. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-rosomakho-tls-
supplemental-auth/.
Discussion of this document takes place on the Transport Layer
Security Working Group mailing list (mailto:tls@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe
at https://www.ietf.org/mailman/listinfo/tls/.
Rosomakho, et al. Expires 27 December 2026 [Page 1]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
Source for this draft and an issue tracker can be found at
https://github.com/yaroslavros/tls-supplemental-auth.
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/.
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 December 2026.
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
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Overview of Supplemental Authentication . . . . . . . . . . . 5
3.1. Server Supplemental Authentication Example . . . . . . . 6
3.2. Client Supplemental Authentication Example . . . . . . . 7
4. The supplemental_certificate_requests Extension . . . . . . . 8
5. The supplemental_certificate TLS flag . . . . . . . . . . . . 11
5.1. Use in the Main Handshake . . . . . . . . . . . . . . . . 11
5.2. Use in Supplemental Authentication Certificates . . . . . 11
6. Supplemental Authentication Flights . . . . . . . . . . . . . 12
6.1. Record Protection . . . . . . . . . . . . . . . . . . . . 12
6.2. Transcript Construction . . . . . . . . . . . . . . . . 12
Rosomakho, et al. Expires 27 December 2026 [Page 2]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
6.3. Request Matching . . . . . . . . . . . . . . . . . . . . 14
6.4. Message Ordering . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. Authentication Binding . . . . . . . . . . . . . . . . . 15
7.2. Message Ordering and Integrity . . . . . . . . . . . . . 16
7.3. Authorization Semantics . . . . . . . . . . . . . . . . . 16
7.4. Resource Consumption . . . . . . . . . . . . . . . . . . 16
7.5. Confidentiality of Authentication Requests . . . . . . . 17
7.6. Session Resumption . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. TLS Extension . . . . . . . . . . . . . . . . . . . . . . 17
8.2. TLS Flag . . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19
Appendix B. Appendix . . . . . . . . . . . . . . . . . . . . . . 19
B.1. Application Policy Enforcement . . . . . . . . . . . . . 19
B.2. Policy Enforcement Scenarios . . . . . . . . . . . . . . 20
B.2.1. Hybrid Post-Quantum and Traditional Authentication . 20
B.2.2. Device and User Identity . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
TLS 1.3 [TLS] allows endpoints to authenticate using certificates
during the handshake. A server presents its certificate chain in the
handshake Certificate message, and the server may request a client
certificate using the CertificateRequest message. TLS 1.3 also
defines post-handshake client authentication, which allows a server
to request a client certificate after the handshake has completed.
Some deployments require presenting multiple certificate-based
authentication statements bound to the same TLS connection. Examples
include separating device and user authentication, presenting
attestation evidence in addition to a device identity, or providing
multiple certificate chains during cryptographic transitions such as
migration to post-quantum algorithms. In these scenarios, multiple
authentication statements may need to be associated with a single
secure connection.
While TLS 1.3 post-handshake authentication can be used to request
additional client certificates, it is rarely deployed in practice.
Post-handshake authentication is explicitly prohibited in HTTP/2
(Section 9.2.3 of [H2]) and QUIC (Section 4.4 of [QUIC-TLS]).
Rosomakho, et al. Expires 27 December 2026 [Page 3]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
This document defines Supplemental Authentication for TLS 1.3.
Supplemental authentication allows endpoints to present additional
certificate-based authentication messages after the sender's Finished
message and before that sender transmits application data or any
other post-handshake TLS message. These additional authentication
statements are cryptographically bound to the TLS connection and
reuse the existing Certificate, CertificateVerify, and Finished
message structure defined by TLS 1.3.
Endpoints signal support for supplemental authentication and
optionally request additional authentication statements using a new
supplemental_certificate_requests extension. A peer that is willing
to provide supplemental authentication in response to this extension
indicates this by setting the supplemental_certificate flag in its
main handshake Certificate message, and then sends any supplemental
authentication flights after its own Finished message and before it
transmits application data. When both endpoints use supplemental
authentication, each endpoint follows this rule independently.
Supplemental authentication extends the existing TLS certificate
authentication mechanism. It does not replace primary certificate
authentication performed during the handshake and does not change the
semantics of TLS authentication or authorization decisions, which
remain application-specific.
Supplemental authentication requires certificate-based authentication
in the main handshake. An endpoint MUST NOT send supplemental
authentication sequences unless that endpoint presented a non-empty
certificate chain in the main handshake Certificate message.
Consequently, this mechanism cannot be used by an endpoint
authenticated only with a PSK.
The mechanism defined in this document can also be used with DTLS 1.3
[DTLS] and protocols that use the TLS 1.3 handshake such as QUIC
[QUIC-TLS].
2. Conventions and Definitions
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.
Rosomakho, et al. Expires 27 December 2026 [Page 4]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
3. Overview of Supplemental Authentication
Supplemental authentication allows endpoints to present additional
certificate-based authentication statements associated with an
established TLS connection.
A fundamental concept of this specification is the clear separation
between the "Main Handshake" and the "Supplemental Authentication
phase". The Main Handshake is considered complete upon the
successful processing of the initial Finished messages by both
endpoints, at which point a secure connection is established and
application traffic keys are available.
These additional authentication statements are exchanged during the
Supplemental Authentication phase, after the sender's Finished
message and before that sender transmits application data or any
other post-handshake TLS message, and are cryptographically bound to
the connection using the same authentication mechanisms defined in
TLS 1.3.
Endpoints signal support for supplemental authentication and
optionally request additional authentication statements using the
supplemental_certificate_requests extension. This extension can
appear in the ClientHello or CertificateRequest messages and contains
SupplementalCertificateRequest structures that describe the requested
authentication contexts and associated parameters.
A peer that is willing to provide supplemental authentication
indicates acceptance by including the supplemental_certificate flag
in its main handshake Certificate message. The presence of this flag
indicates that the sender will transmit at least one additional
authentication flight after the handshake completes.
Each supplemental authentication flight consists of the TLS 1.3
authentication message sequence:
Certificate
CertificateVerify
Finished
Figure 1: TLS 1.3 authentication message sequence
These messages are processed using the same cryptographic mechanisms
defined for certificate authentication in TLS 1.3. Supplemental
authentication flights are sent after the handshake Finished message
and are protected using the established connection keys.
Rosomakho, et al. Expires 27 December 2026 [Page 5]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
Multiple supplemental authentication flights may be sent by a single
endpoint. If the supplemental_certificate flag is present in a
supplemental Certificate message, it indicates that another
supplemental authentication flight will follow. If the flag is
absent, the Certificate message is the final supplemental
authentication flight sent by that endpoint.
Supplemental authentication flights from a given sender MUST form a
contiguous sequence of handshake messages from that sender. An
endpoint MUST NOT interleave application data or other TLS messages
from that endpoint with its supplemental authentication flights.
Each supplemental authentication flight satisfies at most one
SupplementalCertificateRequest. A sender MAY transmit multiple
supplemental authentication flights that satisfy the same request,
provided that the number of flights does not exceed the
max_certificates value specified in the corresponding request.
Supplemental authentication flights for different request contexts
MAY appear in any order. The receiver determines which
SupplementalCertificateRequest a supplemental authentication flight
satisfies based on the certificate_request_context value.
The following sections illustrate typical message flows.
3.1. Server Supplemental Authentication Example
In this example, the client requests additional authentication
statements from the server using the
supplemental_certificate_requests extension in the ClientHello. The
server indicates acceptance in its handshake Certificate message and
sends two supplemental authentication flights after the handshake.
Rosomakho, et al. Expires 27 December 2026 [Page 6]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
Client Server
------ ------
ClientHello
+ supplemental_certificate_requests
-------->
ServerHello
EncryptedExtensions
Certificate
+ supplemental_certificate
CertificateVerify
Finished
Certificate
+ supplemental_certificate
CertificateVerify
Finished
Certificate
CertificateVerify
Finished
<--------
Figure 2: Server Supplemental Authentication example
3.2. Client Supplemental Authentication Example
In this example, the server requests client authentication in the
main handshake and additionally requests supplemental authentication
statements from the client using the
supplemental_certificate_requests extension in the CertificateRequest
message. After the client completes the handshake, it sends two
supplemental authentication flights.
Rosomakho, et al. Expires 27 December 2026 [Page 7]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
Client Server
------ ------
ClientHello
-------->
ServerHello
EncryptedExtensions
CertificateRequest
+ supplemental_certificate_requests
Certificate
CertificateVerify
Finished
<--------
Certificate
+ supplemental_certificate
CertificateVerify
Finished
Certificate
+ supplemental_certificate
CertificateVerify
Finished
Certificate
CertificateVerify
Finished
-------->
Figure 3: Client Supplemental Authentication example
4. The supplemental_certificate_requests Extension
The supplemental_certificate_requests TLS extension is used to signal
support for supplemental authentication and to optionally request
additional certificate-based authentication statements from the peer.
This extension MAY appear in the ClientHello or CertificateRequest
messages:
* When included in a ClientHello, the extension indicates that the
client supports supplemental authentication and optionally
requests supplemental authentication statements from the server.
* When included in a CertificateRequest, the extension indicates
that the server supports supplemental authentication and
optionally requests supplemental authentication statements from
the client.
Rosomakho, et al. Expires 27 December 2026 [Page 8]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
When included in a CertificateRequest, this extension augments rather
than replaces the semantics of the enclosing CertificateRequest. In
particular, a CertificateRequest sent during the main handshake still
requests client authentication for the main handshake.
The extension contains a list of SupplementalCertificateRequest
structures describing requested supplemental authentication contexts.
The extension structure is defined as follows:
struct {
uint8 max_certificates;
opaque certificate_request_context<0..255>;
Extension extensions<0..2^16-1>;
} SupplementalCertificateRequest;
struct {
SupplementalCertificateRequest requests<0..2^16-1>;
} SupplementalCertificateRequests;
Figure 4: supplemental_certificate_requests Extension Structure
The requests field contains zero or more
SupplementalCertificateRequest structures.
If the list is empty, the sender indicates willingness to receive
supplemental authentication statements without specifying any
particular request contexts.
Each SupplementalCertificateRequest describes a requested
supplemental authentication context and the parameters associated
with that request.
The fields of SupplementalCertificateRequest are defined as follows:
*max_certificates*: A limit on the number of supplemental
authentication flights that the peer may send in response to this
request. The value specifies the maximum number of Certificate
authentication flights that may satisfy this request. The value
MUST be greater than zero.
*certificate_request_context*: An opaque value used to identify this
supplemental authentication request. This value is carried in the
certificate_request_context field of the Certificate message sent
in response to this request.
Rosomakho, et al. Expires 27 December 2026 [Page 9]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
Within a single supplemental_certificate_requests extension, each
certificate_request_context value MUST be unique. If more than one
SupplementalCertificateRequest structure is present, at most one of
them MAY use an empty certificate_request_context.
*extensions*: A list of extensions that describe parameters
associated with this request. Except as described below for
server_name, these extensions follow the same syntax and semantics
as extensions carried in the TLS 1.3 CertificateRequest message.
Only extensions that are valid in a CertificateRequest message MAY
appear in this list. The supplemental_certificate_requests
extension MUST NOT appear in the extensions list of a
SupplementalCertificateRequest.
The server_name extension MAY appear in the extensions list of a
SupplementalCertificateRequest when the containing
supplemental_certificate_requests extension appears in the
ClientHello. The server_name extension MUST NOT appear in the
extensions list of a SupplementalCertificateRequest when the
containing supplemental_certificate_requests extension appears in a
CertificateRequest.
If an extension is not present in the extensions list of a
SupplementalCertificateRequest, the parameters for that extension are
inherited from the corresponding values negotiated in the main
handshake. Unlike the TLS 1.3 ClientHello and CertificateRequest
messages, the signature_algorithms extension is OPTIONAL in a
SupplementalCertificateRequest.
When the supplemental_certificate_requests extension appears in the
ClientHello, the inherited values are taken from the client's
ClientHello. When the extension appears in a CertificateRequest, the
inherited values are taken from the parameters of the enclosing
CertificateRequest message.
A peer receiving the supplemental_certificate_requests extension MAY
respond to zero or more of the contained
SupplementalCertificateRequest structures. For a given request, the
peer MAY send between zero and max_certificates supplemental
authentication flights.
If a peer sends a supplemental authentication flight in response to a
request, the certificate_request_context field of the Certificate
message MUST be equal to the certificate_request_context value of the
corresponding SupplementalCertificateRequest.
The following is an example of SupplementalCertificateRequests:
Rosomakho, et al. Expires 27 December 2026 [Page 10]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
SupplementalCertificateRequests {
requests = [
// Request for the Device Certificate
SupplementalCertificateRequest {
max_certificates = 1,
certificate_request_context = "device-identity",
extensions = { device cert specific extensions ... }
},
// Request for the User Certificate
SupplementalCertificateRequest {
max_certificates = 1,
certificate_request_context = "user-identity",
extensions = { user cert specific extensions ... }
}
]
}
5. The supplemental_certificate TLS flag
The supplemental_certificate TLS flag signals the use of supplemental
authentication.
This flag is defined as a TLS flag as specified in [TLS-FLAGS] and
may appear in a Certificate message.
The semantics of this flag depend on the context in which it appears.
5.1. Use in the Main Handshake
When the supplemental_certificate flag appears in the main handshake
Certificate message, it indicates that the sender will transmit at
least one additional certificate authentication sequence after the
TLS handshake has completed.
An endpoint MUST NOT set the supplemental_certificate flag in its
main handshake Certificate message unless the peer indicated
willingness to receive supplemental authentication by including the
supplemental_certificate_requests extension.
5.2. Use in Supplemental Authentication Certificates
When the supplemental_certificate flag appears in a Certificate
message sent after the handshake, it indicates that another
supplemental authentication sequence will follow.
Rosomakho, et al. Expires 27 December 2026 [Page 11]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
If the flag is absent from a supplemental Certificate message, that
Certificate message is the final supplemental authentication sequence
sent by that endpoint.
6. Supplemental Authentication Flights
Supplemental authentication is performed using one or more additional
certificate authentication sequences exchanged after the TLS
handshake has completed.
Each supplemental authentication sequence consists of the following
TLS 1.3 authentication messages:
Certificate
CertificateVerify
Finished
These messages use the same structure and processing rules as the
corresponding TLS 1.3 handshake messages defined in [TLS].
6.1. Record Protection
Supplemental authentication messages are sent after the TLS handshake
has completed and are protected using the established application
traffic secrets. In TLS and DTLS, these messages are carried as
protected handshake messages and are encrypted under the sender's
current application traffic keys.
6.2. Transcript Construction
Supplemental authentication does not extend the TLS 1.3 handshake
transcript used for the key schedule, exporters, or session
resumption. For the purpose of constructing supplemental
authentication messages, each endpoint maintains a sender-local
supplemental transcript.
For a server sending supplemental authentication sequences, the
sender-local supplemental transcript begins with the handshake
transcript that includes all handshake messages up to and including
the server's main-handshake Finished message.
For a client sending supplemental authentication sequences, the
sender-local supplemental transcript begins with the handshake
transcript that includes all handshake messages up to and including
the client's main-handshake Finished message.
Rosomakho, et al. Expires 27 December 2026 [Page 12]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
The sender-local supplemental transcript does not include post-
handshake messages from the peer, including supplemental
authentication sequences sent by the peer. Each endpoint therefore
signs only its own supplemental authentication sequences together
with the relevant TLS handshake transcript prefix.
For each supplemental authentication sequence, the sender-local
supplemental transcript additionally includes:
* all messages from any preceding supplemental authentication
sequences sent by this endpoint, and
* the Certificate, CertificateVerify and Finished message of the
current supplemental authentication sequence.
The CertificateVerify message is constructed using the same procedure
and context string defined for certificate authentication in TLS 1.3
[TLS]. A server uses the server CertificateVerify context string,
and a client uses the client CertificateVerify context string.
CertificateVerify: A signature over the value
Transcript-Hash(Handshake Context, Certificate).
The Finished message is constructed using the same procedure as
Finished in TLS 1.3, except that the transcript hash is taken over
the sender-local supplemental transcript defined above. The Base Key
is the sender's current application traffic secret, namely
server_application_traffic_secret_0 for a server and
client_application_traffic_secret_0 for a client.
Finished: A MAC over the value Transcript-Hash(Handshake Context,
Certificate, CertificateVerify) using a MAC key derived from the
Base Key.
Handshake Context and Base Key are specified in the following table:
Rosomakho, et al. Expires 27 December 2026 [Page 13]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
+--------------+-----------------------------+--------------------------------+
| Mode | Handshake Context | Base Key |
+--------------+-----------------------------+--------------------------------+
| Server | ClientHello ... server | server_application_traffic_ |
| Supplemental | Finished + | secret_N |
| | all messages from | |
| | previously sent server | |
| | supplemental authentication | |
| | sequences | |
| | | |
| Client | ClientHello ... client | client_application_traffic_ |
| Supplemental | Finished + | secret_N |
| | all messages from | |
| | previously sent client | |
| | supplemental authentication | |
| | sequences | |
+--------------+-----------------------------+--------------------------------+
After a supplemental authentication sequence is sent, its
Certificate, CertificateVerify, and Finished messages are appended to
the sender's Handshake Context, so that each subsequent sequence is
bound to all previously transmitted sequences from that sender.
Endpoints performing supplemental authentication MUST retain the
transcript hash state at the end of the handshake and update it with
each supplemental authentication message sent, until all supplemental
authentication sequences have been transmitted.
An endpoint MUST NOT change its sending application traffic keys in
the middle of a supplemental authentication sequence. If an endpoint
sends more than one supplemental authentication sequence, it MAY
update its sending application traffic keys between sequences.
Endpoints performing supplemental authentication MUST retain the
necessary handshake authentication state required to compute
additional CertificateVerify and Finished messages until supplemental
authentication has completed.
6.3. Request Matching
If the peer previously sent a supplemental_certificate_requests
extension, a supplemental authentication sequence MAY satisfy one of
the contained SupplementalCertificateRequest structures.
If a supplemental authentication sequence is sent in response to a
request, the certificate_request_context field of the Certificate
message MUST be equal to the certificate_request_context value of the
corresponding SupplementalCertificateRequest.
Rosomakho, et al. Expires 27 December 2026 [Page 14]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
A sender MAY transmit multiple supplemental authentication sequences
that satisfy the same request, provided that the number of sequences
does not exceed the max_certificates value specified in the request.
A sender MAY also transmit supplemental authentication sequences that
are not associated with any specific request context, in which case
the certificate_request_context field of the Certificate message is
empty.
6.4. Message Ordering
Supplemental authentication sequences sent by an endpoint MUST form a
contiguous sequence of TLS handshake messages from that endpoint.
An endpoint MUST NOT interleave application data or other TLS
messages from that endpoint with its supplemental authentication
sequences.
If the supplemental_certificate TLS flag in a Certificate message
indicates that another supplemental authentication sequence will
follow, the Finished message completing that sequence MUST be
followed by a Certificate message starting the next supplemental
authentication sequence.
Messages from the peer MAY appear between supplemental authentication
sequences and are processed according to TLS 1.3. Such peer messages
are not included in the sender-local supplemental transcript defined
in Section 6.
If any other TLS message is received from that endpoint before the
next Certificate message, the receiver MUST abort the connection with
an unexpected_message alert.
7. Security Considerations
7.1. Authentication Binding
Each supplemental authentication sequence includes a
CertificateVerify and Finished message constructed using the sender-
local supplemental transcript and the sender's application traffic
secrets as described in Section 6. This ensures that each
supplemental certificate authentication statement is
cryptographically bound to the TLS connection and cannot be replayed
across connections.
Supplemental authentication sequences sent by one endpoint are not
included in the transcript used by the peer when constructing its own
supplemental authentication messages. As a result, supplemental
Rosomakho, et al. Expires 27 December 2026 [Page 15]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
authentication statements produced by each endpoint are independently
bound to the TLS handshake transcript rather than to the peer's
supplemental authentication statements.
This design allows both endpoints to transmit supplemental
authentication sequences without introducing additional round-trip
latency. Applications that rely on relationships between multiple
authentication statements from different endpoints MUST verify those
relationships explicitly at the application layer.
7.2. Message Ordering and Integrity
The supplemental_certificate TLS flag ensures that supplemental
authentication sequences cannot be truncated or reordered without
detection. If a Certificate message indicates that another
supplemental authentication sequence will follow, the receiver
expects the next message from that endpoint to begin the next
sequence. Any deviation from this ordering results in a TLS protocol
error.
Because each supplemental authentication sequence includes a Finished
message that covers the transcript defined in Section 6,
modification, removal, or reordering of messages within a sequence is
detected by the TLS authentication mechanisms.
7.3. Authorization Semantics
TLS authentication establishes the identity of the peer but does not
define how that identity is used for authorization. Supplemental
authentication introduces additional authentication statements that
may represent different identities or attributes (for example, device
identity, user identity, or attestation evidence).
Applications using supplemental authentication MUST define how these
authentication statements are interpreted and how multiple statements
are combined when making authorization decisions. Incorrect or
ambiguous interpretation of multiple authentication statements could
lead to unintended authorization outcomes.
7.4. Resource Consumption
A peer can request supplemental authentication using the
supplemental_certificate_requests extension. Responding to such
requests may require the peer to construct certificate chains and
produce signatures. Implementations SHOULD ensure that the
processing of supplemental authentication requests is subject to
appropriate resource limits and policy checks to prevent denial-of-
service conditions.
Rosomakho, et al. Expires 27 December 2026 [Page 16]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
The max_certificates field in SupplementalCertificateRequest limits
the number of supplemental authentication sequences that may satisfy
a given request. Implementations MUST enforce this limit.
7.5. Confidentiality of Authentication Requests
The supplemental_certificate_requests extension may reveal
information about the types of authentication statements requested by
an endpoint. When this extension appears in the ClientHello, its
contents are visible to on-path observers unless the connection uses
Encrypted ClientHello [ECH].
Clients that wish to avoid revealing requested supplemental
authentication contexts SHOULD use ECH so that the contents of the
inner ClientHello are encrypted.
A client MAY include an empty supplemental_certificate_requests
extension in the outer ClientHello to indicate support for
supplemental authentication while withholding the specific request
parameters until the encrypted inner ClientHello is processed.
7.6. Session Resumption
The resumption_master_secret is derived from ClientHello...client
Finished per Section 7.1 of [TLS] and does not include supplemental
authentication messages. A server MUST NOT send a NewSessionTicket
message until all supplemental authentication sequences from both
endpoints have been completed. This ensures that a resumed session
is not established before the supplemental authentication guarantees
of the original session have been fully established.
8. IANA Considerations
8.1. TLS Extension
IANA is requested to add the following entry to the "TLS
ExtensionType Values" extension registry [TLS-Ext-Registry]:
* Value: TBD1
* Extension Name: supplemental_certificate_requests
* TLS 1.3: CH, CR
* DTLS-Only: N
* Recommended: Y
Rosomakho, et al. Expires 27 December 2026 [Page 17]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
* Reference: [This document]
8.2. TLS Flag
IANA is requested to add the following entry to the "TLS Flags"
registry created by [TLS-FLAGS]:
* Value: TBD2
* Flag Name: supplemental_certificate
* Messages: CT
* Recommended: Y
* Reference: [This document]
9. References
9.1. Normative References
[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", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8446bis-14, 13 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8446bis-14>.
[TLS-FLAGS]
Nir, Y., "A Flags Extension for TLS 1.3", Work in
Progress, Internet-Draft, draft-ietf-tls-tlsflags-17, 17
March 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-tls-tlsflags-17>.
9.2. Informative References
Rosomakho, et al. Expires 27 December 2026 [Page 18]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
[DTLS] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
rfc9147bis-01, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc9147bis-01>.
[ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
March 2026, <https://www.rfc-editor.org/rfc/rfc9849>.
[H2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/rfc/rfc9113>.
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/rfc/rfc9001>.
[TLS-Ext-Registry]
IANA, "Transport Layer Security (TLS) Extensions", March
2026, <https://www.iana.org/assignments/tls-extensiontype-
values>.
Appendix A. Acknowledgments
Appendix B. Appendix
B.1. Application Policy Enforcement
Applications making use of supplemental authentication must define a
clear and unambiguous policy for interpreting the set of
authentication statements presented in the TLS handshake and
subsequent supplemental authentication flights. This policy dictates
the requirements for establishing a connection and for granting
access to specific resources. When evaluating a connection, the
application's policy engine must consider all received authentication
statements, as well as the absence of expected statements, as inputs
to its authorization decision. Incorrect or incomplete policy
evaluation can lead to severe security vulnerabilities.
Endpoints should perform their complete policy evaluation after all
supplemental authentication flights are complete and before
processing any application data. If the full set of presented
identities does not satisfy the application's policy, the endpoint
must terminate the connection, preferably with a specific alert
(e.g., bad_certificate or access_denied).
Rosomakho, et al. Expires 27 December 2026 [Page 19]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
B.2. Policy Enforcement Scenarios
The following non-normative examples illustrate how application
policy interacts with the supplemental authentication mechanism.
B.2.1. Hybrid Post-Quantum and Traditional Authentication
A high-security client has a local policy requiring that all
connections to a specific server be mutually authenticated using both
a traditional ECDSA certificate and a post-quantum ML-DSA
certificate.
* Client Policy: Connection requires client authentication with both
an ECDSA certificate and a ML-DSA certificate.
* Handshake: The server sends a CertificateRequest message.
* Success: The server includes the supplemental_certificate_requests
extension. The main request asks for an ECDSA certificate, and a
supplemental request asks for a ML-DSA certificate. The client is
able to satisfy both and proceeds.
* Failure: The server's CertificateRequest only asks for an ECDSA
certificate and does not include a supplemental request for ML-
DSA. Upon receiving the CertificateRequest, the client's policy
engine determines that its mandatory requirement for dual
authentication cannot be met. The client must abort the handshake
by sending a handshake_failure alert. It is a policy violation to
proceed with a connection that is only partially authenticated
according to its own requirements.
B.2.2. Device and User Identity
A service provider uses supplemental authentication to separate
device and user identity for a remote access service. The policy
grants different levels of access based on the combination of
identities presented.
Server Policy:
* Any connection requires a valid, corporate-managed device
certificate.
* Access to the general user portal requires a valid user
certificate in addition to the device certificate.
* Access to the admin portal requires a valid user certificate with
the "admin" role, in addition to the device certificate.
Rosomakho, et al. Expires 27 December 2026 [Page 20]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
Handshake:
The server sends a CertificateRequest asking for the device
certificate in the main handshake and includes a
supplemental_certificate_requests extension asking for a user
certificate.
Server Action:
* If a client provides only a valid device certificate, the
connection is established, but the application will deny access to
any resource pending the user authentication.
* If a client provides a valid device certificate and a valid
standard user certificate, the application grants access to the
general user portal but denies access to the admin portal.
* If a client provides a valid device certificate and a valid admin
user certificate, the application grants access to both portals.
* If a client provides an invalid device certificate, the server
must abort the handshake, regardless of what user certificate is
offered. The primary authentication failed to meet the baseline
policy.
Authors' Addresses
Yaroslav Rosomakho
Zscaler
Email: yrosomakho@zscaler.com
Tirumaleswar Reddy
Nokia
Bangalore
Karnataka
India
Email: k.tirumaleswar_reddy@nokia.com
Rifaat Shekh-Yusef
Ciena
Canada
Email: rifaat.s.ietf@gmail.com
Rosomakho, et al. Expires 27 December 2026 [Page 21]
Internet-Draft Supplemental Authentication in TLS 1.3 June 2026
Hannes Tschofenig
University of the Bundeswehr Munich
Germany
Email: hannes.tschofenig@gmx.net
Rosomakho, et al. Expires 27 December 2026 [Page 22]