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

Robert Sparks <rjsparks@nostrum.com> Fri, 10 April 2015 14:37 UTC

Return-Path: <rjsparks@nostrum.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 D4DA61A0263 for <dispatch@ietfa.amsl.com>; Fri, 10 Apr 2015 07:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 vhn4ObHZBd6W for <dispatch@ietfa.amsl.com>; Fri, 10 Apr 2015 07:37:25 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950631A024E for <dispatch@ietf.org>; Fri, 10 Apr 2015 07:37:25 -0700 (PDT)
Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3AEbOC2022045 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <dispatch@ietf.org>; Fri, 10 Apr 2015 09:37:24 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local
Message-ID: <5527E01F.9040507@nostrum.com>
Date: Fri, 10 Apr 2015 09:37:19 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: dispatch@ietf.org
References: <55134454.9050302@ericsson.com> <DF642B61-47ED-4F33-BE7F-3F70FF80B294@nostrum.com>
In-Reply-To: <DF642B61-47ED-4F33-BE7F-3F70FF80B294@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/fFsD8-85TRLqp6zfkEm8VE-iQ9w>
Subject: Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC)
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, 10 Apr 2015 14:37:29 -0000

So, I think this should get chartered.
I have a couple of charter-bashing questions/comments.

It would be good to be clear what any interactions with the work in CLUE 
might be.

What is the motivation for declaring any extensions to signalling 
systems out of scope? (Not saying I see any that need to be created, but 
I'm surprised that it's not something that the group might need to 
investigate rather than making that call at chartering time)?

RjS

On 4/9/15 4:29 PM, Ben Campbell wrote:
> 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 dispatch@ietf.org 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  +46 10 7148287
>> Färögatan 6                 | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch