DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange

5.1. Endpoint Procedures

The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764] 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 SDP [!@RFC4566] attribute sent by the endpoint in both offer and answer [RFC3264] messages as per [RFC8842]. Further, the endpoint MUST include this same unique identifier in the external_session_id extension [RFC8844] in the ClientHello message when establishing a DTLS association.¶

When receiving a 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.¶

5.2. Tunnel Establishment Procedures

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.¶

5.3. Media Distributor Tunneling Procedures

The first message transmitted over the tunnel is the SupportedProfiles (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 randomly assigned UUID value as described Section 4.4 of [RFC4122].¶

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 TuneledDtls 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 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 distributors 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, is not specified. The media distributor MAY use additional indicators to determine when an endpoint has disconnected.¶

5.4. Key Distributor Tunneling Procedures

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 tls-id value the endpoint transmitted via SDP. If the values in SDP and the ClientHello do not match, the DTLS association MUST be rejected.¶

The process through which the tls-id in SDP is conveyed to the key distributor is outside the scope of this document.¶

The key distributor MUST match the certificate fingerprint and external_session_id received from endpoint's ClientHello message with the values received from the SDP transmitted by the endpoint. It is through this process that the key distributor can be sure to deliver the correct conference key to the endpoint.¶

When sending the ServerHello message, the key distributor MUST insert its own unique identifier in the external_session_id extension. 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 a given DTLS association through the same tunnel if more than one tunnel has been established between it and a 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 as soon as the HBH encryption key is computed and before it sends a DTLS Finished message to the endpoint. The MediaKeys message includes the selected cipher (i.e. protection profile), MKI [RFC3711] value (if any), 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.¶

The key distributor uses the certificate fingerprint of the endpoint along with the unique identifier received in the external_session_id extension to determine which conference a given DTLS association is associated.¶

The key distributor MUST select a cipher that is supported by both 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.¶

5.5. Versioning Considerations

All messages for an established tunnel MUST utilize the same version value.¶

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, it MUST discard the message, transmit an UnsupportedVersion message, 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 UnsupportedVersion. The media distributor can determine from the first two octets received what the version number is and that the message is UnsupportedVersion. The rest of the data received, if any, would be discarded and the connection closed (if not already closed).¶

6.1. Tunnel Message Format

The syntax of the protocol is defined below. TunnelMessage defines the structure of all messages sent via the tunnel protocol. That structure includes a field called msg_type that identifies the specific type of message contained within TunnelMessage.¶

enum {
    supported_profiles(1),
    unsupported_version(2),
    media_keys(3),
    tunneled_dtls(4),
    endpoint_disconnect(5),
    (255)
} MsgType;

opaque uuid[16];

struct {
    MsgType msg_type;
    uint16 length;
    select (MsgType) {
        case supported_profiles:  SupportedProfiles;
        case unsupported_version: UnsupportedVersion;
        case media_keys:          MediaKeys;
        case tunneled_dtls:       TunneledDtls;
        case endpoint_disconnect: EndpointDisconnect;
  } body;
} TunnelMessage;

The elements of TunnelMessage include:¶

• msg_type: the type of message contained within the structure body.¶

• length: the length in octets of the following body of the message.¶

The SupportedProfiles message is defined as:¶

uint8 SRTPProtectionProfile[2]; /* from RFC5764 */

struct {
    uint8 version;
    SRTPProtectionProfile protection_profiles<0..2^16-1>;
} SupportedProfiles;

This message contains this single element:¶

• version: indicates the version of this protocol (0x00).¶

• protection_profiles: The list of two-octet SRTP protection profile values as per [RFC5764] supported by the media distributor.¶

The UnsupportedVersion message is defined as follows:¶

struct {
    uint8 highest_version;
} UnsupportedVersion;

The elements of UnsupportedVersion include:¶

• highest_version: indicates the highest supported protocol version.¶

The MediaKeys message is defined as:¶

struct {
    uuid association_id;
    SRTPProtectionProfile protection_profile;
    opaque mki<0..255>;
    opaque client_write_SRTP_master_key<1..255>;
    opaque server_write_SRTP_master_key<1..255>;
    opaque client_write_SRTP_master_salt<1..255>;
    opaque server_write_SRTP_master_salt<1..255>;
} MediaKeys;

The fields are described as follows:¶

• association_id: A value that identifies a distinct DTLS association between an endpoint and the key distributor.¶

• protection_profiles: The value of the two-octet SRTP protection profile value as per [RFC5764] used for this DTLS association.¶

• mki: Master key identifier [RFC3711]. A zero-length field indicates that no MKI value is present.¶

• clientwriteSRTPmasterkey: The value of the SRTP master key used by the client (endpoint).¶

• serverwriteSRTPmasterkey: The value of the SRTP master key used by the server (media distributor).¶

• clientwriteSRTPmastersalt: The value of the SRTP master salt used by the client (endpoint).¶

• serverwriteSRTPmastersalt: The value of the SRTP master salt used by the server (media distributor).¶

The TunneledDtls message is defined as:¶

struct {
    uuid association_id;
    opaque dtls_message<0..2^16-1>;
} TunneledDtls;

The fields are described as follows:¶

• association_id: An value that identifies a distinct DTLS association between an endpoint and the key distributor.¶

• dtls_message: the content of the DTLS message received by the endpoint or to be sent to the endpoint.¶

The EndpointDisconect message is defined as:¶

struct {
    uuid association_id;
} EndpointDisconnect;

The fields are described as follows:¶

• association_id: An value that identifies a distinct DTLS association between an endpoint and the key distributor.¶