TLS Handshake Message for Supplemental Data
Extracted elements (15)
Rather than defining a new TLS handshake message type for each new kind of supplemental application data (e.g., username hints, attribute certificates, SAML assertions), this specification defines a single bundled message type that carries all supplemental data objects together, avoiding proliferation of handshake message types.
An explicit agreement that governs presence of any supplemental data MUST be concluded between client and server for each SupplementalDataType using TLS extensions in the hello messages. Receiving an unexpected SupplementalData handshake message results in a fatal error and the receiver MUST close the connection with a fatal unexpected_message alert.
If present, the SupplementalData handshake message MUST contain a non-empty SupplementalDataEntry structure carrying data associated with at least one defined SupplementalDataType.
Information provided in a supplemental data object MUST be intended for use exclusively by applications and protocols above the TLS layer, and MUST NOT need to be processed by TLS itself.
The client MUST NOT send more than one SupplementalData handshake message, and the server MUST NOT send more than one SupplementalData handshake message. Receiving more than one results in a fatal error and the receiver MUST close the connection with a fatal unexpected_message alert.
The SupplementalData handshake message, if exchanged, MUST be sent as the first handshake message after the ServerHelloDone (from server) or before Certificate/ClientKeyExchange (from client), as illustrated in the message flow diagram.
A new TLS handshake message type, supplemental_data(23), is defined to carry supplemental application data objects negotiated via TLS hello extensions. It bundles together all supplemental data objects into a single handshake message rather than defining separate messages per data type.
IANA added supplemental_data(23) to the existing TLS HandshakeType registry (originally defined in RFC 2246).
IANA established a new registry for TLS Supplemental Data Formats (SupplementalDataType). Values 0–16385 require Standards Action; values 16386–65279 require IETF Consensus; values 65280–65535 are reserved for Private Use.
Each SupplementalDataType introduces its own unique set of security properties and considerations. Security considerations MUST therefore be defined in each document that defines a supplemental data type; this document does not attempt to enumerate them.
In the standard handshake flow, the server provides its SupplementalData information before the client is authenticated. In many situations, servers will not want to provide authorization information until the client is authenticated; the double handshake technique addresses this.
Sensitive SupplementalData can be protected using the double handshake technique: an initial TLS handshake (no extensions) establishes an encrypted channel, then a second TLS handshake (with extensions and SupplementalData) runs over that protected channel, ensuring mutual authentication before supplemental data is exchanged.
When SupplementalData is exchanged, the message flow is: ClientHello (with extensions) → ServerHello (with extensions) + SupplementalData* + Certificate* + ServerKeyExchange* + CertificateRequest* + ServerHelloDone → SupplementalData* + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished → [ChangeCipherSpec] + Finished → Application Data. The asterisk (*) indicates optional or situation-dependent messages.
The Handshake message wrapper for supplemental_data uses the standard TLS HandshakeType enum value 23, a uint24 length field, and a body selected on HandshakeType containing SupplementalData. The SupplementalDataType enum is defined with range up to 65535.
The SupplementalData structure contains a variable-length sequence of SupplementalDataEntry items (1 to 2^24-1 bytes). Each SupplementalDataEntry has a SupplementalDataType (uint16 enum), a supp_data_length field (uint16, bytes of type-specific data), and the type-selected data payload.