3. Binding to Application Contexts
3. Binding to Application Contexts
In addition to using an exporter to obtain keying material, an application using the keying material has to securely establish the upper-layer context where the keying material will be used. The details of this context depend on the application, but it could include things such as algorithms and parameters that will be used with the keys, identifier(s) for the endpoint(s) who will use the keys, identifier(s) for the session(s) where the keys will be used, and the lifetime(s) for the context and/or keys. At a minimum, there should be some mechanism for signaling that an exporter will be used.
This specification does not mandate a single mechanism for agreeing on such context; instead, there are several possibilities that can be used (and can complement each other). For example:
-
Information about the upper-layer context can be included in the optional data after the exporter label (see Section 4).
-
Information about the upper-layer context can be exchanged in TLS extensions included in the ClientHello and ServerHello messages. This approach is used in [DTLS-SRTP]. The handshake messages are protected by the Finished messages, so once the handshake completes, the peers will have the same view of the information. Extensions also allow a limited form of negotiation: for example, the TLS client could propose several alternatives for some context parameters, and the TLS server could select one of them.
-
The upper-layer protocol can include its own handshake, which can be protected using the keys exported by TLS.
No matter how the context is agreed, it is required that it has one part that indicates which application will use the exported keys. This part is the disambiguating label string (see Section 4).
It is important to note that just embedding TLS messages in the upper-layer protocol may not automatically secure all the important context information, since the upper-layer messages are not covered by TLS Finished messages.