From nobody Mon Sep 7 04:18:54 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21F81AD0B3; Mon, 7 Sep 2015 04:18:51 -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 IHRVm2TwGWwI; Mon, 7 Sep 2015 04:18:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5340A1A0015; Mon, 7 Sep 2015 04:18:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150907111850.15847.52122.idtracker@ietfa.amsl.com> Date: Mon, 07 Sep 2015 04:18:50 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-datachannel-10.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 11:18:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : CLUE Protocol data channel Author : Christer Holmberg Filename : draft-ietf-clue-datachannel-10.txt Pages : 13 Date : 2015-09-07 Abstract: This document defines how to use the WebRTC data channel mechanism in order to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol messages between two CLUE entities. The document defines how to describe the SCTPoDTLS association used to realize the CLUE data channel using the Session Description Protocol (SDP), and defines usage of SDP-based "SCTP over DTLS" data channel negotiation mechanism for establishing a CLUE data channel. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures for negotiating usage of a CLUE data channel, are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-datachannel-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 7 09:36:59 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3251B544B for ; Mon, 7 Sep 2015 09:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 oNGwE6Hl_HSP for ; Mon, 7 Sep 2015 09:36:57 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137011B543F for ; Mon, 7 Sep 2015 09:36:57 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7A42D21A30 for ; Mon, 7 Sep 2015 12:36:56 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 07 Sep 2015 12:36:56 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=kSzJWit2Qe4bWHQqts5UnRPlHKA=; b=dXwmP9 FEG7pHsMRzCE0cgDoctNWM+QcHtMb4MK0WhWGk4ixWmvhyk8ENF9yQ9Cpi9y8Cff R5ShkmSq6Yp/B572RMwMTXOBzhf759pFToA552TyGS/8hDyORXpkSFqnAK5G2O9q FWo/+6rsarAI82J2a+i69KNkYIZxbsFX+8hXA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=kSzJWit2Qe4bWHQ qts5UnRPlHKA=; b=r0hUd3nBR6PEWzOz7cnMJmLQbas5c7XiNACVmukufxzYqaE Ue4YXESbgA8NMqOpmbC+WlgteGJgVMtIcOg5DSY/Kc++DWzL/Z0+tnyZN+6zxI/+ rAHElUVpzKrz/Bfa4VoZvFQYHi8z9ow4bMwfFcolv9cfOHAJcAOajAoIbB2Y= X-Sasl-enc: PYb3ztmNNjpgyYYx2R4emVGRpukfATqibDh01Xw4oDWE 1441643816 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.179]) by mail.messagingengine.com (Postfix) with ESMTPA id DD21C6800C3; Mon, 7 Sep 2015 12:36:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <55ACE688.1000207@alum.mit.edu> Date: Mon, 7 Sep 2015 09:36:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55ACE688.1000207@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.2104) Archived-At: Cc: CLUE Subject: Re: [clue] Unauthenticated participants X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 16:36:58 -0000 Dropping a mail to note that the resolution of this issue and the other = edits resulting from my AD review of -framework are still outstanding. = Would be good to get these resolved so we can get this document out to = the IETF for last call. Thanks, Alissa= From nobody Mon Sep 7 14:03:55 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9171B3387 for ; Mon, 7 Sep 2015 14:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 pMV6yJATHbrv for ; Mon, 7 Sep 2015 14:03:53 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01841B32AE for ; Mon, 7 Sep 2015 14:03:53 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-09v.sys.comcast.net with comcast id EM3i1r0032Udklx01M3tLY; Mon, 07 Sep 2015 21:03:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id EM3s1r0063Ge9ey01M3snz; Mon, 07 Sep 2015 21:03:53 +0000 To: Alissa Cooper References: <55ACE688.1000207@alum.mit.edu> From: Paul Kyzivat Message-ID: <55EDFBB7.1030305@alum.mit.edu> Date: Mon, 7 Sep 2015 17:03:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1441659833; bh=vPWKRAv5TPodfsKA9zff+BLFe0gSHn0jSy4WLj+tbSw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=snUEPhrHi/FZ6dNn96EKuosGFpeABHj3mrlWa8/6GMn1fnpPz12F4W6G7dHgULaeQ 6wpxfGC+ywOItMFHpeHUw47b9AeMnMKRmVQtZH+YcK8Z23v22Fhxd4o93tKhXwk2lX CoENdK8pQ1uWIqWI1rLEm2f1fW/FP4GEznZXO3HtQNdEV1kKNX00BKgnb9QEpNdFxK 7XD/3q76RpRFJRiKz/Mv4m/VamdYnwdW1VaNUxtCsEf/5qewjhV8xC0iEBzMH6IBUl ZRVHBRzUB8UQKSmTcw9OmHQvm5l3evkP9w+s4CMHR7NXiYQG1rCaSc2AqSQqS4Pdyb jx94l6KcQ2qxA== Archived-At: Cc: CLUE Subject: Re: [clue] Unauthenticated participants X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 21:03:54 -0000 Mark, There has been considerable discussion on the list. Do you need anything else before revising the document to resolve the issues? Thanks, Paul On 9/7/15 12:36 PM, Alissa Cooper wrote: > Dropping a mail to note that the resolution of this issue and the other edits resulting from my AD review of -framework are still outstanding. Would be good to get these resolved so we can get this document out to the IETF for last call. > > Thanks, > Alissa > From nobody Mon Sep 7 14:24:39 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D31D1B2C97 for ; Mon, 7 Sep 2015 14:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 PRvj_Bp7ylit for ; Mon, 7 Sep 2015 14:24:37 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 1F89F1B2BBB for ; Mon, 7 Sep 2015 14:24:37 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so57071402wic.1 for ; Mon, 07 Sep 2015 14:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=mzbjcwpbyRv6jQP4HENyUTjOhiFTgqiNCM2Q/6kTukI=; b=nQAve/OFRNmSHiRrTAcyp3CDmmWlSC95ClTiXXDZzglGnf1+FGqdfB8Oxkv2cbT9XG y5js7M4sTg/ggpEsGTC6GladE+v8B/0EeIasiKSDXlMuGlpE+duN6hkYO4KAYOPB2dsF fSVJffnYPrFodcf3xkJwk0JqSbIpDRnU8XslM1UWzAEpLNrqB6vuuYLyjB4IqsZYtUZJ p9y52R4yBMtoiTPzWY2rlNDHu1D2dg98LoSd6yk3YOrLrwC7TE1rW8KhWxcXbL90IfRB 9qHVayVels0maodtmXq1K2cC96KKSEBwJ91QOy1ifuzEY0oxLG51/+i5fI/Y3bUhN1gP GW3g== X-Received: by 10.180.84.131 with SMTP id z3mr39389462wiy.9.1441661075581; Mon, 07 Sep 2015 14:24:35 -0700 (PDT) Received: from RoniPC (bzq-79-180-110-132.red.bezeqint.net. [79.180.110.132]) by smtp.gmail.com with ESMTPSA id im10sm1310703wjb.40.2015.09.07.14.24.33 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Sep 2015 14:24:34 -0700 (PDT) From: "Roni Even" To: Date: Tue, 8 Sep 2015 00:24:29 +0300 Message-ID: <029701d0e9b3$95376e00$bfa64a00$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0298_01D0E9CC.BA860590" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDpsztimCa419eaRGK0YFQFq4MnwQ== Content-Language: he Archived-At: Subject: [clue] Security censidertions for CLUE datachannel X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 21:24:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0298_01D0E9CC.BA860590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Looking at the security section in the framework, it reference the clue datachannel document for security of the CLUE data channel. I read the security section in the datachannel document and think it should also reference the security dicussed in draft-ietf-tsvwg-sctp-dtls-encaps-09 thanks Roni Even As individual ------=_NextPart_000_0298_01D0E9CC.BA860590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, =

Looking at the security section in = the framework, it reference the clue datachannel document for security = of the CLUE data channel.  I read the security section in the = datachannel document and think it should also reference the security = dicussed in

draft-ietf-tsvwg-sctp-dtls-encaps-09

thanks

Roni = Even

As = individual

------=_NextPart_000_0298_01D0E9CC.BA860590-- From nobody Mon Sep 7 14:26:54 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F5C1B3200 for ; Mon, 7 Sep 2015 14:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 jaBHE9Oce3qm for ; Mon, 7 Sep 2015 14:26:52 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 C2F901B31C9 for ; Mon, 7 Sep 2015 14:26:51 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so99838816wic.0 for ; Mon, 07 Sep 2015 14:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=a7Ntdap/KaROhkwYlI1SkZqoCW3VWqi6BQlW0gx/AFE=; b=qYXwVs3tc9BjjmWEPxuBp8skhsS+lMuVC36Eie9hoEB64+H6+i075Kwicp+NF1Cq5M sXL/olXscPEXyhAhHZIA0tJK01PQHqZ0gE0GYCFP+mKTkLJOpD1WGcUlX/vPWzPfjYst MaLNhGAkTiYb9AoKCkFN6G/xr3ANx+BIAwZjxB6rAYiHZ+OADan8Z/0g93DdCnG4GH+I w9AeaCWQDoI6XPiO+3wKuWgg+DYHRN7S4x9HvEis4nRcX6/83rIQANisnvLj4tjatOsL SH0fetKPgFPYQkLuxAy7HQt/VBpBufb0nwu3iMTKH7oAX7ZcTZq8p1SQxGGlbWl8y3iz 15iQ== X-Received: by 10.194.105.73 with SMTP id gk9mr42465451wjb.122.1441661210386; Mon, 07 Sep 2015 14:26:50 -0700 (PDT) Received: from RoniPC (bzq-79-180-110-132.red.bezeqint.net. [79.180.110.132]) by smtp.gmail.com with ESMTPSA id mx19sm1375002wic.0.2015.09.07.14.26.48 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Sep 2015 14:26:49 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , "'Alissa Cooper'" References: <55ACE688.1000207@alum.mit.edu> <55EDFBB7.1030305@alum.mit.edu> In-Reply-To: <55EDFBB7.1030305@alum.mit.edu> Date: Tue, 8 Sep 2015 00:26:43 +0300 Message-ID: <029c01d0e9b3$e5848730$b08d9590$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJYv6c1dJwUSB+Tkzed/OtzvXYA3QHypO2JAr5JPp6c/GChMA== Content-Language: he Archived-At: Cc: 'CLUE' Subject: Re: [clue] Unauthenticated participants X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 21:26:53 -0000 Hi guys, I am working on the security section and will post some text tomorrow. I sent a question about the security section of the datachannel since it is referenced by the framework and there was a comment from the AD about the security of the datachannel Roni -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Tuesday, September 08, 2015 12:04 AM To: Alissa Cooper Cc: CLUE; Roni Even Subject: Re: [clue] Unauthenticated participants Mark, There has been considerable discussion on the list. Do you need anything else before revising the document to resolve the issues? Thanks, Paul On 9/7/15 12:36 PM, Alissa Cooper wrote: > Dropping a mail to note that the resolution of this issue and the other edits resulting from my AD review of -framework are still outstanding. Would be good to get these resolved so we can get this document out to the IETF for last call. > > Thanks, > Alissa > From nobody Tue Sep 8 05:56:13 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D151B43ED for ; Tue, 8 Sep 2015 05:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 Q4uBmOfxN2Ie for ; Tue, 8 Sep 2015 05:56:02 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 0A6981A906E for ; Tue, 8 Sep 2015 05:56:02 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so114378273wic.1 for ; Tue, 08 Sep 2015 05:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=0NitPy56waZ9UoGIfL32RsBmjZxc2GG0T3eRA+jp5eI=; b=vB+WQbwB/PN3GhXk3o7Yr67tP8u+QWcbUdzlTOSouTv0IwckpxvrtCwU2rNGgIkMry aNmNVQvgYAcq3KXPRicSNAcTcVQ7xywj2SOLILMnisMxFMS8AYoZPi7f7wYL8zbtqfyz h3pLi7WWeB2tnOosniUbuFvDYmS3sC2Q6qyQkjrLK+GkFcLb3ml7axBfjhgrWPgUwIv8 7MmuQQ8bmsdXi9rwnXVBO/w4ZZCMxJV6Na4UDVI0HSI4A2m0aezTfC32f35PaYC00U+6 +0iZNV/FtvMR4kmmDeGCYtJvp56Pv6DDHQEl4jhCvLq24chrM/2KES/VMXuAltTMYG/I wgLQ== X-Received: by 10.194.110.37 with SMTP id hx5mr46771619wjb.149.1441716960402; Tue, 08 Sep 2015 05:56:00 -0700 (PDT) Received: from RoniPC (bzq-79-180-110-132.red.bezeqint.net. [79.180.110.132]) by smtp.gmail.com with ESMTPSA id kb5sm4747429wjc.17.2015.09.08.05.55.58 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Sep 2015 05:55:59 -0700 (PDT) From: "Roni Even" To: Date: Tue, 8 Sep 2015 15:55:53 +0300 Message-ID: <02e701d0ea35$b2de1710$189a4530$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02E8_01D0EA4E.D8303110" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDqNGcsnCTgs8FaTSe01IuYp92MlA== Content-Language: he Archived-At: Subject: [clue] proposed text for the security section of the framework document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 12:56:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02E8_01D0EA4E.D8303110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is my proposed text for section 15 of the framework document. As for authenticating users note that the a teleconference call starts with SIP and the SIP mechanisms MUST be supported. As for the xcard information content and what is sent to each participant this is an application policy that can be based on an application level authentication of the participant for example by asking the use to provide his own credentials, (and not the endpoint) Roni 15. Security Considerations There are several potential attacks related to telepresence, and specifically the protocols used by CLUE, in the case of conferencing sessions, due to the natural involvement of multiple endpoints and the many, often user-invoked, capabilities provided by the systems. An MCU involved in a CLUE session can experience many of the same attacks as that of a conferencing system such as that enabled by the XCON framework [RFC5239]. Examples of attacks include the following: an endpoint attempting to listen to sessions in which it is not authorized to participate, an endpoint attempting to disconnect or mute other users, and theft of service by an endpoint in attempting to create telepresence sessions it is not allowed to create. Thus, it is RECOMMENDED that an MCU implementing the protocols necessary to support CLUE, follow the security recommendations specified in the conference control protocol documents. In the case of CLUE, SIP is the conferencing protocol, thus the security considerations in [RFC4579] MUST be followed. . Other security issues related to MCUs are discussed in the XCON framework [RFC5239]. The conference wide information including conference roster are similar to the xCard information in CLUE and CLUE based implementations MUST considers those issues and the proposed solutions in [RFC5239] security section. One primary security concern, surrounding the CLUE framework introduced in this document, involves securing the actual protocols and the associated authorization mechanisms. These concerns apply to endpoint to endpoint sessions, as well as sessions involving multiple endpoints and MCUs. Figure 2 in section 5 provides a basic flow of information exchange for CLUE and the protocols involved. As described in section 5, CLUE uses SIP/SDP to establish the session prior to exchanging any CLUE specific information. Thus the security mechanisms recommended for SIP [RFC3261], including user authentication and authorization, MUST be supported. In addition, the media is based on RTP and thus existing RTP security mechanisms SHOULD be used, and DTLS/SRTP MUST be supported. Media security is also discussed in [I-D.ietf-clue-signaling] and [I-D.ietf-clue-rtp-mapping]. Note that SIP call setup in done before any CLUE specific information is available so the authentication and authorization are based on the SIP mechanisms. The entity that will be authenticated may use the Endpoint identity or the endpoint user identity; this is an application issue and not a CLUE specific issue. A separate data channel is established to transport the CLUE protocol messages. The contents of the CLUE protocol messages are based on information introduced in this document. The CLUE data model [I-D.ietf-clue-data-model-schema] defines through an XML schema the syntax to be used. Some of the information which could possibly introduce privacy concerns is the xCard information as described in section 7.1.1.11 The decision about which xCard information to send in the CLUE channel is an application policy for pint to point and multipoint calls base on the authenticated identity that can be the endpoint identity or the user of the endpoint, for example the telepresence multipoint application can authenticate a user before starting a CLUE exchange with the telepresenec system and have a policy per user. In addition, the (text) description field in the Media Capture attribute (section 7.1.1.7) could possibly reveal sensitive information or specific identities. The same would be true for the descriptions in the Capture Scene (section 7.3.1) and Capture Scene View (7.3.2) attributes. One other important consideration for the information in the xCard as well as the description field in the Media Capture and Capture Scene View attributes is that while the endpoints involved in the session have been authenticated, there is no assurance that the information in the xCard or description fields is authentic. Thus, this information MUST NOT be used to make any authorization decisions. While other information in the CLUE protocol messages does not reveal specific identities, it can reveal characteristics and capabilities of the endpoints. That information could possibly uniquely identify specific endpoints. It might also be possible for an attacker to manipulate the information and disrupt the CLUE sessions. It would also be possible to mount a DoS attack on the CLUE endpoints if a malicious agent has access to the data channel. Thus, it MUST be possible for the endpoints to establish a channel which is secure against both message recovery and message modification. Further details on this are provided in the CLUE data channel solution document. There are also security issues associated with the authorization to perform actions at the CLUE endpoints to invoke specific capabilities (e.g., re-arranging screens, sharing content, etc.). However, the policies and security associated with these actions are outside the scope of this document and the overall CLUE solution. ------=_NextPart_000_02E8_01D0EA4E.D8303110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is my = proposed text for section 15 of the framework document.

