Summary

Add API and implementation support for TLS Keying Material Exporters (KME) as described in RFC 5705 and RFC 8446 to the JDK TLS stacks.

Problem

RFC 5705 provides a general solution to the following problem:

A number of protocols wish to leverage Transport Layer Security (TLS)
or Datagram TLS (DTLS) to perform key establishment but then use
some of the keying material for their own purposes.

Many protocols have since been defined which use this generalized approach, including RFCs 5216, 5281, 5764, 6083, 6347, 8471, 9431, 9190, 9261, 9427, and others including 5G (mobile) specs.

We have recently received requests for supporting this approach, and it is a good candidate for inclusion in the JDK.

Adding this functionality will bring Java on-par with other TLS stacks, including Bouncy Castle, GnuTLS, NSS, OpenSSL, and Microsoft.

Solution

The approach is straightforward.

Add new methods to javax.net.ssl.ExtendedSSLSession which allow applications to pass the needed fields to the underlying JSSE implementation, which in turn will calculate the required bytes according to the defined algorithms and return that to the caller, either as a SecretKey or a byte[].

There are slight differences in the parameters for TLSv1-1.2 (RFC 5705) and TLSv1.3 (RFC 8446) which will be accounted for in the javadoc specification.

Specification

(Due to a markdown rendering bug in JIRA/JBS, the specification is included as a text attachment.)

Both methods allow applications to pass label and context byte arrays to the underlying EKM mechanism.