Internet-Draft | Secondary Clients Certificates | July 2025 |
Rosomakho & Hoyland | Expires 8 January 2026 | [Page] |
This document defines a mechanism for HTTP/2 and HTTP/3 clients to provide additional certificate-based credentials after the TLS handshake has completed, using TLS Exported Authenticators. Unlike traditional client authentication during the TLS handshake, this mechanism allows clients to present multiple certificates over the lifetime of a session.¶
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/httpbis-secondary-client-certs/draft-rosomakho-httpbis-secondary-client-certs.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-rosomakho-httpbis-secondary-client-certs/.¶
Discussion of this document takes place on the HTTP mailing list (mailto:ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/.¶
Source for this draft and an issue tracker can be found at https://github.com/yaroslavros/httpbis-secondary-client-certs.¶
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 8 January 2026.¶
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.¶
[TLS] provides an option for client authentication during the initial handshake, but this approach has several limitations. It requires early commitment to a single identity and can expose identifying information prematurely.¶
This document defines a protocol extension that allows [HTTP/2] and [HTTP/3] clients to provide certificate-based credentials after the TLS handshake, using TLS Exported Authenticators [EXPORTED-AUTH]. This enables clients to authenticate in a flexible and dynamic manner, for example when accessing specific resources, elevating privileges, or switching identities.¶
An important use case for this mechanism is the ability for a client to provide multiple identities or contextual information distributed across several certificates, such as separate device and user credentials.¶
This mechanism builds on and complements the secondary certificate support for HTTP servers defined in [SECONDARY-SERVER].¶
Client authentication is initiated by the server once both peers have negotiated support for this mechanism.¶
The client signals support and the maximum number of certificate-based credentials it is expecting to provide during the lifetime of the connection using HTTP/2 or HTTP/3 SETTINGS
parameters. The server may request client credentials by sending an AUTHENTICATOR_REQUESTS
frame, and the client responds with a sequence of CERTIFICATE
frames, each containing an Exported Authenticator.¶
The server may initiate additional authentication exchanges later in the connection, provided the total number of requested credentials does not exceed the client's declared limit.¶
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.¶
Support for HTTP-layer client certificate authentication is negotiated via a SETTINGS
parameter. An endpoint MUST NOT send frames related to client authentication (AUTHENTICATOR_REQUESTS
, or client-initiated CERTIFICATE
) unless the peer has explicitly advertised support via the SETTINGS
parameter defined in Section 3.1.¶
This restriction does not apply to server-initiated CERTIFICATE
frames, which are governed by [SECONDARY-SERVER].¶
A new SETTINGS
parameter is defined for both HTTP/2 and HTTP/3 to indicate support for HTTP-layer client certificate authentication.¶
Clients use this parameter to advertise the maximum number of certificate-based credentials they are expecting to provide during the lifetime of the connection. This value MUST be a non-zero integer. A value of zero indicates that the client does not support client certificate authentication.¶
Servers that support this mechanism MUST respond with a value of 1 to confirm support. The server's value does not affect the number of authenticator requests it can send; it merely confirms participation in the protocol.¶
Each endpoint must advertise its own support. A client MUST NOT send CERTIFICATE
frames unless both parties have advertised support for this mechanism. Similarly, a server MUST NOT send an AUTHENTICATOR_REQUESTS
frame unless both parties have advertised support.¶
Endpoints MUST NOT send a SETTINGS_HTTP_CLIENT_CERT_AUTH
parameter with a value of 0 after previously sending a value greater than 0. Once support for this extension has been advertised, it is considered enabled for the lifetime of the connection.¶
In HTTP/2, this parameter is defined as an entry in the SETTINGS
frame as specified in Section 6.5.2 of [HTTP/2].¶
In HTTP/3, this parameter is defined as a SETTINGS
parameter in accordance with Section 7.2.4.1 of [HTTP/3].¶
Once both endpoints have negotiated support for HTTP-layer client certificate authentication via SETTINGS_HTTP_CLIENT_CERT_AUTH
as described in Section 3.1), the server may initiate client authentication at any time by sending an AUTHENTICATOR_REQUESTS
frame.¶
The AUTHENTICATOR_REQUESTS
frame contains a list of authenticator requests, as defined in Section 4 of [EXPORTED-AUTH]. Each request presents a cryptographic challenge for the client to use in the construction of a corresponding Exported Authenticator.¶
The client MAY use provided authenticator requests to send CERTIFICATE
frames. Each CERTIFICATE
frame carries an Exported Authenticator that includes a certificate chain and proof of possession, as specified in Section 5 of [EXPORTED-AUTH]. A client MAY send an empty authenticator as defined in Section 6 of [EXPORTED-AUTH] in cases where it declines to authenticate for a given request.¶
This section defines the structure of the AUTHENTICATOR_REQUESTS
frame and outlines how it and the CERTIFICATE
frames, as defined in [SECONDARY-SERVER], are exchanged, ordered, and validated during the authentication process.¶
The AUTHENTICATOR_REQUESTS
frame is sent by the server to deliver authenticator requests to the client. It may be sent at any point after the client has advertised support via the SETTINGS_HTTP_CLIENT_CERT_AUTH
parameter.¶
The server MAY send multiple AUTHENTICATOR_REQUESTS
frames over the lifetime of the connection. However, the total number of outstanding authenticator requests (those for which the client has not yet responded with a CERTIFICATE
frame) MUST NOT exceed the maximum specified by the client in its SETTINGS_HTTP_CLIENT_CERT_AUTH
parameter. If this limit is exceeded, the client MUST treat it as a connection error.¶
The server MAY send additional AUTHENTICATOR_REQUESTS
frames after receiving one or more CERTIFICATE
frames from the client, in order to replenish the client's pool of active challenges. This allows the server to control the pace of client authentication while adhering to the negotiated limits.¶
The list of authenticator requests in AUTHENTICATOR_REQUESTS
frame MUST NOT be empty.¶
Each authenticator request is used by the client to construct an Exported Authenticator as defined in Section 5 of [EXPORTED-AUTH]. This frame is a control frame and MUST be sent on stream 0 in HTTP/2 or the control stream in HTTP/3.¶
AUTHENTICATOR_REQUESTS Frame { Length (24), Type (8) = 0xTBD, Unused Flags (8), Reserved (1), Stream Identifier (31) = 0, Authenticator Request (..) ..., }
If this frame is received by a server on any stream, or by a client on a stream other than stream 0, the recipient MUST treat it as a connection error of type PROTOCOL_ERROR
according to Section 5.4.1 of [HTTP/2].¶
If the frame payload is malformed or contains malformed authenticator requests (e.g., incomplete length-prefixes or invalid encoding), the recipient MUST treat it as a connection error of type PROTOCOL_ERROR
.¶
AUTHENTICATOR_REQUESTS Frame { Type (i) = 0xTBD, Length (i), Authenticator Request (..) ..., }
If this frame is received by a server on any stream, or by a client on a stream other than the control stream, the recipient MUST treat it as a connection error of type H3_FRAME_UNEXPECTED
according to Section 8 of [HTTP/3].¶
If the frame payload is malformed or contains malformed authenticator requests, the recipient MUST treat it as a connection error of type H3_MESSAGE_ERROR
.¶
Each Authenticator Request is an encoded structure consisting of a variable-length integer length and the corresponding binary value of the request:¶
Authenticator Request { Length (i), ClientCertificateRequest (..), }
Length (i): A variable-length integer specifying the length, in bytes, of the ClientCertificateRequest.¶
ClientCertificateRequest: A structure as defined in Section 4 of [EXPORTED-AUTH].¶
The payload of the AUTHENTICATOR_REQUESTS
frame consists of a sequence of these Authenticator Request elements. The list MUST NOT be empty. Clients parse the payload by reading the length, then interpreting the following bytes as a ClientCertificateRequest structure.¶
Clients MUST respond to each authenticator request context with a corresponding CERTIFICATE
frame, in the same order as the authenticator requests appeared in the AUTHENTICATOR_REQUESTS
frame.¶
The total number of outstanding authenticator requests MUST NOT exceed the value the client advertised in the SETTINGS_HTTP_CLIENT_CERT_AUTH
parameter. If the server exceeds this limit, the client MUST treat it as a connection error.¶
In HTTP/2, the connection MUST be closed with a PROTOCOL_ERROR according to Section 5.4.1 of [HTTP/2]. In HTTP/3, the connection MUST be closed with H3_FRAME_UNEXPECTED
according to Section 8 of [HTTP/3].¶
The CERTIFICATE
frame is used by the client to respond to each authenticator request previously delivered by the server in an AUTHENTICATOR_REQUESTS
frame. Each CERTIFICATE
frame carries a single Exported Authenticator structure constructed using the TLS Exported Authenticator mechanism defined in Section 5.2 of [EXPORTED-AUTH].¶
The format and semantics of the CERTIFICATE
frame are defined in [SECONDARY-SERVER], and are reused without modification for client authentication.¶
Clients MUST send exactly one CERTIFICATE
frame for each authenticator request context received. These frames MUST be sent in the same order as the corresponding authenticator requests appeared in the AUTHENTICATOR_REQUESTS
frame.¶
A CERTIFICATE
frame MAY carry an empty authenticator, as described in Section 6 of [EXPORTED-AUTH]. This allows the client to decline authentication for a particular request context without terminating the connection.¶
Clients MUST NOT send CERTIFICATE
frames unless they are in response to an outstanding AUTHENTICATOR_REQUESTS
frame. If a server receives a CERTIFICATE
frame when no authenticator request is outstanding, it MUST treat this as a connection error.¶
Servers MUST NOT send CERTIFICATE
frames unless the secondary certificate authentication mechanism for HTTP servers has been negotiated according to [SECONDARY-SERVER]. If a client receives a server-generated CERTIFICATE
frame without such negotiation, it MUST treat this as a connection error of type PROTOCOL_ERROR
(HTTP/2) or H3_FRAME_UNEXPECTED
(HTTP/3).¶
This mechanism builds on TLS Exported Authenticators [EXPORTED-AUTH], which provide cryptographic binding to the underlying TLS connection and strong guarantees of authenticity, integrity, and freshness. However, several considerations remain relevant for implementers and deployers.¶
Servers MUST carefully validate client-provided certificates and ensure that they are trusted, appropriate for the context, and bound to the intended identity. Failure to enforce proper certificate validation could allow an attacker to impersonate another client or gain unauthorized access.¶
Authorization decisions based on certificates are application-specific and must be handled with care. A certificate's presence does not imply entitlement.¶
Exported Authenticators are constructed using unique per-session cryptographic context and include binding to the TLS connection via the handshake transcript. This provides replay protection across different sessions, provided the ClientCertificateRequest includes a fresh context value. Reuse of identical request contexts across connections SHOULD be avoided.¶
Certificates often contain long-lived identifiers (such as names, device serial numbers, or email addresses). When a client presents such certificates, it exposes identity information to the server. Clients should avoid presenting identifying certificates unless necessary for the resource or context being accessed.¶
If client authentication is not required, clients may prefer to respond with an empty Exported Authenticator.¶
Exported Authenticators are cryptographically bound to the TLS session in which they are sent. A certificate authenticated using this mechanism applies to the entire HTTP connection and all streams within it. Servers MUST NOT assume that certificate-based identity can vary between streams on the same connection.¶
Applications MUST ensure that any authenticated identity is scoped to the connection lifetime, and not reused across connections unless explicitly permitted by policy.¶
The process of generating authenticator requests, tracking their state, and verifying the resulting authenticators can be computationally expensive for the server. A malicious or misbehaving client could send excessive CERTIFICATE
frames to force the server to consume memory, perform cryptographic operations, or maintain authentication state unnecessarily.¶
Servers SHOULD enforce limits on the number of authenticator requests they are willing to issue. Servers MAY respond with fewer Authenticator Requests than requested by the client or choose not to repelish consumed requests with new ones. Implementations SHOULD bound memory and compute usage per connection to mitigate such attacks.¶
Applications should consider the potential for timing side channels in certificate validation and authenticator generation. Variations in processing time may reveal information about internal policies, trust anchors, or user behavior. Constant-time validation and randomized delays are potential mitigations in sensitive deployments.¶
This document registers the AUTHENTICATOR_REQUESTS
frame type and SETTINGS_HTTP_CLIENT_CERT_AUTH
for both [HTTP/2] and [HTTP/3].¶
This specification registers the following entry in the "HTTP/2 Frame Types" registry defined in [HTTP/2]:¶
AUTHENTICATOR_REQUESTS
frame:¶
This specification registers the following entry in the "HTTP/3 Frame Types" registry defined in [HTTP/3]:¶
AUTHENTICATOR_REQUESTS
frame:¶
Value: 0xTBD¶
Frame Type: AUTHENTICATOR_REQUESTS¶
Status: provisional (permanent if this document is approved)¶
Reference: This document¶
Change Controller: Yaroslav Rosomakho (IETF if this document is approved)¶
Contact: yrosomakho@zscaler.com (HTTP_WG; HTTP working group; ietf-http-wg@w3.org if this document is approved)¶
Notes: None¶
This specification registers the following entry in the "HTTP/2 Settings" registry defined in [HTTP/2]:¶
This specification registers the following entry in the "HTTP/3 Settings" registry defined in [HTTP/3]:¶
Code: 0xTBD¶
Setting Name: SETTINGS_HTTP_CLIENT_CERT_AUTH¶
Default: 0¶
Status: provisional (permanent if this document is approved)¶
Reference: This document¶
Change Controller: Yaroslav Rosomakho (IETF if this document is approved)¶
Contact: yrosomakho@zscaler.com (HTTP_WG; HTTP working group; ietf-http-wg@w3.org if this document is approved)¶
Notes: None¶
TODO acknowledge.¶