As for authenticating users note that the  a = teleconference call starts with SIP and the SIP mechanisms MUST be = supported.

As for the xcard = information content and what is sent to each participant this is an = application policy that can be based on an application level = authentication of the participant for example by asking the use to = provide his own credentials, (and not the endpoint)

 

Roni

 

15. Security = Considerations

   There are several potential attacks = related to telepresence, and
   specifically the protocols = used by CLUE, in the case of conferencing sessions, due to the natural = involvement of multiple
   endpoints and the many, often = user-invoked, capabilities provided
   by the = systems.

   An MCU involved in a CLUE session can = experience many of the same
   attacks as that of a = conferencing system such as that enabled by
   the XCON = framework [RFC5239]. Examples of attacks include the
   = following: an endpoint attempting to listen to sessions in = which
   it is not authorized to participate, an endpoint = attempting to
   disconnect or mute other users, and theft = of service by an
   endpoint in attempting to create = telepresence sessions it is not
   allowed to create. Thus, = it is RECOMMENDED that an MCU
   implementing the protocols = necessary to support CLUE, follow the
   security = recommendations specified in the conference control
   = protocol documents.  In the case of CLUE, SIP is the = conferencing
   protocol, thus the security considerations = in [RFC4579] MUST be
   followed. . Other security issues related to MCUs are = discussed in the XCON framework [RFC5239]. =

The conference wide information including = conference roster are similar to the xCard information in CLUE =

and CLUE based implementations MUST considers = those issues and the proposed solutions in [RFC5239] security = section. 

  

 

One primary security concern, = surrounding the CLUE framework
   introduced in this = document, involves securing the actual
   protocols and the = associated authorization mechanisms.  These
   = concerns apply to endpoint to endpoint sessions, as well = as
   sessions involving multiple endpoints and MCUs. = Figure 2 in
   section 5 provides a basic flow of = information exchange for CLUE
   and the protocols = involved.

   As described in section 5, CLUE uses = SIP/SDP to establish the
   session prior to exchanging any = CLUE specific information. Thus
   the security mechanisms = recommended for SIP [RFC3261], including
   user = authentication and authorization, MUST be supported. = In
   addition, the media is based on RTP and thus existing = RTP security
   mechanisms SHOULD be used, and = DTLS/SRTP MUST be supported.
   Media security is = also discussed in [I-D.ietf-clue-signaling] and
   = [I-D.ietf-clue-rtp-mapping]. Note that SIP call setup in done before = any CLUE specific information is available

so the = authentication and authorization are based on the SIP mechanisms. The = entity that will be authenticated may use the Endpoint identity or the = endpoint user identity; this is an application issue and not a CLUE = specific issue.

   A separate data channel is established to = transport the CLUE
   protocol messages. The contents of = the CLUE protocol messages are
   based on information = introduced in this document.  The CLUE data
   model = [I-D.ietf-clue-data-model-schema] defines through an XML
   = schema the syntax to be used. Some of the information which = could
   possibly introduce privacy concerns is the xCard = information as
   described in section 7.1.1.11 The = decision about which xCard information to send in the CLUE channel =

is an application policy for pint to = point and multipoint calls base on the authenticated identity that can = be the endpoint identity or the user of the endpoint, =

for example the telepresence = multipoint application can authenticate a user before starting a CLUE = exchange with the telepresenec system and have a policy per user. =

 

 

In addition, the = (text)
   description field in the Media Capture attribute = (section 7.1.1.7)
   could possibly reveal sensitive = information or specific
   identities. The same would be = true for the descriptions in the
   Capture Scene (section = 7.3.1) and Capture Scene View (7.3.2)
   = attributes.   One other important consideration for = the
   information in the xCard as well as the description = field in the
   Media Capture and Capture Scene View = attributes is that while the
   endpoints involved in the = session have been authenticated, there
   is no assurance = that the information in the xCard or description
   fields = is authentic.  Thus, this information MUST NOT be used to
=   make any authorization decisions.

   While = other information in the CLUE protocol messages does not
   = reveal specific identities, it can reveal characteristics = and
   capabilities of the endpoints.  That = information could possibly
   uniquely identify specific = endpoints.  It might also be possible
   for an = attacker to manipulate the information and disrupt the = CLUE
   sessions.  It would also be possible to mount = a DoS attack on the
   CLUE endpoints if a malicious agent = has access to the data
   channel.  Thus, it MUST be = possible for the endpoints to establish
   a channel which = is secure against both message recovery and
   message = modification. Further details on this are provided in = the
   CLUE data channel solution = document.

   There are also security issues associated = with the authorization
   to perform actions at the CLUE = endpoints to invoke specific
   capabilities (e.g., = re-arranging screens, sharing content, etc.).
   However, = the policies and security associated with these actions
   = are outside the scope of this document and the overall = CLUE
   solution.=

 =

 =

 =

 =

 =

 =

 =

