[dispatch] WG Review: Privacy Enhanced RTP Conferencing (perc)

[The IESG <[e-mail]>]

A new IETF working group has been proposed in the Applications and
Real-Time Area. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list (iesg
at ietf.org) by 2015-06-22.

Privacy Enhanced RTP Conferencing  (perc)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Richard Barnes <[e-mail]>
  Suhas Nandakumar <[e-mail]>

Assigned Area Director:
  Ben Campbell <[e-mail]>

Mailing list
  Address: [e-mail]
  To Subscribe: 
  Archive: 

Charter:

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 can’t 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.
 
Collaboration
 
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. 
 
Non-Goals
 
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:

https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/
https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framework/
https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/




Milestones:
  Sep 2016 - Submit architecture or framework specification to IESG
(Standards Track)
  Jan 2017 - Submit documentation of how to integrate solution in SIP,
WebRTC and CLUE to IESG (Informational)
  Jun 2017 - Submit SRTP protocol extension specification to IESG
(Standards Track)
  Jun 2017 - Submit Key-management protocol specification to IESG
(Standards Track)