[dispatch] Updated PERC Charter proposal

Mary Barnes <mary.ietf.barnes@gmail.com> Fri, 22 May 2015 15:52 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25F81A1B6A for <dispatch@ietfa.amsl.com>; Fri, 22 May 2015 08:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIKRNgbboJk5 for <dispatch@ietfa.amsl.com>; Fri, 22 May 2015 08:52:04 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4126A1A1B51 for <dispatch@ietf.org>; Fri, 22 May 2015 08:52:04 -0700 (PDT)
Received: by lbbuc2 with SMTP id uc2so15863059lbb.2 for <dispatch@ietf.org>; Fri, 22 May 2015 08:52:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=H0orVpYTe/RomFRAxYCYJOnsin9WRO1Jo2MlJ3zvic4=; b=aZML0gOLaMRHXBSlfWhjDOM0MYVhPWHPBYd0/glsEepvTxbiRF5AnkzK6SdOUdh5/1 uGbW+iiweSQ/I5Y5h0sUvC5/q4yHtFV3XIGw/2O1T0kkiByXNSruOshyHjTl1K5mCBlO Y/hIrW4RKohDdIHK9nZp1gUNDluWuOK7SZD3jj3LDv2IUT/LbnBo92jcBWV2EIH6WFlL IeP0l2xBeSWBNAti+N+zJJOwLZG/qua16fMNL6eFBMAsLcDzsS6y68pzYdYA/gEorRc6 gqL5W5CnSdU60AqTDzzQ6Keu3qQ1eYYmb4doyAS+jcBiMw5Cv7UCEbHlPanAfdtdxbEb 6cbw==
MIME-Version: 1.0
X-Received: by 10.112.12.68 with SMTP id w4mr319540lbb.87.1432309922768; Fri, 22 May 2015 08:52:02 -0700 (PDT)
Received: by 10.25.128.207 with HTTP; Fri, 22 May 2015 08:52:02 -0700 (PDT)
Date: Fri, 22 May 2015 10:52:02 -0500
Message-ID: <CAHBDyN6BeyL-wh_=t7jN+tfhTTnZK0uTBra-F7MR11x9eFkGpg@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: DISPATCH <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c3b43427b0a40516ada40e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/82KmFyg5LFHRxvCDCe-AAkel_2M>
Cc: Barry Leiba <barryleiba@computer.org>, Ben Campbell <ben@nostrum.com>
Subject: [dispatch] Updated PERC Charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 May 2015 15:52:09 -0000

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 dispatch@ietf.org 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/