------=_NextPart_000_02E8_01D0EA4E.D8303110-- From nobody Tue Sep 8 08:59:57 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A25D1A9124 for ; Tue, 8 Sep 2015 08:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 7W8TOGb0AQUr for ; Tue, 8 Sep 2015 08:59:55 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.109]) (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 135B91A9218 for ; Tue, 8 Sep 2015 08:59:55 -0700 (PDT) Received: from [216.82.254.20] by server-13.bemta-7.messagelabs.com id BB/17-28439-9F50FE55; Tue, 08 Sep 2015 15:59:53 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-47.messagelabs.com!1441727932!27200999!3 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23847 invoked from network); 8 Sep 2015 15:59:23 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-9.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 8 Sep 2015 15:59:23 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Tue, 8 Sep 2015 08:58:55 -0700 From: "Duckworth, Mark" To: Paul Kyzivat Date: Tue, 8 Sep 2015 08:58:54 -0700 Thread-Topic: [clue] Unauthenticated participants Thread-Index: AdDpsLnbWA0Ko/MST928tsRoAopdzAAni0NQ Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC16C869B63@CRPMBOXPRD08.polycom.com> References: <55ACE688.1000207@alum.mit.edu> <55EDFBB7.1030305@alum.mit.edu> In-Reply-To: <55EDFBB7.1030305@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: CLUE Subject: Re: [clue] Unauthenticated participants X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 15:59:56 -0000 Hi Paul, There are some minor things I can update. I think some of Alissa's comment= s were addressed on the list without needing any framework document update.= I will read through the "Unauthenticated participants" discussion and inc= orporate any conclusions into the document as needed. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, September 07, 2015 5:04 PM > To: Alissa Cooper > Cc: CLUE > Subject: Re: [clue] Unauthenticated participants >=20 > Mark, >=20 > There has been considerable discussion on the list. Do you need anything > else before revising the document to resolve the issues? >=20 > Thanks, > Paul >=20 > On 9/7/15 12:36 PM, Alissa Cooper wrote: > > Dropping a mail to note that the resolution of this issue and the other= edits > resulting from my AD review of -framework are still outstanding. Would be > good to get these resolved so we can get this document out to the IETF fo= r > last call. > > > > Thanks, > > Alissa > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Sep 8 21:27:54 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FAD1B32C6 for ; Tue, 8 Sep 2015 21:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 cwmAB3nqBMUm for ; Tue, 8 Sep 2015 21:27:51 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4BA1A0092 for ; Tue, 8 Sep 2015 21:27:51 -0700 (PDT) Received: from ppp118-209-253-105.lns20.mel8.internode.on.net ([118.209.253.105]:61138 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZZWz5-0025AE-MD; Wed, 09 Sep 2015 14:27:47 +1000 To: Roni Even , clue@ietf.org References: <02e701d0ea35$b2de1710$189a4530$@gmail.com> From: Christian Groves Message-ID: <55EFB53E.10805@nteczone.com> Date: Wed, 9 Sep 2015 14:27:42 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <02e701d0ea35$b2de1710$189a4530$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] proposed text for the security section of the framework document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 04:27:52 -0000 Hello Roni, On 8/09/2015 10:55 PM, Roni Even wrote: > > Hi, > > This is my proposed text for section 15 of the framework document. > > As for authenticating users note that the a teleconference call > starts with SIP and the SIP mechanisms MUST be supported. > > As for the xcard information content and what is sent to each > participant this is an application policy that can be based on an > application level authentication of the participant for example by > asking the use to provide his own credentials, (and not the endpoint) > > Roni > > 15. Security Considerations > > There are several potential attacks related to telepresence, and > specifically the protocols used by CLUE, in the case of > conferencing sessions, due to the natural involvement of multiple > endpoints and the many, often user-invoked, capabilities provided > by the systems. > > An MCU involved in a CLUE session can experience many of the same > attacks as that of a conferencing system such as that enabled by > the XCON framework [RFC5239]. Examples of attacks include the > following: an endpoint attempting to listen to sessions in which > it is not authorized to participate, an endpoint attempting to > disconnect or mute other users, and theft of service by an > endpoint in attempting to create telepresence sessions it is not > allowed to create. Thus, it is RECOMMENDED that an MCU > implementing the protocols necessary to support CLUE, follow the > security recommendations specified in the conference control > protocol documents. In the case of CLUE, SIP is the conferencing > protocol, thus the security considerations in [RFC4579] MUST be > followed. . *Other security issues related to MCUs are discussed in > the XCON framework [RFC5239]. * > > *The conference wide information including conference roster are > similar to the xCard information in CLUE * > > *and CLUE based implementations MUST considers those issues and the > proposed solutions in [RFC5239] security section. * > > ** > > Would it be sufficient simply to leave the first sentence? The second sentence is confusing because RFC5239 doesn't use the term "conference wide" and xCard may be for a singe participant not conference wide. Actually do we need the text at all as the paragraph above refers to RFC5239 and recommendations specified in the conference control protocol documents? If we want to specifically capture xcard could we say something like "The use of xCard with potentially sensitive provides another reason to implement recommendations of section 11/[RFC 5239]."? The other changes listed are OK. There's a few typos but Mark will probably pick those up. Regards, Christian From nobody Mon Sep 14 14:28:32 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEAE1A9218 for ; Mon, 14 Sep 2015 14:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 F_pMEK1wgwEy for ; Mon, 14 Sep 2015 14:28:29 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.108]) (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 451AC1A8AF9 for ; Mon, 14 Sep 2015 14:28:29 -0700 (PDT) Received: from [216.82.254.20] by server-12.bemta-7.messagelabs.com id AF/C5-06956-CFB37F55; Mon, 14 Sep 2015 21:28:28 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-47.messagelabs.com!1442266097!28910639!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32351 invoked from network); 14 Sep 2015 21:28:17 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-9.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 14 Sep 2015 21:28:17 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Mon, 14 Sep 2015 14:28:17 -0700 From: "Duckworth, Mark" To: Christian Groves , Roni Even , "clue@ietf.org" Date: Mon, 14 Sep 2015 14:28:15 -0700 Thread-Topic: [clue] proposed text for the security section of the framework document Thread-Index: AdDqt+cYOnOgatBySgOIIQAiatoJbwEe8bcQ Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E3062@CRPMBOXPRD08.polycom.com> References: <02e701d0ea35$b2de1710$189a4530$@gmail.com> <55EFB53E.10805@nteczone.com> In-Reply-To: <55EFB53E.10805@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [clue] proposed text for the security section of the framework document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 21:28:31 -0000 I agree with Roni's proposal for improvements to the security section, and = Christian's suggestion to change a sentence from Roni's. So with Christian= 's proposed change, the end of that paragraph would be, I think: "In the case of CLUE, SIP is the conferencing protocol, thus the security = considerations in [RFC4579] MUST be followed. Other security issues related= to MCUs are discussed in the XCON framework [RFC5239].=20 The use of xCard with potentially sensitive information provides another re= ason to implement recommendations of section 11/[RFC 5239]." Do I have that right? Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Wednesday, September 09, 2015 12:28 AM > To: Roni Even; clue@ietf.org > Subject: Re: [clue] proposed text for the security section of the framewo= rk > document >=20 > Hello Roni, >=20 > On 8/09/2015 10:55 PM, Roni Even wrote: > > > > Hi, > > > > This is my proposed text for section 15 of the framework document. > > > > As for authenticating users note that the a teleconference call > > starts with SIP and the SIP mechanisms MUST be supported. > > > > As for the xcard information content and what is sent to each > > participant this is an application policy that can be based on an > > application level authentication of the participant for example by > > asking the use to provide his own credentials, (and not the endpoint) > > > > Roni > > > > 15. Security Considerations > > > > There are several potential attacks related to telepresence, and > > specifically the protocols used by CLUE, in the case of > > conferencing sessions, due to the natural involvement of multiple > > endpoints and the many, often user-invoked, capabilities provided > > by the systems. > > > > An MCU involved in a CLUE session can experience many of the same > > attacks as that of a conferencing system such as that enabled by > > the XCON framework [RFC5239]. Examples of attacks include the > > following: an endpoint attempting to listen to sessions in which > > it is not authorized to participate, an endpoint attempting to > > disconnect or mute other users, and theft of service by an > > endpoint in attempting to create telepresence sessions it is not > > allowed to create. Thus, it is RECOMMENDED that an MCU > > implementing the protocols necessary to support CLUE, follow the > > security recommendations specified in the conference control > > protocol documents. In the case of CLUE, SIP is the conferencing > > protocol, thus the security considerations in [RFC4579] MUST be > > followed. . *Other security issues related to MCUs are discussed in > > the XCON framework [RFC5239]. * > > > > *The conference wide information including conference roster are > > similar to the xCard information in CLUE * > > > > *and CLUE based implementations MUST considers those issues and the > > proposed solutions in [RFC5239] security section. * > > > > ** > > > > > Would it be sufficient simply to leave the first sentence? The second > sentence is confusing because RFC5239 doesn't use the term "conference > wide" and xCard may be for a singe participant not conference wide. > Actually do we need the text at all as the paragraph above refers to > RFC5239 and recommendations specified in the conference control protocol > documents? If we want to specifically capture xcard could we say > something like "The use of xCard with potentially sensitive provides > another reason to implement recommendations of section 11/[RFC 5239]."? >=20 > The other changes listed are OK. There's a few typos but Mark will > probably pick those up. >=20 > Regards, Christian >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Sep 14 16:37:08 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D036F1B4196 for ; Mon, 14 Sep 2015 16:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 D-T-76W9PH8W for ; Mon, 14 Sep 2015 16:37:04 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B11B1B41E5 for ; Mon, 14 Sep 2015 16:37:04 -0700 (PDT) Received: from ppp118-209-230-180.lns20.mel8.internode.on.net ([118.209.230.180]:49737 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZbdIz-0015uV-0y; Tue, 15 Sep 2015 09:37:01 +1000 To: "Duckworth, Mark" , Roni Even , "clue@ietf.org" References: <02e701d0ea35$b2de1710$189a4530$@gmail.com> <55EFB53E.10805@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E3062@CRPMBOXPRD08.polycom.com> From: Christian Groves Message-ID: <55F75A1A.70500@nteczone.com> Date: Tue, 15 Sep 2015 09:36:58 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E3062@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] proposed text for the security section of the framework document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 23:37:07 -0000 Hello Mark, That looks good to me. Regards, Christian On 15/09/2015 7:28 AM, Duckworth, Mark wrote: > I agree with Roni's proposal for improvements to the security section, and Christian's suggestion to change a sentence from Roni's. So with Christian's proposed change, the end of that paragraph would be, I think: > > "In the case of CLUE, SIP is the conferencing protocol, thus the security considerations in [RFC4579] MUST be followed. Other security issues related to MCUs are discussed in the XCON framework [RFC5239]. > The use of xCard with potentially sensitive information provides another reason to implement recommendations of section 11/[RFC 5239]." > > Do I have that right? > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Wednesday, September 09, 2015 12:28 AM >> To: Roni Even; clue@ietf.org >> Subject: Re: [clue] proposed text for the security section of the framework >> document >> >> Hello Roni, >> >> On 8/09/2015 10:55 PM, Roni Even wrote: >>> Hi, >>> >>> This is my proposed text for section 15 of the framework document. >>> >>> As for authenticating users note that the a teleconference call >>> starts with SIP and the SIP mechanisms MUST be supported. >>> >>> As for the xcard information content and what is sent to each >>> participant this is an application policy that can be based on an >>> application level authentication of the participant for example by >>> asking the use to provide his own credentials, (and not the endpoint) >>> >>> Roni >>> >>> 15. Security Considerations >>> >>> There are several potential attacks related to telepresence, and >>> specifically the protocols used by CLUE, in the case of >>> conferencing sessions, due to the natural involvement of multiple >>> endpoints and the many, often user-invoked, capabilities provided >>> by the systems. >>> >>> An MCU involved in a CLUE session can experience many of the same >>> attacks as that of a conferencing system such as that enabled by >>> the XCON framework [RFC5239]. Examples of attacks include the >>> following: an endpoint attempting to listen to sessions in which >>> it is not authorized to participate, an endpoint attempting to >>> disconnect or mute other users, and theft of service by an >>> endpoint in attempting to create telepresence sessions it is not >>> allowed to create. Thus, it is RECOMMENDED that an MCU >>> implementing the protocols necessary to support CLUE, follow the >>> security recommendations specified in the conference control >>> protocol documents. In the case of CLUE, SIP is the conferencing >>> protocol, thus the security considerations in [RFC4579] MUST be >>> followed. . *Other security issues related to MCUs are discussed in >>> the XCON framework [RFC5239]. * >>> >>> *The conference wide information including conference roster are >>> similar to the xCard information in CLUE * >>> >>> *and CLUE based implementations MUST considers those issues and the >>> proposed solutions in [RFC5239] security section. * >>> >>> ** >>> >>> >> Would it be sufficient simply to leave the first sentence? The second >> sentence is confusing because RFC5239 doesn't use the term "conference >> wide" and xCard may be for a singe participant not conference wide. >> Actually do we need the text at all as the paragraph above refers to >> RFC5239 and recommendations specified in the conference control protocol >> documents? If we want to specifically capture xcard could we say >> something like "The use of xCard with potentially sensitive provides >> another reason to implement recommendations of section 11/[RFC 5239]."? >> >> The other changes listed are OK. There's a few typos but Mark will >> probably pick those up. >> >> Regards, Christian >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From nobody Tue Sep 15 08:55:34 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C8C1A1B12 for ; Tue, 15 Sep 2015 08:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 ccYBpFvdHb5d for ; Tue, 15 Sep 2015 08:55:31 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.11]) (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 B3F521A1B0B for ; Tue, 15 Sep 2015 08:55:31 -0700 (PDT) Received: from [216.82.249.212] by server-11.bemta-12.messagelabs.com id 5A/A1-31485-37F38F55; Tue, 15 Sep 2015 15:55:31 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-7.tower-219.messagelabs.com!1442332425!42201751!9 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5150 invoked from network); 15 Sep 2015 15:54:28 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-7.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 15 Sep 2015 15:54:28 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Tue, 15 Sep 2015 08:54:16 -0700 From: "Duckworth, Mark" To: "'clue@ietf.org'" Date: Tue, 15 Sep 2015 08:54:13 -0700 Thread-Topic: coming updates to framework document Thread-Index: AdDvzjXFcW9BY8urRGeudPkBI196Zg== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E30CE@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E30CECRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Subject: [clue] coming updates to framework document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 15:55:33 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E30CECRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Here is what I have so far, for Framework updates: - updated security section from Roni, with Christian's amendment - fixed all the nits Alissa pointed out We answered Alissa's other questions on the list, without needing any chang= e to the document. Is the group satisfied with this, or are there still other updates needed? Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E30CECRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

