Keying Material Exporters for Transport Layer Security (TLS)
updated by
Extracted elements (19)
The context value allows applications to mix their own data with the TLS PRF to prevent substitution attacks. For example, when client credentials are valid for more than one identity, the expected identity can be mixed into the keying material via the context value.
The mechanism was previously named 'TLS Extractors' but was renamed to 'TLS Exporters' to avoid a name conflict with the use of 'Extractor' in the cryptographic community.
The two-formula construction (with and without context) allows interoperability with older exporter-type constructions that do not use context values, such as EAP-TTLSv0 (RFC 5281). The context_value_length field in the PRF input is what distinguishes the two modes.
The exporter mechanism is compatible with all versions of TLS. The no-context formula enables interoperability with older exporter-type constructions (e.g., RFC 5281) which do not use context values.
Upper-layer context information exchanged in TLS extensions (ClientHello/ServerHello) is protected by Finished messages, ensuring both peers share the same view. However, upper-layer messages embedded in the protocol are not covered by TLS Finished messages and may not automatically secure all important context information.
All exporter label values not beginning with 'EXPERIMENTAL' MUST be registered via Specification Required as described by RFC 5226.
An attacker who can control the context value MUST NOT be able to predict the output of the exporter, even when allowed to choose multiple (label, context value) pairs and observe their outputs.
Any application using the exporter must establish the upper-layer context where keying material will be used, and at a minimum there should be some mechanism for signaling that an exporter will be used. The context must include a part indicating which application will use the exported keys.
Exporter labels SHOULD begin with 'EXPORTER' to prevent collision with existing PRF labels. This is not a MUST because there are existing uses with labels that do not begin with this prefix.
IANA MUST verify that one registered exporter label is not a prefix of any other label. For example, labels 'key' or 'master secretary' are forbidden.
The reserved labels 'client finished', 'server finished', 'master secret', and 'key expansion' MUST NOT be used for the exporter purpose described in RFC 5705, to avoid confusion with their use in RFC 5246.
Labels are ASCII strings with no terminating NULL, following the same definition as TLS PRF labels. Label values beginning with 'EXPERIMENTAL' MAY be used for private use without registration.
The TLS keying material exporter (EKM) takes three inputs: a disambiguating label string, a per-association context value provided by the application, and a length value. It outputs a pseudorandom bit string derived from the TLS master_secret via the PRF.
IANA created a 'TLS Exporter Label' registry. Initial entries include 'client finished', 'server finished', 'master secret', 'key expansion' (all from RFC 5246, reserved), 'client EAP encryption' (RFC 5216), 'ttls keying material', and 'ttls challenge' (RFC 5281). Future values use the Specification Required policy.
Because an exporter produces the same value when applied twice with the same label to the same master_secret, two EKM values generated with the same label MUST NOT be used for two different purposes — hence the requirement for IANA registration.
The prime security requirement is that exporter outputs be independent: after a TLS session, an adversary given outputs for chosen (label, context value) pairs must be unable to distinguish exporter output for any other pair from a random value. An attacker without the master secret must not distinguish valid exporter outputs from random values.
With RSA key exchange, a malicious party acting as TLS server in one session and TLS client in another can cause both sessions to share the same TLS master secret. Applications using EKM must consider this; requiring Diffie-Hellman key exchange cipher suites may be advisable.
When a context value is provided, the exporter computes PRF(master_secret, label, client_random + server_random + context_value_length + context_value)[length]. The context_value_length is encoded as an unsigned 16-bit quantity (uint16). The context MAY be zero length.
When no context is provided, the exporter computes PRF(master_secret, label, client_random + server_random)[length]. This construction allows interoperability with older exporter-type constructions that do not use context values.