Exported Authenticators in TLS
Extracted elements (31)
Exported Authenticators are intended as a replacement for TLS renegotiation-based post-handshake client authentication. Unlike renegotiation, they require no changes at the TLS layer and work with TLS 1.2 and later.
Exported Authenticators provide two advantages over native TLS authentication: (1) endpoints authoritative for multiple identities can authenticate each over a single connection without a combined certificate, and (2) endpoints can authenticate spontaneously after connection establishment in response to higher-layer protocol events.
TLS 1.3 post-handshake authentication requires additional TLS state-machine state and its authentication boundaries align with TLS record boundaries, which do not align with multiplexed protocols like HTTP/2. Exported Authenticators avoid both problems by operating entirely at the application layer without modifying the TLS layer.
Exported Authenticators cannot be used with (D)TLS 1.2 ciphersuites that do not use the TLS PRF, nor with TLS 1.3 ciphersuites lacking an associated hash function. The minimum supported versions are TLS 1.2 and DTLS 1.2.
All Exported Authenticator APIs MUST fail if the connection uses (D)TLS version 1.1 or earlier, or if the connection is (D)TLS 1.2 and the extended master secret extension was not negotiated.
Certificates chosen in the Certificate message MUST conform to the requirements of the negotiated (D)TLS version, including being valid for the signature algorithms indicated in the peer's 'signature_algorithms' and 'signature_algorithms_cert' extensions.
Clients MUST NOT send an authenticator without a preceding authenticator request. Servers, however, may generate a spontaneous authenticator without a request, in which case the server chooses the certificate_request_context.
For TLS 1.3 connections, the exporter_master_secret MUST be used to derive Handshake Context and Finished MAC Key values; the early_exporter_master_secret MUST NOT be used.
If an authenticator request was provided, the Certificate message MUST contain only extensions present in the authenticator request. Without a request, the Certificate message MUST contain only extensions present in the (D)TLS ClientHello. Unrecognized extensions in the authenticator request MUST be ignored.
Only the X.509 certificate type defined in RFC 8446 is supported. Alternative formats such as Raw Public Keys (RFC 7250) are not supported in this version of the specification.
The application-layer protocol used to transmit an authenticator request or authenticator SHOULD use a secure transport channel with equivalent security to TLS (e.g., QUIC) to maintain confidentiality. The application MAY use the existing (D)TLS connection itself.
The certificate_request_context SHOULD be chosen to be unpredictable to the peer (e.g., generated randomly) in order to prevent an attacker with temporary access to the peer's private key from precomputing valid authenticators.
The certificate_request_context value MUST be unique for each authenticator request within the scope of a connection, preventing replay attacks and context confusion. This uniqueness requirement spans both CertificateRequest and ClientCertificateRequest messages used as authenticator requests on the same connection.
The signature scheme used in CertificateVerify MUST be a valid TLS 1.3 signature scheme; this excludes all RSASSA-PKCS1-v1_5 algorithms and ECDSA combined with hash algorithms not supported in TLS 1.3. If an authenticator request is present, the algorithm MUST be chosen from the 'signature_algorithms' extension of the request.
To avoid key synchronization attacks, Exported Authenticators MUST NOT be generated or accepted on (D)TLS 1.2 connections that did not negotiate the extended master secret extension (RFC 7627).
When validating an authenticator, constant-time comparisons SHOULD be used for signature and MAC validation to prevent timing side-channel attacks.
An authenticator is the concatenation of three TLS 1.3 handshake messages: Certificate || CertificateVerify || Finished. These are encoded with TLS handshake length and type fields but without record-layer framing or encryption.
An empty authenticator is an authenticated refusal: a Finished message sent without a Certificate or CertificateVerify. Its HMAC is computed over Hash(Handshake Context || authenticator request || Certificate) where Certificate contains no CertificateEntries. Well-formed empty authenticators MUST be treated as invalid by the validate API.
Authenticator keys are derived from the (D)TLS connection via TLS exporters using four distinct labels: 'EXPORTER-client authenticator handshake context', 'EXPORTER-server authenticator handshake context', 'EXPORTER-client authenticator finished key', and 'EXPORTER-server authenticator finished key'. The exported length equals the output of the ciphersuite's associated hash function (the 'authenticator hash').
The CertificateVerify signature is computed over: 64 octets of value 0x20, the ASCII context string 'Exported Authenticator' (non-NUL-terminated), a single 0x00 separator octet, and Hash(Handshake Context || authenticator request || Certificate). This structure mirrors TLS 1.3's signing input to leverage existing security analysis.
The Finished message is an HMAC computed using the Finished MAC Key over Hash(Handshake Context || authenticator request || Certificate || CertificateVerify), where Hash is the authenticator hash and the HMAC uses RFC 2104.
Three message sequences are defined: (1) Client Authentication — server generates request, client produces authenticator, server validates; (2) Server Authentication — client generates request, server produces authenticator, client validates; (3) Spontaneous Server Authentication — server generates authenticator without a preceding request, client validates.
A new handshake type 'client_certificate_request' (value 17) added to the IANA 'TLS HandshakeType' registry with DTLS-OK=Y. This type is used in TLS versions prior to 1.3.
Four new labels added to the IANA 'TLS Exporter Labels' registry: 'EXPORTER-client authenticator handshake context', 'EXPORTER-server authenticator handshake context', 'EXPORTER-client authenticator finished key', and 'EXPORTER-server authenticator finished key'; all with DTLS-OK=Y and Recommended=Y.
The server_name(0) entry in the 'TLS ExtensionType Values' registry is updated to add 'CR' to the 'TLS 1.3' column, marking server_name as valid in a ClientCertificateRequest used in client-generated authenticator requests.
Authenticators are independent and unidirectional: there is no explicit state change inside TLS when an authenticator is created or validated. This makes it difficult to formally prove that a server is jointly authoritative over multiple identities rather than individually authoritative over each.
In TLS 1.3, a server cannot confirm receipt of the client's Finished message from TLS alone. To prevent disagreement on EA authentication status, servers MUST verify the client Finished message before sending an Exported Authenticator or processing a received one.
Signatures generated with the Exported Authenticator API cover the context string 'Exported Authenticator', which prevents them from being transplanted into other protocols.
There is no indication in (D)TLS about when an authenticator was computed. Applications requiring temporal semantics must track authenticator creation and validation time as application-layer state.
The CertificateRequest and ClientCertificateRequest messages share the same structure: a variable-length certificate_request_context (0–255 octets) followed by a variable-length extensions field (2–65535 octets). They are encoded as TLS handshake messages with length and type fields but without TLS record-layer framing or encryption.
The CertificateVerify message carries a 2-byte SignatureScheme algorithm field followed by a variable-length signature (0–65535 octets). This structure is taken from TLS 1.3 (RFC 8446 Section 4.4.3).