diff options
Diffstat (limited to 'doc/rfc/rfc9185.txt')
| -rw-r--r-- | doc/rfc/rfc9185.txt | 861 |
1 files changed, 861 insertions, 0 deletions
diff --git a/doc/rfc/rfc9185.txt b/doc/rfc/rfc9185.txt new file mode 100644 index 0000000..f89076c --- /dev/null +++ b/doc/rfc/rfc9185.txt @@ -0,0 +1,861 @@ + + + + +Internet Engineering Task Force (IETF) P. Jones +Request for Comments: 9185 Cisco Systems +Category: Informational P. Ellenbogen +ISSN: 2070-1721 Princeton University + N. Ohlmeier + 8x8, Inc. + April 2022 + + + DTLS Tunnel between a Media Distributor and Key Distributor to + Facilitate Key Exchange + +Abstract + + This document defines a protocol for tunneling DTLS traffic in + multimedia conferences that enables a Media Distributor to facilitate + key exchange between an endpoint in a conference and the Key + Distributor. The protocol is designed to ensure that the keying + material used for hop-by-hop encryption and authentication is + accessible to the Media Distributor, while the keying material used + for end-to-end encryption and authentication is inaccessible to the + Media Distributor. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9185. + +Copyright Notice + + Copyright (c) 2022 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in 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 + + An objective of Privacy-Enhanced RTP Conferencing (PERC) [RFC8871] is + to ensure that endpoints in a multimedia conference have access to + the end-to-end (E2E) and hop-by-hop (HBH) keying material used to + encrypt and authenticate Real-time Transport Protocol (RTP) packets + [RFC3550], while the Media Distributor has access only to the HBH + keying material for encryption and authentication. + + This specification defines a tunneling protocol that enables the + Media Distributor to tunnel DTLS messages [RFC9147] between an + endpoint and a Key Distributor, thus allowing an endpoint to use DTLS + for the Secure Real-time Transport Protocol (DTLS-SRTP) [RFC5764] for + establishing encryption and authentication keys with the Key + Distributor. + + The tunnel established between the Media Distributor and Key + Distributor is a TLS connection [RFC8446] that is established before + any messages are forwarded by the Media Distributor on behalf of + endpoints. DTLS packets received from an endpoint are encapsulated + by the Media Distributor inside this tunnel as data to be sent to the + Key Distributor. Likewise, when the Media Distributor receives data + from the Key Distributor over the tunnel, it extracts the DTLS + message inside and forwards the DTLS message to the endpoint. In + this way, the DTLS association for the DTLS-SRTP procedures is + established between an endpoint and the Key Distributor, with the + Media Distributor forwarding DTLS messages between the two entities + via the established tunnel to the Key Distributor and having no + visibility into the confidential information exchanged. + + Following the existing DTLS-SRTP procedures, the endpoint and Key + Distributor will arrive at a selected cipher and keying material, + which are used for HBH encryption and authentication by both the + endpoint and the Media Distributor. However, since the Media + Distributor would not have direct access to this information, the Key + Distributor explicitly shares the HBH key information with the Media + Distributor via the tunneling protocol defined in this document. + Additionally, the endpoint and Key Distributor will agree on a cipher + for E2E encryption and authentication. The Key Distributor will + transmit keying material to the endpoint for E2E operations but will + not share that information with the Media Distributor. + + By establishing this TLS tunnel between the Media Distributor and Key + Distributor and implementing the protocol defined in this document, + it is possible for the Media Distributor to facilitate the + establishment of a secure DTLS association between an endpoint and + the Key Distributor in order for the endpoint to generate E2E and HBH + keying material. At the same time, the Key Distributor can securely + provide the HBH keying material to the Media Distributor. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + This document uses the terms "endpoint", "Media Distributor", and + "Key Distributor" defined in [RFC8871]. + +3. Tunneling Concept + + A TLS connection (tunnel) is established between the Media + Distributor and the Key Distributor. This tunnel is used to relay + DTLS messages between the endpoint and Key Distributor, as depicted + in Figure 1: + + +-------------+ + | Key | + | Distributor | + +-------------+ + # ^ ^ # + # | | # <-- TLS Tunnel + # | | # + +----------+ +-------------+ +----------+ + | | DTLS | | DTLS | | + | Endpoint |<------------| Media |------------>| Endpoint | + | | to Key | Distributor | to Key | | + | | Distributor | | Distributor | | + +----------+ +-------------+ +----------+ + + Figure 1: TLS Tunnel to Key Distributor + + The three entities involved in this communication flow are the + endpoint, the Media Distributor, and the Key Distributor. The + behavior of each entity is described in Section 5. + + The Key Distributor is a logical function that might be co-resident + with a key management server operated by an enterprise, might reside + in one of the endpoints participating in the conference, or might + reside at some other location that is trusted with E2E keying + material. + +4. Example Message Flows + + This section provides an example message flow to help clarify the + procedures described later in this document. It is necessary that + the Key Distributor and Media Distributor establish a mutually + authenticated TLS connection for the purpose of sending tunneled + messages, though the complete TLS handshake for the tunnel is not + shown in Figure 2 because there is nothing new this document + introduces with regard to those procedures. + + Once the tunnel is established, it is possible for the Media + Distributor to relay the DTLS messages between the endpoint and the + Key Distributor. Figure 2 shows a message flow wherein the endpoint + uses DTLS-SRTP to establish an association with the Key Distributor. + In the process, the Media Distributor shares its supported SRTP + protection profile information (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 has been established, each of the + messages on the right-hand side of Figure 2 is a tunneling protocol + message, as defined in Section 6. + + SRTP protection profiles supported by the Media Distributor will be + sent in a SupportedProfiles message when the TLS tunnel is initially + established. The Key Distributor will use that information to select + a common profile supported by both the endpoint and the Media + Distributor to ensure that HBH operations can be successfully + performed. + + As DTLS messages are received from the endpoint by the Media + Distributor, they are forwarded to the Key Distributor encapsulated + inside a TunneledDtls message. Likewise, as TunneledDtls messages + are received by the Media Distributor from the Key Distributor, the + encapsulated DTLS packet is forwarded to the endpoint. + + The Key Distributor will provide the SRTP keying material [RFC3711] + to the Media Distributor for HBH operations via the MediaKeys + message. The Media Distributor will extract this keying material + from the MediaKeys message when received and use it for HBH + encryption and authentication. + +5. Tunneling Procedures + + 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. + +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 Session + Description Protocol (SDP) attribute [RFC8866] in all offer and + answer messages [RFC3264] that it generates, 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 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. + +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 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 [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 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. + +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 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 [RFC8844] received from the endpoint via DTLS + with the expected fingerprint [RFC8122] and tls-id [RFC8842] 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 [RFC3711] (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 [RFC8723]. As explained in + Section 5.2 of [RFC8723], 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. + +5.5. Versioning Considerations + + 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). + +6. Tunneling Protocol + + Tunneled messages are transported via 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. As in [RFC8446], all values are stored in network byte + (big endian) order; the uint32 represented by the hex bytes 01 02 03 + 04 is equivalent to the decimal value 16909060. + + This protocol defines several different messages, each of which + contains the following information: + + * message type identifier + + * message body length + + * the message body + + Each of the tunnel messages is a TunnelMessage structure with the + message type indicating the actual content of the message body. + +6.1. TunnelMessage Structure + + 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. + + 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 provides 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 + + 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 + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, DOI 10.17487/RFC3711, March 2004, + <https://www.rfc-editor.org/info/rfc3711>. + + [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally + Unique IDentifier (UUID) URN Namespace", RFC 4122, + DOI 10.17487/RFC4122, July 2005, + <https://www.rfc-editor.org/info/rfc4122>. + + [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer + Security (DTLS) Extension to Establish Keys for the Secure + Real-time Transport Protocol (SRTP)", RFC 5764, + DOI 10.17487/RFC5764, May 2010, + <https://www.rfc-editor.org/info/rfc5764>. + + [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media + Transport over the Transport Layer Security (TLS) Protocol + in the Session Description Protocol (SDP)", RFC 8122, + DOI 10.17487/RFC8122, March 2017, + <https://www.rfc-editor.org/info/rfc8122>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, + "Double Encryption Procedures for the Secure Real-Time + Transport Protocol (SRTP)", RFC 8723, + DOI 10.17487/RFC8723, April 2020, + <https://www.rfc-editor.org/info/rfc8723>. + + [RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol + (SDP) Offer/Answer Considerations for Datagram Transport + Layer Security (DTLS) and Transport Layer Security (TLS)", + RFC 8842, DOI 10.17487/RFC8842, January 2021, + <https://www.rfc-editor.org/info/rfc8842>. + + [RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on + Uses of TLS with the Session Description Protocol (SDP)", + RFC 8844, DOI 10.17487/RFC8844, January 2021, + <https://www.rfc-editor.org/info/rfc8844>. + + [RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution + Framework for Private Media in Privacy-Enhanced RTP + Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871, + January 2021, <https://www.rfc-editor.org/info/rfc8871>. + + [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The + Datagram Transport Layer Security (DTLS) Protocol Version + 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, + <https://www.rfc-editor.org/info/rfc9147>. + +10.2. Informative References + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + DOI 10.17487/RFC3264, June 2002, + <https://www.rfc-editor.org/info/rfc3264>. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, <https://www.rfc-editor.org/info/rfc3550>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: + Session Description Protocol", RFC 8866, + DOI 10.17487/RFC8866, January 2021, + <https://www.rfc-editor.org/info/rfc8866>. + +Acknowledgements + + The authors would like to thank David Benham and Cullen Jennings for + reviewing this document and providing constructive comments. + +Authors' Addresses + + 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 + Princeton University + Phone: +1 206 851 2069 + Email: pe5@cs.princeton.edu + + + Nils H. Ohlmeier + 8x8, Inc. + Phone: +1 408 659 6457 + Email: nils@ohlmeier.org |