Here is what I have so far, for Framework update= s:

-    &nbs= p;     updated security section= from Roni, with Christian’s amendment

-          fixed all the nits Alissa pointed out

 

We answered Aliss= a’s other questions on the list, without needing any change to the do= cument.

 

Is the group satisfied with this, or are there still other update= s needed?

 

Mark

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E30CECRPMBOXPRD08p_-- From nobody Tue Sep 15 22:03:08 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4458E1B348A for ; Tue, 15 Sep 2015 22:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.891 X-Spam-Level: X-Spam-Status: No, score=0.891 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 tW1gq8mq8nIA for ; Tue, 15 Sep 2015 22:03:05 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBA61B3494 for ; Tue, 15 Sep 2015 22:03:03 -0700 (PDT) Received: from ppp118-209-0-247.lns20.mel4.internode.on.net ([118.209.0.247]:53895 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Zc4s1-001PPF-FZ for clue@ietf.org; Wed, 16 Sep 2015 15:03:01 +1000 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E30CE@CRPMBOXPRD08.polycom.com> From: Christian Groves Message-ID: <55F8A999.8070902@nteczone.com> Date: Wed, 16 Sep 2015 09:28:25 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E30CE@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] coming updates to framework document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 05:03:07 -0000 Hello Mark, I'm satisfied, time to put this to bed. Regards, Christian On 16/09/2015 1:54 AM, Duckworth, Mark wrote: > > Hi All, > > Here is what I have so far, for Framework updates: > > -updated security section from Roni, with Christian’s amendment > > -fixed all the nits Alissa pointed out > > We answered Alissa’s other questions on the list, without needing any > change to the document. > > Is the group satisfied with this, or are there still other updates needed? > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Sep 15 22:45:24 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83EC1B3553 for ; Tue, 15 Sep 2015 22:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no 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 JvPdY6cekjBl for ; Tue, 15 Sep 2015 22:45:21 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 220FA1B3551 for ; Tue, 15 Sep 2015 22:45:21 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so54603747wic.1 for ; Tue, 15 Sep 2015 22:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=6yei87qIgiDKIMQsKvLGDwgHlCpYxR0bwqUFBARiqNE=; b=GirZ1pFcmm3wBHUUgLtzs5hcs1oP5qT1JX63p8uh3/1R88SXAZUjqBccYkcf4DaAjX nXDnTOE9Jopa1F9k89fDTzP1N3zq2LBZHS4oXUHpxmSvxVUGpq39ovPRyi+fPPswSc5h Hf1s7EIHhRO+2WSzZzAcQFqxIiUt1cGs+Fi8u41cIiEKHPSsWLLn02urlxnbMpKz0vIY t384/TKl7EF/vbYC+9MJatQzs4zAGnYmwVtAjYtVkp4tt5qCoo7qSPUHWFs5X6QaRK3D 9kEy1X3bt+9tZi+Vp0uAEXxlzApxyKFQ5B5dyyGb45l5wbMVPzwO7nIIhvig9yvorxWT Y7uA== X-Received: by 10.194.143.6 with SMTP id sa6mr45823468wjb.67.1442382319719; Tue, 15 Sep 2015 22:45:19 -0700 (PDT) Received: from RoniPC (bzq-79-176-23-173.red.bezeqint.net. [79.176.23.173]) by smtp.gmail.com with ESMTPSA id bh5sm24540281wjb.42.2015.09.15.22.45.18 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Sep 2015 22:45:18 -0700 (PDT) From: "Roni Even" To: "'Christian Groves'" , "'Duckworth, Mark'" , References: <02e701d0ea35$b2de1710$189a4530$@gmail.com> <55EFB53E.10805@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E3062@CRPMBOXPRD08.polycom.com> <55F75A1A.70500@nteczone.com> In-Reply-To: <55F75A1A.70500@nteczone.com> Date: Wed, 16 Sep 2015 08:45:15 +0300 Message-ID: <064901d0f042$ddadff60$9909fe20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGNok0MVHZTb4MHg1VXFANvP2LTRgKv+kqDApOCnIQBJaweDp6R988w Content-Language: he Archived-At: Subject: Re: [clue] proposed text for the security section of the framework document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 05:45:23 -0000 OK for me Roni -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com] Sent: Tuesday, September 15, 2015 2:37 AM To: Duckworth, Mark; Roni Even; clue@ietf.org Subject: Re: [clue] proposed text for the security section of the framework document Hello Mark, That looks good to me. Regards, Christian On 15/09/2015 7:28 AM, Duckworth, Mark wrote: > I agree with Roni's proposal for improvements to the security section, and Christian's suggestion to change a sentence from Roni's. So with Christian's proposed change, the end of that paragraph would be, I think: > > "In the case of CLUE, SIP is the conferencing protocol, thus the security considerations in [RFC4579] MUST be followed. Other security issues related to MCUs are discussed in the XCON framework [RFC5239]. > The use of xCard with potentially sensitive information provides another reason to implement recommendations of section 11/[RFC 5239]." > > Do I have that right? > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >> Groves >> Sent: Wednesday, September 09, 2015 12:28 AM >> To: Roni Even; clue@ietf.org >> Subject: Re: [clue] proposed text for the security section of the >> framework document >> >> Hello Roni, >> >> On 8/09/2015 10:55 PM, Roni Even wrote: >>> Hi, >>> >>> This is my proposed text for section 15 of the framework document. >>> >>> As for authenticating users note that the a teleconference call >>> starts with SIP and the SIP mechanisms MUST be supported. >>> >>> As for the xcard information content and what is sent to each >>> participant this is an application policy that can be based on an >>> application level authentication of the participant for example by >>> asking the use to provide his own credentials, (and not the >>> endpoint) >>> >>> Roni >>> >>> 15. Security Considerations >>> >>> There are several potential attacks related to telepresence, and >>> specifically the protocols used by CLUE, in the case of >>> conferencing sessions, due to the natural involvement of multiple >>> endpoints and the many, often user-invoked, capabilities provided >>> by the systems. >>> >>> An MCU involved in a CLUE session can experience many of the same >>> attacks as that of a conferencing system such as that enabled by >>> the XCON framework [RFC5239]. Examples of attacks include the >>> following: an endpoint attempting to listen to sessions in which >>> it is not authorized to participate, an endpoint attempting to >>> disconnect or mute other users, and theft of service by an >>> endpoint in attempting to create telepresence sessions it is not >>> allowed to create. Thus, it is RECOMMENDED that an MCU >>> implementing the protocols necessary to support CLUE, follow the >>> security recommendations specified in the conference control >>> protocol documents. In the case of CLUE, SIP is the conferencing >>> protocol, thus the security considerations in [RFC4579] MUST be >>> followed. . *Other security issues related to MCUs are discussed >>> in the XCON framework [RFC5239]. * >>> >>> *The conference wide information including conference roster are >>> similar to the xCard information in CLUE * >>> >>> *and CLUE based implementations MUST considers those issues and the >>> proposed solutions in [RFC5239] security section. * >>> >>> ** >>> >>> >> Would it be sufficient simply to leave the first sentence? The second >> sentence is confusing because RFC5239 doesn't use the term >> "conference wide" and xCard may be for a singe participant not conference wide. >> Actually do we need the text at all as the paragraph above refers to >> RFC5239 and recommendations specified in the conference control >> protocol documents? If we want to specifically capture xcard could we >> say something like "The use of xCard with potentially sensitive >> provides another reason to implement recommendations of section 11/[RFC 5239]."? >> >> The other changes listed are OK. There's a few typos but Mark will >> probably pick those up. >> >> Regards, Christian >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From nobody Tue Sep 15 22:45:40 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E491B3559 for ; Tue, 15 Sep 2015 22:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.67 X-Spam-Level: X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no 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 h96fwuAHmnoL for ; Tue, 15 Sep 2015 22:45:37 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c: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 F04EE1B3555 for ; Tue, 15 Sep 2015 22:45:36 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so54609806wic.1 for ; Tue, 15 Sep 2015 22:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=soE0g3y+RkTpmRSxSoRsiY9/jOmkmbkBu+TVypgYyoQ=; b=jDKgQXTgkAv0OwyHZ00yF7jjDNBvxmaUlJ8bHjqBdBi8GOQjGTQ+wfjK0tKf3UwF/F W62fP0T1DOsi14dN/iqqOpRgkGcF+bQMT53pAsR7G4PauofRL7v5RTTD1TUNshJLwTD6 kKxzb07aKIGoItPrvfCdSmse+fX3S4398ubIDp6Z8qt6X3nXVqvkyf5SqcLDk/t8fWYg XCLDO1armQ/U07o8aRvsSd0X8KAlHJTEZv0KaYS9/tqyXt3ZlhWuUWyN8JffDIgg51u4 AflIh6tMcDDoF2UXj3CwPosMLnu/KhLgkXHUDPX/va5VYQrZj1LkVU1xtNC+qRVAUWiC egGA== X-Received: by 10.180.87.162 with SMTP id az2mr15016890wib.62.1442382335605; Tue, 15 Sep 2015 22:45:35 -0700 (PDT) Received: from RoniPC (bzq-79-176-23-173.red.bezeqint.net. [79.176.23.173]) by smtp.gmail.com with ESMTPSA id ht5sm2491384wib.10.2015.09.15.22.45.33 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Sep 2015 22:45:34 -0700 (PDT) From: "Roni Even" To: "'Duckworth, Mark'" , References: <5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E30CE@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E30CE@CRPMBOXPRD08.polycom.com> Date: Wed, 16 Sep 2015 08:45:31 +0300 Message-ID: <064a01d0f042$e719f450$b54ddcf0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_064B_01D0F05C.0C67EFA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQILJcmmcMPwbZF1mVjWMY6u7hV7Up3KOi8w Content-Language: he Archived-At: Subject: Re: [clue] coming updates to framework document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 05:45:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_064B_01D0F05C.0C67EFA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit OK for me Roni From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, September 15, 2015 6:54 PM To: 'clue@ietf.org' Subject: [clue] coming updates to framework document Hi All, Here is what I have so far, for Framework updates: - updated security section from Roni, with Christian's amendment - fixed all the nits Alissa pointed out We answered Alissa's other questions on the list, without needing any change to the document. Is the group satisfied with this, or are there still other updates needed? Mark ------=_NextPart_000_064B_01D0F05C.0C67EFA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK for me

Roni

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, = Mark
Sent: Tuesday, September 15, 2015 6:54 PM
To: = 'clue@ietf.org'
Subject: [clue] coming updates to framework = document

 

Hi = All,

Here is what I have so far, for = Framework updates:

-          = updated security section = from Roni, with Christian’s amendment

-          = fixed all the nits Alissa = pointed out

 

We answered Alissa’s other questions on the = list, without needing any change to the document.

 

Is the group = satisfied with this, or are there still other updates = needed?

 

Mark

------=_NextPart_000_064B_01D0F05C.0C67EFA0-- From nobody Thu Sep 24 15:03:37 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4BE1B3C00; Thu, 24 Sep 2015 15:03:35 -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 aLdTLX_S2yyQ; Thu, 24 Sep 2015 15:03:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E561B3BF7; Thu, 24 Sep 2015 15:03:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150924220334.6564.15546.idtracker@ietfa.amsl.com> Date: Thu, 24 Sep 2015 15:03:34 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-23.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 22:03:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Authors : Mark Duckworth Andrew Pepperell Stephan Wenger Filename : draft-ietf-clue-framework-23.txt Pages : 83 Date : 2015-09-24 Abstract: This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling and SDP negotiation for setting up a telepresence session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-framework-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-framework-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 24 15:05:35 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D3B1B3C17 for ; Thu, 24 Sep 2015 15:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 mLi9B0XhLOWm for ; Thu, 24 Sep 2015 15:05:33 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.103]) (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 69AB01B3C02 for ; Thu, 24 Sep 2015 15:05:33 -0700 (PDT) Received: from [216.82.254.20] by server-7.bemta-7.messagelabs.com id AD/B8-03260-CA374065; Thu, 24 Sep 2015 22:05:32 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-2.tower-47.messagelabs.com!1443132194!35180759!12 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20803 invoked from network); 24 Sep 2015 22:05:23 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-2.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 24 Sep 2015 22:05:23 -0000 Received: from PWEHUB01.polycom.com (10.236.2.221) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.389.2; Thu, 24 Sep 2015 15:04:38 -0700 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([::1]) with mapi; Thu, 24 Sep 2015 15:04:38 -0700 From: "Duckworth, Mark" To: "'clue@ietf.org'" Date: Thu, 24 Sep 2015 15:04:36 -0700 Thread-Topic: New draft-ietf-clue-framework-23 Thread-Index: AdD3FO/5wyaSGANiSmyOiQV6k3abgw== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E3807@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E3807CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Subject: [clue] New draft-ietf-clue-framework-23 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 22:05:34 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E3807CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Changes from 22 to 23: 1. Updates to Security Considerations section. 2. Update version number of references to other CLUE documents i= n progress. 3. Change some "MAY" to "may". 4. Fix a few grammatical errors. Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E3807CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Changes from 22 = to 23:

1.     &= nbsp;      Updates to Security Considerations sect= ion.

2.     &nb= sp;      Update version number of references to ot= her CLUE documents in progress.

3. =            Change some &q= uot;MAY" to "may".

4.&nbs= p;           Fix a few gr= ammatical errors.

 

<= p class=3DMsoNormal>Mark

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC16C9E3807CRPMBOXPRD08p_--