Skip to main content

Privacy Enhanced RTP Conferencing

Document Charter Privacy Enhanced RTP Conferencing WG (perc) Snapshot
Title Privacy Enhanced RTP Conferencing
Last updated 2020-03-25
State Approved
WG State Active
IESG Responsible AD Murray Kucherawy
Charter edit AD Murray Kucherawy
Send notices to (None)

RTP-based real-time multi-party interactive media conferencing is in widespread
use today. Many of the deployments use one or more centrally located media
distribution devices that perform selective forwarding of mixed-media streams
received from the participating endpoints. The media transport protocol
commonly used is RTP (RFC3550). There are various signaling systems used to
establish these multi-party conferences.

These conferences require security to ensure that the RTP media and related
metadata of the conference is kept private and only available to the set of
invited participants and other devices trusted by those participants with their
media.  At the same time, multi-party media conferences need source
authentication and integrity checks to protect against modifications,
insertions, and replay attacks.  Media distribution devices supporting these
conferences may also perform RTP header changes, and they often consume and
create RTCP messages for efficient media handling.

To date, deployment models for these multi-party media distribution devices do
not enable the devices to perform their functions without having keys to
decrypt the participants' media, primarily using Secure RTP (RFC3711) to
provide session security.

This trust model has limitations and prevents or hampers deployment of secure
RTP conferencing in a multitude of cases, including outsourcing, legal
requirements on confidentiality, and utilization of virtualized servers. Thus,
a new architectural model and related specifications are needed, with a focused
effort from the RTP and Security communities.

WG Objectives

This WG will work on a solution that enables centralized SRTP-based
conferencing, where the central device distributing the media is not required
to be trusted with the keys to decrypt the participants' media. The media
must be kept confidential and authenticated between an originating endpoint and
the explicitly allowed receiving endpoints or other devices. The meta
information provided to the central device is to be limited to the minimal
required for it to perform its function to preserve the conference participants
privacy. Further, it is desired that a solution still provides replay
protection, so that the media distribution devices cannot replay previous parts
of the media.

The solution must also provide security for each hop between endpoints and
multi-party media distribution devices and between multi-party media
distribution devices. The RTCP messages and RTP header extensions required for
the media distribution device to perform the selective media forwarding may
require both source authentication and integrity as well as confidentiality.
The solution may also consider providing end-to-end security for a subset of
the RTCP messages or RTP header extensions.

The solution should be implementable by both SIP (RFC3261) and WebRTC endpoints
(draft-ietf-rtcweb-overview). How telepresence endpoints using the protocols
defined in the CLUE working group could utilize the defined security solution
needs to be considered. However, it is acknowledged that limitations may exist,
resulting in restricted functionality or need for additional adaptations of the
CLUE protocols.

This working group will perform the following work:

1.    Define a general architecture and RTP topology(s) that enables end-to-end
media security for multi-party RTP conferencing. 2.    Define the trust model
and describe the resulting security properties. 3.    Document models
considered for integrating the solution with WebRTC, SIP and CLUE establishment
of conferencing sessions. 4.    Specify any necessary extensions to SRTP. 5.  
Define needed Key Management Functions that distribute the keys. The system
needs to be able to bind the media to the identity of the sender of the media
and/or the identity of the conference.


If there is identification of missing protocols or functionalities, such work
can be requested to be done in another working group with a suitable charter or
by requests for chartering it in this WG or another WG. Potential items that
might require work in other WGs are DTLS extensions (TLS WG) and RTP header
extensions (AVTEXT WG). This work requires strong collaboration with the
security area. We will notify, and when needed coordinate with, AVTCore, CLUE,
MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and other related groups about this work.


The PERC working group is not chartered to extend any signaling system used to
establish the RTP-based conferences. It will, however, need to consider in its
architecture how the solution may integrate with these systems, and document
such consideration for WebRTC, SIP, and CLUE. The specification of how a
particular system integrates the security solution will happen outside of this
working group, in suitable venues.

The WG will not consider non-real-time usage, multicast-based media
distribution, or Security descriptions-based keying (RFC4568).

Input to the WG

Proposals already existing relating to this charter proposal: