From nobody Thu Jul 7 14:45:59 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D582012D8C9 for ; Thu, 7 Jul 2016 14:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=yKVJDgII; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ok0dTCZ3 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 i_TW8PDagik6 for ; Thu, 7 Jul 2016 14:45:56 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214D212D8C8 for ; Thu, 7 Jul 2016 14:45:56 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7B44D2019A; Thu, 7 Jul 2016 17:45:55 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 07 Jul 2016 17:45:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=dxIhD Ys1qILI350gb2Pxzd8bhik=; b=yKVJDgIIVXacWgtdcHWNfRW0J+kahekmk+V0D cvSqzqjr8M+bJRZ59gECp42s/dsRXMHA4qusUk266CsEqRoOU8o2QNzo2lhgOffk eetuui9uc4NWhRBuezOhGDPybp3/Y4FAU29/SdOZjUr3tsLdmipNuRhoobh/3f8N APVikQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=dxIhDYs1qILI350gb2Pxzd8bhik=; b=ok0dT CZ3O6uCFc7qrK7NZq/pNonkMxYfLwQ9w7RCC88SNAM+4iAL0SZ5gQIpqQjRvzT8u UKUMniBJkq9GZagZZIMoX3BsFUTRMT/wXwCtHSETo+Lm+0ah1Q0LZJzXxd6YKBGG jPTQjv+TNq6+NZFlingKZE0SjnxYIDldaYSSdA= X-Sasl-enc: 32ZZfyZQITTGcpNC8Y8cfGuDH91L7o6YssZtvEeGF6si 1467927954 Received: from dhcp-171-68-21-119.cisco.com (dhcp-171-68-21-119.cisco.com [171.68.21.119]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F654F29E1; Thu, 7 Jul 2016 17:45:54 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_87DEFE41-32D9-41DF-829D-73ABF9D44AE7" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Thu, 7 Jul 2016 14:45:53 -0700 Message-Id: <26B9B438-70E9-46AD-BFA7-BF9094D62DE7@cooperw.in> References: To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "clue@ietf.org" , "clue-chairs@tools.ietf.org" Subject: Re: [clue] Draft new version: draft-clue-data-channel-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jul 2016 21:45:58 -0000 --Apple-Mail=_87DEFE41-32D9-41DF-829D-73ABF9D44AE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I requested IETF last call on this. That way it will be ready to move = forward once the security considerations dependency is resolved. Alissa > On Jun 21, 2016, at 3:02 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > Based on Alissa=92s comments, I=92ve submitted a new version (-13) of = the CLUE data channel draft. >=20 > Note that the comment regarding the Security Considerations is still = pending. >=20 > GitHub: https://github.com/cdh4u/draft-clue-datachannel = (personal repo) >=20 > Regards, >=20 > Christer --Apple-Mail=_87DEFE41-32D9-41DF-829D-73ABF9D44AE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I requested IETF last call on this. That way = it will be ready to move forward once the security considerations = dependency is resolved.

Alissa

On Jun 21, 2016, at 3:02 AM, Christer = Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

Based on Alissa=92s comments, I=92ve submitted a new = version (-13) of the CLUE data channel draft.

Note that the comment regarding the Security = Considerations is still pending.

GitHub: https://github.com/cdh4u/draft-clue-datachannel (perso= nal repo)

Regards,

Christer

= --Apple-Mail=_87DEFE41-32D9-41DF-829D-73ABF9D44AE7-- From nobody Thu Jul 7 14:56:25 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3295F12D5CD; Thu, 7 Jul 2016 14:56:20 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160707215620.18849.71255.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 14:56:20 -0700 Archived-At: Cc: clue-chairs@ietf.org, pkyzivat@cisco.com, clue@ietf.org, draft-ietf-clue-datachannel@ietf.org Subject: [clue] Last Call: (CLUE Protocol data channel) to Proposed Standard X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 21:56:20 -0000 The IESG has received a request from the ControLling mUltiple streams for tElepresence WG (clue) to consider the following document: - 'CLUE Protocol data channel' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-07-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Jul 10 09:52:53 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAD012D0DF for ; Sun, 10 Jul 2016 09:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 BE2nizj834gN for ; Sun, 10 Jul 2016 09:52:50 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE9A12B005 for ; Sun, 10 Jul 2016 09:52:50 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-97-57827d60e0ab Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DD.90.12516.06D72875; Sun, 10 Jul 2016 18:52:48 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Sun, 10 Jul 2016 18:52:47 +0200 From: Christer Holmberg To: Alissa Cooper Thread-Topic: Draft new version: draft-clue-data-channel-13 Thread-Index: AQHRy6QVTjIVVvIOX0eA4T0TW3uZXaANeQ+AgASGlnA= Date: Sun, 10 Jul 2016 16:52:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38120532@ESESSMB209.ericsson.se> References: <26B9B438-70E9-46AD-BFA7-BF9094D62DE7@cooperw.in> In-Reply-To: <26B9B438-70E9-46AD-BFA7-BF9094D62DE7@cooperw.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B38120532ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7qG5CbVO4wf02HYvpZ/4yWsyc9oHV Yv+py8wOzB5fnrxk8liy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4MiataGIqeGZZcefyaZYG xikmXYwcHBICJhIvNhR0MXICmWISF+6tZ+ti5OIQEjjCKPH+4StWCGcJo8Tlw1uYQBrYBCwk uv9pgzSICKhKXD32gw3EZhZIkLj2eS4riC0sYCVxfu4uNogaa4m9myewQ9hWEvfnvGACsVmA eh+93ANWzyvgK9HU/B6sXkggT6Lx1B1GEJtTwE7ixfQvYDWMQMd9P7WGCWKXuMStJ/OZII4W kFiy5zwzhC0q8fLxP1YIW0lixfZLjBD1+RJbbixngdglKHFy5hOWCYyis5CMmoWkbBaSMoi4 jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzAC D275rbuDcfVrx0OMAhyMSjy8D4obw4VYE8uKK3MPMUpwMCuJ8H6uagoX4k1JrKxKLcqPLyrN SS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnVwKiZ6pEsy9JztnWRNuO1ncFReZJN YvofDtZUTQ8oftV57/udx5wvvF97H1vyYEPYpJX/9DdKPLfb8K53V9CS+AvL7pjMW/67pvFF +K0LX0Pz068duHTufqcP641cG7nP2QHflq4XmHXyUOk9P9nnmkWeZu5HJZ4WrtzT8GeuJM8q s1673/yft/IqsRRnJBpqMRcVJwIAGYNt27wCAAA= Archived-At: Cc: "clue@ietf.org" , "clue-chairs@tools.ietf.org" Subject: Re: [clue] Draft new version: draft-clue-data-channel-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 16:52:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B38120532ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks! Regards, Christer From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: 08 July 2016 00:46 To: Christer Holmberg Cc: clue@ietf.org; clue-chairs@tools.ietf.org Subject: Re: Draft new version: draft-clue-data-channel-13 I requested IETF last call on this. That way it will be ready to move forwa= rd once the security considerations dependency is resolved. Alissa On Jun 21, 2016, at 3:02 AM, Christer Holmberg > wrote: Hi, Based on Alissa's comments, I've submitted a new version (-13) of the CLUE = data channel draft. Note that the comment regarding the Security Considerations is still pendin= g. GitHub: https://github.com/cdh4u/draft-clue-datachannel (personal repo) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B38120532ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks!

 = ;

Regards,

 = ;

Christer

 

From: = Alissa Cooper [mailto:alissa@cooperw.in]
Sent: 08 July 2016 00:46
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: clue@ietf.org; clue-chairs@tools.ietf.org
Subject: Re: Draft new version: draft-clue-data-channel-13

 

I requested IETF last call on this. That way it will= be ready to move forward once the security considerations dependency is re= solved.

 

Alissa

 

On Jun 21, 2016, at 3:02 AM, Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com">christer.holmberg@ericsson= .com> wrote:

 

Hi,

 

Based on Alissa’s comments, I’ve submit= ted a new version (-13) of the CLUE data channel draft.

 

Note that the comment regarding the Security Consid= erations is still pending.

 

GitHub: https://github.com/cdh4u/draft-clue-datachannel&n= bsp;(personal repo)

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B38120532ESESSMB209erics_-- From nobody Tue Jul 12 10:14:08 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFC312D556; Tue, 12 Jul 2016 10:14:03 -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.27.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160712171403.5192.74484.idtracker@ietfa.amsl.com> Date: Tue, 12 Jul 2016 10:14:03 -0700 Archived-At: Cc: clue-chairs@ietf.org, pkyzivat@cisco.com, clue@ietf.org, draft-ietf-clue-datachannel@ietf.org Subject: [clue] Extended Last Call: (CLUE Protocol data channel) to Proposed Standard X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 17:14:03 -0000 The IESG has received a request from the ControLling mUltiple streams for tElepresence WG (clue) to consider the following document: - 'CLUE Protocol data channel' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jul 15 12:39:38 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAE312DD56; Fri, 15 Jul 2016 12:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MJE3RSagaH9E; Fri, 15 Jul 2016 12:39:33 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 5513712DD54; Fri, 15 Jul 2016 12:39:30 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id l125so110875210ywb.2; Fri, 15 Jul 2016 12:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=StMCrC/jylLi6kjuYEUvqBafKapoFyDUtxWFbkgOzoE=; b=yS4A3/k4KxpVq7L2PGgmhJWTKekmBCX7yFwYxqCRcW5ofL7p0jpvrHVjqOsxWe5RW2 mzh6PafNWMeTEf15+xDsx5mIQ/6AnaHWDiYorV+O6avkXuv/qbrd+Oud6EjiyTCk0Hyw eiy85sbW9d+aW6J2zV2O3+brwdDoGtzpSUUJzApwKOS7neIYMG9prwe5+idUob/Jd9Qm 99Y/WE/RszN05z2IYttG3bRO84nQrgBC+VmQWdn1CZ56mXfWd05u61GQZQPqCo+glPt0 R+jOSx2MZN2JxlkGZmBtN8KHDlYsFyCmsdPDxh5V9vJ4n9QxnQR0fPv5tUSiB4rb7Lse eIRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=StMCrC/jylLi6kjuYEUvqBafKapoFyDUtxWFbkgOzoE=; b=g1KMOkMnJaMKQ29wjaJUNox3N7CjD/HnCrMzOMIqgQ5+bxsQ9gaemKB0XlkwtSUY9K 0lDKB/5ZTtncaGP/B4pEWxcuQ16h/xhoEPkRXQhYbUivZtTB3d/uLTperNFmiRKqrFnZ 8DOCRWrRXzuTDC6tpmamVIHjjGqgyA8221l1JmxhtjtEtXeZXg47hvJxW4WsF0OKu2zI ZZfJvw/XE+6c6aOJsGwpVf2vZ0sUQ0REW975FrRuvOUYeiFjuV8PMi5n3o2p9SejgvYr 0g1jtlDgs9+d6a7g46XzeKelFt+PX3haiDUNAhfoPmNdaHovTl4wUiXeQY680uzhcJHf B9og== X-Gm-Message-State: ALyK8tLsqwpYYAJ8P1xhRcEvN0KLnLh9Gy2M6SfJgc/9UCck3hpMxoa82r8ih/te4gno9Chrc9T5jN3IMOhfPw== X-Received: by 10.37.52.87 with SMTP id b84mr15452469yba.60.1468611569239; Fri, 15 Jul 2016 12:39:29 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.83.33.137 with HTTP; Fri, 15 Jul 2016 12:39:28 -0700 (PDT) From: Barry Leiba Date: Fri, 15 Jul 2016 15:39:28 -0400 X-Google-Sender-Auth: PYTlumXe4suEztmsrDvh8cYlVRQ Message-ID: To: draft-ietf-clue-datachannel.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: clue@ietf.org, ietf@ietf.org, secdir@ietf.org Subject: [clue] Security Directorate review of draft-ietf-clue-datachannel-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:39:35 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready for publication. It's well written, and, while I have a few minor comments, they are only of the most minor sort. -- Section 3.1 -- As described in [I-D.ietf-rtcweb-data-channel], the SCTP streams realizing a WebRTC data channel must be associated with the same SCTP association. In addition, both SCTP streams realizing the WebRTC data channel must use the same SCTP stream identifier value. These rules also apply to a CLUE data channel. I don't know that it matters a lot, but this seems to be an odd way of saying that because a CLUE data channel is a WebRTC data channel, a CLUE data channel behaves like and has the same rules as a WebRTC data channel. I think I might word it more straightforwardly that way, something like this: NEW Because a CLUE data channel is a special case of a WebRTC data channel [I-D.ietf-rtcweb-data-channel], a CLUE data channel behaves like a WebRTC data channel and abides by the same rules. In particular, the SCTP streams realizing a WebRTC data channel must be associated with the same SCTP association, and both SCTP streams realizing the WebRTC data channel must use the same SCTP stream identifier value. END Worded that way, it also supports the many other times in the document that you point out things that rtcweb-data-channel says that affect CLUE data channel behaviour. But, as I said, I don't know that it matters a lot, so... just a suggestion. -- Section 3.2.3 -- I think I'd move (or copy) the citation of [I-D.ietf-clue-protocol] to Section 1, where "CLUE protocol" is first mentioned. -- Section 3.3.1.1 -- CLUE entities SHOULD NOT transport the SCTPoDTLS association used to realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP" proto value), unless it is known that UDP/DTLS/SCTP will not work Are there other reasons to transport over TCP other than "knowing that UDP/DTLS/SCTP will not work"? If so, OK. If not, then I think you really mean "MUST NOT ... unless ...." -- References -- I don't think RFC 3264 is normative. -- Barry From nobody Fri Jul 29 11:32:45 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47C112D0E4 for ; Fri, 29 Jul 2016 11:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 ObOS1P2d0b6V for ; Fri, 29 Jul 2016 11:32:41 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 C3D7E120727 for ; Fri, 29 Jul 2016 11:32:41 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-06v.sys.comcast.net with SMTP id TCa3bwjEa2NhqTCaObrA2v; Fri, 29 Jul 2016 18:32:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id TCaNbBEdQCigVTCaObVZ6I; Fri, 29 Jul 2016 18:32:40 +0000 References: <571673E9.4050005@alum.mit.edu> <94A3329C-F25B-439E-B6D2-CF6C98D9A3A6@unina.it> <79B5EFE2-761E-4351-AD73-88A200C0F6E9@unina.it> To: Simon Pietro Romano From: Paul Kyzivat Message-ID: Date: Fri, 29 Jul 2016 14:32:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfPlDcnolNnsEn8hbJsrC5R4Oi6kTcGs0uD1Fz8NMmjsXSJXJx6PO13DA14XvChq9KSlkXz9DW4njmPN+TOUM9wvGbHNHvOX3P8tcYgJOwR0G6Sovbl70 m9gzD7z15h0tIoA6TXXh5/eKpE1fR4LGKbjcmZVPzFnMf9t6Z3ztUtj4oFi0gpdBsrzSAEUJBWn98ZjwuLLowQ8T49tZoC4CRPI= Archived-At: Cc: clue@ietf.org Subject: Re: [clue] Finishing up Security Considerations for protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 18:32:44 -0000 Simon, Can we get this done now? I believe Alissa is simply waiting for the remaining few changes we already discussed. Then we can wrap this up. Thanks, Paul On 5/13/16 12:20 PM, Paul Kyzivat wrote: > On 5/13/16 12:12 PM, Simon Pietro Romano wrote: >>> Where did the last paragraph (re RBAC) come from? ISTM that this is >>> speculative - not anything that the WG has discussed. I'd like to >>> hear what others think about this. >> >> You’re right. This actually comes from far away in the past! It digs >> its roots in the disucssions we had at the time of the XCON WG and is >> in fact something that I added to the CCMP document, too. >> I personally bend towards role-based access control when it comes to >> policy-based managament and I thought this might be a useful piece of >> information for an interested reader. Though, I agree with >> you that we never discussed this within CLUE (which is btw clearly >> stated in the document). If you deem it useless, we can just remove >> that paragraph. > > Lets wait and see what others (including Alissa) think. > > Thanks, > Paul > >> Thanks, >> >> Simon >> >>> >>> Thanks, >>> Paul >>> >>>> Thank you once again for your input and comments, >>>> >>>> Simon >>>> >>>> ***************************************** START OF SECURITY >>>> CONSIDERATIONS SECTION ********************************************** >>>> As a general consideration, we remark that the CLUE framework (and >>>> related protocol) has been conceived at the outset by embracing the >>>> security-by-design paradigm. This entails that a number of >>>> requirements have been identified and properly standardized as >>>> mandatory within the entire set of documents associated with the CLUE >>>> architecture. Among such requirements we mention the following: (i) >>>> always leave space for criptography and authentication; (ii) get sure >>>> that all sensitive fields can be protected; (iii) envisage mutual >>>> authentication between CLUE endpoints; (iv) envisage the presence of >>>> authorization mechanisms; (v) envisage the presence of native defense >>>> mechanisms against malicious activities such as eavesdropping, >>>> selective modification, deletion, replay (and related combinations >>>> thereof). Hence, security of the single components of the CLUE >>>> solution cannot be evaluated independently of the integrated view of >>>> the final architecture. >>>> >>>> Coming to the details of the CLUE protocol, this is an application- >>>> level protocol allowing a Media Producer and a Media Consumer to >>>> negotiate a variegated set of parameters associated with the >>>> establishment of a telepresence session. This unavoidably exposes a >>>> CLUE-enabled telepresence system to a number of potential threats, >>>> most of which are extensively discussed in the framework document >>>> [I-D.ietf-clue-framework]. The security considerations section of >>>> the mentioned document actually discusses issues associated with the >>>> setup and management of a telepresence session both in the basic case >>>> involving two CLUE endpoints acting, respectively, as MP and MC, and >>>> in the more advanced scenario envisaging the presence of an MCU. >>>> >>>> The framework document also mentions that the information carried >>>> within CLUE protocol messages might contain sensitive data, which >>>> SHOULD hence be accessed only by authenticated endpoints. Security >>>> issues associated with the CLUE data model schema are discussed in >>>> [I-D.ietf-clue-data-model-schema]. >>>> >>>> There is indeed some piece of extra information carried by the CLUE >>>> protocol which is not associated with the standard data model and >>>> which exposes information that might be of concern. This is >>>> primarily what gets exchanged during the options negotiation phase. >>>> From the Clue Participant state machine, we know that in the OPTIONS >>>> state both parties agree on the version and on the options to be used >>>> in the subsequent CLUE messages exchange phase. A malicious >>>> participant might either try to retrieve a detailed footprint of a >>>> specific CLUE protocol implementation during this initial setup >>>> phase, or force the communicating party to stick to a non-up-to-date >>>> version of the protocol which they know how to break. Indeed, >>>> exposing all of the supported versions and options could conceivably >>>> leak a bit of information about the specific implementation of the >>>> protocol. In theory an implementation could choose not to announce >>>> all of the versions it supports if it wants to avoid such leakage, >>>> though at the expenses of interoperability. With respect to the >>>> above considerations, we nonetheless remark that the OPTIONS state is >>>> only reached after the CLUE data channel has been successfully set >>>> up. This ensures that only authenticated parties can exchange >>>> OPTIONS and related OPTIONS RESPONSE messages and hence drastically >>>> reduces the attack surface which is exposed to malicious parties. >>>> >>>> Coming to the content of the protocol messages themselves, the CLUE >>>> framework clearly states the requirement to protect against threats >>>> deriving from the presence of a malicious agent capable to gain >>>> access to the CLUE data channel. Such a requirement is met by the >>>> CLUE data channel solution described in [I-D.ietf-clue-datachannel], >>>> which ensures protection from both message recovery and message >>>> tampering. With respect to this last point, we once again remark >>>> that any implementation of the CLUE protocol which claims to be >>>> compliant with the CLUE specification MUST rely on the exchaning of >>>> messages which flow on top of a reliable and ordered SCTP over DTLS >>>> transport channel connecting two CLUE Participants. >>>> >>>> As a final consideration, we remark that policy-based management of a >>>> CLUE-compliant telepresence architecture, though not in the scope of >>>> the CLUE WG charter, can easily be realized. To the purpose, common >>>> Role-Based Access Control (RBAC) approaches can be leveraged. In >>>> RBAC, the following elements are identified: (i) Users; (ii) Roles; >>>> (iii) Objects; (iv) Operations; (v) Permissions. For all of the >>>> above elements, a direct mapping exists onto the main CLUE entities. >>>> As an example, RBAC objects map onto CLUE data model objects and RBAC >>>> operations map onto CLUE protocol operations. Future documents can >>>> define an RBAC framework for CLUE, by first focusing on the >>>> definition of roles and then specifying the needed permission policy >>>> sets and role policy sets (used to associate policy permission sets >>>> with specific roles). With these policies in place, access to >>>> information compliant with the CLUE data model can be appropriately >>>> controlled. As far as assigning users to roles, the Users in the >>>> RBAC model relate directly to the element in the CLUE >>>> object. The element is comprised of elements >>>> representing a specific user in the telepresence system. Each >>>> element contains a 'personID' attribute acting as a unique >>>> identifier and a element describing their role in the >>>> CLUE session ("presenter", "timekeeper", "attendee", "minute taker", >>>> "translator", "chairman", "vice-chairman") . Thus, each authorized >>>> user can be associated with a well-defined role in the RBAC model. >>>> >>>> ***************************************** END OF SECURITY >>>> CONSIDERATIONS >>>> SECTION ********************************************** >>>> >>>> >>>> >>>> >>>> >>>>> On 19/apr/2016, at 20:07, Paul Kyzivat >>>> > wrote: >>>>> >>>>> The protocol needs to have a Security Considerations section before it >>>>> can progress. That is the main gating item at this point. >>>>> >>>>> This should be pretty simple. The following are my thoughts about what >>>>> should be in it: >>>>> >>>>> - it should reference the security considerations in the framework. >>>>> They cover many important issues and those probably don't need to be >>>>> restated as long as they are referenced. >>>>> >>>>> - it should reference the security considerations in the data model. >>>>> That document has most of the critical data to be concerned with. >>>>> >>>>> - a reference to the security considerations in the clue-datachannel >>>>> draft will cover the protection of the content of the protocol >>>>> messages. >>>>> >>>>> - There probably should be a brief discussion of the extra data in the >>>>> protocol (not in the data model) that exposes information that might >>>>> be of concern. I think this is primarily in the options negotiation: >>>>> exposing all the versions and options supported could conceivably leak >>>>> a bit of info about the specific software. In theory an implementation >>>>> could choose not to announce all the versions it supports if it wants >>>>> to avoid such leakage, though it would reduce interoperability. And of >>>>> course it will only be relevant when there are multiple versions and >>>>> options. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _\\|//_ >>>> ( O-O ) >>>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Simon Pietro Romano >>>> Universita' di Napoli Federico II >>>> Computer Engineering Department >>>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>>> e-mail: spromano@unina.it >>>> >>>> >>>> <>>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>>> oooO >>>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> \ ( ( ) >>>> \_) ) / >>>> (_/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >> >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue