Re: [dispatch] Updated PERC Charter proposal

[Mary Barnes <[e-mail]>]

Hi Roni,

My understanding of the charter is that the first milestone will encompass
deliverables 1. and 2, thus new RTP topologies that may be required would
be considered as part of that milestone.

Regards,
Mary.

On Sat, May 23, 2015 at 2:27 AM, Roni Even <[e-mail]> wrote:

> Hi,
>
> The charter looks good to me,
>
>
>
> One comment about the milestone, the first milestone is for architecture
> while the first bullet in the work to be done also mentions the RTP
> topologies, so I assume that the first milestone also includes new RTP
> topologies or will the RTP topologies to be used will only be topologies
> from draft-ietf-avtcore-rtp-topologies-update-07
> <https://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-07>
> ?
>
>
>
> Roni Even
>
>
>
> *From:* dispatch [mailto:[e-mail]] *On Behalf Of *Mary
> Barnes
> *Sent:* 22 May, 2015 6:52 PM
> *To:* DISPATCH
> *Cc:* Barry Leiba; Ben Campbell
> *Subject:* [dispatch] Updated PERC Charter proposal
>
>
>
> Hi all,
>
>
>
> Below, please find an updated charter for PERC.  Magnus has updated the
> charter to incorporate feedback from the DISPATCH WG mailing list
> discussions and we've made a round of editorial changes.  It should be
> ready for Ben to submit to the IESG for consideration as a new WG.  So,
> please review and provide any final comments no later than 18:00 GMT on
> Monday, May 25th (and yeah, I know it's a US holiday but folks in the US
> have the rest of today to review and there really should be no surprises;)
>
>
>
> Regards,
>
> Mary
>
> DISPATCH WG co-chair
>
>
>
>
>
> =========================================================================
>
>
>
>
>
>
>
> 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 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.  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 (
> draft-ietf-rtcweb-overview
> <https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/>)
> endpoints. 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 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 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 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).
>
>
>
> Goals and Milestones
>
>
>
> TBD  Submit architecture or framework specification to IESG (Standards
> Track)
>
>
>
> TBD Submit documentation of how to integrate solution in SIP, WebRTC and
> CLUE to IESG (Informational)
>
> TBD  Submit SRTP protocol extension specification to IESG (Standards Track)
>
>
>
> TBD  Submit Key-management protocol specification to IESG (Standards Track)
>
>
>
> 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/
>
>
>