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 athttps://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

An objective of Privacy-Enhanced RTP Conferencing (PERC)[RFC8871] is toensure that endpoints in a multimedia conference have access to theend-to-end (E2E) and hop-by-hop (HBH) keying material used to encryptand authenticate Real-time Transport Protocol (RTP) packets[RFC3550], while the Media Distributor has access only to the HBHkeying material for encryption and authentication.¶

This specification defines a tunneling protocol that enables the MediaDistributor to tunnel DTLS messages[RFC9147] between an endpointand 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 withthe Key Distributor.¶

The tunnel established between the Media Distributor and KeyDistributor is a TLS connection[RFC8446] that is established before anymessages are forwarded by the Media Distributor on behalf ofendpoints. DTLS packets received from an endpoint are encapsulated bythe Media Distributor inside this tunnel as data to be sent to the KeyDistributor. Likewise, when the Media Distributor receives data fromthe Key Distributor over the tunnel, it extracts the DTLS messageinside and forwards the DTLS message to the endpoint. In this way,the DTLS association for the DTLS-SRTP procedures is establishedbetween an endpoint and the Key Distributor, with the MediaDistributor forwarding DTLS messages between the two entities via theestablished tunnel to the Key Distributor and having no visibility intothe confidential information exchanged.¶

Following the existing DTLS-SRTP procedures, the endpoint and KeyDistributor will arrive at a selected cipher and keying material,which are used for HBH encryption and authentication by both theendpoint and the Media Distributor. However, since the MediaDistributor would not have direct access to this information, the KeyDistributor explicitly shares the HBH key information with the MediaDistributor via the tunneling protocol defined in this document.Additionally, the endpoint and Key Distributor will agree on a cipherfor E2E encryption and authentication. The Key Distributor willtransmit keying material to the endpoint for E2E operations but willnot share that information with the Media Distributor.¶

By establishing this TLS tunnel between the Media Distributor and KeyDistributor and implementing the protocol defined in this document, itis possible for the Media Distributor to facilitate the establishmentof a secure DTLS association between an endpoint and the KeyDistributor in order for the endpoint to generate E2E and HBH keyingmaterial. At the same time, the Key Distributor can securely providethe 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 inFigure 1:¶

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

The three entities involved in this communication flow are theendpoint, the Media Distributor, and the Key Distributor. Thebehavior of each entity is described inSection 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 theprocedures described later in this document. It is necessary that theKey Distributor and Media Distributor establish a mutuallyauthenticated TLS connection for the purpose of sending tunneledmessages, though the complete TLS handshake for the tunnel is notshown inFigure 2 because there is nothing new this documentintroduces with regard to those procedures.¶

Once the tunnel is established, it is possible for the MediaDistributor to relay the DTLS messages between the endpoint and theKey Distributor.Figure 2 shows a message flow wherein theendpoint uses DTLS-SRTP to establish an association with the KeyDistributor. In the process, the Media Distributor shares itssupported SRTP protection profile information (see[RFC5764]), andthe Key Distributor shares the HBH keying material and selected cipherwith 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 |

After the initial TLS connection has been established, each of themessages on the right-hand side ofFigure 2 is a tunnelingprotocol message, as defined inSection 6.¶

SRTP protection profiles supported by the Media Distributor will besent in aSupportedProfiles message when the TLS tunnel is initiallyestablished. The Key Distributor will use that information to selecta common profile supported by both the endpoint and the MediaDistributor to ensure that HBH operations can be successfullyperformed.¶

As DTLS messages are received from the endpoint by the MediaDistributor, they are forwarded to the Key Distributor encapsulatedinside aTunneledDtls message. Likewise, asTunneledDtlsmessages are received by the Media Distributor from the KeyDistributor, the encapsulated DTLS packet is forwarded to theendpoint.¶

The Key Distributor will provide the SRTP keying material[RFC3711] to the Media Distributor for HBH operations via theMediaKeysmessage. The Media Distributor will extract this keying material fromtheMediaKeys message when received and use it for HBHencryption and authentication.¶

5.Tunneling Procedures

The following subsections explain in detail the expected behavior ofthe endpoint, the Media Distributor, and the Key Distributor.¶

It is important to note that the tunneling protocol described in thisdocument is not an extension to TLS or DTLS. Rather, it is a protocol thattransports DTLS messages generated by an endpoint or Key Distributor as datainside of the TLS connection established between the Media Distributor andKey Distributor.¶

6.Tunneling Protocol

Tunneled messages are transported via the TLS tunnel as applicationdata between the Media Distributor and the Key Distributor. Tunnelmessages 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 0304 is equivalent to the decimal value 16909060.¶

This protocol defines several different messages, each of whichcontains the following information:¶

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

Each of the tunnel messages is aTunnelMessage structure with themessage type indicating the actual content of the message body.¶

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;

uint8 SRTPProtectionProfile[2]; /* from RFC 5764 */struct {    uint8 version;    SRTPProtectionProfile protection_profiles<2..2^16-1>;} SupportedProfiles;

struct {    uint8 highest_version;} UnsupportedVersion;

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;

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

struct {    uuid association_id;} EndpointDisconnect;

7.Example Binary Encoding

TheTunnelMessage 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 theSupportedProfiles message that advertises support for bothDOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM andDOUBLE_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 inTable 1 below, leaving the balance of possible values reserved for future specifications:¶

The value 0x00 is reserved, and all values in the range 0x06 to 0xFF areavailable for allocation. The procedures for updating this table are thosedefined as "IETF Review" inSection 4.8 of [RFC8126].¶

9.Security Considerations

Since the procedures in this document rely on TLS[RFC8446] for transportsecurity, the security considerations for TLS should be reviewed whenimplementing the protocol defined in this document.¶

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

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

A requirement in this document is that a TLS connection between the MediaDistributor and the Key Distributor be mutually authenticated. The reasonfor this requirement is to ensure that only an authorized Media Distributorreceives the HBH keying material. If an unauthorized Media Distributor gainsaccess to the HBH keying material, it can easily cause service degradation ordenial by transmitting HBH-valid packets that ultimately fail E2Eauthentication or replay protection checks (seeSection 3.3.2 of [RFC3711]).Even if service does not appear degraded in any way, transmitting andprocessing bogus packets are a waste of both computational and networkresources.¶

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

While E2E keying material passes through the Media Distributor via the protocoldefined in this document, the Media Distributor has no means of gaining accessto that information and therefore cannot affect the E2E media processingfunction in the endpoint except to present it with invalid or replayed data.That said, any entity along the path that interferes with the DTLS exchangebetween the endpoint and the Key Distributor, including a malicious MediaDistributor that is not properly authorized, could prevent an endpoint fromproperly communicating with the Key Distributor and therefore preventsuccessful conference participation.¶

It is worth noting that a compromised Media Distributor can conveyinformation to an adversary, such as participant IP addresses,negotiated protection profiles, or other metadata. While[RFC8871] explains thata malicious or compromised Media Distributor can disrupt communications,an additional attack vector introduced by this protocol is the potentialdisruption of DTLS negotiation or premature removal of a participant froma conference by sending anEndpointDisconnect message to theKey Distributor.¶

The Key Distributor should be aware of the possibility that a maliciousMedia Distributor might transmit anEndpointDisconnect message to the KeyDistributor when the endpoint is in fact still connected.¶

While the Security Considerations section of[RFC8871] describes variousattacks one needs to consider with respect to the Key Distributor anddenial of service, use of this protocol introduces another possibleattack vector. Consider the case where a malicious endpoint sends unsolicitedDTLS-SRTP messages to a Media Distributor. The Media Distributor will normallyforward those messages to the Key Distributor and, if found invalid, suchmessages only serve to consume resources on both the Media Distributor andKey Distributor.¶

Acknowledgements

The authors would like to thankDavid Benham andCullen Jennings for reviewing this document and providing constructive comments.¶

Authors' Addresses