From nobody Wed Jun 10 10:30:47 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FD91ACD1E; Mon, 8 Jun 2015 12:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Q7YlDbndHNzc; Mon, 8 Jun 2015 12:47:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE431A8F48; Mon, 8 Jun 2015 12:47:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608194758.14681.73891.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 12:47:58 -0700 Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2015 10:30:45 -0700 Cc: rlb@ipv.sx, suhasietf@gmail.com, perc@ietf.org Subject: [Perc] New Non-WG Mailing List: Perc -- Privacy Enhanced RTP Conferencing X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 19:47:59 -0000 A new IETF non-working group email list has been created. List address: perc@ietf.org Archive: http://www.ietf.org/mail-archive/web/perc/ To subscribe: https://www.ietf.org/mailman/listinfo/perc Purpose: Discussion list for Privacy Enhanced RTP Conferencing (PERC). The purpose is to develop a solution based on SRTP that enables end-to-end security in a centralized multi-party conference, utilizing one or more semi-trusted central media forwarding devices. The media forwarding devices are not trusted with the media content, but can make selection decisions on which media streams to forward. In addition to the media protection also key-management will be defined. The goal is to enable integration in WebRTC endpoints, CLUE endpoints as well as endpoints using SIP to establish communication. For additional information, please contact the list administrators. From nobody Thu Jun 11 09:27:11 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E05D1B2C90 for ; Thu, 11 Jun 2015 09:27:09 -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 q6KSdi8XbFKL for ; Thu, 11 Jun 2015 09:27:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5685E1B2BCF for ; Thu, 11 Jun 2015 09:27:08 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5BGQlj9043874 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 11 Jun 2015 11:26:58 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Magnus Westerlund" , "Richard Barnes" , "Suhas Nandakumar" Date: Thu, 11 Jun 2015 11:26:47 -0500 Message-ID: <57945B43-F3CD-450A-ABB5-A97DE52E4570@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: perc@ietf.org Subject: [Perc] PERC Charter X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 16:27:09 -0000 (oops, meant to include the mailing list) Hi, The PERC charter is approved to go to external review, pending a couple of last minute things. 1) Are you guys willing to put some dates to the milestones? I don't think it's _required_ for external review, but people will ask. If so, I will move the milestones from the text to the milestone list. 2) Do you want to add anything based on Stephen's last email (quoted below): > BTW - just to clarify in case it's useful - I interpret > the name of this WG and the charter to be implicitly > saying that the goal is to minimise the amount of data > (whether metadata or not) that is meaningful to the > media distribution device. If that's a bad assumption > then it'd probably be good to bottom out on that during > chartering. If it's a good assumption then maybe it's > something to consider being explicit about in the > charter. (Sorry, I forgot to say that in my initial > ballot.) From nobody Fri Jun 12 01:28:48 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C14C1A88C4 for ; Fri, 12 Jun 2015 01:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 1HTRakn4Qb1L for ; Fri, 12 Jun 2015 01:28:45 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25FC1A88C1 for ; Fri, 12 Jun 2015 01:28:44 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-4e-557a983add50 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D9.A5.28096.B389A755; Fri, 12 Jun 2015 10:28:43 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Fri, 12 Jun 2015 10:28:42 +0200 Message-ID: <557A9838.6030108@ericsson.com> Date: Fri, 12 Jun 2015 10:28:40 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ben Campbell , Richard Barnes , Suhas Nandakumar References: <57945B43-F3CD-450A-ABB5-A97DE52E4570@nostrum.com> In-Reply-To: <57945B43-F3CD-450A-ABB5-A97DE52E4570@nostrum.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvra71jKpQgx/tvBbzO0+zW6xeOJ3R YmqfrcXOuR3MDiweO2fdZfdYsuQnk8fkjbNYPGbtfMISwBLFZZOSmpNZllqkb5fAlbFr7h/m gsVSFQ8/WDUw/hbpYuTkkBAwkTj9fD0zhC0mceHeejYQW0jgKKPEnx6+LkYuIHs5o8TN5vdg CV4BbYkHTSdZQGwWAVWJpQf+soPYbAIWEjd/NILViApESUx9vI4Fol5Q4uTMJ2C2iECmxMFN C8DqmQWEJd6tWge2WFhAUmLalmOMEIvtJGa/WQg0h4ODU8BeYs90bRCTGch8sLUMolNeonnr bGaIam2JhqYO1gmMgrOQLJuF0DELSccCRuZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHB fHDLb6sdjAefOx5iFOBgVOLhVbCtChViTSwrrsw9xCjNwaIkzjtjc16okEB6YklqdmpqQWpR fFFpTmrxIUYmDk6pBsYV9usNbt4XTbaYsGBOtYrF8uDfnAd9C2/wn3H4U23b2DZdZ/HJJUtF mv8lTzHuZZoWZ/vj6RWewFPX40+d2jjVJ+PwzAtGjtc9NbueTMk+vriykfuz3g1LVq1tR5sl dQTehb+J4NL58ZtbzV/FcBer55IL8174zvrQcbGpsnf3Ky3HX2Vbt3crsRRnJBpqMRcVJwIA 1pj9XEcCAAA= Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] PERC Charter X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 08:28:47 -0000 Ben Campbell skrev den 2015-06-11 18:26: > (oops, meant to include the mailing list) > > Hi, > > The PERC charter is approved to go to external review, pending a couple > of last minute things. > > 1) Are you guys willing to put some dates to the milestones? I don't > think it's _required_ for external review, but people will ask. If so, I > will move the milestones from the text to the milestone list. Yes, I am willing to give it an initial shot. 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) I know people see this as quite urgent, but we actually appear to have quite a lot to discuss on how it should work and be solved. Then we must show due dillegence in getting the pieces well specified and well reviewed and tested. Thus, I think 2 years is not at all uncalled for, unfortunately. > > 2) Do you want to add anything based on Stephen's last email (quoted > below): > >> BTW - just to clarify in case it's useful - I interpret >> the name of this WG and the charter to be implicitly >> saying that the goal is to minimise the amount of data >> (whether metadata or not) that is meaningful to the >> media distribution device. If that's a bad assumption >> then it'd probably be good to bottom out on that during >> chartering. If it's a good assumption then maybe it's >> something to consider being explicit about in the >> charter. (Sorry, I forgot to say that in my initial >> ballot.) > Yes, I think it is a goal. I would propose that we enter into the WG objectives the following sentence: 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. The full paragraph would then read: 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. Opinions on that. Please respond quickly. Magnus Westerlund ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- From nobody Fri Jun 12 12:39:39 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04791AD34F for ; Fri, 12 Jun 2015 12:39:35 -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 xCvdC8HwH4JR for ; Fri, 12 Jun 2015 12:39:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 100D81A1B78 for ; Fri, 12 Jun 2015 12:39:30 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5CJdBLj021164 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 12 Jun 2015 14:39:21 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Magnus Westerlund" Date: Fri, 12 Jun 2015 14:39:11 -0500 Message-ID: <935C4BE4-1C8D-46E3-AB34-DC4F8655F8B0@nostrum.com> In-Reply-To: <557A9838.6030108@ericsson.com> References: <57945B43-F3CD-450A-ABB5-A97DE52E4570@nostrum.com> <557A9838.6030108@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Richard Barnes , Suhas Nandakumar , perc@ietf.org Subject: Re: [Perc] PERC Charter X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 19:39:35 -0000 Thanks Magnus, I've entered the milestones and the addition from Stephen, and will approve this for external review now. If others have more feedback, we can handle that as part of the external review. Thanks! Ben. On 12 Jun 2015, at 3:28, Magnus Westerlund wrote: > Ben Campbell skrev den 2015-06-11 18:26: >> (oops, meant to include the mailing list) >> >> Hi, >> >> The PERC charter is approved to go to external review, pending a >> couple >> of last minute things. >> >> 1) Are you guys willing to put some dates to the milestones? I don't >> think it's _required_ for external review, but people will ask. If >> so, I >> will move the milestones from the text to the milestone list. > > Yes, I am willing to give it an initial shot. > > > 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) > > I know people see this as quite urgent, but we actually appear to have > quite a lot to discuss on how it should work and be solved. Then we > must show due dillegence in getting the pieces well specified and well > reviewed and tested. Thus, I think 2 years is not at all uncalled for, > unfortunately. > > >> >> 2) Do you want to add anything based on Stephen's last email (quoted >> below): >> >>> BTW - just to clarify in case it's useful - I interpret >>> the name of this WG and the charter to be implicitly >>> saying that the goal is to minimise the amount of data >>> (whether metadata or not) that is meaningful to the >>> media distribution device. If that's a bad assumption >>> then it'd probably be good to bottom out on that during >>> chartering. If it's a good assumption then maybe it's >>> something to consider being explicit about in the >>> charter. (Sorry, I forgot to say that in my initial >>> ballot.) >> > > Yes, I think it is a goal. I would propose that we enter into the WG > objectives the following sentence: > > 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. > > > The full paragraph would then read: > > 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. > > > Opinions on that. > > Please respond quickly. > > Magnus Westerlund > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- From nobody Wed Jun 24 07:13:37 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8220F1AC3A2; Wed, 24 Jun 2015 07:13:34 -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 W7NQInqpNh9g; Wed, 24 Jun 2015 07:13:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 ECF931ABD3B; Wed, 24 Jun 2015 07:13:31 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5OEDDtM061385 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 24 Jun 2015 09:13:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Martin Stiemerling" Date: Wed, 24 Jun 2015 09:13:13 -0500 Message-ID: In-Reply-To: <20150624101358.17850.99950.idtracker@ietfa.amsl.com> References: <20150624101358.17850.99950.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: The IESG , perc@ietf.org Subject: Re: [Perc] Martin Stiemerling's No Objection on charter-ietf-perc-00-04: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 14:13:34 -0000 On 24 Jun 2015, at 5:13, Martin Stiemerling wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > a nit: > s/can???t/cannot/ Thanks, fixed in version 05. From nobody Thu Jun 25 10:10:29 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DC11B34D5; Wed, 24 Jun 2015 03:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] 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 WsdBVqDbGKPH; Wed, 24 Jun 2015 03:14:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E111B34D9; Wed, 24 Jun 2015 03:13:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150624101358.17850.99950.idtracker@ietfa.amsl.com> Date: Wed, 24 Jun 2015 03:13:58 -0700 Archived-At: X-Mailman-Approved-At: Thu, 25 Jun 2015 10:10:27 -0700 Cc: perc@ietf.org Subject: [Perc] Martin Stiemerling's No Objection on charter-ietf-perc-00-04: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 10:14:04 -0000 Martin Stiemerling has entered the following ballot position for charter-ietf-perc-00-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-perc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- a nit: s/can???t/cannot/ From nobody Thu Jun 25 10:10:30 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183CB1B322C; Thu, 25 Jun 2015 01:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 1arV266MY0-w; Thu, 25 Jun 2015 01:20:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1061A8759; Thu, 25 Jun 2015 01:20:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150625082023.23715.20491.idtracker@ietfa.amsl.com> Date: Thu, 25 Jun 2015 01:20:23 -0700 Archived-At: X-Mailman-Approved-At: Thu, 25 Jun 2015 10:10:27 -0700 Cc: perc@ietf.org Subject: [Perc] Benoit Claise's No Objection on charter-ietf-perc-00-05: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 08:20:25 -0000 Benoit Claise has entered the following ballot position for charter-ietf-perc-00-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-perc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nit: "the participants??? media" From nobody Fri Jun 26 10:52:29 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8181A1A9D; Fri, 26 Jun 2015 09:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hA9MGnJKMJgE; Fri, 26 Jun 2015 09:33:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4721A1B11; Fri, 26 Jun 2015 09:33:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150626163305.16432.48283.idtracker@ietfa.amsl.com> Date: Fri, 26 Jun 2015 09:33:05 -0700 Archived-At: X-Mailman-Approved-At: Fri, 26 Jun 2015 10:52:27 -0700 Cc: perc WG Subject: [Perc] WG Action: Formed Privacy Enhanced RTP Conferencing (perc) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 16:33:08 -0000 A new IETF working group has been formed in the Applications and Real-Time Area. For additional information please contact the Area Directors or the WG Chairs. Privacy Enhanced RTP Conferencing (perc) ------------------------------------------------ Current Status: Proposed WG Chairs: Richard Barnes Suhas Nandakumar Assigned Area Director: Ben Campbell Mailing list Address: perc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/perc Archive: https://mailarchive.ietf.org/arch/browse/perc/ 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 cannot 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) From nobody Fri Jun 26 11:27:53 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F601A9241 for ; Fri, 26 Jun 2015 11:27:51 -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 axrDDkNFuBWF for ; Fri, 26 Jun 2015 11:27:49 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4ACB91A9177 for ; Fri, 26 Jun 2015 11:27:49 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5QIRVEM054080 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 26 Jun 2015 13:27:42 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: perc@ietf.org, "Richard Barnes" , "Suhas Nandakumar" , "Magnus Westerlund" Date: Fri, 26 Jun 2015 13:27:31 -0500 Message-ID: <6904BBE4-FBF0-4DF0-B98D-B932BCC0C585@nostrum.com> References: <20150626163305.16432.48283.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: [Perc] Fwd: WG Action: Formed Privacy Enhanced RTP Conferencing (perc) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 18:27:51 -0000 PERC is now a working group! Ben. Forwarded message: > From: The IESG > To: IETF-Announce > Cc: perc WG > Subject: [Perc] WG Action: Formed Privacy Enhanced RTP Conferencing > (perc) > Date: Fri, 26 Jun 2015 09:33:05 -0700 > > A new IETF working group has been formed in the Applications and > Real-Time Area. For additional information please contact the Area > Directors or the WG Chairs. > > Privacy Enhanced RTP Conferencing (perc) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > Richard Barnes > Suhas Nandakumar > > Assigned Area Director: > Ben Campbell > > Mailing list > Address: perc@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/perc > Archive: https://mailarchive.ietf.org/arch/browse/perc/ > > 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 cannot 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) > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Fri Jun 26 12:38:57 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E311AC3D9 for ; Fri, 26 Jun 2015 12:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 tlYDUAS4UpkW for ; Fri, 26 Jun 2015 12:38:53 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 205431AC3BE for ; Fri, 26 Jun 2015 12:38:53 -0700 (PDT) Received: by igblr2 with SMTP id lr2so20118784igb.0 for ; Fri, 26 Jun 2015 12:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3C9qpKRBLSqnjv/PLkutUjk7KwW6TLN75HK6uDTAmcQ=; b=h1kJufBalyeq3rgwMt58Hi5Bv31mh7abZWtjfKA0GtmD/LEdZL8gmQRKGCQJwGNIzo 4HmCJ8Wmms7X27Wj4YknA3OWu/8GLeWkqjLftfqO0T2r+05XlUD34IiC/e3aq97ndXT9 gXcntvlbCzbfLMMF58wGkj3DOK+69KGBjirvfMzFxQloO/oFqszFTlAJspZNVpwds0fP LYskI4hTiwI+FVIyFnBaC9wMbIzmCt/cl0kL1RnW3YgGCs4L5xslyhmq8eL+1jCOZxPG UETZs3O1pwyovHeRR27OV+21YvDceoPXjyotjHqzMrhv9rccDAnlLKdgWZTdAjRrTDnI GbTQ== MIME-Version: 1.0 X-Received: by 10.50.49.46 with SMTP id r14mr5776072ign.45.1435347532500; Fri, 26 Jun 2015 12:38:52 -0700 (PDT) Received: by 10.107.17.35 with HTTP; Fri, 26 Jun 2015 12:38:52 -0700 (PDT) In-Reply-To: References: <20150626163305.16432.48283.idtracker@ietfa.amsl.com> <6904BBE4-FBF0-4DF0-B98D-B932BCC0C585@nostrum.com> Date: Fri, 26 Jun 2015 12:38:52 -0700 Message-ID: From: Suhas Nandakumar To: Richard Barnes Content-Type: multipart/alternative; boundary=047d7bdca420cdd765051970e383 Archived-At: Cc: Ben Campbell , "perc@ietf.org" , Magnus Westerlund Subject: Re: [Perc] WG Action: Formed Privacy Enhanced RTP Conferencing (perc) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 19:38:56 -0000 --047d7bdca420cdd765051970e383 Content-Type: text/plain; charset=UTF-8 +1 Ben On Friday, June 26, 2015, Richard Barnes wrote: > Thanks for getting this through the IESG, Ben! > > On Fri, Jun 26, 2015 at 11:27 AM, Ben Campbell > wrote: > > PERC is now a working group! > > > > Ben. > > > > Forwarded message: > > > >> From: The IESG > > >> To: IETF-Announce > > >> Cc: perc WG > > >> Subject: [Perc] WG Action: Formed Privacy Enhanced RTP Conferencing > (perc) > >> Date: Fri, 26 Jun 2015 09:33:05 -0700 > >> > >> > >> A new IETF working group has been formed in the Applications and > >> Real-Time Area. For additional information please contact the Area > >> Directors or the WG Chairs. > >> > >> Privacy Enhanced RTP Conferencing (perc) > >> ------------------------------------------------ > >> Current Status: Proposed WG > >> > >> Chairs: > >> Richard Barnes > >> Suhas Nandakumar > > >> > >> Assigned Area Director: > >> Ben Campbell > > >> > >> Mailing list > >> Address: perc@ietf.org > >> To Subscribe: https://www.ietf.org/mailman/listinfo/perc > >> Archive: https://mailarchive.ietf.org/arch/browse/perc/ > >> > >> 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 cannot 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) > >> > >> > >> _______________________________________________ > >> Perc mailing list > >> Perc@ietf.org > >> https://www.ietf.org/mailman/listinfo/perc > --047d7bdca420cdd765051970e383 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Ben

