Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC)

["Ben Campbell" <[e-mail]>]

For the record, I'd love to see this get chartered. I think the charter 
is on the right track. It might be worth mentioning the drafts in the 
charter as "inputs" to the work.

Is anyone else interested in working on this?

/Ben

On 25 Mar 2015, at 18:27, Magnus Westerlund wrote:

> Dispatch,
>
> AVTCORE WG has discussed a couple of proposals that discusses 
> end-to-end
> security in centralized RTP based conferences.
>
> Drafts for these Proposals:
> 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/
>
> In these discussions one has reached the conclusion that this work
> requires its own venue to continue the work. Therefore a number of
> interested has put together a initial draft charter for a new WG.
>
> Please review and provide feedback.
>
>
> Name: Privacy Enhanced RTP Conferencing (PERC)
> Area: ART
> Chairs: TBD
> Mailing List: <using [e-mail] for now>
>
> Motivation for new WG
> ---------------------
>
> RTP-based real-time multi-party interactive media conferencing is 
> today
> in widespread use. Many of the deployments uses one or more centrally
> located media distribution devices that perform selective forwarding 
> or
> mixes 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 meta data of the conference is kept private to the set of
> invited participants and only other devices trusted by those
> participants with their media.  At the same time, multi-party media
> conferences do need source authentication and integrity checks to
> protect against modifications, insertions or replay attacks.  Media
> distribution devices supporting these conferences may also perform RTP
> header changes and often consume and create RTCP messages for 
> efficient
> media handling.
>
> To date, deployment models for these multi-party media distribution
> devices do not enable them to perform their functions without having
> keys to decrypt the participants’ media, primarily using Secure RTP
> (RFC3711) to provide session security.
>
> A new architecture model and related specifications is 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 participant’s 
> media.
> The media must be kept confidential and authenticated between an
> originating endpoint and the explicitly allowed receiving endpoints or
> other devices.  Further it is desired that a solution still provide
> 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 header 
> extensions.
>
> The solution should be usable from both SIP and WebRTC endpoints that
> implement the extension defined by this WG.
>
> This WG 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.    Specify any necessary extensions to SRTP.
>
> 4.    Define a Key Management Function that distributes the keys. The
>    system needs to be able to bind the media to the sender of the
>    media’s identity 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 work that might require work in other WGs are DTLS
> extensions (TLS) as well as RTP header extensions (AVTEXT). This
> requires strong collaboration with the security area. We will notify
> SIPREC, W3C WebRTC, AVTCore, and other related groups about this work.
>
> Non-Goals
> ---------
>
> The WG 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.
>
> Will not consider non-real-time usages, multicast based media
> distribution, or Security descriptions-based keying.
>
> Goals and Milestones
> --------------------
>
> TBD  Submit architecture or framework specification to IESG (Standards
> Track)
>
> TBD  Submit protocol specification(s) to IESG (Standards Track)
>
>
>
>
> Cheers
>
> Magnus Westerlund
> (AVTCORE WG chair)
>
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch