RFC 9185

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

📅 published April 2022, from ietf

🎀 RFC 9185: DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange 🎀

okay bestie, title block time 💅🌸 this one is an Informational doc (so NOT a Standards Track spec, just published for info 🦋). It's from April 2022, written by P. Jones (Cisco Systems), P. Ellenbogen (Princeton University), and N. Ohlmeier (8x8, Inc.). It's part of the ISSN 2070-1721 series, and it doesn't obsolete or update anything. Clean slate, no drama 💖

Quick heads up: this is part 1 of 4, so more is coming 🧚

Abstract ✨

okay so the big idea is this 🔥 It defines a protocol for tunneling DTLS traffic in multimedia conferences 🎀 so a Media Distributor can help an endpoint and the Key Distributor do key exchange 🤝 The vibe: the keys used for hop-by-hop (HBH) encryption and auth have to be accessible to the Media Distributor 🔑, while the keys for end-to-end (E2E) encryption and auth have to be totally inaccessible to the Media Distributor 🙈 main character energy for privacy 👑

Status of This Memo ✨

ngl this section is mostly housekeeping 💅 It says this doc is NOT an Internet Standards Track spec, it's just published for info 🦋 It's an IETF product with IETF community consensus, public review, and IESG approval, but not every IESG-approved doc is a candidate for any level of Internet Standard (see Section 2 of RFC 7841 🌈). If you want the current status, errata, or to send feedback, go to https://www.rfc-editor.org/info/rfc9185 🫶

Copyright (c) 2022 IETF Trust and the document authors, all rights reserved 🎀 This doc is subject to BCP 78 and the IETF Trust's Legal Provisions (https://trustee.ietf.org/license-info) as of publication date, so read those carefully because they cover your rights 🦋 Any Code Components pulled out of this doc must include Revised BSD License text (Section 4.e of the Trust Legal Provisions) and come with no warranty, per the Revised BSD License 💜

Table of Contents 🌸

1.  Introduction
2.  Conventions Used in This Document
3.  Tunneling Concept
4.  Example Message Flows
5.  Tunneling Procedures
  5.1.  Endpoint Procedures
  5.2.  Tunnel Establishment Procedures
  5.3.  Media Distributor Tunneling Procedures
  5.4.  Key Distributor Tunneling Procedures
  5.5.  Versioning Considerations
6.  Tunneling Protocol
  6.1.  TunnelMessage Structure
  6.2.  SupportedProfiles Message
  6.3.  UnsupportedVersion Message
  6.4.  MediaKeys Message
  6.5.  TunneledDtls Message
  6.6.  EndpointDisconnect Message
7.  Example Binary Encoding
8.  IANA Considerations
9.  Security Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🧚

okay so PERC (Privacy-Enhanced RTP Conferencing) [RFC8871] has this goal 💖 Endpoints in a multimedia conference should have access to both the E2E and HBH keying material used to encrypt and authenticate RTP packets [RFC3550] 🎶 But the Media Distributor should only get the HBH keying material for encryption and auth 🔐

This spec defines a tunneling protocol 🦋 so the Media Distributor can tunnel DTLS messages [RFC9147] between an endpoint and a Key Distributor 🌈 That lets an endpoint use DTLS-SRTP [RFC5764] to establish its encryption and auth keys with the Key Distributor 🎀

Here's how it flows 💅 The TLS tunnel between the Media Distributor and the Key Distributor [RFC8446] gets set up BEFORE the Media Distributor forwards anything for endpoints 🔥 DTLS packets from an endpoint get wrapped by the Media Distributor inside that tunnel as data for the Key Distributor 📦 And when data comes back from the Key Distributor over the tunnel, the Media Distributor unwraps the DTLS message and forwards it to the endpoint 🫶 So the DTLS association for DTLS-SRTP is actually between the endpoint and the Key Distributor 🤝 The Media Distributor just relays in the middle and can't see the confidential stuff 🙈

Following the usual DTLS-SRTP steps, the endpoint and Key Distributor land on a cipher and keying material that both the endpoint and the Media Distributor use for HBH encryption and auth 🔑 But the Media Distributor can't get that info on its own, so the Key Distributor explicitly shares the HBH key info with it through this tunneling protocol 💌 The endpoint and Key Distributor also agree on a cipher for E2E encryption and auth 🌸 The Key Distributor sends keying material to the endpoint for E2E stuff but never shares it with the Media Distributor 🙅‍♀️

So with this TLS tunnel plus this protocol 🧚‍♀️, the Media Distributor can help set up a secure DTLS association between an endpoint and the Key Distributor, so the endpoint can generate E2E and HBH keying material ✨ Meanwhile the Key Distributor can securely hand the HBH keying material to the Media Distributor 👑

2. Conventions Used in This Document 🎀

okay so the BCP 14 key words 💅 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14 [RFC2119] [RFC8174] ONLY when they're in all capitals, like shown here 🦋

This doc uses the terms "endpoint", "Media Distributor", and "Key Distributor" as defined in [RFC8871] 🌈

3. Tunneling Concept 🧚

A TLS connection (tunnel) gets set up between the Media Distributor and the Key Distributor 🔐 That tunnel relays DTLS messages between the endpoint and the Key Distributor, like Figure 1 shows 🌸

                              +-------------+
                              |     Key     |
                              | Distributor |
                              +-------------+
                                  # ^ ^ #
                                  # | | # <-- TLS Tunnel
                                  # | | #
     +----------+             +-------------+             +----------+
     |          |     DTLS    |             |    DTLS     |          |
     | Endpoint |<------------|    Media    |------------>| Endpoint |
     |          |    to Key   | Distributor |   to Key    |          |
     |          | Distributor |             | Distributor |          |
     +----------+             +-------------+             +----------+

                  Figure 1: TLS Tunnel to Key Distributor

Three entities are in this flow: the endpoint, the Media Distributor, and the Key Distributor 👯 Each one's behavior is described in Section 5 💖

The Key Distributor is a logical function 🧠 It might sit alongside a key management server run by an enterprise 🏢, it might live inside one of the endpoints in the conference 📱, or it might be somewhere else that's trusted with E2E keying material 🔑

4. Example Message Flows 🦋

This section has an example message flow to help you get the procedures we cover later 💅 The Key Distributor and Media Distributor MUST establish a mutually authenticated TLS connection to send tunneled messages 🔒 The full TLS handshake isn't shown in Figure 2, because this doc doesn't introduce anything new for those procedures 🙈

Once the tunnel is up, the Media Distributor can relay DTLS messages between the endpoint and the Key Distributor 🌈 Figure 2 shows an endpoint using DTLS-SRTP to set up an association with the Key Distributor 🎀 Along the way, the Media Distributor shares its supported SRTP protection profile info (see [RFC5764]), and the Key Distributor shares the HBH keying material and selected cipher with the Media Distributor 🫶

     Endpoint              Media Distributor          Key Distributor
         |                         |                         |
         |                         |<=======================>|
         |                         |    TLS Connection Made  |
         |                         |                         |
         |                         |========================>|
         |                         | SupportedProfiles       |
         |                         |                         |
         |------------------------>|========================>|
         | DTLS handshake message  | TunneledDtls            |
         |                         |                         |
              .... may be multiple handshake messages ...
         |                         |                         |
         |<------------------------|<========================|
         | DTLS handshake message  |            TunneledDtls |
         |                         |                         |
         |                         |                         |
         |                         |<========================|
         |                         |               MediaKeys |

             Figure 2: Sample DTLS-SRTP Exchange via the Tunnel

After the initial TLS connection is up, each message on the right-hand side of Figure 2 is a tunneling protocol message, defined in Section 6 🧚

The SRTP protection profiles the Media Distributor supports get sent in a SupportedProfiles message when the TLS tunnel is first established 💌 The Key Distributor uses that info to pick a profile supported by both the endpoint and the Media Distributor, so HBH operations can actually work 🔥

As DTLS messages come in from the endpoint to the Media Distributor, they get forwarded to the Key Distributor wrapped in a TunneledDtls message 📦 And when TunneledDtls messages come back from the Key Distributor, the wrapped DTLS packet gets forwarded to the endpoint 🫶

The Key Distributor gives the SRTP keying material [RFC3711] to the Media Distributor for HBH operations through the MediaKeys message 🔑 Once received, the Media Distributor pulls that keying material out of the MediaKeys message and uses it for HBH encryption and auth 👑

5. Tunneling Procedures ✨

okay so this section is the step-by-step for what the endpoint, the Media Distributor, and the Key Distributor each do, bestie 💅 we're going through all three in detail 🦋

quick but important: this tunneling protocol is not an extension to TLS or DTLS 🙅‍♀️ it's its own thing that carries DTLS messages (made by an endpoint or the Key Distributor) as plain data inside the TLS connection between the Media Distributor and the Key Distributor 🎀

5.1. Endpoint Procedures

the endpoint follows the DTLS-SRTP steps from [RFC5764] to set up the cipher and keys for encryption and authentication 🔐 the endpoint plays the client, and the Key Distributor plays the server 🌸 the cutest part is that the endpoint doesn't even need to know its DTLS messages are getting tunneled to the Key Distributor 🙈

the endpoint MUST put a unique identifier in the tls-id Session Description Protocol (SDP) attribute [RFC8866] in every offer and answer [RFC3264] it generates, following [RFC8842] 💜 and then it MUST also put that same identifier in the external_session_id extension [RFC8844] inside its ClientHello when it starts a DTLS association 🧚

when the endpoint gets an external_session_id back from the Key Distributor, the client MUST check that it matches the tls-id it got in SDP 👀 if they don't match, the endpoint MUST consider any keying material it received to be invalid and terminate the DTLS association 💀

5.2. Tunnel Establishment Procedures

either the Media Distributor or the Key Distributor can kick off setting up a TLS tunnel ✨ which side acts as the TLS client, and what event triggers the tunnel, are outside the scope of this document 🤷‍♀️ same deal for how the trust relationships between the Key Distributor and Media Distributor get set up 🔒

a tunnel MUST be a mutually authenticated TLS connection 🫶

the Media Distributor or Key Distributor MUST establish a tunnel before forwarding any tunneled DTLS messages ⭐ because DTLS-SRTP is so time-sensitive 😭, a tunnel SHOULD be established before the Media Distributor gets 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 set up between itself and one or more Key Distributors 💖 when that happens, which tunnel (or tunnels) gets used for a given conference is outside the scope of this document 🦋

5.3. Media Distributor Tunneling Procedures

the very first message sent over the tunnel is the SupportedProfiles message (see Section 6) 🎀 it tells the Key Distributor which DTLS-SRTP profiles the Media Distributor supports 💅 this message MUST be sent every time a new tunnel connection is set up, or when a dropped connection gets re-established 🌸 and the Media Distributor MUST support the same list of protection profiles for as long as an endpoint-initiated DTLS association and the tunnel connection are around 🔁

the Media Distributor MUST assign a unique association identifier to each endpoint-initiated DTLS association and include it in every message it forwards to the Key Distributor 🪪 the Key Distributor then puts that identifier in every message it sends back, so the Media Distributor can map each incoming message to the right endpoint 🧭 the association identifier MUST be a version 4 Universally Unique Identifier (UUID), as described in Section 4.4 of [RFC4122] 💜

when the Media Distributor gets a DTLS message from an endpoint, it forwards the UDP payload part of that message to the Key Distributor, wrapped up in a TunneledDtls message 🎁 the Media Distributor is not required to send every message from an endpoint for a given DTLS association through the same tunnel, if it has more than one tunnel set up with a Key Distributor 🌈

when a MediaKeys message arrives, the Media Distributor MUST extract the cipher and keying material inside it, so it can do HBH encryption and authentication for RTP and RTP Control Protocol (RTCP) packets going between itself and an endpoint 🔐✨ since the HBH keying material is different for every endpoint, the Media Distributor uses the association identifier that the Key Distributor included to make sure each key goes with the correct endpoint 🫶

the Media Distributor MUST forward all DTLS messages it gets from either the endpoint or the Key Distributor (via the TunneledDtls message), so those two can keep talking properly 💬

when the Media Distributor notices an endpoint has disconnected, or when conference control messages say the endpoint is supposed to be disconnected, the Media Distributor MUST send an EndpointDisconnect message with that endpoint's association identifier to the Key Distributor 👋 the Media Distributor SHOULD treat a loss of all RTP and RTCP packets as a sign the endpoint has disconnected 📉 how exactly RTP and RTCP get used to detect a disconnect, like the timeout period, is not specified 🤷‍♀️ and the Media Distributor MAY use additional indicators to decide when an endpoint has disconnected 🌸

5.4. Key Distributor Tunneling Procedures

each TLS tunnel between the Media Distributor and the Key Distributor MUST be mutually authenticated 🔒🫶

when the Media Distributor relays a DTLS message from an endpoint, it includes an association identifier that is unique to each endpoint-originated DTLS association 🪪 that identifier stays the same for the whole life of the DTLS association 💜 the Key Distributor tells each distinct endpoint-originated DTLS association apart by its association identifier ✨

when the Key Distributor processes an incoming endpoint association, it MUST pull the external_session_id value out of the ClientHello and match it against the tls-id value the endpoint sent over SDP 👀 if the SDP value and the ClientHello value don't match, the DTLS association MUST be rejected 🚫

how the tls-id value from SDP gets to the Key Distributor is outside the scope of this document 📮

the Key Distributor MUST match the fingerprint of the certificate and the external_session_id [RFC8844] it gets from the endpoint over DTLS against the expected fingerprint [RFC8122] and tls-id [RFC8842] values it got via SDP 🕵️‍♀️ this is how the Key Distributor can be sure it's handing the correct conference key to the correct endpoint 🔑

the Key Distributor MUST report its own unique identifier in the external_session_id extension 🆔 that extension goes in the EncryptedExtensions message for DTLS 1.3, and in the ServerHello message for earlier DTLS versions 🧚 this value MUST also be sent back to the client through SDP as a tls-id attribute 🎀

the Key Distributor MUST wrap any DTLS message it sends to an endpoint inside a TunneledDtls message (see Section 6) 🎁 it's not required to send all messages for a given DTLS association through the same tunnel, if it has more than one tunnel set up with the Media Distributor 🌈

the Key Distributor MUST use the same association identifier in messages it sends to an endpoint as it got in messages from that endpoint 🪪 this is what lets the Media Distributor forward each message to the correct endpoint 🧭

the Key Distributor pulls tunneled DTLS messages out of an endpoint and handles them as if that endpoint had set up the DTLS association directly with the Key Distributor 💁‍♀️ the Key Distributor acts as the DTLS server, and the endpoint acts as the DTLS client 🫶 the handling of messages and certificates is exactly the same as normal DTLS-SRTP between endpoints, no difference at all 💅

the Key Distributor MUST send a MediaKeys message to the Media Distributor right after the DTLS handshake completes 🔐 the MediaKeys message includes the selected cipher (i.e., protection profile), the Master Key Identifier (MKI) value [RFC3711] (if there is one), the HBH SRTP master keys, and the SRTP master salt values 📦 the Key Distributor MUST use the same association identifier in the MediaKeys message that it uses in the TunneledDtls messages for that endpoint 🪪

there are currently two SRTP protection profiles defined for PERC, and they are DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [RFC8723] 🌸 as Section 5.2 of [RFC8723] explains, the Media Distributor only gets the SRTP master key for HBH operations 🔑 so the SRTP master key length advertised in the MediaKeys message is half the length of the key normally tied to the chosen "double" protection profile 📏✨

the Key Distributor uses the endpoint's certificate fingerprint, along with the unique identifier received in the external_session_id extension, to figure out which conference a given DTLS association belongs to 🕵️‍♀️💖

the Key Distributor MUST select a cipher that is supported by itself, the endpoint, and the Media Distributor, so that HBH operations work properly 🧩

when the DTLS association between the endpoint and the Key Distributor ends, no matter which side started the termination, the Key Distributor MUST send an EndpointDisconnect message with that endpoint's association identifier to the Media Distributor 👋🥺

5.5. Versioning Considerations

since the Media Distributor sends the first message over the tunnel, it's basically the one that sets which version of the protocol gets used 👑 if the Key Distributor doesn't support that version, the Key Distributor MUST send back an UnsupportedVersion message with the highest version number it supports, and then close the TLS connection 🙅‍♀️

the Media Distributor MUST take note of the version in an UnsupportedVersion message, and use that version when it tries to re-establish a failed tunnel connection 📝 the Media Distributor doesn't need to understand a newer version of the protocol to recognize that the first message it got is an UnsupportedVersion message 🧠 it can tell from the first four octets what the version number is, and that the message is an UnsupportedVersion message 🔍 any rest of the data received gets thrown away, and the connection gets closed (if it isn't already) 🫧

6. Tunneling Protocol 🧚

tunneled messages get carried over the TLS tunnel as application data between the Media Distributor and the Key Distributor 🎀 tunnel messages are specified using the format described in [RFC8446], Section 3 💅 like in [RFC8446], all values are stored in network byte (big endian) order, so the uint32 represented by the hex bytes 01 02 03 04 is equivalent to the decimal value 16909060 🔢✨

this protocol defines several different messages, and each one contains the following info:

  • message type identifier
  • message body length
  • the message body

each of the tunnel messages is a TunnelMessage structure, and the message type tells you what's actually in the message body 💜

6.1. TunnelMessage Structure 💖

Okay so TunnelMessage is the struct that wraps EVERY message sent through the tunnel protocol 🫶 It has a field called msg_type that tells you which kind of message is inside, so you always know what you're dealing with ✨

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. 📏
  • body: the actual message being conveyed within this TunnelMessage structure. 💌

6.2. SupportedProfiles Message 🎀

The SupportedProfiles message is defined as:

uint8 SRTPProtectionProfile[2]; /* from RFC 5764 */

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

The elements of SupportedProfiles include:

  • version: this document specifies version 0x00. 🧚
  • protection_profiles: the list of two-octet SRTP protection profile values, as per [RFC5764], supported by the Media Distributor. 🦋

6.3. UnsupportedVersion Message 🙈

The UnsupportedVersion message is defined as:

struct {
    uint8 highest_version;
} UnsupportedVersion;

UnsupportedVersion contains this single element:

  • highest_version: indicates the highest version of the protocol supported by the Key Distributor. 👑

6.4. MediaKeys Message 🔐

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. 🫥
  • client_write_SRTP_master_key: the value of the SRTP master key used by the client (endpoint). 🗝️
  • server_write_SRTP_master_key: the value of the SRTP master key used by the server (Media Distributor). 🗝️
  • client_write_SRTP_master_salt: the value of the SRTP master salt used by the client (endpoint). 🧂
  • server_write_SRTP_master_salt: the value of the SRTP master salt used by the server (Media Distributor). 🧂

6.5. TunneledDtls Message 🚇

The TunneledDtls message is defined as:

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

The fields are described as follows:

  • association_id: a 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, including one or more complete DTLS records. 📦

6.6. EndpointDisconnect Message 👋

The EndpointDisconnect message is defined as:

struct {
    uuid association_id;
} EndpointDisconnect;

The field is described as follows:

  • association_id: a value that identifies a distinct DTLS association between an endpoint and the Key Distributor. 🥀

7. Example Binary Encoding 🦋

The TunnelMessage is encoded in binary, following the procedures specified in [RFC8446]. This section gives an example of what the bits on the wire would look like for the SupportedProfiles message that advertises support for both DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [RFC8723]. 🌈

TunnelMessage:
         message_type: 0x01
               length: 0x0007
    SupportedProfiles:
                   version:  0x00
       protection_profiles:  0x0004 (length)
                             0x0009000A (value)

Thus, the encoding on the wire, presented here in network byte order, would be this stream of octets:

0x0100070000040009000A

8. IANA Considerations 🎀

This document establishes the "Datagram Transport Layer Security (DTLS) Tunnel Protocol Message Types for Privacy Enhanced Conferencing" registry to contain message type values used in the DTLS tunnel protocol. These message type values are a single octet in length. This document defines the values shown in Table 1 below, leaving the balance of possible values reserved for future specifications: 📋

+=========+====================================+
| MsgType | Description                        |
+=========+====================================+
|   0x01  | Supported SRTP Protection Profiles |
+---------+------------------------------------+
|   0x02  | Unsupported Version                |
+---------+------------------------------------+
|   0x03  | Media Keys                         |
+---------+------------------------------------+
|   0x04  | Tunneled DTLS                      |
+---------+------------------------------------+
|   0x05  | Endpoint Disconnect                |
+---------+------------------------------------+

            Table 1: Message Type Values for the DTLS
                         Tunnel Protocol

The value 0x00 is reserved, and all values in the range 0x06 to 0xFF are available for allocation. The procedures for updating this table are those defined as "IETF Review" in Section 4.8 of [RFC8126]. 🔢

9. Security Considerations 🚨

Okay bestie, this part is SERIOUS, so read it with your whole brain 🧠

Since the procedures in this document rely on TLS [RFC8446] for transport security, the security considerations for TLS should be reviewed when implementing the protocol defined in this document. 🔒

While the tunneling protocol defined in this document does not use DTLS-SRTP [RFC5764] directly, it does convey and negotiate some of the same information (e.g., protection profile data). As such, a review of the security considerations found in that document may be useful. 🧾

This document describes a means of securely exchanging keying material and cryptographic transforms for both E2E and HBH encryption and authentication of media between an endpoint and a Key Distributor via a Media Distributor. Additionally, the procedures result in delivering HBH information to the intermediary Media Distributor. The Key Distributor and endpoint are the only two entities with access to both the E2E and HBH keys, while the Media Distributor has access to only HBH information. Section 8.2 of [RFC8871] enumerates various attacks against which one must guard when implementing a Media Distributor; these scenarios are important to note. 🕵️‍♀️

A requirement in this document is that a TLS connection between the Media Distributor and the Key Distributor be mutually authenticated. The reason for this requirement is to ensure that only an authorized Media Distributor receives the HBH keying material. If an unauthorized Media Distributor gains access to the HBH keying material, it can easily cause service degradation or denial by transmitting HBH-valid packets that ultimately fail E2E authentication or replay protection checks (see Section 3.3.2 of [RFC3711]). Even if service does not appear degraded in any way, transmitting and processing bogus packets are a waste of both computational and network resources. 🗑️

The procedures defined in this document assume that the Media Distributor will properly convey DTLS messages between the endpoint and Key Distributor. Should it fail in that responsibility by forwarding DTLS messages from endpoint A advertised as being from endpoint B, this will result in a failure at the DTLS layer of those DTLS sessions. This could be an additional attack vector that Key Distributor implementations should consider. 🎭

While E2E keying material passes through the Media Distributor via the protocol defined in this document, the Media Distributor has no means of gaining access to that information and therefore cannot affect the E2E media processing function in the endpoint except to present it with invalid or replayed data. That said, any entity along the path that interferes with the DTLS exchange between the endpoint and the Key Distributor, including a malicious Media Distributor that is not properly authorized, could prevent an endpoint from properly communicating with the Key Distributor and therefore prevent successful conference participation. 🚫

It is worth noting that a compromised Media Distributor can convey information to an adversary, such as participant IP addresses, negotiated protection profiles, or other metadata. While [RFC8871] explains that a malicious or compromised Media Distributor can disrupt communications, an additional attack vector introduced by this protocol is the potential disruption of DTLS negotiation or premature removal of a participant from a conference by sending an EndpointDisconnect message to the Key Distributor. 😱

The Key Distributor should be aware of the possibility that a malicious Media Distributor might transmit an EndpointDisconnect message to the Key Distributor when the endpoint is in fact still connected. 👀

While the Security Considerations section of [RFC8871] describes various attacks one needs to consider with respect to the Key Distributor and denial of service, use of this protocol introduces another possible attack vector. Consider the case where a malicious endpoint sends unsolicited DTLS-SRTP messages to a Media Distributor. The Media Distributor will normally forward those messages to the Key Distributor and, if found invalid, such messages only serve to consume resources on both the Media Distributor and Key Distributor. 💀

10. References 📚

10.1. Normative References

Okay bestie, these are the must-reads 📚✨ Every entry is kept in full, with the authors, titles, numbers, DOIs, and links.

10.2. Informative References

Here's the extra reading, the "ooh, tell me more" stuff 💅

Acknowledgements 🫶

The authors would like to thank David Benham and Cullen Jennings for reviewing this document and providing constructive comments. They were so helpful, and we love them for it 💜

Authors' Addresses 💅

Paul E. Jones, the first author, is at Cisco Systems, Inc.:

Paul E. Jones
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, North Carolina 27709
United States of America
Phone: +1 919 476 2048
Email: paulej@packetizer.com

Paul M. Ellenbogen is at Princeton University:

Paul M. Ellenbogen
Princeton University
Phone: +1 206 851 2069
Email: pe5@cs.princeton.edu

Nils H. Ohlmeier is at 8x8, Inc.:

Nils H. Ohlmeier
8x8, Inc.
Phone: +1 408 659 6457
Email: nils@ohlmeier.org
📦 where this page comes from