The following subsections explain in detail the expected behavior of the endpoint, the Media Distributor, and the Key Distributor.
It is important to note that the tunneling protocol described in this document is not an extension to TLS or DTLS. Rather, it is a protocol that transports DTLS messages generated by an endpoint or Key Distributor as data inside of the TLS connection established between the Media Distributor and Key Distributor.
The endpoint follows the procedures outlined for DTLS-SRTP [
RFC 5764] in order to establish the cipher and keys used for encryption and authentication, with the endpoint acting as the client and the Key Distributor acting as the server. The endpoint does not need to be aware of the fact that DTLS messages it transmits toward the Media Distributor are being tunneled to the Key Distributor.
The endpoint
MUST include a unique identifier in the
tls-id Session Description Protocol (SDP) attribute [
RFC 8866] in all offer and answer messages [
RFC 3264] that it generates, as per [
RFC 8842]. Further, the endpoint
MUST include this same unique identifier in the
external_session_id extension [
RFC 8844] in the
ClientHello message when establishing a DTLS association.
When receiving an
external_session_id value from the Key Distributor, the client
MUST check to ensure that value matches the
tls-id value received in SDP. If the values do not match, the endpoint
MUST consider any received keying material to be invalid and terminate the DTLS association.
Either the Media Distributor or Key Distributor initiates the establishment of a TLS tunnel. Which entity acts as the TLS client when establishing the tunnel and what event triggers the establishment of the tunnel are outside the scope of this document. Further, how the trust relationships are established between the Key Distributor and Media Distributor are also outside the scope of this document.
A tunnel
MUST be a mutually authenticated TLS connection.
The Media Distributor or Key Distributor
MUST establish a tunnel prior to forwarding tunneled DTLS messages. Given the time-sensitive nature of DTLS-SRTP procedures, a tunnel
SHOULD be established prior to the Media Distributor receiving a DTLS message from an endpoint.
A single tunnel
MAY be used to relay DTLS messages between any number of endpoints and the Key Distributor.
A Media Distributor
MAY have more than one tunnel established between itself and one or more Key Distributors. When multiple tunnels are established, which tunnel or tunnels to use to send messages for a given conference is outside the scope of this document.
The first message transmitted over the tunnel is the
SupportedProfiles message (see
Section 6). This message informs the Key Distributor about which DTLS-SRTP profiles the Media Distributor supports. This message
MUST be sent each time a new tunnel connection is established or, in the case of connection loss, when a connection is re-established. The Media Distributor
MUST support the same list of protection profiles for the duration of any endpoint-initiated DTLS association and tunnel connection.
The Media Distributor
MUST assign a unique association identifier for each endpoint-initiated DTLS association and include it in all messages forwarded to the Key Distributor. The Key Distributor will subsequently include this identifier in all messages it sends so that the Media Distributor can map messages received via a tunnel and forward those messages to the correct endpoint. The association identifier
MUST be a version 4 Universally Unique Identifier (UUID), as described in
Section 4.4 of
RFC 4122.
When a DTLS message is received by the Media Distributor from an endpoint, it forwards the UDP payload portion of that message to the Key Distributor encapsulated in a
TunneledDtls message. The Media Distributor is not required to forward all messages received from an endpoint for a given DTLS association through the same tunnel if more than one tunnel has been established between it and a Key Distributor.
When a
MediaKeys message is received, the Media Distributor
MUST extract the cipher and keying material conveyed in order to subsequently perform HBH encryption and authentication operations for RTP and RTP Control Protocol (RTCP) packets sent between it and an endpoint. Since the HBH keying material will be different for each endpoint, the Media Distributor uses the association identifier included by the Key Distributor to ensure that the HBH keying material is used with the correct endpoint.
The Media Distributor
MUST forward all DTLS messages received from either the endpoint or the Key Distributor (via the
TunneledDtls message) to ensure proper communication between those two entities.
When the Media Distributor detects an endpoint has disconnected or when it receives conference control messages indicating the endpoint is to be disconnected, the Media Distributor
MUST send an
EndpointDisconnect message with the association identifier assigned to the endpoint to the Key Distributor. The Media Distributor
SHOULD take a loss of all RTP and RTCP packets as an indicator that the endpoint has disconnected. The particulars of how RTP and RTCP are to be used to detect an endpoint disconnect, such as timeout period, are not specified. The Media Distributor
MAY use additional indicators to determine when an endpoint has disconnected.
Each TLS tunnel established between the Media Distributor and the Key Distributor
MUST be mutually authenticated.
When the Media Distributor relays a DTLS message from an endpoint, the Media Distributor will include an association identifier that is unique per endpoint-originated DTLS association. The association identifier remains constant for the life of the DTLS association. The Key Distributor identifies each distinct endpoint-originated DTLS association by the association identifier.
When processing an incoming endpoint association, the Key Distributor
MUST extract the
external_session_id value transmitted in the
ClientHello message and match that against the
tls-id value the endpoint transmitted via SDP. If the values in SDP and the
ClientHello message do not match, the DTLS association
MUST be rejected.
The process through which the
tls-id value in SDP is conveyed to the Key Distributor is outside the scope of this document.
The Key Distributor
MUST match the fingerprint of the certificate and
external_session_id [
RFC 8844] received from the endpoint via DTLS with the expected fingerprint [
RFC 8122] and
tls-id [
RFC 8842] values received via SDP. It is through this process that the Key Distributor can be sure to deliver the correct conference key to the endpoint.
The Key Distributor
MUST report its own unique identifier in the
external_session_id extension. This extension is sent in the
EncryptedExtensions message in DTLS 1.3 and the
ServerHello message in previous DTLS versions. This value
MUST also be conveyed back to the client via SDP as a
tls-id attribute.
The Key Distributor
MUST encapsulate any DTLS message it sends to an endpoint inside a
TunneledDtls message (see
Section 6). The Key Distributor is not required to transmit all messages for a given DTLS association through the same tunnel if more than one tunnel has been established between it and the Media Distributor.
The Key Distributor
MUST use the same association identifier in messages sent to an endpoint as was received in messages from that endpoint. This ensures the Media Distributor can forward the messages to the correct endpoint.
The Key Distributor extracts tunneled DTLS messages from an endpoint and acts on those messages as if that endpoint had established the DTLS association directly with the Key Distributor. The Key Distributor is acting as the DTLS server, and the endpoint is acting as the DTLS client. The handling of the messages and certificates is exactly the same as normal DTLS-SRTP procedures between endpoints.
The Key Distributor
MUST send a
MediaKeys message to the Media Distributor immediately after the DTLS handshake completes. The
MediaKeys message includes the selected cipher (i.e., protection profile), Master Key Identifier (MKI) value [
RFC 3711] (if any), HBH SRTP master keys, and SRTP master salt values. The Key Distributor
MUST use the same association identifier in the
MediaKeys message as is used in the
TunneledDtls messages for the given endpoint.
There are presently two SRTP protection profiles defined for PERC, namely
DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and
DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [
RFC 8723]. As explained in
Section 5.2 of
RFC 8723, the Media Distributor is only given the SRTP master key for HBH operations. As such, the SRTP master key length advertised in the
MediaKeys message is half the length of the key normally associated with the selected "double" protection profile.
The Key Distributor uses the certificate fingerprint of the endpoint along with the unique identifier received in the
external_session_id extension to determine with which conference a given DTLS association is associated.
The Key Distributor
MUST select a cipher that is supported by itself, the endpoint, and the Media Distributor to ensure proper HBH operations.
When the DTLS association between the endpoint and the Key Distributor is terminated, regardless of which entity initiated the termination, the Key Distributor
MUST send an
EndpointDisconnect message with the association identifier assigned to the endpoint to the Media Distributor.
Since the Media Distributor sends the first message over the tunnel, it effectively establishes the version of the protocol to be used. If that version is not supported by the Key Distributor, the Key Distributor
MUST transmit an
UnsupportedVersion message containing the highest version number supported and close the TLS connection.
The Media Distributor
MUST take note of the version received in an
UnsupportedVersion message and use that version when attempting to re-establish a failed tunnel connection. Note that it is not necessary for the Media Distributor to understand the newer version of the protocol to understand that the first message received is an
UnsupportedVersion message. The Media Distributor can determine from the first four octets received what the version number is and that the message is an
UnsupportedVersion message. The rest of the data received, if any, would be discarded and the connection closed (if not already closed).