On Friday, June 26, 2015, Richard Barnes <rlb= @ipv.sx> wrote:
Thanks for getting thi= s through the IESG, Ben!

On Fri, Jun 26, 2015 at 11:27 AM, Ben Campbell <ben@nostr= um.com> wrote:
> PERC is now a working group!
>
> Ben.
>
> Forwarded message:
>
>> From: The IESG <iesg-secretary@ietf.org<= /a>>
>> To: IETF-Announce <ietf-announce@ietf.org= >
>> Cc: perc WG <perc@ietf.org>
>> Subject: [Perc] WG Action: Formed Privacy Enhanced RTP Conferencin= g (perc)
>> Date: Fri, 26 Jun 2015 09:33:05 -0700
>>
>>
>> A new IETF working group has been formed in the Applications and >> Real-Time Area. For additional information please contact the Area=
>> Directors or the WG Chairs.
>>
>> Privacy Enhanced RTP Conferencing=C2=A0 (perc)
>> ------------------------------------------------
>> Current Status: Proposed WG
>>
>> Chairs:
>> Richard Barnes <rlb@ipv.sx>
>> Suhas Nandakumar <suhasietf@gmail.com>= ;
>>
>> Assigned Area Director:
>> Ben Campbell <ben@nostrum.com>
>>
>> Mailing list
>> Address: perc@ietf.org
>> To Subscribe: https://www.ietf.org/mailman/listinfo/perc
>> Archive: https://mailarchive.ietf.org/arch/browse/perc/
>>
>> Charter:
>>
>> RTP-based real-time multi-party interactive media conferencing is = in
>> widespread use today. Many of the deployments use one or more cent= rally
>> located media distribution devices that perform selective forwardi= ng of
>> mixed-media streams received from the participating endpoints. The= media
>> transport protocol commonly used is RTP (RFC3550). There are vario= us
>> signaling systems used to establish these multi-party conferences.=
>>
>> These conferences require security to ensure that the RTP media an= d
>> related metadata of the conference is kept private and only availa= ble to
>> the set of invited participants and other devices trusted by those=
>> participants with their media.=C2=A0 At the same time, multi-party= media
>> conferences need source authentication and integrity checks to pro= tect
>> against modifications, insertions, and replay attacks.=C2=A0 Media=
>> distribution devices supporting these conferences may also perform= RTP
>> header changes, and they often consume and create RTCP messages fo= r
>> efficient media handling.
>>
>> To date, deployment models for these multi-party media distributio= n
>> devices do not enable the devices to perform their functions witho= ut
>> having keys to decrypt the participants' media, primarily usin= g Secure
>> RTP (RFC3711) to provide session security.
>>
>> This trust model has limitations and prevents or hampers deploymen= t of
>> secure RTP conferencing in a multitude of cases, including outsour= cing,
>> legal requirements on confidentiality, and utilization of virtuali= zed
>> servers. Thus, a new architectural model and related specification= s are
>> needed, with a focused effort from the RTP and Security communitie= s.
>>
>> WG Objectives
>>
>> This WG will work on a solution that enables centralized SRTP-base= d
>> conferencing, where the central device distributing the media is n= ot
>> required to be trusted with the keys to decrypt the participants&#= 39; media.
>> The media must be kept confidential and authenticated between an >> originating endpoint and the explicitly allowed receiving endpoint= s 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 desir= ed that
>> a solution still provides replay protection, so that the media
>> distribution devices cannot replay previous parts of the media. >>
>> The solution must also provide security for each hop between endpo= ints
>> and multi-party media distribution devices and between multi-party= media
>> distribution devices. The RTCP messages and RTP header extensions<= br> >> required for the media distribution device to perform the selectiv= e media
>> forwarding may require both source authentication and integrity as= well
>> as confidentiality. The solution may also consider providing end-t= o-end
>> security for a subset of the RTCP messages or RTP header extension= s.
>>
>> The solution should be implementable by both SIP (RFC3261) and Web= RTC
>> 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 acknowled= ged
>> 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.=C2=A0 =C2=A0 Define a general architecture and RTP topology(s) = that enables
>> end-to-end media security for multi-party RTP conferencing.
>> 2.=C2=A0 =C2=A0 Define the trust model and describe the resulting = security
>> properties.
>> 3.=C2=A0 =C2=A0 Document models considered for integrating the sol= ution with
>> WebRTC, SIP and CLUE establishment of conferencing sessions.
>> 4.=C2=A0 =C2=A0 Specify any necessary extensions to SRTP.
>> 5.=C2=A0 =C2=A0Define needed Key Management Functions that distrib= ute the keys. The
>> system needs to be able to bind the media to the identity of the s= ender
>> 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 s= uitable
>> charter or by requests for chartering it in this WG or another WG.=
>> Potential items that might require work in other WGs are DTLS exte= nsions
>> (TLS WG) and RTP header extensions (AVTEXT WG). This work requires= strong
>> collaboration with the security area. We will notify, and when nee= ded
>> 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 sy= stem
>> used to establish the RTP-based conferences. It will, however, nee= d to
>> consider in its architecture how the solution may integrate with t= hese
>> systems, and document such consideration for WebRTC, SIP, and CLUE= . The
>> specification of how a particular system integrates the security s= olution
>> will happen outside of this working group, in suitable venues.
>>
>> The WG will not consider non-real-time usage, multicast-based medi= a
>> distribution, or Security descriptions-based keying (RFC4568).
>>
>> Input to the WG
>>
>> Proposals already existing relating to this charter proposal:
>>
>> https://datatracker.ietf.org/doc/draf= t-jones-avtcore-private-media-reqts/
>>
>> https://datatracker.ietf.org/doc/= draft-jones-avtcore-private-media-framework/
>> https://datatracker.ietf.org/doc/draft-cheng-a= vtcore-srtp-cloud/
>>
>>
>>
>>
>> Milestones:
>> Sep 2016 - Submit architecture or framework specification to IESG<= br> >> (Standards Track)
>> Jan 2017 - Submit documentation of how to integrate solution in SI= P,
>> 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)
>>
>>
>> _______________________________________________
>> Perc mailing list
>> Perc@ietf.org
>> https://www.ietf.org/mailman/listinfo/perc
--047d7bdca420cdd765051970e383-- From nobody Fri Jun 26 13:37:01 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073301A92EC for ; Fri, 26 Jun 2015 11:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 lJnkcHECYAL5 for ; Fri, 26 Jun 2015 11:42:14 -0700 (PDT) Received: from mail-vn0-f46.google.com (mail-vn0-f46.google.com [209.85.216.46]) (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 B008A1A90E2 for ; Fri, 26 Jun 2015 11:42:13 -0700 (PDT) Received: by vnbg1 with SMTP id g1so16816179vnb.3 for ; Fri, 26 Jun 2015 11:42:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sPpxApich36DhqA5PptSrQ1qPpoPMvNfqASvTKyDmlc=; b=kqzx+XsgXgnoPBgbTvbGrlxnSaaVztyHoe+LNc5HPA3jrZRRTQOKWVX62bTbgn5peD UrNiXYHRcFeTlGUyZJgcSbTixqwlYTzJQl4IggktTqOxpNyGY2V8kWKZOui49Lz2ePrL Sn35pEC3sxnbt7fUwwU7xTjMBmw356dlR6m+Lahin7w4np+iUkK3x0rRUnGvMyfjg05G 749BtINtvmV+ueI7AzWtdHbNmNPKH+GEYKRM6vjpFZT/wsiv25TZAf7LRNf6MKf3Mjlr hm9d3brpRBmmf49+I5HmKrKvWvpkBIb6cmzvcXdXpwRFiPceUYzimTErhEknLyWWm9tW H7fA== X-Gm-Message-State: ALoCoQlSh0z/Nn1G7kFpdzCvpnrFDHk0VbCvsEdIYmvqfwFOKtNTQDpfSZenRMuRVvoN+qgWauPQ MIME-Version: 1.0 X-Received: by 10.52.139.105 with SMTP id qx9mr2560446vdb.81.1435344132902; Fri, 26 Jun 2015 11:42:12 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Fri, 26 Jun 2015 11:42:12 -0700 (PDT) In-Reply-To: <6904BBE4-FBF0-4DF0-B98D-B932BCC0C585@nostrum.com> References: <20150626163305.16432.48283.idtracker@ietfa.amsl.com> <6904BBE4-FBF0-4DF0-B98D-B932BCC0C585@nostrum.com> Date: Fri, 26 Jun 2015 11:42:12 -0700 Message-ID: From: Richard Barnes To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Fri, 26 Jun 2015 13:36:59 -0700 Cc: Magnus Westerlund , Suhas Nandakumar , perc@ietf.org Subject: Re: [Perc] WG Action: Formed Privacy Enhanced RTP Conferencing (perc) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 18:42:16 -0000 Thanks for getting this through the IESG, Ben! On Fri, Jun 26, 2015 at 11:27 AM, Ben Campbell wrote: > PERC is now a working group! > > Ben. > > Forwarded message: > >> From: The IESG >> To: IETF-Announce >> Cc: perc WG >> Subject: [Perc] WG Action: Formed Privacy Enhanced RTP Conferencing (perc) >> Date: Fri, 26 Jun 2015 09:33:05 -0700 >> >> >> A new IETF working group has been formed in the Applications and >> Real-Time Area. For additional information please contact the Area >> Directors or the WG Chairs. >> >> Privacy Enhanced RTP Conferencing (perc) >> ------------------------------------------------ >> Current Status: Proposed WG >> >> Chairs: >> Richard Barnes >> Suhas Nandakumar >> >> Assigned Area Director: >> Ben Campbell >> >> Mailing list >> Address: perc@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/perc >> Archive: https://mailarchive.ietf.org/arch/browse/perc/ >> >> 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 cannot 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) >> >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc