From nobody Fri Jul 3 11:28:19 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 CA87E1A1A97 for ; Fri, 3 Jul 2015 11:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 GkeSgayGixlM for ; Fri, 3 Jul 2015 11:28:16 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ADFC1A1A43 for ; Fri, 3 Jul 2015 11:28:16 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 68D69204E8 for ; Fri, 3 Jul 2015 14:28:15 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 03 Jul 2015 14:28:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=pMx GCiEYYlESldI+R+EUt21nCQY=; b=faKsZxzi805TEjSM6z2tU3XHDKOJJALm8Ks btm8AQGHBXSw3SiA53FMw3YP6KKmuYu5B7fo2PqK7Agtt4KvWofTMFL2lUyLXS7G NJtvoFj4kw1eO7Df7WPCza6GDm1ea7ObQohVAau8oiqfRVaJn3VLo/m8fM4h59jL cCDVqh2c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=pMxGCiEYYlESldI+R+EUt21nCQY=; b=cjAyg sZ3juqlVDm3t4zwdB7YU9E+G0w6WEZjqmw3/TfMYFPzYsEGZ3QHomxVIL15u5Cld pEX8kqf5JMt0QHRQK2v4S/EODjC4guXOBgUB9piHKK21ramOBj5F9+gF81evaTv2 L6XrNThRUogUoLnJ9GtYBa2iPBKPGjM56uVG1c= X-Sasl-enc: B5gjszObPlV2hbAa6Q+KbNvg6kk2IY9PDSonmI9KrP+O 1435948094 Received: from sjc-alcoop-8818.cisco.com (unknown [128.107.241.161]) by mail.messagingengine.com (Postfix) with ESMTPA id A1C176800FE for ; Fri, 3 Jul 2015 14:28:14 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 3 Jul 2015 11:28:14 -0700 To: clue@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [clue] AD evaluation: draft-ietf-clue-framework-22 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: Fri, 03 Jul 2015 18:28:18 -0000 I have reviewed this document in preparation for IETF LC and I have some = comments and questions I'd like to see resolved before issuing the last = call. I've also listed some nits further below that should be resolved = in the next revision of the document. Overall, the amount of complexity that this framework supports in terms = of the number of configuration choices that can be provided and consumed = is daunting. I know the WG is already well down the path towards = finishing this off so I'm not suggesting changes in this regard, but I = do think folks should be prepared for questions about the trade-off = between flexibility and implementability that may arise during IETF LC = or IESG evaluation. Substantive comments and questions: =3D Section 3 =3D Why are these definitions not necessarily consistent with the = definitions in RFC 7262 (e.g., Endpoint)? Why not just rely on the = definitions in that document for terms being re-used? I know there was a = conclusion that strict alignment with the taxonomy doc was not = necessary, but it seems like at least the CLUE docs should be internally = consistent. =3D Section 7.1.1.10 =3D I think this section (and to some extent the one that follows) require a = more thorough explanation to justify how it is that sending a lot of = detailed information about the people involved in a telepresence session = actually helps the endpoints decide how to arrange the media in the = session. I understand that some (limited) information is useful for = display purposes, but this section provides really broad leeway for = endpoints to send a lot of information about individual participants = without a thoroughgoing justification of how policies are built that act = on such detailed information. On the other hand, there are some data fields I would have expected to = possibly be useful for these kinds of policies, like device type or room = type or even device name, but it's not clear how endpoints are supposed = to communicate those, if at all (stuff them into an xCard somewhow?). = What is the story as far as those kinds of attributes go? =3D Section 7.2.1.1 =3D Just because the syntax of the MaxCaptures definition theoretically = allows for it to be set to <=3D1 does not mean that semantic should = necessarily be allowed in the protocol. I don't understand the case = where sending <=3D1 should be considered valid -- why have an MCC with = zero captures in it? It seems like =3D1 and <=3DN where N>1 are the only = valid values here. =3D Section 15 =3D "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." The specific documents need to be listed here, assuming RFC 4579 is not = the only one to be mentioned. "Thus the security mechanisms recommended for SIP [RFC3261], including user authentication and authorization, SHOULD be followed." Given that implementations will need to be updated to support CLUE, what = is the rationale for having user authentication and authorization be = optional? What are the cases where allowing an unauthenticated or = unauthorized participant to join a telepresence session would be = considered acceptable? "In addition, the media is based on RTP and thus existing RTP security mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported. Media security is also discussed in [I-D.ietf-clue-signaling] and [I-D.ietf-clue-rtp-mapping]." I think it's worth pointing out in this document that DTLS/SRTP is = required to use for CLUE-controlled m-lines. Also, I just did a quick = skim of draft-ietf-clue-rtp-mapping and didn't see anything in there = about media security. "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. 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." I don't think it's enough to point out that sensitive data can be sent = back and forth with CLUE and that it shouldn't be used for authorization = decisions. Is there some guidance that can be given about minimizing the = amount and sensitivity of data to be sent? Are there certain xCard = fields that endpoints should avoid sending? Some of this is obviously = dependent on context and whether the participants in a conference know = this information about each other already, but it's still worth = mentioning how to mitigate the risks of sharing more data or more = sensitive data than is necessary for the purposes of supporting a = telepresence session. This might imply additional text in 7.1.1.10 as = well. "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 no details about how the data channel is secured in = draft-ietf-clue-datachannel (which should be cited here if it's going to = be referenced). Nor are the details in draft-ietf-rtcweb-data-channel, = but rather they are in draft-ietf-rtcweb-security-arch and = draft-ietf-rtcweb-security.=20 Furthermore, the details provided in draft-ietf-rtcweb-security-arch and = draft-ietf-rtcweb-security explain the situation for rtcweb, where the = endpoints rely on identity providers to authenticate each others' = identities. IdPs are not specifically included in the CLUE architecture = and, as noted above, the SIP authentication mechanisms are optional -- = so how is it that the CLUE data channel is actually secured against an = active MITM? Nits: There are a bunch of uses of normative MAY in this document that don't = really fit the RFC 2119 usage of the term (i.e., are not actually = protocol options). I've pointed them out below along with other nits. =3D Section 3 =3D "The spatial region represented by a Capture Scene MAY correspond to a real region in physical space, such as a room." I don't think normative language is necessary here. s/MAY/may/ s/[RFC4353] like Mixer/[RFC4353]-like Mixer/ =3D Section 4 =3D s/it should be stressed that its use in an implementation/it should be = stressed that their use in an implementation/ =3D Section 5 =3D "Also, the Consumer MAY use the information provided to tailor the SDP it is going to send during any following SIP offer/answer exchange, and its reaction to SDP it receives in that step." =20 I don't think normative language is necessary here. s/MAY/may/ "For example, if both sides decide to upgrade the call from a single = screen to a multi-screen call and more bandwidth is required for the additional video channels compared to what was previously negotiated using offer/answer, a new O/A exchange is REQUIRED." =20 I don't think normative language is necessary here since this is just an = example. s/REQUIRED/required/ =3D Secton 7.1.1.4 =3D s/High dynamic/Highly dynamic/ =3D Section 7.1.1.11 =3D Not everyone considers "chairman" to be a gender-neutral term. You might = want to consider "chair" and "vice-chair" instead. In general it's hard for me to believe that there is much of an = interoperability gain from specifying titles in this level of detail, = rather than just allowing advertisers to specify all of their own -- is = there some compelling need to specify this set of values initially? =3D Section 7.1.1.12 =3D s/no assumptions regarding relative important/no assumptions regarding = relative importance/ =3D Section 7.1.1.13 =3D s/the video Capture MAY contain speech to text information/the video = Capture may contain speech to text information/ =3D Section 7.2.1.1 =3D s/MaxCaptures MAY be set to one/MaxCaptures may be set to one/ =3D Section 10 =3D s/Optimized implementations MAY speed up the reaction to the offer/answer exchange/Optimized implementations may speed up the = reaction to the offer/answer exchange/ =3D Section 10.1 =3D s/if the Consumer is an MCU, it MAY choose to receive/if the Consumer is = an MCU, it may choose to receive/ s/user choice (for instance, selection of a new layout) MAY result/user = choice (for instance, selection of a new layout) may result From nobody Mon Jul 6 04:00: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 E9C991A00E3 for ; Mon, 6 Jul 2015 04:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 8e4BG8fzcCOs for ; Mon, 6 Jul 2015 04:00:06 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (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 752A31A00BC for ; Mon, 6 Jul 2015 04:00:06 -0700 (PDT) Received: by lagx9 with SMTP id x9so149780113lag.1 for ; Mon, 06 Jul 2015 04:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uwwk7+IJ9SlWSDNwzoWHO2Lv/gt5cwj2aFsRIvxrNmU=; b=yDTmiQcruH9mP05ntCtAq/JeLwZi5zzUolSTDPHAo9OPvXbO7odx96aS6SGjqUkrbz XFVM+6NI7HPyPMNN+ZV2RZ2ISS3g6mA530MygzjJ6BAjYBl+588xgmVHW7rld6LVBdG/ TUO03Mq5QMze8zlIHy2hfkC6XnWsMBk5QJPLyaFM7OPkzpS3ViGh1s1SRYXKFXT5+pj3 07+ZVWRHsdEeq8l416+8z/dwUUPDU8CH7F278mzwyMvg0GnC0bo1GmYYuThlREz5h7dK 91u3hxcxQfK59EtcVdSse3vfXchzgVU0NI43/5W6ieyQZItmuALLIP73dEkm3W4zybXB X+6Q== MIME-Version: 1.0 X-Received: by 10.152.28.73 with SMTP id z9mr48216875lag.93.1436180405033; Mon, 06 Jul 2015 04:00:05 -0700 (PDT) Received: by 10.112.118.99 with HTTP; Mon, 6 Jul 2015 04:00:04 -0700 (PDT) Date: Mon, 6 Jul 2015 14:00:04 +0300 Message-ID: From: Ron Even To: "clue@ietf.org" Content-Type: multipart/mixed; boundary=089e0158c026e056c3051a32ced9 Archived-At: Subject: [clue] CLUE agenda for Prague 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, 06 Jul 2015 11:00:08 -0000 --089e0158c026e056c3051a32ced9 Content-Type: text/plain; charset=UTF-8 Hi, Here is the proposed agenda, any comments? See you in Prague Roni Even --089e0158c026e056c3051a32ced9 Content-Type: text/plain; charset=US-ASCII; name="c1507.txt" Content-Disposition: attachment; filename="c1507.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: file2 Q29udHJvTGxpbmcgbVVsdGlwbGUgc3RyZWFtcyBmb3IgdEVsZXByZXNlbmNlICAoQ0xVRSkgV29y a2luZyBHcm91cA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KDQpDSEFJUlM6ICBEYW5pZWwgQnVybmV0dCAgICAgICA8 ZGFuaWVsY2J1cm5ldHRAZ21haWwuY29tPg0KICAgICAgICAgUm9uaSBFdmVuICAgICAgICAgPHJv bmkuZXZlbkBtYWlsMDEuaHVhd2VpLmNvbT4NCiAgICAgICAgIFBhdWwga3l6aXZhdCAgICAgICAg PHBreXppdmF0QGFsdW0ubWl0LmVkdT4NCg0KQUdFTkRBDQoNCk1vbmRheSwgMjAgSnVseTIwMTUg YXQgMTM6MDAtMTU6MDAgKEthcmxpbiBJSUkpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KMTM6MDAgICBDTFVFIFN0YXR1cyBVcGRhdGUgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKENoYWlycywgMjApDQoNCjEzOjIwICAgQ0xVRSBwcm90 b2NvbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChTaW1vbiBSb21hbm8sIDIwKQ0K ICAgICAgICBkcmFmdC1pZXRmLWNsdWUtcHJvdG9jb2wtMDQNCg0KMTM6NDAgICBDTFVFIFNpZ25h bGluZyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoUm9iIEhhbnNlbiwgMzApDQog ICAgICAgIGRyYWZ0LWlldGYtY2x1ZS1zaWduYWxpbmctMDUNCg0KMTQ6MTAgICBNYXBwaW5nIFJU UCBzdHJlYW1zIHRvIENMVUUgbWVkaWEgY2FwdHVyZXMgICAgICAgKFJvbmkgRXZlbiwgMTUpDQog ICAgICAgIGRyYWZ0LWlldGYtY2x1ZS1ydHAtbWFwcGluZy0wNA0KDQoxNDoyNSAgIEVuZA0K --089e0158c026e056c3051a32ced9 Content-Type: text/html; charset=US-ASCII; name="c1507.html" Content-Disposition: attachment; filename="c1507.html" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5Db250cm9MbGluZyBtVWx0aXBsZSBzdHJlYW1zIGZvciB0 RWxlcHJlc2VuY2UgIChDTFVFKSBXb3JraW5nIEdyb3VwIEFnZW5kYTwvdGl0bGU+DQo8L2hlYWQ+ DQo8Ym9keSBiZ2NvbG9yPSIjZmZmZmZmIj48aDE+Q29udHJvTGxpbmcgbVVsdGlwbGUgc3RyZWFt cyBmb3IgdEVsZXByZXNlbmNlICAoQ0xVRSkgV29ya2luZyBHcm91cCBBZ2VuZGE8L2gxPg0KPGhy Pg0KPHA+DQo8aDM+DQpDaGFpcnM6IERhbmllbCBCdXJuZXR0ICAgICAgIDxkYW5pZWxjYnVybmV0 dEBnbWFpbC5jb20+LCBSb25pIEV2ZW4gICAgICAgICA8cm9uaS5ldmVuQG1haWwwMS5odWF3ZWku Y29tPiwgUGF1bCBreXppdmF0ICAgICAgICA8cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KPC9oMz4N CjxwPg0KPGgyPk1vbmRheSwgMjAgSnVseTIwMTUgYXQgMTM6MDAtMTU6MDAgKEthcmxpbiBJSUkp PC9oMj4NCjxwPg0KPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjUiPg0KPHRyPg0KPHRo IGFsaWduPSJsZWZ0Ij4xMzowMA0KPHRoIGFsaWduPSJsZWZ0Ij5DTFVFIFN0YXR1cyBVcGRhdGU8 dGggYWxpZ249ImxlZnQiPkNoYWlycw0KPHRyPg0KPHRoIGFsaWduPSJsZWZ0Ij4xMzoyMA0KPHRo IGFsaWduPSJsZWZ0Ij5DTFVFIHByb3RvY29sPHRoIGFsaWduPSJsZWZ0Ij5TaW1vbiBSb21hbm8N Cjx0cj4NCjx0ZCBhbGlnbj0ibGVmdCI+DQo8dGQgYWxpZ249ImxlZnQiPjxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWNsdWUtcHJvdG9jb2wtMDQiPmRyYWZ0LWll dGYtY2x1ZS1wcm90b2NvbC0wNDwvYT4NCjx0cj4NCjx0aCBhbGlnbj0ibGVmdCI+MTM6NDANCjx0 aCBhbGlnbj0ibGVmdCI+Q0xVRSBTaWduYWxpbmc8dGggYWxpZ249ImxlZnQiPlJvYiBIYW5zZW4N Cjx0cj4NCjx0ZCBhbGlnbj0ibGVmdCI+DQo8dGQgYWxpZ249ImxlZnQiPjxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWNsdWUtc2lnbmFsaW5nLTA1Ij5kcmFmdC1p ZXRmLWNsdWUtc2lnbmFsaW5nLTA1PC9hPg0KPHRyPg0KPHRoIGFsaWduPSJsZWZ0Ij4xNDoxMA0K PHRoIGFsaWduPSJsZWZ0Ij5NYXBwaW5nIFJUUCBzdHJlYW1zIHRvIENMVUUgbWVkaWEgY2FwdHVy ZXM8dGggYWxpZ249ImxlZnQiPlJvbmkgRXZlbg0KPHRyPg0KPHRkIGFsaWduPSJsZWZ0Ij4NCjx0 ZCBhbGlnbj0ibGVmdCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWll dGYtY2x1ZS1ydHAtbWFwcGluZy0wNCI+ZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5nLTA0PC9h Pg0KPHRyPg0KPHRoIGFsaWduPSJsZWZ0Ij4xNDoyNQ0KPHRoIGFsaWduPSJsZWZ0Ij5FbmQ8L3Rh YmxlPg0K --089e0158c026e056c3051a32ced9-- From nobody Wed Jul 8 05:24:05 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 1721F1A8FD7 for ; Wed, 8 Jul 2015 05:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 w_cvnK3hrPh1 for ; Wed, 8 Jul 2015 05:24:01 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.16]) (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 9C7221A8F3F for ; Wed, 8 Jul 2015 05:23:58 -0700 (PDT) Received: from [216.82.249.212] by server-16.bemta-12.messagelabs.com id 08/DE-32232-E561D955; Wed, 08 Jul 2015 12:23:58 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-219.messagelabs.com!1436358237!13676094!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8858 invoked from network); 8 Jul 2015 12:23:57 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-9.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 8 Jul 2015 12:23:57 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.184]) by Crpehubprd01.polycom.com ([::1]) with mapi; Wed, 8 Jul 2015 05:23:57 -0700 From: "Duckworth, Mark" To: Alissa Cooper , "'Christian Groves (Christian.Groves@nteczone.com)'" Date: Wed, 8 Jul 2015 05:23:55 -0700 Thread-Topic: [clue] AD evaluation: draft-ietf-clue-framework-22 Thread-Index: AdC1vhArxbpIPnoQSDaRd4Je6ELzlgDujoXA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F9BEA2A8EB7@CRPMBOXPRD08.polycom.com> References: In-Reply-To: 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@ietf.org" Subject: Re: [clue] AD evaluation: draft-ietf-clue-framework-22 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, 08 Jul 2015 12:24:04 -0000 Thanks for the feedback Alissa. I will be a bit slow in responding to all = the points, due to other commitments. Christian, can you respond to questions about section 7.1.1.10 and 7.2.1.1? Can anybody help with the Security section? as I don't have much expertise = in that area. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Alissa Cooper > Sent: Friday, July 03, 2015 2:28 PM > To: clue@ietf.org > Subject: [clue] AD evaluation: draft-ietf-clue-framework-22 >=20 > I have reviewed this document in preparation for IETF LC and I have some > comments and questions I'd like to see resolved before issuing the last c= all. > I've also listed some nits further below that should be resolved in the n= ext > revision of the document. >=20 > Overall, the amount of complexity that this framework supports in terms o= f > the number of configuration choices that can be provided and consumed is > daunting. I know the WG is already well down the path towards finishing t= his > off so I'm not suggesting changes in this regard, but I do think folks sh= ould be > prepared for questions about the trade-off between flexibility and > implementability that may arise during IETF LC or IESG evaluation. >=20 > Substantive comments and questions: >=20 > =3D Section 3 =3D > Why are these definitions not necessarily consistent with the definitions= in > RFC 7262 (e.g., Endpoint)? Why not just rely on the definitions in that > document for terms being re-used? I know there was a conclusion that stri= ct > alignment with the taxonomy doc was not necessary, but it seems like at > least the CLUE docs should be internally consistent. >=20 > =3D Section 7.1.1.10 =3D > I think this section (and to some extent the one that follows) require a = more > thorough explanation to justify how it is that sending a lot of detailed > information about the people involved in a telepresence session actually > helps the endpoints decide how to arrange the media in the session. I > understand that some (limited) information is useful for display purposes= , > but this section provides really broad leeway for endpoints to send a lot= of > information about individual participants without a thoroughgoing > justification of how policies are built that act on such detailed informa= tion. >=20 > On the other hand, there are some data fields I would have expected to > possibly be useful for these kinds of policies, like device type or room = type or > even device name, but it's not clear how endpoints are supposed to > communicate those, if at all (stuff them into an xCard somewhow?). What i= s > the story as far as those kinds of attributes go? >=20 > =3D Section 7.2.1.1 =3D > Just because the syntax of the MaxCaptures definition theoretically allow= s > for it to be set to <=3D1 does not mean that semantic should necessarily = be > allowed in the protocol. I don't understand the case where sending <=3D1 > should be considered valid -- why have an MCC with zero captures in it? I= t > seems like =3D1 and <=3DN where N>1 are the only valid values here. >=20 > =3D Section 15 =3D > "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." >=20 > The specific documents need to be listed here, assuming RFC 4579 is not t= he > only one to be mentioned. >=20 > "Thus > the security mechanisms recommended for SIP [RFC3261], including > user authentication and authorization, SHOULD be followed." >=20 > Given that implementations will need to be updated to support CLUE, what = is > the rationale for having user authentication and authorization be optiona= l? > What are the cases where allowing an unauthenticated or unauthorized > participant to join a telepresence session would be considered acceptable= ? >=20 > "In > addition, the media is based on RTP and thus existing RTP security > mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported. > Media security is also discussed in [I-D.ietf-clue-signaling] and > [I-D.ietf-clue-rtp-mapping]." >=20 > I think it's worth pointing out in this document that DTLS/SRTP is requir= ed to > use for CLUE-controlled m-lines. Also, I just did a quick skim of draft-i= etf-clue- > rtp-mapping and didn't see anything in there about media security. >=20 > "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. 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." >=20 > I don't think it's enough to point out that sensitive data can be sent ba= ck and > forth with CLUE and that it shouldn't be used for authorization decisions= . Is > there some guidance that can be given about minimizing the amount and > sensitivity of data to be sent? Are there certain xCard fields that endpo= ints > should avoid sending? Some of this is obviously dependent on context and > whether the participants in a conference know this information about each > other already, but it's still worth mentioning how to mitigate the risks = of > sharing more data or more sensitive data than is necessary for the purpos= es > of supporting a telepresence session. This might imply additional text in > 7.1.1.10 as well. >=20 > "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." >=20 > There are no details about how the data channel is secured in draft-ietf-= clue- > datachannel (which should be cited here if it's going to be referenced). = Nor > are the details in draft-ietf-rtcweb-data-channel, but rather they are in= draft- > ietf-rtcweb-security-arch and draft-ietf-rtcweb-security. >=20 > Furthermore, the details provided in draft-ietf-rtcweb-security-arch and > draft-ietf-rtcweb-security explain the situation for rtcweb, where the > endpoints rely on identity providers to authenticate each others' identit= ies. > IdPs are not specifically included in the CLUE architecture and, as noted > above, the SIP authentication mechanisms are optional -- so how is it tha= t the > CLUE data channel is actually secured against an active MITM? >=20 >=20 > Nits: > There are a bunch of uses of normative MAY in this document that don't > really fit the RFC 2119 usage of the term (i.e., are not actually protoco= l > options). I've pointed them out below along with other nits. >=20 > =3D Section 3 =3D > "The spatial region represented by a Capture > Scene MAY correspond to a real region in physical space, such as a > room." >=20 > I don't think normative language is necessary here. s/MAY/may/ >=20 > s/[RFC4353] like Mixer/[RFC4353]-like Mixer/ >=20 > =3D Section 4 =3D > s/it should be stressed that its use in an implementation/it should be > stressed that their use in an implementation/ >=20 > =3D Section 5 =3D > "Also, the Consumer > MAY use the information provided to tailor the SDP it is going to > send during any following SIP offer/answer exchange, and its > reaction to SDP it receives in that step." >=20 > I don't think normative language is necessary here. s/MAY/may/ >=20 > "For example, if both sides decide to upgrade the call from a single scre= en to > a > multi-screen call and more bandwidth is required for the additional > video channels compared to what was previously negotiated using > offer/answer, a new O/A exchange is REQUIRED." >=20 > I don't think normative language is necessary here since this is just an > example. s/REQUIRED/required/ >=20 > =3D Secton 7.1.1.4 =3D > s/High dynamic/Highly dynamic/ >=20 > =3D Section 7.1.1.11 =3D > Not everyone considers "chairman" to be a gender-neutral term. You might > want to consider "chair" and "vice-chair" instead. >=20 > In general it's hard for me to believe that there is much of an interoper= ability > gain from specifying titles in this level of detail, rather than just all= owing > advertisers to specify all of their own -- is there some compelling need = to > specify this set of values initially? >=20 > =3D Section 7.1.1.12 =3D > s/no assumptions regarding relative important/no assumptions regarding > relative importance/ >=20 > =3D Section 7.1.1.13 =3D > s/the video Capture MAY contain speech to text information/the video > Capture may contain speech to text information/ >=20 > =3D Section 7.2.1.1 =3D > s/MaxCaptures MAY be set to one/MaxCaptures may be set to one/ >=20 > =3D Section 10 =3D > s/Optimized implementations MAY speed up the reaction to the > offer/answer exchange/Optimized implementations may speed up the > reaction to the > offer/answer exchange/ >=20 > =3D Section 10.1 =3D > s/if the Consumer is an MCU, it MAY choose to receive/if the Consumer is = an > MCU, it may choose to receive/ >=20 > s/user choice (for instance, selection of a new layout) MAY result/user c= hoice > (for instance, selection of a new layout) may result >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jul 13 22:57: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 2914E1A0338 for ; Mon, 13 Jul 2015 22:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 P1cpk55-XvRj for ; Mon, 13 Jul 2015 22:57: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 65C131A0248 for ; Mon, 13 Jul 2015 22:57:51 -0700 (PDT) Received: from ppp118-209-54-82.lns20.mel4.internode.on.net ([118.209.54.82]:51289 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZEtDu-0029Pm-30; Tue, 14 Jul 2015 15:57:46 +1000 Message-ID: <55A4A4D1.2050100@nteczone.com> Date: Tue, 14 Jul 2015 15:57:37 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Duckworth, Mark" , Alissa Cooper References: <5C4AC54BFF7A0842A6A11F554D6FB52F9BEA2A8EB7@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F9BEA2A8EB7@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: Cc: "clue@ietf.org" Subject: Re: [clue] AD evaluation: draft-ietf-clue-framework-22 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, 14 Jul 2015 05:57:55 -0000 Hello Alissa and Mark, Please see my comments below. Regards, Christian On 8/07/2015 10:23 PM, Duckworth, Mark wrote: > Thanks for the feedback Alissa. I will be a bit slow in responding to all the points, due to other commitments. > > Christian, can you respond to questions about section 7.1.1.10 and 7.2.1.1? > > Can anybody help with the Security section? as I don't have much expertise in that area. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Alissa Cooper >> Sent: Friday, July 03, 2015 2:28 PM >> To: clue@ietf.org >> Subject: [clue] AD evaluation: draft-ietf-clue-framework-22 >> >> I have reviewed this document in preparation for IETF LC and I have some >> comments and questions I'd like to see resolved before issuing the last call. >> I've also listed some nits further below that should be resolved in the next >> revision of the document. >> >> Overall, the amount of complexity that this framework supports in terms of >> the number of configuration choices that can be provided and consumed is >> daunting. I know the WG is already well down the path towards finishing this >> off so I'm not suggesting changes in this regard, but I do think folks should be >> prepared for questions about the trade-off between flexibility and >> implementability that may arise during IETF LC or IESG evaluation. >> >> Substantive comments and questions: >> >> = Section 3 = >> Why are these definitions not necessarily consistent with the definitions in >> RFC 7262 (e.g., Endpoint)? Why not just rely on the definitions in that >> document for terms being re-used? I know there was a conclusion that strict >> alignment with the taxonomy doc was not necessary, but it seems like at >> least the CLUE docs should be internally consistent. >> >> = Section 7.1.1.10 = >> I think this section (and to some extent the one that follows) require a more >> thorough explanation to justify how it is that sending a lot of detailed >> information about the people involved in a telepresence session actually >> helps the endpoints decide how to arrange the media in the session. I >> understand that some (limited) information is useful for display purposes, >> but this section provides really broad leeway for endpoints to send a lot of >> information about individual participants without a thoroughgoing >> justification of how policies are built that act on such detailed information. [CNG] Just because xCard format is used it doesn't mean that an endpoint has to send data for every field vCard has defined. The usage of the xCard was chosen because it is a standard way of sending name, title, address information etc and is fairly commonly used. It's up to the endpoints to determine how much they send. We didn't want to mandate certain fields (other than the mandatory xCard) ones because that may limit innovative applications. Displaying information is certainly one possibility e.g. displaying the names of the people in each capture. Being able to view organisational information about people e.g. sales manager, CEO is also valuable beyond a name. Another application would being able to browse people's photos provided by xCard to associate people faces to names. Logging is another application - the endpoint logs the contact details of who was in the conference which makes it easy to send an email, im, voice call to a person. Capture selection a endpoint could select select to receive captures from certain people (e.g. your manager) or a location (e.g. head office). Communication information - my endpoint could tell me that the person in the capture has a preference to talk German based on their xCard information. In face to face meetings exchanging business cards is something that is done prior to meetings starting and enhances the interpersonal relationships. The intention is that using xCards facilitates a similar process for telepresense, i.e. a "being there experience". >> >> On the other hand, there are some data fields I would have expected to >> possibly be useful for these kinds of policies, like device type or room type or >> even device name, but it's not clear how endpoints are supposed to >> communicate those, if at all (stuff them into an xCard somewhow?). What is >> the story as far as those kinds of attributes go? [CNG] CLUE has been defined in a device agnostic manner by using scenes/captures etc. Rather than saying a device is a tablet, smart phone, laptop or dedicated room endpoint, scenes/captures and encodings describe the capabilities of the endpoints. A receiving endpoint then makes its decisions based on these capabilities. With respect to room type again CLUE is agnostic, the capture scene concept is used to describe the "room". The scene information attribute can provide a description. >> >> = Section 7.2.1.1 = >> Just because the syntax of the MaxCaptures definition theoretically allows >> for it to be set to <=1 does not mean that semantic should necessarily be >> allowed in the protocol. I don't understand the case where sending <=1 >> should be considered valid -- why have an MCC with zero captures in it? It >> seems like =1 and <=N where N>1 are the only valid values here. [CNG] The data model defines MaxCaptures as "xs:positiveInteger" which excludes zero. So an endpoint can't send "0" as a maxcaptures value. "<=1" is allowed because it allows an endpoint to either send a source capture (i.e. 1) or not (i.e. 0). Take the following example: | Capture Scene #1 | | +-----------------------|---------------------------------+ | VC1 | Description=Left | | VC2 | Description=Centre | | VC3 | Description=Right | | CSV(VC1,VC2,VC3) | | +=======================+=================================+ | Capture Scene #2 | | +-----------------------|---------------------------------+ | VC4 | Description=Left | | VC5 | Description=Right | | CSV(VC4,VC5) | | +=======================+=================================+ | Capture Scene #3 | | +-----------------------|---------------------------------+ | MCC1(VC1,VC4) | SynchronisationID=1 | | | MaxCaptures=1 | | MCC2(VC2,VC5) | SynchronisationID=1 | | | MaxCaptures=1 | | MCC3(VC3) | SynchronisationID=1 | | | MaxCaptures<=1 | MCC3 utilising MaxCaptures<=1 would allow VC3 not to be sent when capture related to Capture Scene #1 were sent. >> >> = Section 15 = >> "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." >> >> The specific documents need to be listed here, assuming RFC 4579 is not the >> only one to be mentioned. >> >> "Thus >> the security mechanisms recommended for SIP [RFC3261], including >> user authentication and authorization, SHOULD be followed." >> >> Given that implementations will need to be updated to support CLUE, what is >> the rationale for having user authentication and authorization be optional? >> What are the cases where allowing an unauthenticated or unauthorized >> participant to join a telepresence session would be considered acceptable? >> >> "In >> addition, the media is based on RTP and thus existing RTP security >> mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported. >> Media security is also discussed in [I-D.ietf-clue-signaling] and >> [I-D.ietf-clue-rtp-mapping]." >> >> I think it's worth pointing out in this document that DTLS/SRTP is required to >> use for CLUE-controlled m-lines. Also, I just did a quick skim of draft-ietf-clue- >> rtp-mapping and didn't see anything in there about media security. >> >> "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. 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." >> >> I don't think it's enough to point out that sensitive data can be sent back and >> forth with CLUE and that it shouldn't be used for authorization decisions. Is >> there some guidance that can be given about minimizing the amount and >> sensitivity of data to be sent? Are there certain xCard fields that endpoints >> should avoid sending? Some of this is obviously dependent on context and >> whether the participants in a conference know this information about each >> other already, but it's still worth mentioning how to mitigate the risks of >> sharing more data or more sensitive data than is necessary for the purposes >> of supporting a telepresence session. This might imply additional text in >> 7.1.1.10 as well. >> >> "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 no details about how the data channel is secured in draft-ietf-clue- >> datachannel (which should be cited here if it's going to be referenced). Nor >> are the details in draft-ietf-rtcweb-data-channel, but rather they are in draft- >> ietf-rtcweb-security-arch and draft-ietf-rtcweb-security. >> >> Furthermore, the details provided in draft-ietf-rtcweb-security-arch and >> draft-ietf-rtcweb-security explain the situation for rtcweb, where the >> endpoints rely on identity providers to authenticate each others' identities. >> IdPs are not specifically included in the CLUE architecture and, as noted >> above, the SIP authentication mechanisms are optional -- so how is it that the >> CLUE data channel is actually secured against an active MITM? >> >> >> Nits: >> There are a bunch of uses of normative MAY in this document that don't >> really fit the RFC 2119 usage of the term (i.e., are not actually protocol >> options). I've pointed them out below along with other nits. >> >> = Section 3 = >> "The spatial region represented by a Capture >> Scene MAY correspond to a real region in physical space, such as a >> room." >> >> I don't think normative language is necessary here. s/MAY/may/ >> >> s/[RFC4353] like Mixer/[RFC4353]-like Mixer/ >> >> = Section 4 = >> s/it should be stressed that its use in an implementation/it should be >> stressed that their use in an implementation/ >> >> = Section 5 = >> "Also, the Consumer >> MAY use the information provided to tailor the SDP it is going to >> send during any following SIP offer/answer exchange, and its >> reaction to SDP it receives in that step." >> >> I don't think normative language is necessary here. s/MAY/may/ >> >> "For example, if both sides decide to upgrade the call from a single screen to >> a >> multi-screen call and more bandwidth is required for the additional >> video channels compared to what was previously negotiated using >> offer/answer, a new O/A exchange is REQUIRED." >> >> I don't think normative language is necessary here since this is just an >> example. s/REQUIRED/required/ >> >> = Secton 7.1.1.4 = >> s/High dynamic/Highly dynamic/ >> >> = Section 7.1.1.11 = >> Not everyone considers "chairman" to be a gender-neutral term. You might >> want to consider "chair" and "vice-chair" instead. >> >> In general it's hard for me to believe that there is much of an interoperability >> gain from specifying titles in this level of detail, rather than just allowing >> advertisers to specify all of their own -- is there some compelling need to >> specify this set of values initially? >> >> = Section 7.1.1.12 = >> s/no assumptions regarding relative important/no assumptions regarding >> relative importance/ >> >> = Section 7.1.1.13 = >> s/the video Capture MAY contain speech to text information/the video >> Capture may contain speech to text information/ >> >> = Section 7.2.1.1 = >> s/MaxCaptures MAY be set to one/MaxCaptures may be set to one/ >> >> = Section 10 = >> s/Optimized implementations MAY speed up the reaction to the >> offer/answer exchange/Optimized implementations may speed up the >> reaction to the >> offer/answer exchange/ >> >> = Section 10.1 = >> s/if the Consumer is an MCU, it MAY choose to receive/if the Consumer is an >> MCU, it may choose to receive/ >> >> s/user choice (for instance, selection of a new layout) MAY result/user choice >> (for instance, selection of a new layout) may result >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From nobody Fri Jul 17 11:26:28 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 1F5541AD0C1 for ; Fri, 17 Jul 2015 11:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 mIBAPc-mbka8 for ; Fri, 17 Jul 2015 11:26:23 -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 6803A1AD0BB for ; Fri, 17 Jul 2015 11:26:23 -0700 (PDT) Received: from [216.82.254.20] by server-7.bemta-7.messagelabs.com id 2A/69-13540-FC849A55; Fri, 17 Jul 2015 18:26:23 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-13.tower-47.messagelabs.com!1437157582!17818480!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19917 invoked from network); 17 Jul 2015 18:26:22 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-13.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 17 Jul 2015 18:26:22 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.184]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 17 Jul 2015 11:26:21 -0700 From: "Duckworth, Mark" To: "'clue@ietf.org'" Date: Fri, 17 Jul 2015 11:26:20 -0700 Thread-Topic: Mark's WGLC comments on protocol-04 Thread-Index: AdDAuclvW+PQb8GDT0CYrIOXn4otlA== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F9BEA2A972B@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_5C4AC54BFF7A0842A6A11F554D6FB52F9BEA2A972BCRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Subject: [clue] Mark's WGLC comments on protocol-04 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: Fri, 17 Jul 2015 18:26:27 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F9BEA2A972BCRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I see no major issues, I just have these minor comments and questions. section 1 uses terms MP and MC which aren't defined, maybe should spell it = out here, and define abbreviations in section 2. section 2 - what's the difference between CLUE Participant and CLUE-capable= device? The sound the same to me. Can we just make CLUE Participant a sy= nonym for CLUE-capable device? Or describe better what the difference is? = Also should define abbreviation CP. section 4 - clueId - "the identifier of the CP" - this isn't clear to me. H= ow/where should this identifier be assigned? Can it be just any string? I= s this meant to be just a name for the CP, administratively assigned? "Each CP should manage up to three streams of sequence numbers" - Do we nee= d to define more rules for sequence numbers? such as: - do they always start at 0 or 1? - do they always increment by 1 for each successive message? - if sender is re-sending a message due to timeout or error, does = it use same sequence number or a new one? - any special rules for handling rollover of the 32 bit value? - there is mention of 401 Invalid Sequencing error code for "out o= f date" sequence number. How does the receiver detect this, taking rollove= r into account? - Is there any problem if the receiver detects a gap in sequence n= umbers? Seems to me this doesn't have to be treated as an error. page 11 typo "whithin" -> "within" section 4.3 para 2 - should also mention simultaneous sets in the list of e= lements. section 4.5 - ack within configureMessage - if it is included in the messag= e, does that imply a 200 Success response code always? I think the document= should say that. "The element SHOULD not be present at all if an ACK message has been = already sent back to the MP" - Can we make this MUST instead of SHOULD? section 4.7 response code table Is "reason string" and "response string" supposed to be the same thing? If= so, can we use "reason string" consistently, to match the reasonString ele= ment within Ack message? Section 5 - "Over such a channel there are typically two CLUE streams...". = I suggest change to "Over such a channel there are typically two CLUE prot= ocol streams..." to avoid confusion between media streams. Section 2 says = "stream" is a capture encoding, but that is not what we are talking about h= ere. Section 6 state machine - are the timeout values and retry count thresholds= defined anywhere, or is an implementer free to choose anything? section 7 - "Such a schema is the one included in the yet to come RFC" - it= is included in this document section 9 section 10 Examples - should this section be non-normative? Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F9BEA2A972BCRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I see no major issues, I just have these minor comme= nts and questions.

 

=

section 1 uses terms MP and MC which aren’t defi= ned, maybe should spell it out here, and define abbreviations in section 2.=

 

section 2 - what’s the difference between CLUE Participant and CLU= E-capable device?  The sound the same to me.  Can we just make CL= UE Participant a synonym for CLUE-capable device?  Or describe better = what the difference is? Also should define abbreviation CP.

<= p class=3DMsoNormal> 

section 4 - c= lueId - “the identifier of the CP” - this isn’t clear to = me. How/where should this identifier be assigned?  Can it be just any = string?  Is this meant to be just a name for the CP, administratively = assigned?

 

“Each CP should manage up to three streams of sequence n= umbers” - Do we need to define more rules for sequence numbers? = such as:

-   &nb= sp;      do they always st= art at 0 or 1?

-  &nbs= p;       do they alwa= ys increment by 1 for each successive message?

-          if sender is re-sending a message due to timeout or err= or, does it use same sequence number or a new one?

-         = ; any special rules for handling rollover of the 32= bit value?

-   &= nbsp;      there is mentio= n of 401 Invalid Sequencing error code for “out of date” sequen= ce number.  How does the receiver detect this, taking rollover into ac= count?

-    =       Is there any problem= if the receiver detects a gap in sequence numbers?  Seems to me this = doesn’t have to be treated as an error.

 

page 11 typo “whithin= ” -> “within”

=  

section 4.3 para 2 - should also menti= on simultaneous sets in the list of elements.

 

section 4.5 - ack within co= nfigureMessage - if it is included in the message, does that imply a 200 Su= ccess response code always? I think the document should say that.

 

“= The <ack> element SHOULD not be present at all if an ACK message has = been already sent back to the MP” - Can we make this MUST instead of = SHOULD?

 

section 4.7 response code table

Is “reason string” and “response string” supposed= to be the same thing?  If so, can we use “reason string” = consistently, to match the reasonString element within Ack message?

 

Secti= on 5 - “Over such a channel there are typically two CLUE streams...&#= 8221;.  I suggest change to “Over such a channel there are typic= ally two CLUE protocol streams...” to avoid confusion between media s= treams.  Section 2 says “stream” is a capture encoding, bu= t that is not what we are talking about here.

 

Section 6 state machine - a= re the timeout values and retry count thresholds defined anywhere, or is an= implementer free to choose anything?

 

section 7 - “Such a schema is= the one included in the yet to come RFC” - it is included in this do= cument section 9

 

section 10 Examples - should this section be non-normati= ve?

 

Mark

 

 

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F9BEA2A972BCRPMBOXPRD08p_-- From nobody Fri Jul 17 19:20:00 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 4C4F81A1BCB for ; Fri, 17 Jul 2015 19:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 6-EdOWgbMdbr for ; Fri, 17 Jul 2015 19:19:49 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456761A87EF for ; Fri, 17 Jul 2015 19:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36183; q=dns/txt; s=iport; t=1437185964; x=1438395564; h=from:to:subject:date:message-id:mime-version; bh=jDDDeQYNF/6/3OVhe11rudHzs/bnziCRpeNPQLuPCSE=; b=VfMwewx/1kaJ3f1VEcDbnRgBNRtfx/JcO/w/olnCL+b/8UpONG6LebM7 evCnpMQ1zW2Du+KK2kwGWWYLL000/2asnygScqBF9DrksqsaYYGaiHZKC /xSqW3mOfMevDrAteMuJhoKAwDK7oxJ5jeZpNluoZk2hB3/Ar3E5gagr6 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AcAwC+tqlV/4ENJK1QCoJGTVRvu1kJh2wCgUU4FAEBAQEBAQGBCoQlAQQaE14BKhYBPyYBBBsXiA+qC6VTAQEBAQEFAQEBAQEBHI9uAQYFBgEgg0+BFAWUTwGNYocpkBomY4EqHIFTgXMBBAQXBB+BBAEBAQ X-IronPort-AV: E=Sophos; i="5.15,498,1432598400"; d="scan'208,217"; a="12765354" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 18 Jul 2015 02:19:20 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6I2JLiu030454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 18 Jul 2015 02:19:21 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.17]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Fri, 17 Jul 2015 21:19:20 -0500 From: "Rob Hansen (rohanse2)" To: "clue@ietf.org" Thread-Topic: Rob's WGLC of the protocols draft Thread-Index: AdDBACSP1a4Gv+l5S2KHBgaAn06RLA== Date: Sat, 18 Jul 2015 02:19:20 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.72.81] Content-Type: multipart/alternative; boundary="_000_C6252EA94E00E44EADC3A2FEB59D4402046524D0xmbalnx07ciscoc_" MIME-Version: 1.0 Archived-At: Subject: [clue] Rob's WGLC of the protocols draft 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: Sat, 18 Jul 2015 02:19:59 -0000 --_000_C6252EA94E00E44EADC3A2FEB59D4402046524D0xmbalnx07ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Simon, Roberta, I've now reviewed the protocols document, and think the schemas and protoco= l look solid and workable; I have a couple of minor quibbles with the state= machines that are probably worth discussion that I'll highlight here: 1) We need a timeout for the 'Wait for ADV' state (see comments on pag= e 22); at present there's no way for an MC that doesn't receive an ACK to g= ive up. 2) Generally I don't see the utility of the retry count mechanism when= receiving NACKs for its ADV/CONF messages (see page 19). I don't see a re= ason to limit the sender from sending as many new ADV/CONFs that may be mor= e acceptable as they want, mandating it must be different from any that hav= e been NACKed since the last ACK, is a better way to do it. Since the error= codes generally mean the sender has done something invalid sending a new m= essage probably won't help and most implementations will move straight to t= he exit state on receiving a NACK. Those were my only issues of note with the protocol. However, I did have co= ncerns with the level of normative direction that's provided as part of the= document; I think it needs to be more rigorous throughout in defining what= a sender and receive should do when they receive or construct messages; re= ading it through it was obvious to me what everything was *meant* to do bas= ed on the names of the fields and concepts common with other protocols, but= RFCs are generally meant to be written so that a hypothetical robot with = no prior experience could read it and its references and go ahead and imple= ment a working system. I've called specific instances out below where I cou= ld identify areas I thought needed more rigor. Am happy to review it again = for new language or maybe even to go through myself and revise the document= with more normative language if you two didn't have the time or inclinatio= n. The remaining issues are minor schema niggles, spelling or grammar notes an= d a note that an overall security section is probably required. Specific is= sues are listed at the end of the email. As per not attending the previous IETF my role at work has transitioned to = the point where I'm much less involved with the design of new standards so = I'm also not attending the current IETF in person and won't be in the futur= e until and unless my role shifts again. I'll be attending the CLUE session= virtually, though, and I'm still committed to finishing the CLUE work (As = soon as the WGLC for the protocol document finishes and the initial discuss= ions shake out I'll be updating the signalling document ready for WGLC). Ha= ve fun in Prague, all; I enjoyed all the IETFs attended and will definitely= miss them! Rob Specific issues: Page 3: "enabling a MP" - should be "enabling an MP" "enabling a MC" - should be "enabling an MC" "protocol messages are detailed in Section 4 The CLUE Participant" - should= have a full stop afer '4' MP and MC are used without bhaving been previously defined Page 4: List of endpoint types is almost but not quite alphabetically ordered. "a synonymous of Capture Encoding." - should be "a synonym of Capture Encod= ing." "flow on a realiable and ordered" - should be "flow on a reliable and order= ed" Page 5: "the CPs are able" - "CP" is used without having been defined "A mechanism for the negotiation of the CLUE protocol version and extension= s is envisioned in the initiation phase" - such a mechanism has been define= d elsewhere in the document; I don't think 'envisioned' is the right word; = "is part of the initial phase", maybe? "Indeed, being CPs A and B both transmitting and receiving, it is possible = to distinguish between two dialogues:" - I find this sentence difficult to = parse. This is also the first reference to A and B, so they require introdu= ction. Something like "In many cases CPs will seek to both transmit and rec= eive media. Hence in a call between two CPs, A and B, there would be two se= perate dialogs, as follows:" Page 7: "sequenceNr" - I cannot find where in the document the rules for using the = sequence number are made explicit (eg, the sender must increment the sequen= ce numbers by one for each new message sent, the receiver must remember the= most recent sequence number received and send a 401 error if it receives a= message with an unexpected sequence number, etc). I think "sequenceNr" should be of type positiveInteger, not unsignedInt; it= 's not a hard requirement, but generally sequence numbers must be non-zero = in most protocols and I think we should stick to the convention. "clueId" - Similarly, I cannot find any rules for constructing the clueId o= r what should be done with it. "Each CP should manage up to three streams of sequence numbers: (i) one for= the messages exchanged in the initiation phase, (ii) one for the messages = exchanged as MP, and (iii) one for the messages exchanged as MC." - this is= the only guidance currently on using the sequence numbers; when more detai= ls are provided this should be moved there. The fact that these sequence nu= mber streams are independent is important and quite easy for an implementat= ion to get wrong, so it should probably be repeated in the sections on send= ing the OPTIONS, ADV and CONF messages where these independent streams are = used. Page 10: "Only one element SHOULD be provided for each major version suppo= rted" - is there a reason to not make this a MUST? At present there's no explicit normative language mandating including key e= lements for non-error cases. I think this must be stated normatively, somet= hing like "If the responseCode is of the type 2xx the response MUST include= , , and elements;= it MAY include them for any other response code.". The sentence ""These tw= o elements are optional in the OPTIONS RESPONSE since, in case of error res= ponse code, the CR might not want to add further information besides the re= sponse code and the reason string." then becomes unnecesary. Whether the OPTIONS handling behaviour is defined (here on in the state mac= hine) the sections on versioning and extensions should be referenced. Page 11: "During the telepresence session, the ADV can be sent from the MP both peri= odically and on a per-event basis, i.e., each time there are changes in the= MP's CLUE telepresence capabilities." - This seems slightly unclear to me = at present; something like "During a single CLUE session, an MP may send ne= w ADV messages to replace the previously advertised options, if, for instan= ce, its media CLUE telepresence capabilities change mid-call." Either here, in the MC state machine, or both, we need to make clear that a= new ADV completely invalidates the previous ADV. Page 13: "The element SHOULD not be present at all if an ACK message has been = already sent back to the MP." - I can't see a reason not to make this a MUS= T. The words "at all" are also probably unnecessary. "a piggibacking mechanism" - this should be "a piggybacking mechanism" Page 15: "Response codes beginning with "1" could be associated to temporary respons= es." - we don't have any 1xx codes yet; I think until we do this should eit= her be removed or be made more definitive: "will be", not "could be" (thoug= h I'd phrase it "represent a delayed or incomplete response"). Page 16: "a DTLS/SCTP channel established as depicted in [I-D.ietf-clue-signaling]" = - draft-ietf-clue-datachannel, not draft-ietf-clue-signaling "Over such a channel there are typically two CLUE streams between the chann= el terminations flowing in opposite directions. In other words, typically,= both channel terminations act simultaneously as a MP and as a MC." - I'd m= ove this to after "and with the MP process.", and rephrase it as something = like "Endpoints often wish to both send a receiver media, ie, act as both M= P and MC. As such there will often be two sets of messages flowing in oppos= ite directions; the state machines of these two flows do not interact with = each other." "When in the OPTIONS state..." - this paragraph describes the flow of the o= ptions state well, but I think we need two small explicit state machines dr= awn out for it. "The initiation phase might fail because of one of the following reasons...= " - This list doesn't include failing because of a major version mismatch. = Generally I think this part needs to be made more normative: the behaviour = of the OPTIONS receivers should be defined with success and error cases for= both the OPTIONS sender and receiver. This should also reference the rules= for constructing the version numbers in the OPTIONS RESPONSE section as a reminder, or else the definition should be moved here. Page 17: Similarly, the rules on acting as an MP/MC based on the OPTIONS negotiation= should be made explicit (eg, only if A has advertised as MP and B has resp= onded as MC) Page 19: Defaults/guidance on timeout and retry thresholds are required " if a CONF+ACK message arrives" - CONF+ACK should be defined here as a CON= FIGURE message with the element set to TRUE. "CONF+ACK messages referring to out-of-date ADVs MUST be ignored" - one of = the sections that needs to have more rigerous sequence number language - "o= ut of date" must be defined as having a sequence number equal to or less th= an the highest seen so far. "the number of NACKs for the issued ADV is under the retry threshold ("NACK= received && retry not expired"), the MP moves back to the ADV state for pr= eparing a new ADV" - I'm not sure the retry threshold concept refelcts how = implementations can successfully overcome NACKS. I think we may do better w= ith a concept like "the MP MAY return to the ADV state and send a new ADV (= with an incremented sequence number) that it judges may be more acceptable = to the MC. The MP MUST NOT return to the ADV state if it will send an ADVER= TISEMENT with values (excepting the sequence number) identical to one that = has received a NACK response subsequent to the most recent ACK received. If= the MP does not have a new ADVERTISEMENT candidate that may be more accept= able it MUST move to the MP TERMINATED state." "If the MP is fine with the MC's configuration" - "is fine with" should be = something like "successfully processes". I would also remove the retry threshold on the Conf processing section and = just wait to die based on the timeout or the far end giving up. Explicit behaviour needs to be defined for what actually happens when the E= stablished or MP TERMINATED states are reached (reference the signaling doc= for the former and the data channel doc for the latter). Page 22: "Wait for ADV" does not have a timeout and currently has no way to reach th= e MC TERMINATED state except by receiving the requisite number of bad ADVs;= there needs to be a defined way for the MC to give up if the far end never= sends it an ADV. We currently have two paths once an ADV is received; either send an ACK, mo= ve to the CONF state and later send a CONF or send a CONF+ACK. If we feel w= e need both then we need to provide guidance as to which to do; the only re= ason I can see to keep both is something like "If the MC can send a CONF+AC= K immediately it MAY do so
. If= it cannot send the CONF+ACK immediately it MUST immediately send an ACK an= d move to the CONF state
." We = should also be explicit about the CONF/CONF+ACK messages: a CONF+ACK MUST h= ave the element set to true, while a CONF message MUST NOT have the <= ack> element set to true. Again, would suggest removing the the "retry expired" concept and mandate t= hat MCs must only send a new CONF if they can change to be more likely to b= e accepted and have a timeout. Again, need explicit guidance on what actually happens when the Established= or MC TERMINATED states are reached. Page 23: "error CONF RESPONSE received && retry not expired, timeout && retry not ex= pired" - "retry not expired" is specified twice here "timeout && retry expired" - "retry expired" is covered under "error CONF R= ESPONSE received && retry expired", this should just be timeout. Page 24: "CLUE protocol messages are XML messages compliant to the CLUE protocol XML= schema" - may be worth referencing the data model document again here. "Such a schema is the one included in the yet to come RFC" - this is no lon= ger true, and should be covered by the reference above. "The version of the XML schema contained in the standard document deriving = from this draft will be 1.0" - again, this is covered by the data model doc= and no longer needed here. Do we still need the section on pre-standardisation interop? Page 26: Somewhere we need normative language on how two endpoints actually negotiat= e and use an extension. Pages 31-43 I have not gone through and reviewed the examples against the schemas; if t= hese examples were auto-generated from up-to-date versions of the schemas t= hen there should be no need. On the other hand if they were written by hand= then let me know and I'll go through and review them. The document seems to be missing an overall Security Considerations section= , which I believe is mandatory. --_000_C6252EA94E00E44EADC3A2FEB59D4402046524D0xmbalnx07ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all, Simon, Roberta,

 

I’ve now reviewed the protocols document, and = think the schemas and protocol look solid and workable; I have a couple of = minor quibbles with the state machines that are probably worth discussion t= hat I’ll highlight here:

1)      We need a timeout for the ‘Wait for ADV’= ; state (see comments on page 22); at present there’s no way for an M= C that doesn’t receive an ACK to give up.

2)      Generally I don’t see the utility of the retr= y count mechanism when receiving NACKs for its ADV/CONF  messages (see= page 19). I don’t see a reason to limit the sender from sending as m= any new ADV/CONFs that may be more acceptable as they want, mandating it must be different from any that have been NACKed s= ince the last ACK, is a better way to do it. Since the error codes generall= y mean the sender has done something invalid sending a new message probably= won’t help and most implementations will move straight to the exit state on receiving a NACK.

 

Those were my only issues of note with the protocol.= However, I did have concerns with the level of normative direction that= 217;s provided as part of the document; I think it needs to be more rigorou= s throughout in defining what a sender and receive should do when they receive or construct messages; reading it thro= ugh it was obvious to me what everything was *meant* to do based on = the names of the fields and concepts common with other protocols, but RFCs = are generally meant to be written so that a  hypothetical robot with no prior experience could read it = and its references and go ahead and implement a working system. I’ve = called specific instances out below where I could identify areas I thought = needed more rigor. Am happy to review it again for new language or maybe even to go through myself and revise the documen= t with more normative language if you two didn’t have the time or inc= lination.

 

The remaining issues are minor schema niggles, spell= ing or grammar notes and a note that an overall security section is probabl= y required. Specific issues are listed at the end of the email.<= /p>

 

As per not attending the previous IETF my role at wo= rk has transitioned to the point where I’m much less involved with th= e design of new standards so I’m also not attending the current IETF = in person and won’t be in the future until and unless my role shifts again. I’ll be attending the CLUE session virt= ually, though, and I’m still committed to finishing the CLUE work (As= soon as the WGLC for the protocol document finishes and the initial discus= sions shake out I’ll be updating the signalling document ready for WGLC). Have fun in Prague, all; I enjoyed all the IETFs= attended and will definitely miss them!

 

Rob

 

Specific issues:

 

Page 3:

"enabling a MP" - should be "enabling= an MP"

"enabling a MC" - should be "enabling= an MC"

"protocol messages are detailed in Section 4 Th= e CLUE Participant" - should have a full stop afer '4'

MP and MC are used without bhaving been previously d= efined

 

Page 4:

List of endpoint types is almost but not quite alpha= betically ordered.

"a synonymous of Capture Encoding." - shou= ld be "a synonym of Capture Encoding."

"flow on a realiable and ordered" - should= be "flow on a reliable and ordered"

 

Page 5:

"the CPs are able" - "CP" is use= d without having been defined

"A mechanism for the negotiation of the CLUE pr= otocol version and extensions is envisioned in the initiation phase" -= such a mechanism has been defined elsewhere in the document; I don't think= 'envisioned' is the right word; "is part of the initial phase", maybe?

"Indeed, being CPs A and B both transmitting an= d receiving, it is possible to distinguish between two dialogues:" - I= find this sentence difficult to parse. This is also the first reference to= A and B, so they require introduction. Something like "In many cases CPs will seek to both transmit and receive media.= Hence in a call between two CPs, A and B, there would be two seperate dial= ogs, as follows:"

 

Page 7:

"sequenceNr" - I cannot find where in the = document the rules for using the sequence number are made explicit (eg, the= sender must increment the sequence numbers by one for each new message sen= t, the receiver must remember the most recent sequence number received and send a 401 error if it receives a message wit= h an unexpected sequence number, etc).

I think "sequenceNr" should be of type pos= itiveInteger, not unsignedInt; it's not a hard requirement, but generally s= equence numbers must be non-zero in most protocols and I think we should st= ick to the convention.

"clueId" - Similarly, I cannot find any ru= les for constructing the clueId or what should be done with it.<= /p>

"Each CP should manage up to three streams of s= equence numbers: (i) one for the messages exchanged in the initiation phase= , (ii) one for the messages exchanged as MP, and (iii) one for the messages= exchanged as MC." - this is the only guidance currently on using the sequence numbers; when more details are provided th= is should be moved there. The fact that these sequence number streams are i= ndependent is important and quite easy for an implementation to get wrong, = so it should probably be repeated in the sections on sending the OPTIONS, ADV and CONF messages where these = independent streams are used.

 

Page 10:

"Only one <version> element SHOULD be pro= vided for each major version supported" - is there a reason to not mak= e this a MUST?

At present there's no explicit normative language ma= ndating including key elements for non-error cases. I think this must be st= ated normatively, something like "If the responseCode is of the type 2= xx the response MUST include <mediaProvider>,  <mediaConsumer>, <version> and <commonOptions> elements;= it MAY include them for any other response code.". The sentence "= ;"These two elements are optional in the OPTIONS RESPONSE since, in ca= se of error response code, the CR might not want to add further information besides the response code and the reason string." then becomes unnece= sary.

Whether the OPTIONS handling behaviour is defined (h= ere on in the state machine) the sections on versioning and extensions shou= ld be referenced.

 

Page 11:

"During the telepresence session, the ADV can b= e sent from the MP both periodically and on a per-event basis, i.e., each t= ime there are changes in the MP's CLUE telepresence capabilities." - T= his seems slightly unclear to me at present; something like "During a single CLUE session, an MP may send new ADV = messages to replace the previously advertised options, if, for instance, it= s media CLUE telepresence capabilities change mid-call."

Either here, in the MC state machine, or both, we ne= ed to make clear that a new ADV completely invalidates the previous ADV.

 

Page 13:

"The <ack> element SHOULD not be present = at all if an ACK message has been already sent back to the MP." - I ca= n't see a reason not to make this a MUST. The words "at all" are = also probably unnecessary.

"a piggibacking mechanism" - this should b= e "a piggybacking mechanism"

 

Page 15:

"Response codes beginning with "1" co= uld be associated to temporary responses." - we don't have any 1xx cod= es yet; I think until we do this should either be removed or be made more d= efinitive: "will be", not "could be" (though I'd phrase it "represent a delayed or incomplete response").

 

Page 16:

"a DTLS/SCTP channel established as depicted in= [I-D.ietf-clue-signaling]" - draft-ietf-clue-datachannel, not draft-i= etf-clue-signaling

"Over such a channel there are typically two CL= UE streams between the channel terminations flowing in opposite directions.=   In other words, typically, both channel terminations act simultaneou= sly as a MP and as a MC." - I'd move this to after "and with the MP process.", and rephrase it as something l= ike "Endpoints often wish to both send a receiver media, ie, act as bo= th MP and MC. As such there will often be two sets of messages flowing in o= pposite directions; the state machines of these two flows do not interact with each other."

"When in the OPTIONS state..." - this para= graph describes the flow of the options state well, but I think we need two= small explicit state machines drawn out for it.

"The initiation phase might fail because of one= of the following reasons..." - This list doesn't include failing beca= use of a major version mismatch. Generally I think this part needs to be ma= de more normative: the behaviour of the OPTIONS receivers should be defined with success and error cases for both the OPTI= ONS sender and receiver. This should also reference the rules for construct= ing the version numbers in the OPTIONS RESPONSE section

as a reminder, or else the definition should be move= d here.

 

Page 17:

Similarly, the rules on acting as an MP/MC based on = the OPTIONS negotiation should be made explicit (eg, only if A has advertis= ed as MP and B has responded as MC)

 

Page 19:

Defaults/guidance on timeout and retry thresholds ar= e required

" if a CONF+ACK message arrives" - CON= F+ACK should be defined here as a CONFIGURE message with the <ack>= ; element set to TRUE.

"CONF+ACK messages referring to out-of-date= ADVs MUST be ignored" - one of the sections that needs to have more r= igerous sequence number language - "out of date" must be defined = as having a sequence number equal to or less than the highest seen so far.

"the number of NACKs for the issued ADV is unde= r the retry threshold ("NACK received && retry not expired&quo= t;), the MP moves back to the ADV state for preparing a new ADV" - I'm= not sure the retry threshold concept refelcts how implementations can successfully overcome NACKS. I think we may do better with a concept l= ike "the MP MAY return to the ADV state and send a new ADV (with an in= cremented sequence number) that it judges may be more acceptable to the MC.= The MP MUST NOT return to the ADV state if it will send an ADVERTISEMENT with values (excepting the sequence numbe= r) identical to one that has received a NACK response subsequent to the mos= t recent ACK received. If the MP does not have a new ADVERTISEMENT candidat= e that may be more acceptable it MUST move to the MP TERMINATED state."

"If the MP is fine with the MC's configuration&= quot; - "is fine with" should be something like "successfull= y processes".

I would also remove the retry threshold on the Conf = processing section and just wait to die based on the timeout or the far end= giving up.

Explicit behaviour needs to be defined for what actu= ally happens when the Established or MP TERMINATED states are reached (refe= rence the signaling doc for the former and the data channel doc for the lat= ter).

 

Page 22:

"Wait for ADV" does not have a timeout and= currently has no way to reach the MC TERMINATED state except by receiving = the requisite number of bad ADVs; there needs to be a defined way for the M= C to give up if the far end never sends it an ADV.

We currently have two paths once an ADV is received;= either send an ACK, move to the CONF state and later send a CONF or send a= CONF+ACK. If we feel we need both then we need to provide guidance as = to which to do; the only reason I can see to keep both is something like "If the MC can send a CONF+ACK= immediately it MAY do so <details here of how in state machine terms>= ;. If it cannot send the CONF+ACK immediately it MUST immediately send = an ACK and move to the CONF state <details here of how in state machine terms>." We should also be explicit about the= CONF/CONF+ACK messages: a CONF+ACK MUST have the <ack> eleme= nt set to true, while a CONF message MUST NOT have the <ack> element = set to true.

Again, would suggest removing the the "retry ex= pired" concept and mandate that MCs must only send a new CONF if they = can change to be more likely to be accepted and have a timeout.<= /p>

Again, need explicit guidance on what actually happe= ns when the Established or MC TERMINATED states are reached.

 

Page 23:

"error CONF RESPONSE received && retry = not expired, timeout && retry not expired" - "retry not e= xpired" is specified twice here

"timeout && retry expired" - "= ;retry expired" is covered under "error CONF RESPONSE received &a= mp;& retry expired", this should just be timeout.

 

Page 24:

"CLUE protocol messages are XML messages compli= ant to the CLUE protocol XML schema" - may be worth referencing the da= ta model document again here.

"Such a schema is the one included in the yet t= o come RFC" - this is no longer true, and should be covered by the ref= erence above.

"The version of the XML schema contained in the= standard document deriving from this draft will be 1.0" - again, this= is covered by the data model doc and no longer needed here.

Do we still need the section on pre-standardisation = interop?

 

Page 26:

Somewhere we need normative language on how two endp= oints actually negotiate and use an extension.

 

Pages 31-43

I have not gone through and reviewed the examples ag= ainst the schemas; if these examples were auto-generated from up-to-date ve= rsions of the schemas then there should be no need. On the other hand if th= ey were written by hand then let me know and I'll go through and review them.

 

The document seems to be missing an overall Security= Considerations section, which I believe is mandatory.

 

--_000_C6252EA94E00E44EADC3A2FEB59D4402046524D0xmbalnx07ciscoc_-- From nobody Sat Jul 18 07:15: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 CD49D1B2CE1 for ; Sat, 18 Jul 2015 07:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCiaHdnYxjLj for ; Sat, 18 Jul 2015 07:15:53 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 4F7471B2CDB for ; Sat, 18 Jul 2015 07:15:53 -0700 (PDT) Received: by widjy10 with SMTP id jy10so60943162wid.1 for ; Sat, 18 Jul 2015 07:15:52 -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=OcGgtV2OulenksURfjvWmHSTgyV+LACGC/ehzzZwPaw=; b=s6f0qoUdHuNKWtdnMZRO2HJ9dC51x04ljb9gaEQITDAvXgdueUhEX6oytMVhtKaHuk 4lLtnPhNuAyyjPWzSDTIZ84JDiL2kgWXGh+XbRCE3adt/HTzSCOpMQpANfelG9ezub9m Jc752o3Kwg+Btd7Uhyd+dbFgHITImyMExf/Vy3nWprLjwWuyxrnMLX4TqCIUcifMi8tn pZ80Hw3QdpvGy7foMiFGrVDSx8tSt7+Vw6biqRN6V3xQ3W+PJrUCtZ1I/GgoyolkQxR9 loCVMPHq3DVne+9YC8Ux0L2RC4+Gvh/7LmHM+p1/MSgHb5K0SwKdr08DRuBlT+Of36wM HOJA== X-Received: by 10.180.76.232 with SMTP id n8mr5275306wiw.72.1437228952104; Sat, 18 Jul 2015 07:15:52 -0700 (PDT) Received: from RoniPC ([62.168.35.66]) by smtp.gmail.com with ESMTPSA id dz4sm2717091wib.17.2015.07.18.07.15.48 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 18 Jul 2015 07:15:51 -0700 (PDT) From: "Roni Even" To: Date: Sat, 18 Jul 2015 17:15:39 +0300 Message-ID: <000801d0c164$3efc5900$bcf50b00$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01D0C17D.6449B810" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDBYRqJlM7gZxY0QkeiX6N8X3Wz+A== Content-Language: he Archived-At: Subject: [clue] presentations for CLUE session 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: Sat, 18 Jul 2015 14:15:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0009_01D0C17D.6449B810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Please send the chairs the presentations for the CLUE session by Sunday night Thanks Roni Even ------=_NextPart_000_0009_01D0C17D.6449B810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Please send the = chairs the presentations for the CLUE session by Sunday = night

Thanks

Roni Even

------=_NextPart_000_0009_01D0C17D.6449B810-- From nobody Sun Jul 19 01:53:27 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 211C31A8958 for ; Sun, 19 Jul 2015 01:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhJMsQS0hMCX for ; Sun, 19 Jul 2015 01:53:22 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::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 940B21A8A4A for ; Sun, 19 Jul 2015 01:53:21 -0700 (PDT) Received: by lahh5 with SMTP id h5so81634432lah.2 for ; Sun, 19 Jul 2015 01:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LnNkbHVjQs9d3bb6/zO95w8fVwrbyJupcqLdd3HBOCo=; b=jRPqgHTSitIEOjA5NMJ4hl/Lak0hSkjiCx6+v9QoyyxMPPtTgmrGM01CeMZYJzHX+4 rMtOwQXBnip7gBOlP1BFe66IEXPD0D1l+7FEoPi6pop8AEQ0IpmmFHswFu5t/XGLgX/L UZzchRtdFysFAqftcdQ4zUoaGP53Ly+Cpp9zuDvnb96GTMobCU05vU25nVeu2U6fZo9h T8OeJya5nHjlEbxJwabVCaCxlLC5MExezZ7aaFifbiiPw4AjGfkjsE17ojzgM5RVi1Ef tkCk9P0elPucUxz3j3g5SYzsD5jR9LLNQsogG9Mxf0PAQqLbaX8ghPSpDfAWziR7tme2 WWLQ== MIME-Version: 1.0 X-Received: by 10.112.142.232 with SMTP id rz8mr21752513lbb.74.1437295999931; Sun, 19 Jul 2015 01:53:19 -0700 (PDT) Received: by 10.112.118.99 with HTTP; Sun, 19 Jul 2015 01:53:19 -0700 (PDT) In-Reply-To: References: Date: Sun, 19 Jul 2015 11:53:19 +0300 Message-ID: From: Ron Even To: Alissa Cooper Content-Type: multipart/alternative; boundary=089e0112cdfe835cb5051b368d3c Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] AD evaluation: draft-ietf-clue-framework-22 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: Sun, 19 Jul 2015 08:53:26 -0000 --089e0112cdfe835cb5051b368d3c Content-Type: text/plain; charset=UTF-8 Hi Alissa, See inline Roni On Fri, Jul 3, 2015 at 9:28 PM, Alissa Cooper wrote: > I have reviewed this document in preparation for IETF LC and I have some > comments and questions I'd like to see resolved before issuing the last > call. I've also listed some nits further below that should be resolved in > the next revision of the document. > > Overall, the amount of complexity that this framework supports in terms of > the number of configuration choices that can be provided and consumed is > daunting. I know the WG is already well down the path towards finishing > this off so I'm not suggesting changes in this regard, but I do think folks > should be prepared for questions about the trade-off between flexibility > and implementability that may arise during IETF LC or IESG evaluation. > > Substantive comments and questions: > > = Section 3 = > Why are these definitions not necessarily consistent with the definitions > in RFC 7262 (e.g., Endpoint)? Why not just rely on the definitions in that > document for terms being re-used? I know there was a conclusion that strict > alignment with the taxonomy doc was not necessary, but it seems like at > least the CLUE docs should be internally consistent. > RE: We had a definition document https://www.ietf.org/archive/id/draft-wenger-clue-definitions-02.txt that tried to capture the terminology for telepresence systems, we decided that it should not be a separte document and moved the content to the framework, the other documents should be consistent with it > > = Section 7.1.1.10 = > I think this section (and to some extent the one that follows) require a > more thorough explanation to justify how it is that sending a lot of > detailed information about the people involved in a telepresence session > actually helps the endpoints decide how to arrange the media in the > session. I understand that some (limited) information is useful for display > purposes, but this section provides really broad leeway for endpoints to > send a lot of information about individual participants without a > thoroughgoing justification of how policies are built that act on such > detailed information. > RE: By Christian > > On the other hand, there are some data fields I would have expected to > possibly be useful for these kinds of policies, like device type or room > type or even device name, but it's not clear how endpoints are supposed to > communicate those, if at all (stuff them into an xCard somewhow?). What is > the story as far as those kinds of attributes go? > > = Section 7.2.1.1 = > Just because the syntax of the MaxCaptures definition theoretically allows > for it to be set to <=1 does not mean that semantic should necessarily be > allowed in the protocol. I don't understand the case where sending <=1 > should be considered valid -- why have an MCC with zero captures in it? It > seems like =1 and <=N where N>1 are the only valid values here. > RE: By Christian > > = Section 15 = > RE: wii respond later > "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." > > The specific documents need to be listed here, assuming RFC 4579 is not > the only one to be mentioned. > > "Thus > the security mechanisms recommended for SIP [RFC3261], including > user authentication and authorization, SHOULD be followed." > > Given that implementations will need to be updated to support CLUE, what > is the rationale for having user authentication and authorization be > optional? What are the cases where allowing an unauthenticated or > unauthorized participant to join a telepresence session would be considered > acceptable? > > "In > addition, the media is based on RTP and thus existing RTP security > mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported. > Media security is also discussed in [I-D.ietf-clue-signaling] and > [I-D.ietf-clue-rtp-mapping]." > > I think it's worth pointing out in this document that DTLS/SRTP is > required to use for CLUE-controlled m-lines. Also, I just did a quick skim > of draft-ietf-clue-rtp-mapping and didn't see anything in there about media > security. > > "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. 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." > > I don't think it's enough to point out that sensitive data can be sent > back and forth with CLUE and that it shouldn't be used for authorization > decisions. Is there some guidance that can be given about minimizing the > amount and sensitivity of data to be sent? Are there certain xCard fields > that endpoints should avoid sending? Some of this is obviously dependent on > context and whether the participants in a conference know this information > about each other already, but it's still worth mentioning how to mitigate > the risks of sharing more data or more sensitive data than is necessary for > the purposes of supporting a telepresence session. This might imply > additional text in 7.1.1.10 as well. > > "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 no details about how the data channel is secured in > draft-ietf-clue-datachannel (which should be cited here if it's going to be > referenced). Nor are the details in draft-ietf-rtcweb-data-channel, but > rather they are in draft-ietf-rtcweb-security-arch and > draft-ietf-rtcweb-security. > > Furthermore, the details provided in draft-ietf-rtcweb-security-arch and > draft-ietf-rtcweb-security explain the situation for rtcweb, where the > endpoints rely on identity providers to authenticate each others' > identities. IdPs are not specifically included in the CLUE architecture > and, as noted above, the SIP authentication mechanisms are optional -- so > how is it that the CLUE data channel is actually secured against an active > MITM? > > > Nits: > There are a bunch of uses of normative MAY in this document that don't > really fit the RFC 2119 usage of the term (i.e., are not actually protocol > options). I've pointed them out below along with other nits. > > = Section 3 = > "The spatial region represented by a Capture > Scene MAY correspond to a real region in physical space, such as a > room." > > I don't think normative language is necessary here. s/MAY/may/ > > s/[RFC4353] like Mixer/[RFC4353]-like Mixer/ > > = Section 4 = > s/it should be stressed that its use in an implementation/it should be > stressed that their use in an implementation/ > > = Section 5 = > "Also, the Consumer > MAY use the information provided to tailor the SDP it is going to > send during any following SIP offer/answer exchange, and its > reaction to SDP it receives in that step." > > I don't think normative language is necessary here. s/MAY/may/ > > "For example, if both sides decide to upgrade the call from a single > screen to a > multi-screen call and more bandwidth is required for the additional > video channels compared to what was previously negotiated using > offer/answer, a new O/A exchange is REQUIRED." > > I don't think normative language is necessary here since this is just an > example. s/REQUIRED/required/ > > = Secton 7.1.1.4 = > s/High dynamic/Highly dynamic/ > > = Section 7.1.1.11 = > Not everyone considers "chairman" to be a gender-neutral term. You might > want to consider "chair" and "vice-chair" instead. > > In general it's hard for me to believe that there is much of an > interoperability gain from specifying titles in this level of detail, > rather than just allowing advertisers to specify all of their own -- is > there some compelling need to specify this set of values initially? > > = Section 7.1.1.12 = > s/no assumptions regarding relative important/no assumptions regarding > relative importance/ > > = Section 7.1.1.13 = > s/the video Capture MAY contain speech to text information/the video > Capture may contain speech to text information/ > > = Section 7.2.1.1 = > s/MaxCaptures MAY be set to one/MaxCaptures may be set to one/ > > = Section 10 = > s/Optimized implementations MAY speed up the reaction to the > offer/answer exchange/Optimized implementations may speed up the > reaction to the > offer/answer exchange/ > > = Section 10.1 = > s/if the Consumer is an MCU, it MAY choose to receive/if the Consumer is > an MCU, it may choose to receive/ > > s/user choice (for instance, selection of a new layout) MAY result/user > choice (for instance, selection of a new layout) may result > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --089e0112cdfe835cb5051b368d3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alissa,
See inline
Roni
<= div class=3D"gmail_extra">
On Fri, Jul 3, 201= 5 at 9:28 PM, Alissa Cooper <alissa@cooperw.in> wrote:
I have reviewed this document in preparation for IETF LC and= I have some comments and questions I'd like to see resolved before iss= uing the last call. I've also listed some nits further below that shoul= d be resolved in the next revision of the document.

Overall, the amount of complexity that this framework supports in terms of = the number of configuration choices that can be provided and consumed is da= unting. I know the WG is already well down the path towards finishing this = off so I'm not suggesting changes in this regard, but I do think folks = should be prepared for questions about the trade-off between flexibility an= d implementability that may arise during IETF LC or IESG evaluation.

Substantive comments and questions:

=3D Section 3 =3D
Why are these definitions not necessarily consistent with the definitions i= n RFC 7262 (e.g., Endpoint)? Why not just rely on the definitions in that d= ocument for terms being re-used? I know there was a conclusion that strict = alignment with the taxonomy doc was not necessary, but it seems like at lea= st the CLUE docs should be internally consistent.

=
RE: We had a=C2=A0definition document https://www.ietf.org= /archive/id/draft-wenger-clue-definitions-02.txt that tried to capture = the terminology for telepresence systems, we decided that it should not be = a separte document and moved the content to the framework,=C2=A0the other d= ocuments should be consistent with it
=C2=A0

=3D Section 7.1.1.10 =3D
I think this section (and to some extent the one that follows) require a mo= re thorough explanation to justify how it is that sending a lot of detailed= information about the people involved in a telepresence session actually h= elps the endpoints decide how to arrange the media in the session. I unders= tand that some (limited) information is useful for display purposes, but th= is section provides really broad leeway for endpoints to send a lot of info= rmation about individual participants without a thoroughgoing justification= of how policies are built that act on such detailed information.

RE: =C2=A0By Christian

On the other hand, there are some data fields I would have expected to poss= ibly be useful for these kinds of policies, like device type or room type o= r even device name, but it's not clear how endpoints are supposed to co= mmunicate those, if at all (stuff them into an xCard somewhow?). What is th= e story as far as those kinds of attributes go?

=3D Section 7.2.1.1 =3D
Just because the syntax of the MaxCaptures definition theoretically allows = for it to be set to <=3D1 does not mean that semantic should necessarily= be allowed in the protocol. I don't understand the case where sending = <=3D1 should be considered valid -- why have an MCC with zero captures i= n it? It seems like =3D1 and <=3DN where N>1 are the only valid value= s here.
RE: By Christian

=3D Section 15 =3D
RE: wii respond later=C2=A0
"Thus, it is RECOMMENDED that an MCU
=C2=A0 =C2=A0implementing the protocols necessary to support CLUE, follow t= he
=C2=A0 =C2=A0security recommendations specified in the conference control =C2=A0 =C2=A0protocol documents."

The specific documents need to be listed here, assuming RFC 4579 is not the= only one to be mentioned.

"Thus
=C2=A0 =C2=A0the security mechanisms recommended for SIP [RFC3261], includi= ng
=C2=A0 =C2=A0user authentication and authorization, SHOULD be followed.&quo= t;

Given that implementations will need to be updated to support CLUE, what is= the rationale for having user authentication and authorization be optional= ? What are the cases where allowing an unauthenticated or unauthorized part= icipant to join a telepresence session would be considered acceptable?

"In
=C2=A0 =C2=A0addition, the media is based on RTP and thus existing RTP secu= rity
=C2=A0 =C2=A0mechanisms SHOULD be supported, and DTLS/SRTP MUST be supporte= d.
=C2=A0 =C2=A0Media security is also discussed in [I-D.ietf-clue-signaling] = and
=C2=A0 =C2=A0[I-D.ietf-clue-rtp-mapping]."

I think it's worth pointing out in this document that DTLS/SRTP is requ= ired to use for CLUE-controlled m-lines. Also, I just did a quick skim of d= raft-ietf-clue-rtp-mapping and didn't see anything in there about media= security.

"A separate data channel is established to transport the CLUE
=C2=A0 =C2=A0protocol messages. The contents of the CLUE protocol messages = are
=C2=A0 =C2=A0based on information introduced in this document.=C2=A0 The CL= UE data
=C2=A0 =C2=A0model [I-D.ietf-clue-data-model-schema] defines through an XML=
=C2=A0 =C2=A0schema the syntax to be used. Some of the information which co= uld
=C2=A0 =C2=A0possibly introduce privacy concerns is the xCard information a= s
=C2=A0 =C2=A0described in section 7.1.1.11.=C2=A0 In addition, the (text) =C2=A0 =C2=A0description field in the Media Capture attribute (section 7.1.= 1.7)
=C2=A0 =C2=A0could possibly reveal sensitive information or specific
=C2=A0 =C2=A0identities. The same would be true for the descriptions in the=
=C2=A0 =C2=A0Capture Scene (section 7.3.1) and Capture Scene View (7.3.2) =C2=A0 =C2=A0attributes.=C2=A0 =C2=A0One other important consideration for = the
=C2=A0 =C2=A0information in the xCard as well as the description field in t= he
=C2=A0 =C2=A0Media Capture and Capture Scene View attributes is that while = the
=C2=A0 =C2=A0endpoints involved in the session have been authenticated, the= re
=C2=A0 =C2=A0is no assurance that the information in the xCard or descripti= on
=C2=A0 =C2=A0fields is authentic.=C2=A0 Thus, this information MUST NOT be = used to
=C2=A0 =C2=A0make any authorization decisions."

I don't think it's enough to point out that sensitive data can be s= ent back and forth with CLUE and that it shouldn't be used for authoriz= ation decisions. Is there some guidance that can be given about minimizing = the amount and sensitivity of data to be sent? Are there certain xCard fiel= ds that endpoints should avoid sending? Some of this is obviously dependent= on context and whether the participants in a conference know this informat= ion about each other already, but it's still worth mentioning how to mi= tigate the risks of sharing more data or more sensitive data than is necess= ary for the purposes of supporting a telepresence session. This might imply= additional text in 7.1.1.10 as well.

"Thus, it MUST be possible for the endpoints to establish
=C2=A0 =C2=A0a channel which is secure against both message recovery and =C2=A0 =C2=A0message modification. Further details on this are provided in = the
=C2=A0 =C2=A0CLUE data channel solution document."

There are no details about how the data channel is secured in draft-ietf-cl= ue-datachannel (which should be cited here if it's going to be referenc= ed). Nor are the details in draft-ietf-rtcweb-data-channel, but rather they= are in draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security.

Furthermore, the details provided in draft-ietf-rtcweb-security-arch and dr= aft-ietf-rtcweb-security explain the situation for rtcweb, where the endpoi= nts rely on identity providers to authenticate each others' identities.= IdPs are not specifically included in the CLUE architecture and, as noted = above, the SIP authentication mechanisms are optional -- so how is it that = the CLUE data channel is actually secured against an active MITM?


Nits:
There are a bunch of uses of normative MAY in this document that don't = really fit the RFC 2119 usage of the term (i.e., are not actually protocol = options). I've pointed them out below along with other nits.

=3D Section 3 =3D
"The spatial region represented by a Capture
=C2=A0 =C2=A0Scene MAY correspond to a real region in physical space, such = as a
=C2=A0 =C2=A0room."

I don't think normative language is necessary here. s/MAY/may/

s/[RFC4353] like Mixer/[RFC4353]-like Mixer/

=3D Section 4 =3D
s/it should be stressed that its use in an implementation/it should be stre= ssed that their use in an implementation/

=3D Section 5 =3D
"Also, the Consumer
=C2=A0 =C2=A0MAY use the information provided to tailor the SDP it is going= to
=C2=A0 =C2=A0send during any following SIP offer/answer exchange, and its =C2=A0 =C2=A0reaction to SDP it receives in that step."

I don't think normative language is necessary here. s/MAY/may/

"For example, if both sides decide to upgrade the call from a single s= creen to a
=C2=A0 =C2=A0multi-screen call and more bandwidth is required for the addit= ional
=C2=A0 =C2=A0video channels compared to what was previously negotiated usin= g
=C2=A0 =C2=A0offer/answer, a new O/A exchange is REQUIRED."

I don't think normative language is necessary here since this is just a= n example. s/REQUIRED/required/

=3D Secton 7.1.1.4 =3D
s/High dynamic/Highly dynamic/

=3D Section 7.1.1.11 =3D
Not everyone considers "chairman" to be a gender-neutral term. Yo= u might want to consider "chair" and "vice-chair" inste= ad.

In general it's hard for me to believe that there is much of an interop= erability gain from specifying titles in this level of detail, rather than = just allowing advertisers to specify all of their own -- is there some comp= elling need to specify this set of values initially?

=3D Section 7.1.1.12 =3D
s/no assumptions regarding relative important/no assumptions regarding rela= tive importance/

=3D Section 7.1.1.13 =3D
s/the video Capture MAY contain speech to text information/the video Captur= e may contain speech to text information/

=3D Section 7.2.1.1 =3D
s/MaxCaptures MAY be set to one/MaxCaptures may be set to one/

=3D Section 10 =3D
s/Optimized implementations MAY speed up the reaction to the
=C2=A0 =C2=A0offer/answer exchange/Optimized implementations may speed up t= he reaction to the
=C2=A0 =C2=A0offer/answer exchange/

=3D Section 10.1 =3D
s/if the Consumer is an MCU, it MAY choose to receive/if the Consumer is an= MCU, it may choose to receive/

s/user choice (for instance, selection of a new layout) MAY result/user cho= ice (for instance, selection of a new layout) may result

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

--089e0112cdfe835cb5051b368d3c-- From nobody Mon Jul 20 00:04:41 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 2AAF61A00EC for ; Mon, 20 Jul 2015 00:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhZiZX259MWY for ; Mon, 20 Jul 2015 00:04:36 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 397581A00D4 for ; Mon, 20 Jul 2015 00:04:36 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so83386100wib.0 for ; Mon, 20 Jul 2015 00:04: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=/26QbB4BtRFzP5tGAoxL9ZRD1PSKPONK10pp8Ev+feU=; b=mkwqwrKf3yRjKPzN9bpunN6yx+u16BCXbhvMdjuHXDYvcc281tOzGKyw3yr4gtI0Vf P/8L7KkS1YCKV/A6IERHEpsv+Q4bwp+86nu0KZ7OsCxe+sTfjC5zMz13aigSU1Mbb6kv wk2rh/LQyRXqerSFmNKTdArBnAD4wlYIvpbPUOaJcADPh93hJPyJJYG2a9eqa+PFeBTH bcmwlSop5y+UB57vBoIcaKeMmv57TKvciS88kelSYBfR7vnu6rKQAd+q0DoADfYwJUGi JkxSHGlGUCJt09Gm08GX8NrN3r4SdadGq15FrUtkxGaxxU434Sa6EZMrKe3hsdHhbpco t8Aw== X-Received: by 10.180.188.176 with SMTP id gb16mr18203425wic.18.1437375874898; Mon, 20 Jul 2015 00:04:34 -0700 (PDT) Received: from RoniPC ([2001:67c:370:160:9fe:34e7:7515:f9f8]) by smtp.gmail.com with ESMTPSA id r6sm10299895wiy.13.2015.07.20.00.04.33 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 20 Jul 2015 00:04:34 -0700 (PDT) From: "Roni Even" To: Date: Mon, 20 Jul 2015 10:04:32 +0300 Message-ID: <008901d0c2ba$55318a40$ff949ec0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01D0C2D3.7A821DA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDCuSiVhN3ew6qdTjGDfhbkBseG2Q== Content-Language: he Archived-At: Subject: [clue] Security issue - DTLS/SRTP SHOULD or MUST be supported 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, 20 Jul 2015 07:04:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008A_01D0C2D3.7A821DA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, In the last IETF meeting when talking about the signaling document there was a hum to use SHOULD and not MUST be supported for DTLS/SRTP The issue of SHOULD or MUST was raised now for the framework in the AD review. It is clear that we MUST have security for CLUE controlled m-lines and I assume that people where looking at RFC7202 when thinking about SHOULD or MUST We need to have good text that will say why we say SHOULD be supported and not MUST be supported. My personal view here (not as a chair) is that since CLUE is about an interoperability profile and not just a general protocol to be used by other foras we need to have a security interoperability point and if we say SHOULD be supported we do not have one. Note that saying MUST be supported does not mean that it MUST be used in cases where other means are there as explained in RFC7202 In IETF92 notes it says Christer: What was the reason for mandating the DTLS. Is it mandatory to support, mandatory to use? Rob Hansen: DTLS was made mandatory to use to avoid video hammer attack and as general increased security - we had a hum in IETF91. we had explanations in -04 and when we discussed this in -05 room wanted it to be mandatory to use Christer: Proposing that there is no specific reason to make this mandatory. Stefan Wenger: That is only one interpretation. Richard Barnes: Default for new stuff needs to be security. Obviously "must support" as that is the secure mode. Need discussion of what else might be used. Mark Duckworth: Also had same discussion regarding security in the framework document. There says "must support" rather than "must use". Chairs: Seem to be heading towards "must support" only. Steven Botzko: Proposed only recommended to support. Discussion will continue on the list. Chairs take action to start this discussion. Sorry for not doing it earlier but please provide input. Note that this issue is relevant also to the framework and RTP mapping Thanks Roni Even CLUE co-chair ------=_NextPart_000_008A_01D0C2D3.7A821DA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

In the last = IETF meeting when talking about the signaling document there was a hum = to use SHOULD and not MUST be supported for DTLS/SRTP

The issue of SHOULD or MUST was raised now for the = framework in the AD review.

 

It is clear = that we MUST have security for CLUE controlled m-lines and I assume that = people where looking at RFC7202 when thinking about SHOULD or = MUST

 

We need to have good text that will say why we say = SHOULD be supported and not MUST be supported.

 

My personal = view here (not as a chair)  is that since CLUE is about an = interoperability profile and not just a general protocol to be used by = other foras we need to have a security interoperability point and if we = say SHOULD be supported we do not have one. Note that saying MUST be = supported does not mean that it MUST be used in cases where other means = are there as explained in RFC7202

 

In IETF92 = notes it says

 

Christer: What was the = reason for mandating the DTLS. Is it mandatory to support, mandatory to = use?

 

Rob Hansen: DTLS was made = mandatory to use to avoid video hammer attack and as general increased = security - we had a hum in IETF91. we had explanations in -04 and when = we discussed this in -05 room wanted it to be mandatory to = use

 

Christer: Proposing that = there is no specific reason to make this mandatory. =

 

Stefan Wenger: That is = only one interpretation.

 

Richard Barnes: Default = for new stuff needs to be security. Obviously "must support" = as that is the secure mode. Need discussion of what else might be = used.

 

Mark Duckworth: Also had = same discussion regarding security in the framework document. There says = "must support" rather than "must = use".

 

Chairs: Seem to be heading = towards "must support" only.

 

Steven Botzko: Proposed = only recommended to support.

 

Discussion will continue = on the list. Chairs take action to start this = discussion.

 

 

Sorry for not doing it = earlier but please provide input. Note that this issue is relevant also = to the framework and RTP mapping

 

Thanks

Roni = Even

CLUE co-chair

 

 

 

------=_NextPart_000_008A_01D0C2D3.7A821DA0-- From nobody Mon Jul 20 05:16:14 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 4E7231A3BA4 for ; Mon, 20 Jul 2015 05:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68OpwN30vUS7 for ; Mon, 20 Jul 2015 05:16:11 -0700 (PDT) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id E98B61A015F for ; Mon, 20 Jul 2015 05:16:10 -0700 (PDT) X-AuditID: 1207440f-f79df6d000007c0f-1b-55ace68a68f7 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A0.E8.31759.A86ECA55; Mon, 20 Jul 2015 08:16:10 -0400 (EDT) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t6KCG9rB030252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 20 Jul 2015 08:16:10 -0400 Message-ID: <55ACE688.1000207@alum.mit.edu> Date: Mon, 20 Jul 2015 08:16:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsUixO6iqNv1bE2owbrpPBb7T11mdmD0WLLk J1MAYxS3TVJiSVlwZnqevl0Cd8bn18EFW9krbvY8ZGpg/MnaxcjJISFgIrG05RwThC0mceHe erYuRi4OIYHLjBLbTrVCOb+ZJH5e3c4CUsUroC1x59MqNhCbRUBV4vT31WCT2AS0JOYc+g9W IyqQIvFsyW4miHpBiZMzn4DFRQQkJE6dussIYgsD9TacOg0WZxYwk5i3+SEzhC0vsf3tHOYJ jLyzkLTPQlI2C0nZAkbmVYxyiTmlubq5iZk5xanJusXJiXl5qUW6Jnq5mSV6qSmlmxgh4cS/ g7FrvcwhRgEORiUeXoG/q0OFWBPLiitzDzFKcjApifJyPFoTKsSXlJ9SmZFYnBFfVJqTWnyI UYKDWUmEl/UJUI43JbGyKrUoHyYlzcGiJM6rvkTdT0ggPbEkNTs1tSC1CCYrw8GhJMH79SlQ o2BRanpqRVpmTglCmomDE2Q4l5RIcWpeSmpRYmlJRjwowuKLgTEGkuIB2jsLpJ23uCAxFygK 0XqKUZdjwY/ba5mEWPLy81KlxHllQYoEQIoySvPgVsCSxytGcaCPhXnvgbzAA0w8cJNeAS1h AlpyaxbYkpJEhJRUA+PSWzfu2wiH7noqeKXJPFv8NMsDM5+8R7bsEbJH3O9vSijSdbW+szOv oH2zIrfgx/dXrnX/k8mPn/W01du7U84v12vz8zTnSw2nJt7TeHDituTzdQFrYqRmiW7z+vtr 6wqXm5wJh5mUm7SMXic4ylT4Zx7a+uRZZOV1we3GD5Kvisr4S2jkVSqxFGckGmoxFxUnAgBi HxKt+QIAAA== Archived-At: Subject: [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, 20 Jul 2015 12:16:12 -0000 Followup to discussion in session today: A question came up about whether participants must be authenticated. IIUC the answer is no. At the least, there could be participants into a conference who don't support clue and aren't authenticated, while other participants do support clue. When the focus sends out an advertisement, all the participant info in that advertisement is an assertion by it. So when I receive an advertisement I base my trust in it on my level of trust in the advertiser. If the focus is forwarding participant info that it received in advertisements from other participants, then it ought to vet that info before passing it on. It could be useful to add a property to the participant info indicating whether the participant has been authenticated. With appropriate words, this could allow the focus to forward along participant properties even when it cannot vouch for them. Thanks, Paul From nobody Mon Jul 20 07:25: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 949371A889F for ; Mon, 20 Jul 2015 07:25:54 -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 x2FyiwGy6nZr for ; Mon, 20 Jul 2015 07:25:52 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08961A876B for ; Mon, 20 Jul 2015 07:25:52 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3F11D209F0 for ; Mon, 20 Jul 2015 10:25:52 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 20 Jul 2015 10:25:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=PAU Ds6MlPq1XVkUY3FNgRGjqlX0=; b=r7nEX9XLpCUvSRbP72ieI8b3NjzUffGXOQ0 tWVHWQ1YKqI+Vn37X5rhjxA/oM6jdhrq6jUmY3alSuRxyfv3qvnK9D5JG1mTaE7h 3ll8jpnT8gsVwujCdVurNZ4WzKpqlEMkv0N8flrLaeUEVsN6/CRpR6kdWUg/M6j1 VWVx9KzQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=PAUDs6MlPq1XVkUY3FNgRGjqlX0=; b=RqdA2 jBI5z4ZLiFsjTE1cg7eqHFOFvXqL2DzvGV9eQt9o4iiTE2ZslP666QIFdRYdkVg3 1NaQfFfRkrHNJOgP8DebtJcVQrh7JmYKmrIJbrUSQx4HtRcGN3WTcdQrFA7o0UHX 5sgKdaSI4bh+fp3Uax7+RRwXl8gLROCFjz98ys= X-Sasl-enc: S/X8tff10c9JtmmTGMo68iPzrp1Tw2ieTCjyxJDtq3iR 1437402351 Received: from [31.133.179.46] (dhcp-b32e.meeting.ietf.org [31.133.179.46]) by mail.messagingengine.com (Postfix) with ESMTPA id DF743C00028; Mon, 20 Jul 2015 10:25:51 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <39E3AD0C-0E5D-40AC-8980-EBE507AB1529@cooperw.in> Date: Mon, 20 Jul 2015 16:25:52 +0200 To: Paul Kyzivat X-Mailer: iPad Mail (12B466) 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, 20 Jul 2015 14:25:54 -0000 Hi Paul, > On Jul 20, 2015, at 2:16 PM, Paul Kyzivat wrote: >=20 > Followup to discussion in session today: >=20 > A question came up about whether participants must be authenticated. IIUC t= he answer is no. At the least, there could be participants into a conference= who don't support clue and aren't authenticated, while other participants d= o support clue. This is different from my understanding of what Roni said in the meeting. So= , which is it?=20 >=20 > When the focus sends out an advertisement, all the participant info in tha= t advertisement is an assertion by it. So when I receive an advertisement I b= ase my trust in it on my level of trust in the advertiser. If the focus is f= orwarding participant info that it received in advertisements from other par= ticipants, then it ought to vet that info before passing it on. Per your point above and the discussion earlier today, unauthenticated parti= cipants wouldn't be sending advertisements because they wouldn't support CLU= E, right? I thought the trust problem is the other way around: you want the f= ocus to not forward CLUE info *to* unauthenticated participants. Alissa >=20 > It could be useful to add a property to the participant info indicating wh= ether the participant has been authenticated. With appropriate words, this c= ould allow the focus to forward along participant properties even when it ca= nnot vouch for them. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jul 20 08:21: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 8832B1A909D for ; Mon, 20 Jul 2015 08:21:57 -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 B7RffRGDo10p for ; Mon, 20 Jul 2015 08:21:55 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 D577D1A9050 for ; Mon, 20 Jul 2015 08:20:35 -0700 (PDT) Received: by wibud3 with SMTP id ud3so100185170wib.0 for ; Mon, 20 Jul 2015 08:20:34 -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=4aVB15WYlDy1O2BfgX8RMz44aVS5aAwxhGWczk4ViVM=; b=znAM3zS4LpH38KxBqZ4Leim5/CGwAdIrzYX460ybtp0sBjb6Ssj6c3D1MUqIC1EZoD ZaJoZRrMLUFY2ynr0N7xXnS2+KEgWyRwR0SdYORHCQZvIW49gjTiPiNfahjFZTWdgG7F A+MCtYi5PlgonUqb6cYMk6PlgAGyJRQhI2suRRVYhiedU6k6BBdjPgc14Jau1QH9sOqv OEiY5/+1J2uR8my4VU2JltufIbWDcW6+SajjBdogkO8cWQ5A2c6HZqD8DwYycPDpGTW4 YiNwqq0zVUgsRdxhjM8ltqff+BNugjlQ9JIIiC2eD2NyJpxVRD8MgaO0Qwpl5x943/Qc XmqA== X-Received: by 10.180.84.230 with SMTP id c6mr22678201wiz.32.1437405634601; Mon, 20 Jul 2015 08:20:34 -0700 (PDT) Received: from RoniPC ([2001:67c:370:176:1404:4133:12a5:4e59]) by smtp.gmail.com with ESMTPSA id q3sm32464005wjr.38.2015.07.20.08.20.33 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 20 Jul 2015 08:20:33 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , "'CLUE'" References: <55ACE688.1000207@alum.mit.edu> In-Reply-To: <55ACE688.1000207@alum.mit.edu> Date: Mon, 20 Jul 2015 18:20:31 +0300 Message-ID: <01fa01d0c2ff$9f29f340$dd7dd9c0$@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/OtzvXYA3ZzUfjVg Content-Language: he Archived-At: 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, 20 Jul 2015 15:21:57 -0000 Hi Paul, One more point that I forgot during the session is that we have an issue about whom are we authenticating. The CLUE system or the user. If the user comes to a conference room and just uses a system than there is no user to authenticate. Authentication can happen if he registers with the Tele-presence system. So we either authenticate the system or are unable to authenticate. I will write some text about this issue in the security section Roni -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, July 20, 2015 3:16 PM To: CLUE Subject: [clue] Unauthenticated participants Followup to discussion in session today: A question came up about whether participants must be authenticated. IIUC the answer is no. At the least, there could be participants into a conference who don't support clue and aren't authenticated, while other participants do support clue. When the focus sends out an advertisement, all the participant info in that advertisement is an assertion by it. So when I receive an advertisement I base my trust in it on my level of trust in the advertiser. If the focus is forwarding participant info that it received in advertisements from other participants, then it ought to vet that info before passing it on. It could be useful to add a property to the participant info indicating whether the participant has been authenticated. With appropriate words, this could allow the focus to forward along participant properties even when it cannot vouch for them. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jul 20 08:33:31 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 B858B1A8AF3 for ; Mon, 20 Jul 2015 08:33:29 -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 ssUot1fpKy7S for ; Mon, 20 Jul 2015 08:33:28 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343151A8AB7 for ; Mon, 20 Jul 2015 08:33:28 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-02v.sys.comcast.net with comcast id ufYn1q0072JGN3p01fZTaM; Mon, 20 Jul 2015 15:33:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-10v.sys.comcast.net with comcast id ufZT1q0043Ge9ey01fZTvA; Mon, 20 Jul 2015 15:33:27 +0000 Message-ID: <55AD14C6.9000906@alum.mit.edu> Date: Mon, 20 Jul 2015 11:33:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Roni Even , 'CLUE' References: <55ACE688.1000207@alum.mit.edu> <01fa01d0c2ff$9f29f340$dd7dd9c0$@gmail.com> In-Reply-To: <01fa01d0c2ff$9f29f340$dd7dd9c0$@gmail.com> 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=1437406407; bh=CcQ/aLNRcVrxxRnyZ/BPi/lD7KrM77L8v0LUvJaUBU8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kq37xYnDjjVV/lGKfPZBauCdNeh1kYt+xu20BYlcAXQxqIBPBOHHldjfx3lI0u8qB +0pwiB82/IDbanPXSHOHnAQJbrjYZ6DbV8Dk09WMi8z7bSySnV5ltFNk2d9mqcGGNv 7qcoHLuMcDTx5QU9rkgcolTj/uEXMyoYXm8JBH279BNdB7xWs/57OT8xH5Wr2k+iZQ fqkp0nyAiuh/58wHddWTf3c8e9XAzXxJOUM2TRXqems/E4IT3QRi7YXFedKofH0pzD OB6m+PpTmNckyEszGv7HSpBbkYOWHPO5wKG8K0JuQSBnml5Dyho/TJsGdKburRK+fM YIioU96eluVuw== Archived-At: 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, 20 Jul 2015 15:33:29 -0000 On 7/20/15 11:20 AM, Roni Even wrote: > Hi Paul, > One more point that I forgot during the session is that we have an issue > about whom are we authenticating. The CLUE system or the user. > If the user comes to a conference room and just uses a system than there is > no user to authenticate. > Authentication can happen if he registers with the Tele-presence system. So > we either authenticate the system or are unable to authenticate. I will > write some text about this issue in the security section Ultimately we are authenticating the UA. It may be for a room with lots of people, or for a focus, or a UA for an individual user. Doesn't matter. What matters is how much trust we put into the content of the advertisements received from that UA. It is of special concern for a focus. A focus will typically send out advertisements that are constructed, in part, from information it receives from other connected UAs. That information can come both from received advertisements and from sip signaling. If the focus has an unauthenticated UA attached, it could severely restrict what it says about that. (It could just include the streams received, without any identification.) OTOH, even in that case it could be useful to include more, even if it isn't trusted. For instance, for a non-clue client it might want to create a scene and identify it based on the From. For an unauthenticated clue UA it might want to include some or all of the received advertisement. But in these cases there ought to be an indication to the recipients of the advertisement from the focus that this info isn't to be trusted. Thanks, Paul > Roni > > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, July 20, 2015 3:16 PM > To: CLUE > Subject: [clue] Unauthenticated participants > > Followup to discussion in session today: > > A question came up about whether participants must be authenticated. > IIUC the answer is no. At the least, there could be participants into a > conference who don't support clue and aren't authenticated, while other > participants do support clue. > > When the focus sends out an advertisement, all the participant info in that > advertisement is an assertion by it. So when I receive an advertisement I > base my trust in it on my level of trust in the advertiser. If the focus is > forwarding participant info that it received in advertisements from other > participants, then it ought to vet that info before passing it on. > > It could be useful to add a property to the participant info indicating > whether the participant has been authenticated. With appropriate words, this > could allow the focus to forward along participant properties even when it > cannot vouch for them. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From nobody Mon Jul 20 08:39:46 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 BA3311A896B for ; Mon, 20 Jul 2015 08:39:44 -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 dDEt2jnQ4RVw for ; Mon, 20 Jul 2015 08:39:43 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABCB1A8AF7 for ; Mon, 20 Jul 2015 08:39:43 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-07v.sys.comcast.net with comcast id uff21q0042GyhjZ01ffi1f; Mon, 20 Jul 2015 15:39:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-09v.sys.comcast.net with comcast id uffi1q00F3Ge9ey01ffiQp; Mon, 20 Jul 2015 15:39:42 +0000 Message-ID: <55AD163D.2090701@alum.mit.edu> Date: Mon, 20 Jul 2015 11:39:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alissa Cooper References: <39E3AD0C-0E5D-40AC-8980-EBE507AB1529@cooperw.in> In-Reply-To: <39E3AD0C-0E5D-40AC-8980-EBE507AB1529@cooperw.in> 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=1437406782; bh=VXs3SN8oBmwvS7S1IE2UymUwOUXnRqxjgH4+rODah8c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Jc5xrnYX0HokqtJ4of2r9Sq8RcRD4jxyk4c7x8zZfLoycBjIZJjMIyp4VKO1mRQUM rivb++yoYMpqNuHIL++4vs0VS1/0GGxx/h9UlUl0GOhjnuGhOFSj1o3UPP9hCcM2oP 484oeQYnC6njYUM3He5ONt2TomMy/bbxL7gCqi2VXwp7yrArY9eNdFILHbuoxZMemD rn8YAA6uEI/9Ne958OOP1FViHbeH/WrVtU+J7ugAf0D60OBuMqQALtV6Xzi35qe1P1 yuMXaSQl781LhtZQ8/Eughl0XTqvCE6higz9TdLOmjmYkC4NZGUPKl+iIkvkrqmVks JSCMeH3+JdVKA== 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, 20 Jul 2015 15:39:44 -0000 On 7/20/15 10:25 AM, Alissa Cooper wrote: > Hi Paul, > >> On Jul 20, 2015, at 2:16 PM, Paul Kyzivat wrote: >> >> Followup to discussion in session today: >> >> A question came up about whether participants must be authenticated. IIUC the answer is no. At the least, there could be participants into a conference who don't support clue and aren't authenticated, while other participants do support clue. > > This is different from my understanding of what Roni said in the meeting. So, which is it? I'm not sure what Roni said. At the least there can be unauthenticated non-clue participants connected to a focus, with their media being shared with the clue participants. And given that, I see no reason to make a *total* ban on unauthenticated clue participants. (SHOULD strength is ok with me.)_At the very least there ought to be provision to allow a participant whose certification has expired, and for conferences that allow anybody to join. >> When the focus sends out an advertisement, all the participant info in that advertisement is an assertion by it. So when I receive an advertisement I base my trust in it on my level of trust in the advertiser. If the focus is forwarding participant info that it received in advertisements from other participants, then it ought to vet that info before passing it on. > > Per your point above and the discussion earlier today, unauthenticated participants wouldn't be sending advertisements because they wouldn't support CLUE, right? I thought the trust problem is the other way around: you want the focus to not forward CLUE info *to* unauthenticated participants. See my earlier reply in this thread. Thanks, Paul > Alissa > >> >> It could be useful to add a property to the participant info indicating whether the participant has been authenticated. With appropriate words, this could allow the focus to forward along participant properties even when it cannot vouch for them. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jul 20 08:57: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 533151A9075 for ; Mon, 20 Jul 2015 08:57:52 -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 7cKIlgOIPz-4 for ; Mon, 20 Jul 2015 08:57:51 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E320F1A8F41 for ; Mon, 20 Jul 2015 08:57:49 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-01v.sys.comcast.net with comcast id ufxE1q00526dK1R01fxpPj; Mon, 20 Jul 2015 15:57:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-01v.sys.comcast.net with comcast id ufxo1q00P3Ge9ey01fxoyT; Mon, 20 Jul 2015 15:57:48 +0000 Message-ID: <55AD1A7B.7060001@alum.mit.edu> Date: Mon, 20 Jul 2015 11:57:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: clue@ietf.org References: <55ACE688.1000207@alum.mit.edu> In-Reply-To: <55ACE688.1000207@alum.mit.edu> 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=1437407869; bh=ZskNZ5rNWPGJkV3qZRvmvDevwmKGoPm9RW13sWbRPQA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=C9STugeaQusR86zqAOa9h5eyoXL8JTUNJ6cDQxA9c5ZLivI8guvFnvXzYEGgOS3oC N5aYXRiv8g+OMpKOmVf23qpNwZ18RKt+MVZr6VbrMr3sWER4ErFOFwZBGtUk83wbF5 9vrQBYkJrn1QB/1KZ3rFir2kjXLbZwZniOtdzvM4vsNGEKStANfOWGiUqAQ/9fOD7j iPleQZBj3cpK6x5fApC5DapY85LfnO8ZOnK9fIKpGNMLpAZ6Nur2wj3qsrKhm39VKv 5ceiS60zpkPdi89GOyuFb0qMcnW4o/LY+c8ZWg6unVdTCfDGhjtZDc5DJ2o6/wXOLr 7W6bRzhvLsgPA== Archived-At: 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, 20 Jul 2015 15:57:52 -0000 Here is an example of what I am talking about: Assume we have a clue conference server. You go to your clue-enabled TP room and connect to a conference on the server. Then I connect to the conference from a clue-enabled application on my PC. I then send an advertisement to the server offering up my audio and video captures within a scene. I attach a vcard to those asserting that I am John Chambers, CEO of Cisco. The server then constructs its own advertisements to each participant. For you it creates an advertisement containing once scene for each of the participants other than you, containing (roughly) copies of scenes it received in advertisements from the other participants. This includes the scene I sent. It also creates one (virtual) scene of its own, where the captures are MCCs, referencing captures in the other scenes. If your system analyzes the advertisement to get labels for the received streams, it may label the video received from me as being John Chambers. Presumably you would get a good chuckle out of that. If the server was cautious, then it might strip out the vcard info if it doesn't trust me. Or it might use some other policy. If we had an attribute indicating that the info wasn't authenticated, then your client might be more judicious about displaying it. But at the end of the day, the advertisement you get is from the server. Thanks, Paul On 7/20/15 8:16 AM, Paul Kyzivat wrote: > Followup to discussion in session today: > > A question came up about whether participants must be authenticated. > IIUC the answer is no. At the least, there could be participants into a > conference who don't support clue and aren't authenticated, while other > participants do support clue. > > When the focus sends out an advertisement, all the participant info in > that advertisement is an assertion by it. So when I receive an > advertisement I base my trust in it on my level of trust in the > advertiser. If the focus is forwarding participant info that it received > in advertisements from other participants, then it ought to vet that > info before passing it on. > > It could be useful to add a property to the participant info indicating > whether the participant has been authenticated. With appropriate words, > this could allow the focus to forward along participant properties even > when it cannot vouch for them. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jul 20 10:21:27 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 7AC361B2CB6 for ; Mon, 20 Jul 2015 10:21:26 -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 zOb4pvMy1xyP for ; Mon, 20 Jul 2015 10:21:24 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (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 8E8E61B2CA6 for ; Mon, 20 Jul 2015 10:21:24 -0700 (PDT) Received: by wgkl9 with SMTP id l9so135827267wgk.1 for ; Mon, 20 Jul 2015 10:21:23 -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=vky2SXcM2gPRK2b6WhCVtRvJzynPWqeg+B7mZ7hdLC0=; b=kPV2Hcjjq+gXG8OFlnyUNohNJ8w/A9VUNmeAr9zdlxIqljwqMj3uG6n+RjiVUxoV3g TfWeF6/3noJWs6Y/+svSqSuuOvvpPssaW7uCvFa6sH3QFMCVCc91+Dv2b2vUIPukZGSD H92Z27xtPNgN3GBULbXh44pbXb7ung0VREd48ESS9fcUQ3U4N4uNqU/5sulDUifUEmM5 /E/7OflfszY7yX/PEnOL6x9q6ELbD0PXkXq79u5iWajMHs+Sd6CbYV+/PIVUDZYQ3Pz5 oPFasW5GL9grcp9ZsWwLoELxy2nA6Mgmq2OCN998S0qVB/XYdgc1Zji6mKdUHkG3/SJa yhBw== X-Received: by 10.181.12.20 with SMTP id em20mr24092920wid.28.1437412883372; Mon, 20 Jul 2015 10:21:23 -0700 (PDT) Received: from RoniPC ([2001:67c:370:176:2469:a096:ed37:d627]) by smtp.gmail.com with ESMTPSA id l6sm12745974wib.18.2015.07.20.10.21.22 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 20 Jul 2015 10:21:22 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , "'CLUE'" References: <55ACE688.1000207@alum.mit.edu> <01fa01d0c2ff$9f29f340$dd7dd9c0$@gmail.com> <55AD14C6.9000906@alum.mit.edu> In-Reply-To: <55AD14C6.9000906@alum.mit.edu> Date: Mon, 20 Jul 2015 20:21:19 +0300 Message-ID: <002901d0c310$7f904a00$7eb0de00$@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/OtzvXYA3QIwvpUlAqm7Eeucrc204A== Content-Language: he Archived-At: 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, 20 Jul 2015 17:21:26 -0000 Hi Paul, You assume that the endpoint has an identity for authentication which is not always the case Roni -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Monday, July 20, 2015 6:33 PM To: Roni Even; 'CLUE' Subject: Re: [clue] Unauthenticated participants On 7/20/15 11:20 AM, Roni Even wrote: > Hi Paul, > One more point that I forgot during the session is that we have an > issue about whom are we authenticating. The CLUE system or the user. > If the user comes to a conference room and just uses a system than > there is no user to authenticate. > Authentication can happen if he registers with the Tele-presence > system. So we either authenticate the system or are unable to > authenticate. I will write some text about this issue in the security > section Ultimately we are authenticating the UA. It may be for a room with lots of people, or for a focus, or a UA for an individual user. Doesn't matter. What matters is how much trust we put into the content of the advertisements received from that UA. It is of special concern for a focus. A focus will typically send out advertisements that are constructed, in part, from information it receives from other connected UAs. That information can come both from received advertisements and from sip signaling. If the focus has an unauthenticated UA attached, it could severely restrict what it says about that. (It could just include the streams received, without any identification.) OTOH, even in that case it could be useful to include more, even if it isn't trusted. For instance, for a non-clue client it might want to create a scene and identify it based on the From. For an unauthenticated clue UA it might want to include some or all of the received advertisement. But in these cases there ought to be an indication to the recipients of the advertisement from the focus that this info isn't to be trusted. Thanks, Paul > Roni > > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, July 20, 2015 3:16 PM > To: CLUE > Subject: [clue] Unauthenticated participants > > Followup to discussion in session today: > > A question came up about whether participants must be authenticated. > IIUC the answer is no. At the least, there could be participants into > a conference who don't support clue and aren't authenticated, while > other participants do support clue. > > When the focus sends out an advertisement, all the participant info in > that advertisement is an assertion by it. So when I receive an > advertisement I base my trust in it on my level of trust in the > advertiser. If the focus is forwarding participant info that it > received in advertisements from other participants, then it ought to vet that info before passing it on. > > It could be useful to add a property to the participant info > indicating whether the participant has been authenticated. With > appropriate words, this could allow the focus to forward along > participant properties even when it cannot vouch for them. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From nobody Mon Jul 20 10:45:00 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 629D41B2CF5 for ; Mon, 20 Jul 2015 10:44:59 -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 BCc5bBJjakN5 for ; Mon, 20 Jul 2015 10:44:58 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7C91B2D25 for ; Mon, 20 Jul 2015 10:44:19 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-01v.sys.comcast.net with comcast id uhkK1q0054s37d401hkKw9; Mon, 20 Jul 2015 17:44:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-01v.sys.comcast.net with comcast id uhkJ1q00H3Ge9ey01hkJby; Mon, 20 Jul 2015 17:44:19 +0000 Message-ID: <55AD3371.2040605@alum.mit.edu> Date: Mon, 20 Jul 2015 13:44:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Roni Even , 'CLUE' References: <55ACE688.1000207@alum.mit.edu> <01fa01d0c2ff$9f29f340$dd7dd9c0$@gmail.com> <55AD14C6.9000906@alum.mit.edu> <002901d0c310$7f904a00$7eb0de00$@gmail.com> In-Reply-To: <002901d0c310$7f904a00$7eb0de00$@gmail.com> 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=1437414259; bh=zpNzf9rQttrTnS6c9gEHE5wEFTQ7K+9cklYrS35Pzdk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kqHzPZ3aDqn+IFd/hN59A4KmJvi3TS7VmCSprukcBMaNC7k6i/tSNIb0H6zdXNds4 mTVJOexU7Z7GFJcUpz4t6OGhTzRtsY/Zq/aW/FtSw2Mo04z0+k3Gx6kl0z4eQ7eBtJ VkyeaZ3MlubL9inMoT8Opt3lysAzbymgawsm0vQC6hA8MrxQHe7upL2sK7nsqxP3sX ZYillT41StnUQJm+ENNeS/W9nzGwK9jN2WZThflwgn5kVOJW1Vf3Z+CETb2CWGHxr3 LL+HmQk4ez1DjWahrMHPDejh9mH+csyeYeCZE7ShmyLzPciOQT0vffa1xqOdSQ8jkL jZOzQHLC+KX+Q== Archived-At: 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, 20 Jul 2015 17:44:59 -0000 On 7/20/15 1:21 PM, Roni Even wrote: > Hi Paul, > You assume that the endpoint has an identity for authentication which is not > always the case > Roni If the endpoint is to authenticate, then either it has an identity of its own, or else it "borrows" an identity supplied by a user of the device. The effect is the same to the other end. And if neither is the case, and so it can't authenticate, it still has some asserted identity, even if it is Anonymous. Thanks, Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Monday, July 20, 2015 6:33 PM > To: Roni Even; 'CLUE' > Subject: Re: [clue] Unauthenticated participants > > On 7/20/15 11:20 AM, Roni Even wrote: >> Hi Paul, >> One more point that I forgot during the session is that we have an >> issue about whom are we authenticating. The CLUE system or the user. >> If the user comes to a conference room and just uses a system than >> there is no user to authenticate. >> Authentication can happen if he registers with the Tele-presence >> system. So we either authenticate the system or are unable to >> authenticate. I will write some text about this issue in the security >> section > > Ultimately we are authenticating the UA. It may be for a room with lots of > people, or for a focus, or a UA for an individual user. Doesn't matter. What > matters is how much trust we put into the content of the advertisements > received from that UA. > > It is of special concern for a focus. A focus will typically send out > advertisements that are constructed, in part, from information it receives > from other connected UAs. That information can come both from received > advertisements and from sip signaling. > > If the focus has an unauthenticated UA attached, it could severely restrict > what it says about that. (It could just include the streams received, > without any identification.) > > OTOH, even in that case it could be useful to include more, even if it isn't > trusted. For instance, for a non-clue client it might want to create a scene > and identify it based on the From. For an unauthenticated clue UA it might > want to include some or all of the received advertisement. But in these > cases there ought to be an indication to the recipients of the advertisement > from the focus that this info isn't to be trusted. > > Thanks, > Paul > >> Roni >> >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Monday, July 20, 2015 3:16 PM >> To: CLUE >> Subject: [clue] Unauthenticated participants >> >> Followup to discussion in session today: >> >> A question came up about whether participants must be authenticated. >> IIUC the answer is no. At the least, there could be participants into >> a conference who don't support clue and aren't authenticated, while >> other participants do support clue. >> >> When the focus sends out an advertisement, all the participant info in >> that advertisement is an assertion by it. So when I receive an >> advertisement I base my trust in it on my level of trust in the >> advertiser. If the focus is forwarding participant info that it >> received in advertisements from other participants, then it ought to vet > that info before passing it on. >> >> It could be useful to add a property to the participant info >> indicating whether the participant has been authenticated. With >> appropriate words, this could allow the focus to forward along >> participant properties even when it cannot vouch for them. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > > From nobody Mon Jul 20 18:10: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 73E431ACD29 for ; Mon, 20 Jul 2015 18:10:11 -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 b6WLvsX1x51f for ; Mon, 20 Jul 2015 18:10:09 -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 884111ACD35 for ; Mon, 20 Jul 2015 18:10:08 -0700 (PDT) Received: from ppp118-209-187-42.lns20.mel8.internode.on.net ([118.209.187.42]:50573 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZHM4M-002Wfv-8R for clue@ietf.org; Tue, 21 Jul 2015 11:10:06 +1000 To: clue@ietf.org References: <008901d0c2ba$55318a40$ff949ec0$@gmail.com> From: Christian Groves Message-ID: <55AD9BDE.5050909@nteczone.com> Date: Tue, 21 Jul 2015 11:09:50 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <008901d0c2ba$55318a40$ff949ec0$@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] Security issue - DTLS/SRTP SHOULD or MUST be supported 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, 21 Jul 2015 01:10:11 -0000 Hello Roni, I'm a little confused. What are you asking for? You mention we need text to describe that DTLS/SRTP SHOULD be supported but then you seem to argue for MUST be supported. Did you want to re-open the discussion or? Regards, Christian On 20/07/2015 5:04 PM, Roni Even wrote: > > Hi, > > In the last IETF meeting when talking about the signaling document > there was a hum to use SHOULD and not MUST be supported for DTLS/SRTP > > The issue of SHOULD or MUST was raised now for the framework in the AD > review. > > It is clear that we MUST have security for CLUE controlled m-lines and > I assume that people where looking at RFC7202 when thinking about > SHOULD or MUST > > We need to have good text that will say why we say SHOULD be supported > and not MUST be supported. > > My personal view here (not as a chair) is that since CLUE is about an > interoperability profile and not just a general protocol to be used by > other foras we need to have a security interoperability point and if > we say SHOULD be supported we do not have one. Note that saying MUST > be supported does not mean that it MUST be used in cases where other > means are there as explained in RFC7202 > > In IETF92 notes it says > > Christer: What was the reason for mandating the DTLS. Is it mandatory > to support, mandatory to use? > > Rob Hansen: DTLS was made mandatory to use to avoid video hammer > attack and as general increased security - we had a hum in IETF91. we > had explanations in -04 and when we discussed this in -05 room wanted > it to be mandatory to use > > Christer: Proposing that there is no specific reason to make this > mandatory. > > Stefan Wenger: That is only one interpretation. > > Richard Barnes: Default for new stuff needs to be security. Obviously > "must support" as that is the secure mode. Need discussion of what > else might be used. > > Mark Duckworth: Also had same discussion regarding security in the > framework document. There says "must support" rather than "must use". > > Chairs: Seem to be heading towards "must support" only. > > Steven Botzko: Proposed only recommended to support. > > Discussion will continue on the list. Chairs take action to start this > discussion. > > Sorry for not doing it earlier but please provide input. Note that > this issue is relevant also to the framework and RTP mapping > > Thanks > > Roni Even > > CLUE co-chair > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Jul 21 00:24:27 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 38F421AD1FE for ; Tue, 21 Jul 2015 00:24:26 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 zOymWConiNl3 for ; Tue, 21 Jul 2015 00:24:23 -0700 (PDT) Received: from hwsga01-in.huaweimarine.com (hwsga01-in.huaweimarine.com [119.145.15.223]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932321AD1F5 for ; Tue, 21 Jul 2015 00:24:20 -0700 (PDT) Received: from 172.24.1.80 (EHLO szxpml401-hub.exmail.huawei.com) ([172.24.1.80]) by szxrg11-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOF53593; Tue, 21 Jul 2015 15:23:59 +0800 (CST) Received: from SZXPML507-MBS.exmail.huawei.com ([169.254.3.206]) by szxpml401-hub.exmail.huawei.com ([10.82.67.140]) with mapi id 14.03.0235.001; Tue, 21 Jul 2015 15:23:53 +0800 From: Roni Even To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Security issue - DTLS/SRTP SHOULD or MUST be supported Thread-Index: AdDCuSiVhN3ew6qdTjGDfhbkBseG2QAVbp4AAB26ZJE= Date: Tue, 21 Jul 2015 07:23:52 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C24D0959C8@szxpml507-mbs.exmail.huawei.com> References: <008901d0c2ba$55318a40$ff949ec0$@gmail.com>, <55AD9BDE.5050909@nteczone.com> In-Reply-To: <55AD9BDE.5050909@nteczone.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [clue] Security issue - DTLS/SRTP SHOULD or MUST be supported 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, 21 Jul 2015 07:24:26 -0000 Hi Christian, We discussed the issue in the CLUE session and I will follow with a specifi= c mail to the list. One important issue is that the security MUST be consistent between all CLU= E doucments and the framework currently says MUST be supported. I will send proposed text tp be used in all doucments to the list Roni=20 ________________________________________ From: clue [clue-bounces@ietf.org] on behalf of Christian Groves [Christian= .Groves@nteczone.com] Sent: Tuesday, July 21, 2015 4:09 AM To: clue@ietf.org Subject: Re: [clue] Security issue - DTLS/SRTP SHOULD or MUST be supported Hello Roni, I'm a little confused. What are you asking for? You mention we need text to describe that DTLS/SRTP SHOULD be supported but then you seem to argue for MUST be supported. Did you want to re-open the discussion or? Regards, Christian On 20/07/2015 5:04 PM, Roni Even wrote: > > Hi, > > In the last IETF meeting when talking about the signaling document > there was a hum to use SHOULD and not MUST be supported for DTLS/SRTP > > The issue of SHOULD or MUST was raised now for the framework in the AD > review. > > It is clear that we MUST have security for CLUE controlled m-lines and > I assume that people where looking at RFC7202 when thinking about > SHOULD or MUST > > We need to have good text that will say why we say SHOULD be supported > and not MUST be supported. > > My personal view here (not as a chair) is that since CLUE is about an > interoperability profile and not just a general protocol to be used by > other foras we need to have a security interoperability point and if > we say SHOULD be supported we do not have one. Note that saying MUST > be supported does not mean that it MUST be used in cases where other > means are there as explained in RFC7202 > > In IETF92 notes it says > > Christer: What was the reason for mandating the DTLS. Is it mandatory > to support, mandatory to use? > > Rob Hansen: DTLS was made mandatory to use to avoid video hammer > attack and as general increased security - we had a hum in IETF91. we > had explanations in -04 and when we discussed this in -05 room wanted > it to be mandatory to use > > Christer: Proposing that there is no specific reason to make this > mandatory. > > Stefan Wenger: That is only one interpretation. > > Richard Barnes: Default for new stuff needs to be security. Obviously > "must support" as that is the secure mode. Need discussion of what > else might be used. > > Mark Duckworth: Also had same discussion regarding security in the > framework document. There says "must support" rather than "must use". > > Chairs: Seem to be heading towards "must support" only. > > Steven Botzko: Proposed only recommended to support. > > Discussion will continue on the list. Chairs take action to start this > discussion. > > Sorry for not doing it earlier but please provide input. Note that > this issue is relevant also to the framework and RTP mapping > > Thanks > > Roni Even > > CLUE co-chair > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From nobody Tue Jul 21 02:08:21 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 9364B1B2C45 for ; Tue, 21 Jul 2015 02:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWgyqg7NBSFs for ; Tue, 21 Jul 2015 02:08:17 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C885B1B2C04 for ; Tue, 21 Jul 2015 02:08:16 -0700 (PDT) X-AuditID: c1b4fb30-f79706d000007227-67-55ae0bfe7833 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1A.5C.29223.EFB0EA55; Tue, 21 Jul 2015 11:08:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0210.002; Tue, 21 Jul 2015 11:08:13 +0200 From: Christer Holmberg To: "clue@ietf.org" , "clue-chairs@tools.ietf.org" Thread-Topic: IETF#93: CLUE notes Thread-Index: AdDDk+yvJP3UYZ1rQeiQjZYOKWfw1Q== Date: Tue, 21 Jul 2015 09:08:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348BFCD1@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348BFCD1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje5/7nWhBvuPMltMP/OX0WLmtA+s FvtPXWZ2YPb48uQlk8eSJT+ZPL5c/swWwBzFZZOSmpNZllqkb5fAlfH5wAfmgskTGSt+7f/B 1MD4soGxi5GTQ0LAROLQyZlQtpjEhXvr2boYuTiEBI4ySqy5fIUJwlnMKPHuwGHmLkYODjYB C4nuf9ogDSICCRJNt3YwgdjMAtoSC5ffYwOxhQVkJBZM2sgKUaMocXLPLnYIW09i9vYJYDUs AqoSD+6uBFvMK+ArcXp7D1icEeiI76fWQM0Ul7j1ZD4TxHECEkv2nGeGsEUlXj7+xwphK0ks uv0Zqj5fYlXvV6iZghInZz5hmcAoPAvJqFlIymYhKYOI60gs2P2JbRbUO8sWvmaGsc8ceMyE LL6AkX0Vo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmBcHdzy22AH48vnjocYBTgYlXh4Fyxf GyrEmlhWXJl7iFGag0VJnHfG5rxQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwarsctenPX qf1Z+EFswwGbQ9ek1V5NVt6wu2a7jJ73d0+WJ0pKr/5cOnuNmdH7Su83Q4XsCTy2HkWb/l9d YPFFha3HLnRl2vo9XZ1Lkm69lnq85cCm34Vtc747bp87yf+hjVXHxn1fJ77bW51zPV9f9oa+ yAbBjmqTH+1XRabvFy1SmtiedbRIiaU4I9FQi7moOBEAiLkCDYwCAAA= Archived-At: Subject: [clue] IETF#93: CLUE notes 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, 21 Jul 2015 09:08:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348BFCD1ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below are my notes from the CLUE session. Regards, Christer --------------------------- TOPIC: Document status General: =3D=3D=3D=3D=3D=3D=3D=3D - The chairs indicated that there is a need for volunteers to review the = protocol, signalling and RTP mapping drafts. - We need to make sure that security text is consistent throughout all do= cuments. Framework: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D XML schema: - There is a remaining open issue whether an IANA registry is needed for = the policy token. SIP Security: - It was indicated that the document should reference RF 3261 for general= SIP security considerations. - It was indicated that more text is needed regarding user authentication= . SIP in general allows unauthenticated users to establish sessions, but CL= UE sessions may reveal information that one may not want to share with unau= thenticated users. It was suggested to mandate authentication for CLUE sess= ions. ACTION POINT: Roni Even will send an e-mail to the mailing list, veri= fying the approach together with suggested text. Media Security: - There was discussions regarding the mandatory usage/support of DTLS-SRT= P. It was suggested to say that SUPPORT of DTLS-SRTP is mandatory among all= CLUE entities, and that USAGE of *some* media security mechanism (not nece= ssarily DTLS-SRTP) is mandatory. ACTION POINT: Roni Even will send an e-mai= l to the list, verifying the approach such together with suggested text. Data channel: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - We need to reference the correct document regarding how to secure a dat= a channel. ACTION POINT: Christer Holmberg will take care of the issue. CLUE Protocol: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D No remaining open issues. RTP Usage In CLUE: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D No remaining open issues. ACTION POINT: Roni Even will finalize some editor= ial work that is still needed. --_000_7594FB04B1934943A5C02806D1A2204B348BFCD1ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

Below are my notes from the CLUE session.

 

Regards,

 

Christer

 

---------------------------

 

 

TOPIC:     Document status

 

General:

=3D=3D=3D=3D=3D=3D=3D=3D

 

-   The chairs indicated that there is a need for volunteers to review = the protocol, signalling and RTP mapping drafts.

-   We need to make sure that security text is consistent throughout al= l documents.

 

Framework:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

XML schema:

 

-   There is a remaining open issue whether an IANA registry is needed = for the policy token.

 

SIP Security:

 

-   It was indicated that the document should reference RF 3261 for gen= eral SIP security considerations.

 

-   It was indicated that more text is needed regarding user authentica= tion. SIP in general allows unauthenticated users to establish sessions, bu= t CLUE sessions may reveal information that one may not want to share with unauthenticated users. It was suggested to = mandate authentication for CLUE sessions. ACTION POINT: Roni Even will send= an e-mail to the mailing list, verifying the approach together with sugges= ted text.

 

Media Security:

 

-   There was discussions regarding the mandatory usage/support of DTLS= -SRTP. It was suggested to say that SUPPORT of DTLS-SRTP is mandatory among= all CLUE entities, and that USAGE of *some* media security mechanism (not necessarily DTLS-SRTP) is mandatory. ACTION = POINT: Roni Even will send an e-mail to the list, verifying the approach su= ch together with suggested text.

 

 

Data channel:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

-   We need to reference the correct document regarding how to secure a= data channel. ACTION POINT: Christer Holmberg will take care of the issue.=

 

 

CLUE Protocol:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

No remaining open issues.

 

 

RTP Usage In CLUE:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

 

No remaining open issues. ACTION POINT: Roni Even will finalize some edi= torial work that is still needed.

 

--_000_7594FB04B1934943A5C02806D1A2204B348BFCD1ESESSMB209erics_-- From nobody Wed Jul 22 08:06:01 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 341E31A0078 for ; Wed, 22 Jul 2015 08:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.38 X-Spam-Level: * X-Spam-Status: No, score=1.38 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 wptBq7vQnpTv for ; Wed, 22 Jul 2015 08:05:59 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C31A0087 for ; Wed, 22 Jul 2015 08:05:57 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vT5w1q00a2NEPrz01T5wzr; Wed, 22 Jul 2015 17:05:57 +0200 Date: Wed, 22 Jul 2015 17:05:57 +0200 (CEST) From: Meetecho Team To: clue@ietf.org Message-ID: <1437446480.7.1437577557970.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6_422120303.1437577557964" Archived-At: Subject: [clue] Meetecho recordings of CLUE WG session 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, 22 Jul 2015 15:06:00 -0000 ------=_Part_6_422120303.1437577557964 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the CLUE WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#CLUE In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_6_422120303.1437577557964-- From nobody Wed Jul 22 08:45:50 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 6A1181A1BD2 for ; Wed, 22 Jul 2015 08:45:49 -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 rfZ7rv4eUyQ3 for ; Wed, 22 Jul 2015 08:45:47 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 A0FB91A1BEE for ; Wed, 22 Jul 2015 08:45:44 -0700 (PDT) Received: by wibud3 with SMTP id ud3so178920016wib.0 for ; Wed, 22 Jul 2015 08:45:43 -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=jL9cBgInxRpc7AXo9N3HUdNmtGCdeRQt9GvUePnJiag=; b=dk4EbzwRn7tRlU621gLfhyEy/TIHgNrqNrv0Ah6im4jDYfjJvg8iWaX9vKajQcS7U8 7qBxNFzviVJ7KBGWFj0pAxD/uy8guWmAZF3u7/A7cam8VXLTXBj5lPxvVNuOGAd281V5 IiY1SRtrD4Fl/3buoIBoEVXogX7aPXTtwESIHl7IjjI/+m5AtoSsnDZ5xB+ftzGgcib5 gnaBLFUOvx4tCrvsmtC/ab14TLwpImuRNtpnc9mNBxlwZSjPYjji7XHk0QRabzTVWEOh YrHPLeO9Dea3GyLrYl+CUGx9UYHoVAMM5V0TGiOiAm5dy9AeEFiZ9aS/2jy49wdDw785 kqdw== X-Received: by 10.194.47.209 with SMTP id f17mr6278836wjn.39.1437579943365; Wed, 22 Jul 2015 08:45:43 -0700 (PDT) Received: from RoniPC ([2001:67c:370:160:1da8:f901:a537:f42b]) by smtp.gmail.com with ESMTPSA id eu2sm3997106wic.8.2015.07.22.08.45.39 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Jul 2015 08:45:40 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , "'CLUE'" References: <55ACE688.1000207@alum.mit.edu> <01fa01d0c2ff$9f29f340$dd7dd9c0$@gmail.com> <55AD14C6.9000906@alum.mit.edu> <002901d0c310$7f904a00$7eb0de00$@gmail.com> <55AD3371.2040605@alum.mit.edu> In-Reply-To: <55AD3371.2040605@alum.mit.edu> Date: Wed, 22 Jul 2015 18:45:37 +0300 Message-ID: <006601d0c495$74fca530$5ef5ef90$@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/OtzvXYA3QIwvpUlAqm7EesCOxvRvgH5GrHtnI81UOA= Content-Language: he Archived-At: 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: Wed, 22 Jul 2015 15:45:49 -0000 Hi Paul, The difference will be with the x-card information, if no user-id it will say probably the name of the conference room. One question will be if we allow a room that has no identification to join as un-authorize, it may be allowed in which case the conference server should be cautious about what he sends as advertisement to it. This is something we can mention in the security section Roni -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Monday, July 20, 2015 8:44 PM To: Roni Even; 'CLUE' Subject: Re: [clue] Unauthenticated participants On 7/20/15 1:21 PM, Roni Even wrote: > Hi Paul, > You assume that the endpoint has an identity for authentication which > is not always the case Roni If the endpoint is to authenticate, then either it has an identity of its own, or else it "borrows" an identity supplied by a user of the device. The effect is the same to the other end. And if neither is the case, and so it can't authenticate, it still has some asserted identity, even if it is Anonymous. Thanks, Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Monday, July 20, 2015 6:33 PM > To: Roni Even; 'CLUE' > Subject: Re: [clue] Unauthenticated participants > > On 7/20/15 11:20 AM, Roni Even wrote: >> Hi Paul, >> One more point that I forgot during the session is that we have an >> issue about whom are we authenticating. The CLUE system or the user. >> If the user comes to a conference room and just uses a system than >> there is no user to authenticate. >> Authentication can happen if he registers with the Tele-presence >> system. So we either authenticate the system or are unable to >> authenticate. I will write some text about this issue in the security >> section > > Ultimately we are authenticating the UA. It may be for a room with > lots of people, or for a focus, or a UA for an individual user. > Doesn't matter. What matters is how much trust we put into the content > of the advertisements received from that UA. > > It is of special concern for a focus. A focus will typically send out > advertisements that are constructed, in part, from information it > receives from other connected UAs. That information can come both from > received advertisements and from sip signaling. > > If the focus has an unauthenticated UA attached, it could severely > restrict what it says about that. (It could just include the streams > received, without any identification.) > > OTOH, even in that case it could be useful to include more, even if it > isn't trusted. For instance, for a non-clue client it might want to > create a scene and identify it based on the From. For an > unauthenticated clue UA it might want to include some or all of the > received advertisement. But in these cases there ought to be an > indication to the recipients of the advertisement from the focus that this info isn't to be trusted. > > Thanks, > Paul > >> Roni >> >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Monday, July 20, 2015 3:16 PM >> To: CLUE >> Subject: [clue] Unauthenticated participants >> >> Followup to discussion in session today: >> >> A question came up about whether participants must be authenticated. >> IIUC the answer is no. At the least, there could be participants into >> a conference who don't support clue and aren't authenticated, while >> other participants do support clue. >> >> When the focus sends out an advertisement, all the participant info >> in that advertisement is an assertion by it. So when I receive an >> advertisement I base my trust in it on my level of trust in the >> advertiser. If the focus is forwarding participant info that it >> received in advertisements from other participants, then it ought to >> vet > that info before passing it on. >> >> It could be useful to add a property to the participant info >> indicating whether the participant has been authenticated. With >> appropriate words, this could allow the focus to forward along >> participant properties even when it cannot vouch for them. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > > From nobody Wed Jul 22 08:54:12 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 8D2271A1F20 for ; Wed, 22 Jul 2015 08:54:10 -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 13hxmHFGhPwv for ; Wed, 22 Jul 2015 08:54:08 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 75BAB1A1C04 for ; Wed, 22 Jul 2015 08:54:08 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so87519498wic.0 for ; Wed, 22 Jul 2015 08:54:07 -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=ewQ+b0K9bJGiaqQXbrM1Qix20Q6fF753HSAjxddMvDs=; b=S++xu/CRbRV/Ou7xosBuvRjLF4z/nGXYF5oGbJAefRiEZi2t25MivFkI89lwXv8rC3 tjn5mRboOncPYAX9RTnBUhkY9qZNjItjQD4EuVjdkWcpLNXWn+3fFn7spM4LPGVuud4k 7Pl+a2mQFb4Khj0E8jF5GNc67GzxugloqNEaeR0xTT92sZWwC3TEY/9gHW3YiPwNxmDD xNsQeR6aD+F9y1/FjAxywfGPk4om8C/FEG+pxPIeZzOfRrUII651BYlcL35VnwvawUn1 tT7e/+0uyV1c/nOAEcTicZbRwDaTm6Y8lmfkgmTld9sviAvd8yq4Z8IijKYrnl8OebIy eVOQ== X-Received: by 10.194.176.201 with SMTP id ck9mr6381360wjc.108.1437580447247; Wed, 22 Jul 2015 08:54:07 -0700 (PDT) Received: from RoniPC ([2001:67c:370:160:1da8:f901:a537:f42b]) by smtp.gmail.com with ESMTPSA id fb3sm22655035wib.21.2015.07.22.08.54.06 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Jul 2015 08:54:06 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <55ACE688.1000207@alum.mit.edu> <55AD1A7B.7060001@alum.mit.edu> In-Reply-To: <55AD1A7B.7060001@alum.mit.edu> Date: Wed, 22 Jul 2015 18:53:55 +0300 Message-ID: <006701d0c496$a2ff8e60$e8feab20$@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/OtzvXYA3QGX/w/OnMrr4fA= Content-Language: he Archived-At: 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: Wed, 22 Jul 2015 15:54:10 -0000 Hi Paul, I am not sure I understand? All the participants in the examples support CLUE and were authenticated and later in the advertisement sent some x-card information that is not true.? Is there a way to prevent it? So it allows anyone to claim a role in the conference or provide some job title? Any suggestions? Roni -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, July 20, 2015 6:58 PM To: clue@ietf.org Subject: Re: [clue] Unauthenticated participants Here is an example of what I am talking about: Assume we have a clue conference server. You go to your clue-enabled TP room and connect to a conference on the server. Then I connect to the conference from a clue-enabled application on my PC. I then send an advertisement to the server offering up my audio and video captures within a scene. I attach a vcard to those asserting that I am John Chambers, CEO of Cisco. The server then constructs its own advertisements to each participant. For you it creates an advertisement containing once scene for each of the participants other than you, containing (roughly) copies of scenes it received in advertisements from the other participants. This includes the scene I sent. It also creates one (virtual) scene of its own, where the captures are MCCs, referencing captures in the other scenes. If your system analyzes the advertisement to get labels for the received streams, it may label the video received from me as being John Chambers. Presumably you would get a good chuckle out of that. If the server was cautious, then it might strip out the vcard info if it doesn't trust me. Or it might use some other policy. If we had an attribute indicating that the info wasn't authenticated, then your client might be more judicious about displaying it. But at the end of the day, the advertisement you get is from the server. Thanks, Paul On 7/20/15 8:16 AM, Paul Kyzivat wrote: > Followup to discussion in session today: > > A question came up about whether participants must be authenticated. > IIUC the answer is no. At the least, there could be participants into > a conference who don't support clue and aren't authenticated, while > other participants do support clue. > > When the focus sends out an advertisement, all the participant info in > that advertisement is an assertion by it. So when I receive an > advertisement I base my trust in it on my level of trust in the > advertiser. If the focus is forwarding participant info that it > received in advertisements from other participants, then it ought to > vet that info before passing it on. > > It could be useful to add a property to the participant info > indicating whether the participant has been authenticated. With > appropriate words, this could allow the focus to forward along > participant properties even when it cannot vouch for them. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Wed Jul 22 09:14: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 A2F911A8859 for ; Wed, 22 Jul 2015 09:14:19 -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 CkHvI7GmduAY for ; Wed, 22 Jul 2015 09:14:15 -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 F39BF1A8858 for ; Wed, 22 Jul 2015 09:14:14 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-09v.sys.comcast.net with comcast id vUDN1q0042LrikM01UEEzV; Wed, 22 Jul 2015 16:14:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-12v.sys.comcast.net with comcast id vUED1q00b3Ge9ey01UEDjt; Wed, 22 Jul 2015 16:14:14 +0000 Message-ID: <55AFC154.9020205@alum.mit.edu> Date: Wed, 22 Jul 2015 12:14:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Roni Even , 'CLUE' References: <55ACE688.1000207@alum.mit.edu> <01fa01d0c2ff$9f29f340$dd7dd9c0$@gmail.com> <55AD14C6.9000906@alum.mit.edu> <002901d0c310$7f904a00$7eb0de00$@gmail.com> <55AD3371.2040605@alum.mit.edu> <006601d0c495$74fca530$5ef5ef90$@gmail.com> In-Reply-To: <006601d0c495$74fca530$5ef5ef90$@gmail.com> 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=1437581654; bh=e2POsRkyNIeA5xvX73vqpeStX36z/Vqz0FO1+Zp9MF8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aXyT99JPxSxxUle6tJzNbMbwLUAlmyJp+poupLYtTqH8CRgF7jdBwhKcrsGw1j+bO N4QcUVmQrBmyxqse/ec977uCJDxiRGm6GZ9Za8xoHa5xpFWPAvmHeRno5wHtaDoGa7 Elc0IiCJSIJb7l18kVPJTSBwvnqDSO+qSwG5D3lAQxSJJrgraBhgmfy13Agmpr+xUn kkRdN7fYeDqeRIhhJ8FYtitdzWeCqdu3pn/5tZHUPP0zIyshpe71c6Zbr87h2ERoO2 aqasimIopHriIvsRuFy0XCR8wgNSIs61tmcLCrRW+TAVtPLBW7O0XU0hK+GWd2UqW7 E2JVwd699vEhg== Archived-At: 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: Wed, 22 Jul 2015 16:14:19 -0000 On 7/22/15 11:45 AM, Roni Even wrote: > Hi Paul, > The difference will be with the x-card information, if no user-id it will > say probably the name of the conference room. I think we may be talking past one another. If a UA representing a room connects to an MCU, the MCU only knows the identity based on what is in the signaling, including authentication, and what is in the advertisement from the room. If there is no authentication, then all of that information is suspect. When you say "if no user-id it will probably name the room", I think you must be talking about policies of room system - that it allows some person in the room to provide authentication information, or else authenticates with a default for the room. IMO such policies are not within our scope. (It seems equally likely that a room might simply connect without authenticating if no user-id is given, or that it might *always* connect with its own identity/credentials and give no option for user supplied credentials.) > One question will be if we allow a room that has no identification to join > as un-authorize, IMO this is not a choice that we should make. This should be a deployment policy of individual clue devices. > it may be allowed in which case the conference server > should be cautious about what he sends as advertisement to it. This is > something we can mention in the security section > Roni A warning is a good idea. But beyond that, the question is whether, if an MCU allows an unauthenticated device to connect, is there a way for it to indicate the unauthenticated status of the info from that device to be reported to the other participants of the conference. This isn't something that was considered. But I think it would be a good idea. I think a possible way to do this would be to add an attribute (boolean: 'authenticated') about this to the scene attributes. Thanks, Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Monday, July 20, 2015 8:44 PM > To: Roni Even; 'CLUE' > Subject: Re: [clue] Unauthenticated participants > > On 7/20/15 1:21 PM, Roni Even wrote: >> Hi Paul, >> You assume that the endpoint has an identity for authentication which >> is not always the case Roni > > If the endpoint is to authenticate, then either it has an identity of its > own, or else it "borrows" an identity supplied by a user of the device. The > effect is the same to the other end. > > And if neither is the case, and so it can't authenticate, it still has some > asserted identity, even if it is Anonymous. > > Thanks, > Paul > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Monday, July 20, 2015 6:33 PM >> To: Roni Even; 'CLUE' >> Subject: Re: [clue] Unauthenticated participants >> >> On 7/20/15 11:20 AM, Roni Even wrote: >>> Hi Paul, >>> One more point that I forgot during the session is that we have an >>> issue about whom are we authenticating. The CLUE system or the user. >>> If the user comes to a conference room and just uses a system than >>> there is no user to authenticate. >>> Authentication can happen if he registers with the Tele-presence >>> system. So we either authenticate the system or are unable to >>> authenticate. I will write some text about this issue in the security >>> section >> >> Ultimately we are authenticating the UA. It may be for a room with >> lots of people, or for a focus, or a UA for an individual user. >> Doesn't matter. What matters is how much trust we put into the content >> of the advertisements received from that UA. >> >> It is of special concern for a focus. A focus will typically send out >> advertisements that are constructed, in part, from information it >> receives from other connected UAs. That information can come both from >> received advertisements and from sip signaling. >> >> If the focus has an unauthenticated UA attached, it could severely >> restrict what it says about that. (It could just include the streams >> received, without any identification.) >> >> OTOH, even in that case it could be useful to include more, even if it >> isn't trusted. For instance, for a non-clue client it might want to >> create a scene and identify it based on the From. For an >> unauthenticated clue UA it might want to include some or all of the >> received advertisement. But in these cases there ought to be an >> indication to the recipients of the advertisement from the focus that this > info isn't to be trusted. >> >> Thanks, >> Paul >> >>> Roni >>> >>> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: Monday, July 20, 2015 3:16 PM >>> To: CLUE >>> Subject: [clue] Unauthenticated participants >>> >>> Followup to discussion in session today: >>> >>> A question came up about whether participants must be authenticated. >>> IIUC the answer is no. At the least, there could be participants into >>> a conference who don't support clue and aren't authenticated, while >>> other participants do support clue. >>> >>> When the focus sends out an advertisement, all the participant info >>> in that advertisement is an assertion by it. So when I receive an >>> advertisement I base my trust in it on my level of trust in the >>> advertiser. If the focus is forwarding participant info that it >>> received in advertisements from other participants, then it ought to >>> vet >> that info before passing it on. >>> >>> It could be useful to add a property to the participant info >>> indicating whether the participant has been authenticated. With >>> appropriate words, this could allow the focus to forward along >>> participant properties even when it cannot vouch for them. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> >> > > From nobody Wed Jul 22 10:40:18 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 7E6631A907A for ; Wed, 22 Jul 2015 10:40:17 -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 fqumX5jkxVV2 for ; Wed, 22 Jul 2015 10:40:15 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 A97E21A0197 for ; Wed, 22 Jul 2015 10:40:14 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so91219116wic.0 for ; Wed, 22 Jul 2015 10:40:13 -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=UqGegm/lVc6nUzcZN09iU2sWn5W/efIPOab2U7miUAA=; b=B5seoXm18Bt5NdjX+3ljOH65VTcTdjFso31UXr9mkevJQPF/xxxzwFdEB3p4h/u6c6 3CfpvmhuwUiFApSlhIeaWsXvJhhBuxu7JYFabfiwaslRyaw6FNnGmHlt0wNdK2NygPgp 8T8kC1Vlvs/4m1FEE2+OGhDENRTTrhfKSxDFLOAAFBNEY/G2XW5A0CFVEukfiZd5W1jE NbB2FbUBpQc3RgsfXkVlT5PAC5s2Kacg03InCWVngZZOj1TvOle/bsY1CPwbeTdP5h4u YS+R2PEr0w/7BWyLfQA+ZwFEd7t4oM9Z22ZnbCvqgXoAucpqOduZP6B+cynK8axAhLtI Ckig== X-Received: by 10.194.203.3 with SMTP id km3mr6943255wjc.114.1437586813410; Wed, 22 Jul 2015 10:40:13 -0700 (PDT) Received: from RoniPC ([2001:67c:370:160:1da8:f901:a537:f42b]) by smtp.gmail.com with ESMTPSA id ym2sm3386473wjc.44.2015.07.22.10.40.12 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Jul 2015 10:40:12 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , "'CLUE'" References: <55ACE688.1000207@alum.mit.edu> <01fa01d0c2ff$9f29f340$dd7dd9c0$@gmail.com> <55AD14C6.9000906@alum.mit.edu> <002901d0c310$7f904a00$7eb0de00$@gmail.com> <55AD3371.2040605@alum.mit.edu> <006601d0c495$74fca530$5ef5ef90$@gmail.com> <55AFC154.9020205@alum.mit.edu> In-Reply-To: <55AFC154.9020205@alum.mit.edu> Date: Wed, 22 Jul 2015 20:40:10 +0300 Message-ID: <00a601d0c4a5$757627b0$60627710$@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/OtzvXYA3QIwvpUlAqm7EesCOxvRvgH5GrHtAUaK5SgCv5a/gpxvJE6g Content-Language: he Archived-At: 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: Wed, 22 Jul 2015 17:40:17 -0000 Paul, All this discussion is about what to say in the security section and we need to say if authentication and authorization is a MUST and if not explain why not/ Note that part of the advertisement includes the x-card which adds other security concerns related to the above decision, if we allow un-authorized users can they get the x-card information? Roni -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Wednesday, July 22, 2015 7:14 PM To: Roni Even; 'CLUE' Subject: Re: [clue] Unauthenticated participants On 7/22/15 11:45 AM, Roni Even wrote: > Hi Paul, > The difference will be with the x-card information, if no user-id it > will say probably the name of the conference room. I think we may be talking past one another. If a UA representing a room connects to an MCU, the MCU only knows the identity based on what is in the signaling, including authentication, and what is in the advertisement from the room. If there is no authentication, then all of that information is suspect. When you say "if no user-id it will probably name the room", I think you must be talking about policies of room system - that it allows some person in the room to provide authentication information, or else authenticates with a default for the room. IMO such policies are not within our scope. (It seems equally likely that a room might simply connect without authenticating if no user-id is given, or that it might *always* connect with its own identity/credentials and give no option for user supplied credentials.) > One question will be if we allow a room that has no identification to > join as un-authorize, IMO this is not a choice that we should make. This should be a deployment policy of individual clue devices. > it may be allowed in which case the conference server should be > cautious about what he sends as advertisement to it. This is something > we can mention in the security section Roni A warning is a good idea. But beyond that, the question is whether, if an MCU allows an unauthenticated device to connect, is there a way for it to indicate the unauthenticated status of the info from that device to be reported to the other participants of the conference. This isn't something that was considered. But I think it would be a good idea. I think a possible way to do this would be to add an attribute (boolean: 'authenticated') about this to the scene attributes. Thanks, Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Monday, July 20, 2015 8:44 PM > To: Roni Even; 'CLUE' > Subject: Re: [clue] Unauthenticated participants > > On 7/20/15 1:21 PM, Roni Even wrote: >> Hi Paul, >> You assume that the endpoint has an identity for authentication which >> is not always the case Roni > > If the endpoint is to authenticate, then either it has an identity of > its own, or else it "borrows" an identity supplied by a user of the > device. The effect is the same to the other end. > > And if neither is the case, and so it can't authenticate, it still has > some asserted identity, even if it is Anonymous. > > Thanks, > Paul > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Monday, July 20, 2015 6:33 PM >> To: Roni Even; 'CLUE' >> Subject: Re: [clue] Unauthenticated participants >> >> On 7/20/15 11:20 AM, Roni Even wrote: >>> Hi Paul, >>> One more point that I forgot during the session is that we have an >>> issue about whom are we authenticating. The CLUE system or the user. >>> If the user comes to a conference room and just uses a system than >>> there is no user to authenticate. >>> Authentication can happen if he registers with the Tele-presence >>> system. So we either authenticate the system or are unable to >>> authenticate. I will write some text about this issue in the >>> security section >> >> Ultimately we are authenticating the UA. It may be for a room with >> lots of people, or for a focus, or a UA for an individual user. >> Doesn't matter. What matters is how much trust we put into the >> content of the advertisements received from that UA. >> >> It is of special concern for a focus. A focus will typically send out >> advertisements that are constructed, in part, from information it >> receives from other connected UAs. That information can come both >> from received advertisements and from sip signaling. >> >> If the focus has an unauthenticated UA attached, it could severely >> restrict what it says about that. (It could just include the streams >> received, without any identification.) >> >> OTOH, even in that case it could be useful to include more, even if >> it isn't trusted. For instance, for a non-clue client it might want >> to create a scene and identify it based on the From. For an >> unauthenticated clue UA it might want to include some or all of the >> received advertisement. But in these cases there ought to be an >> indication to the recipients of the advertisement from the focus that >> this > info isn't to be trusted. >> >> Thanks, >> Paul >> >>> Roni >>> >>> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: Monday, July 20, 2015 3:16 PM >>> To: CLUE >>> Subject: [clue] Unauthenticated participants >>> >>> Followup to discussion in session today: >>> >>> A question came up about whether participants must be authenticated. >>> IIUC the answer is no. At the least, there could be participants >>> into a conference who don't support clue and aren't authenticated, >>> while other participants do support clue. >>> >>> When the focus sends out an advertisement, all the participant info >>> in that advertisement is an assertion by it. So when I receive an >>> advertisement I base my trust in it on my level of trust in the >>> advertiser. If the focus is forwarding participant info that it >>> received in advertisements from other participants, then it ought to >>> vet >> that info before passing it on. >>> >>> It could be useful to add a property to the participant info >>> indicating whether the participant has been authenticated. With >>> appropriate words, this could allow the focus to forward along >>> participant properties even when it cannot vouch for them. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> >> > > From nobody Wed Jul 22 11:06:58 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 AEA011A1B62 for ; Wed, 22 Jul 2015 11:06:48 -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 elKKlJ_lGKYp for ; Wed, 22 Jul 2015 11:06:46 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F048F1A0065 for ; Wed, 22 Jul 2015 11:05:16 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-03v.sys.comcast.net with comcast id vW3i1q0032LrikM01W5GHr; Wed, 22 Jul 2015 18:05:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-12v.sys.comcast.net with comcast id vW5F1q00Q3Ge9ey01W5F1u; Wed, 22 Jul 2015 18:05:16 +0000 Message-ID: <55AFDB5A.7070608@alum.mit.edu> Date: Wed, 22 Jul 2015 14:05:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Roni Even , 'CLUE' References: <55ACE688.1000207@alum.mit.edu> <01fa01d0c2ff$9f29f340$dd7dd9c0$@gmail.com> <55AD14C6.9000906@alum.mit.edu> <002901d0c310$7f904a00$7eb0de00$@gmail.com> <55AD3371.2040605@alum.mit.edu> <006601d0c495$74fca530$5ef5ef90$@gmail.com> <55AFC154.9020205@alum.mit.edu> <00a601d0c4a5$757627b0$60627710$@gmail.com> In-Reply-To: <00a601d0c4a5$757627b0$60627710$@gmail.com> 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=1437588316; bh=9t3yMNu25bghVQ2JAi6e9dBaltQbT8IVbJVeN3ZzlJo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UMzBby6hXvZYsYijwf1sctnx/eigqW0bsAcEmE3PWrc//r1sNok33h01K9EYdPHBr /Sc7XG+5NgRFONisjmyQTHT7UDG7S71XBv+8GKlrj+6NFCb4zM4++IMgtXRVcQMNDP hZYiMVkVQzOgARjGxM2Us2f/Z145UYwyMcyurIpfz5tq+Zen+Q4NLz35uAExPDGXno jq+E/KgbqNs/rd4G0r5D4WRZ9vsPp4Tp1Dnisrt0mdceEyTAidNn6yT8QLu9eky15U SM+Lx4e3Fp0kkUF2FsCV1w77PMKiWIKCESGUiu8tL24U/EgAmAGiwIyksEuJq+aYeB eVACFAPp3LeAA== Archived-At: 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: Wed, 22 Jul 2015 18:06:48 -0000 On 7/22/15 1:40 PM, Roni Even wrote: > Paul, > All this discussion is about what to say in the security section and we need > to say if authentication and authorization is a MUST and if not explain why > not/ > Note that part of the advertisement includes the x-card which adds other > security concerns related to the above decision, if we allow un-authorized > users can they get the x-card information? ISTM that practically speaking an implementation should have the option of allowing unauthenticated peers. Suppose you have a conference that is intentionally open to all callers. How do you authenticate them? Also, when MCU calls out to participants, how does it authenticate them? Clearly the info from unauthenticated participants needs to be taken with a grain of salt. But they ought to be allowed if policy permits. So, ISTM that the security section should say that every clue endpoint SHOULD authenticate its peer endpoints, with mention that this can be overridden by policy. And then have some special considerations for peers that have not been authenticated. But that does put us into a box. What do we say about *how* the peer is authenticated? IIRC we currently just punt to basic SIP mechanisms. But those are pretty weak - just the digest authentication mechanism. Normally that is used at registration time. It could be used between clue devices, but would require every one to hold a secret about the other. And we would need to figure out how to use it bidirectionally. An alternate way would be to rely on P-Asserted-ID, but that only works in certain environments. I'd like to have a security person chime in here. Thanks, Paul > Roni > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Wednesday, July 22, 2015 7:14 PM > To: Roni Even; 'CLUE' > Subject: Re: [clue] Unauthenticated participants > > On 7/22/15 11:45 AM, Roni Even wrote: >> Hi Paul, >> The difference will be with the x-card information, if no user-id it >> will say probably the name of the conference room. > > I think we may be talking past one another. > > If a UA representing a room connects to an MCU, the MCU only knows the > identity based on what is in the signaling, including authentication, and > what is in the advertisement from the room. If there is no authentication, > then all of that information is suspect. > > When you say "if no user-id it will probably name the room", I think you > must be talking about policies of room system - that it allows some person > in the room to provide authentication information, or else authenticates > with a default for the room. IMO such policies are not within our scope. (It > seems equally likely that a room might simply connect without authenticating > if no user-id is given, or that it might > *always* connect with its own identity/credentials and give no option for > user supplied credentials.) > >> One question will be if we allow a room that has no identification to >> join as un-authorize, > > IMO this is not a choice that we should make. This should be a deployment > policy of individual clue devices. > >> it may be allowed in which case the conference server should be >> cautious about what he sends as advertisement to it. This is something >> we can mention in the security section Roni > > A warning is a good idea. > > But beyond that, the question is whether, if an MCU allows an > unauthenticated device to connect, is there a way for it to indicate the > unauthenticated status of the info from that device to be reported to the > other participants of the conference. This isn't something that was > considered. But I think it would be a good idea. > > I think a possible way to do this would be to add an attribute (boolean: > 'authenticated') about this to the scene attributes. > > Thanks, > Paul > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Monday, July 20, 2015 8:44 PM >> To: Roni Even; 'CLUE' >> Subject: Re: [clue] Unauthenticated participants >> >> On 7/20/15 1:21 PM, Roni Even wrote: >>> Hi Paul, >>> You assume that the endpoint has an identity for authentication which >>> is not always the case Roni >> >> If the endpoint is to authenticate, then either it has an identity of >> its own, or else it "borrows" an identity supplied by a user of the >> device. The effect is the same to the other end. >> >> And if neither is the case, and so it can't authenticate, it still has >> some asserted identity, even if it is Anonymous. >> >> Thanks, >> Paul >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Monday, July 20, 2015 6:33 PM >>> To: Roni Even; 'CLUE' >>> Subject: Re: [clue] Unauthenticated participants >>> >>> On 7/20/15 11:20 AM, Roni Even wrote: >>>> Hi Paul, >>>> One more point that I forgot during the session is that we have an >>>> issue about whom are we authenticating. The CLUE system or the user. >>>> If the user comes to a conference room and just uses a system than >>>> there is no user to authenticate. >>>> Authentication can happen if he registers with the Tele-presence >>>> system. So we either authenticate the system or are unable to >>>> authenticate. I will write some text about this issue in the >>>> security section >>> >>> Ultimately we are authenticating the UA. It may be for a room with >>> lots of people, or for a focus, or a UA for an individual user. >>> Doesn't matter. What matters is how much trust we put into the >>> content of the advertisements received from that UA. >>> >>> It is of special concern for a focus. A focus will typically send out >>> advertisements that are constructed, in part, from information it >>> receives from other connected UAs. That information can come both >>> from received advertisements and from sip signaling. >>> >>> If the focus has an unauthenticated UA attached, it could severely >>> restrict what it says about that. (It could just include the streams >>> received, without any identification.) >>> >>> OTOH, even in that case it could be useful to include more, even if >>> it isn't trusted. For instance, for a non-clue client it might want >>> to create a scene and identify it based on the From. For an >>> unauthenticated clue UA it might want to include some or all of the >>> received advertisement. But in these cases there ought to be an >>> indication to the recipients of the advertisement from the focus that >>> this >> info isn't to be trusted. >>> >>> Thanks, >>> Paul >>> >>>> Roni >>>> >>>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Monday, July 20, 2015 3:16 PM >>>> To: CLUE >>>> Subject: [clue] Unauthenticated participants >>>> >>>> Followup to discussion in session today: >>>> >>>> A question came up about whether participants must be authenticated. >>>> IIUC the answer is no. At the least, there could be participants >>>> into a conference who don't support clue and aren't authenticated, >>>> while other participants do support clue. >>>> >>>> When the focus sends out an advertisement, all the participant info >>>> in that advertisement is an assertion by it. So when I receive an >>>> advertisement I base my trust in it on my level of trust in the >>>> advertiser. If the focus is forwarding participant info that it >>>> received in advertisements from other participants, then it ought to >>>> vet >>> that info before passing it on. >>>> >>>> It could be useful to add a property to the participant info >>>> indicating whether the participant has been authenticated. With >>>> appropriate words, this could allow the focus to forward along >>>> participant properties even when it cannot vouch for them. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> >>> >>> >> >> > > From nobody Fri Jul 24 01:14:04 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 9EEB51B302C for ; Fri, 24 Jul 2015 01:14:02 -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_40=-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 0hJFCybPQuyT for ; Fri, 24 Jul 2015 01:14:01 -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 44F031B3024 for ; Fri, 24 Jul 2015 01:14:01 -0700 (PDT) Received: from ppp118-209-217-193.lns20.mel8.internode.on.net ([118.209.217.193]:52133 helo=[192.168.1.126]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZIY7D-003HYp-AT for clue@ietf.org; Fri, 24 Jul 2015 18:13:59 +1000 To: clue@ietf.org References: <55ACE688.1000207@alum.mit.edu> <55AD1A7B.7060001@alum.mit.edu> <006701d0c496$a2ff8e60$e8feab20$@gmail.com> From: Christian Groves Message-ID: <55B1F3B3.2010706@nteczone.com> Date: Fri, 24 Jul 2015 18:13:39 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <006701d0c496$a2ff8e60$e8feab20$@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] 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: Fri, 24 Jul 2015 08:14:02 -0000 On 23/07/2015 1:53 AM, Roni Even wrote: > Is there a way to prevent it? So it allows anyone to claim a role in the > conference or provide some job title? Any suggestions? I don't see that its much different from today's conferences. I can participate and verbally say that I'm John Chambers or hold my business card saying John Chambers up to the camera. The MCU will forward that information with out caring about the contents. Vcard is just a convenient textual way of doing the same thing. I don't think its up to the MCU to try to determine whether the contents is correct or not. Regards, Christian From nobody Fri Jul 24 02:12:19 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 433DC1A6EE7 for ; Fri, 24 Jul 2015 02:12:18 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 vXCAvH4tfWMo for ; Fri, 24 Jul 2015 02:12:15 -0700 (PDT) Received: from hwsga01-in.huaweimarine.com (hwsga01-in.huaweimarine.com [119.145.15.223]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078481A1A11 for ; Fri, 24 Jul 2015 02:12:13 -0700 (PDT) Received: from 172.24.1.79 (EHLO szxpml405-hub.exmail.huawei.com) ([172.24.1.79]) by szxrg11-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOH07150; Fri, 24 Jul 2015 17:11:58 +0800 (CST) Received: from SZXPML507-MBS.exmail.huawei.com ([169.254.3.206]) by szxpml405-hub.exmail.huawei.com ([10.82.67.69]) with mapi id 14.03.0158.001; Fri, 24 Jul 2015 17:11:52 +0800 From: Roni Even To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Unauthenticated participants Thread-Index: AQHQwuXjB1DHpWYWBUC2fOKyfsm59p3j/byAgAMjlYCAAqQRgIAAlaPI Date: Fri, 24 Jul 2015 09:11:51 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C24D095D0A@szxpml507-mbs.exmail.huawei.com> References: <55ACE688.1000207@alum.mit.edu> <55AD1A7B.7060001@alum.mit.edu> <006701d0c496$a2ff8e60$e8feab20$@gmail.com>,<55B1F3B3.2010706@nteczone.com> In-Reply-To: <55B1F3B3.2010706@nteczone.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: 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: Fri, 24 Jul 2015 09:12:18 -0000 Hi Christian, This is just a concern we need to mention in the security section if we all= ow unauthentcated participants to the conference . It is more about supplyi= ng "true" v-card information to all participants even if joined without aut= hentication. Roni ________________________________________ From: clue [clue-bounces@ietf.org] on behalf of Christian Groves [Christian= .Groves@nteczone.com] Sent: Friday, July 24, 2015 11:13 AM To: clue@ietf.org Subject: Re: [clue] Unauthenticated participants On 23/07/2015 1:53 AM, Roni Even wrote: > Is there a way to prevent it? So it allows anyone to claim a role in the > conference or provide some job title? Any suggestions? I don't see that its much different from today's conferences. I can participate and verbally say that I'm John Chambers or hold my business card saying John Chambers up to the camera. The MCU will forward that information with out caring about the contents. Vcard is just a convenient textual way of doing the same thing. I don't think its up to the MCU to try to determine whether the contents is correct or not. Regards, Christian _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From nobody Fri Jul 24 11:11:19 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 3D71D1A8AC7 for ; Fri, 24 Jul 2015 11:11:18 -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 jNejhos70Uv8 for ; Fri, 24 Jul 2015 11:11:17 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1F2D1A8ABE for ; Fri, 24 Jul 2015 11:11:16 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-11v.sys.comcast.net with comcast id wJAF1q0062Ka2Q501JBGLk; Fri, 24 Jul 2015 18:11:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-11v.sys.comcast.net with comcast id wJBF1q00Z3Ge9ey01JBFFA; Fri, 24 Jul 2015 18:11:16 +0000 Message-ID: <55B27FC3.1090602@alum.mit.edu> Date: Fri, 24 Jul 2015 14:11:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: clue@ietf.org References: <55ACE688.1000207@alum.mit.edu> <55AD1A7B.7060001@alum.mit.edu> <006701d0c496$a2ff8e60$e8feab20$@gmail.com>, <55B1F3B3.2010706@nteczone.com> <760B7D45D1EFF74988DBF5C2122830C24D095D0A@szxpml507-mbs.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C24D095D0A@szxpml507-mbs.exmail.huawei.com> 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=1437761476; bh=B1M3ZlHOdvPn25d7GDBCT6JHXLjbR1B6Cl/BOAnE6Xc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jKe24HREfWihvlOoESKXl9h3QGeP+5EMfjQIilOrCNmHC+xzLdRgEwsw7AHnutMlm 3CrMG5UrFhbMVlT/a/vS+lPtyuHg4jOikAD0XrU+crjr6u+vFrNLZRy0h+sDPuNlU7 7x7HkuubrNYbcWFpm3Ghy5CsByjQT39AW4V/SfYJMi5clIQHud1B+Lfvdp+GSbWrun xrBqvr0SBVBZuw105xo73sPEotf/MSARIkrxGJMIK8b81KX/adVhJbaGA75P3qRuG4 VOBf2tHbzL6C30s/CN9pKg4D7JJXvTiVDrmUaHdfqEQp8TPraD/zYOzGJPGTFwBLOY WZHnvAssbwkbA== Archived-At: 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: Fri, 24 Jul 2015 18:11:18 -0000 On 7/24/15 5:11 AM, Roni Even wrote: > Hi Christian, > This is just a concern we need to mention in the security section if we allow unauthentcated participants to the conference . It is more about supplying "true" v-card information to all participants even if joined without authentication. > Roni Perhaps something like: "All descriptive information in an advertisement, including vcards, is asserted by the advertiser. Advertisers should vet received information before placing it in an advertisement. Consumers of advertisements should consider their trust in the advertiser when evaluating that information." Thanks, Paul > ________________________________________ > From: clue [clue-bounces@ietf.org] on behalf of Christian Groves [Christian.Groves@nteczone.com] > Sent: Friday, July 24, 2015 11:13 AM > To: clue@ietf.org > Subject: Re: [clue] Unauthenticated participants > > On 23/07/2015 1:53 AM, Roni Even wrote: >> Is there a way to prevent it? So it allows anyone to claim a role in the >> conference or provide some job title? Any suggestions? > > I don't see that its much different from today's conferences. I can > participate and verbally say that I'm John Chambers or hold my business > card saying John Chambers up to the camera. The MCU will forward that > information with out caring about the contents. Vcard is just a > convenient textual way of doing the same thing. I don't think its up to > the MCU to try to determine whether the contents is correct or not. > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jul 27 21:47:07 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 188E41A1A64 for ; Mon, 27 Jul 2015 21:47:07 -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_50=0.8, 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 dvciQwZn8moS for ; Mon, 27 Jul 2015 21:47: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 E2DC31A1A55 for ; Mon, 27 Jul 2015 21:47:04 -0700 (PDT) Received: from ppp118-209-108-248.lns20.mel4.internode.on.net ([118.209.108.248]:51824 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZJwmR-001J9a-2Z for clue@ietf.org; Tue, 28 Jul 2015 14:47:01 +1000 To: clue@ietf.org References: <55ACE688.1000207@alum.mit.edu> <55AD1A7B.7060001@alum.mit.edu> <006701d0c496$a2ff8e60$e8feab20$@gmail.com> <55B1F3B3.2010706@nteczone.com> <760B7D45D1EFF74988DBF5C2122830C24D095D0A@szxpml507-mbs.exmail.huawei.com> <55B27FC3.1090602@alum.mit.edu> From: Christian Groves Message-ID: <55B70918.3050208@nteczone.com> Date: Tue, 28 Jul 2015 14:46:16 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B27FC3.1090602@alum.mit.edu> 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] 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, 28 Jul 2015 04:47:07 -0000 Basically "all" the information in an advertisement is asserted by the advertising endpoint. Nearly all the information provided in an Advertisement would have to be configured by someone. They may input different capture area, say the view is a room instead of a table etc. How does the advertiser "vet" the information? Maybe we should take the approach of categorising who can set the information as to the level of "trust"? E.g. The information asserted by an Advertising endpoint may be configured by different sources. It is likely that attributes are set by the sources below. Endpoint owner set: - Point of Capture - Point on Line of Capture - Area of Capture - Mobility of Capture - Audio Capture Sensitivity Pattern - Description - Presentation - View - Embedded Text - Scene Information - Scale Information - Scene Description Participant Set: - Language - Person Information - Person Type - Priority - Related to System set: - MCC Attributes For endpoint owner and system set attributes the Consumer should consider their trust in the advertiser. For participant set attributes the Consumer should consider their trust in the advertiser and be aware that the advertiser may not be able verify the information provided to it by the participant irrespective of whether the participant has been authenticated with the advertising endpoint. The attributes above could also be represented as a table. Thoughts? Regards, Christian On 25/07/2015 4:11 AM, Paul Kyzivat wrote: > On 7/24/15 5:11 AM, Roni Even wrote: >> Hi Christian, >> This is just a concern we need to mention in the security section if >> we allow unauthentcated participants to the conference . It is more >> about supplying "true" v-card information to all participants even if >> joined without authentication. >> Roni > > Perhaps something like: > > "All descriptive information in an advertisement, including vcards, is > asserted by the advertiser. Advertisers should vet received > information before placing it in an advertisement. Consumers of > advertisements should consider their trust in the advertiser when > evaluating that information." > > Thanks, > Paul > >> ________________________________________ >> From: clue [clue-bounces@ietf.org] on behalf of Christian Groves >> [Christian.Groves@nteczone.com] >> Sent: Friday, July 24, 2015 11:13 AM >> To: clue@ietf.org >> Subject: Re: [clue] Unauthenticated participants >> >> On 23/07/2015 1:53 AM, Roni Even wrote: >>> Is there a way to prevent it? So it allows anyone to claim a role >>> in the >>> conference or provide some job title? Any suggestions? >> >> I don't see that its much different from today's conferences. I can >> participate and verbally say that I'm John Chambers or hold my business >> card saying John Chambers up to the camera. The MCU will forward that >> information with out caring about the contents. Vcard is just a >> convenient textual way of doing the same thing. I don't think its up to >> the MCU to try to determine whether the contents is correct or not. >> >> Regards, Christian >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Jul 28 06:48:53 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 105101A907B for ; Tue, 28 Jul 2015 06:48:52 -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 M9Isa5GD1HKm for ; Tue, 28 Jul 2015 06:48:50 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553F51A9074 for ; Tue, 28 Jul 2015 06:48:49 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-05v.sys.comcast.net with comcast id xpoH1q0012N9P4d01pooDf; Tue, 28 Jul 2015 13:48:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-13v.sys.comcast.net with comcast id xpok1q00N3Ge9ey01pom5R; Tue, 28 Jul 2015 13:48:48 +0000 Message-ID: <55B7883B.60901@alum.mit.edu> Date: Tue, 28 Jul 2015 09:48:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: clue@ietf.org References: <55ACE688.1000207@alum.mit.edu> <55AD1A7B.7060001@alum.mit.edu> <006701d0c496$a2ff8e60$e8feab20$@gmail.com> <55B1F3B3.2010706@nteczone.com> <760B7D45D1EFF74988DBF5C2122830C24D095D0A@szxpml507-mbs.exmail.huawei.com> <55B27FC3.1090602@alum.mit.edu> <55B70918.3050208@nteczone.com> In-Reply-To: <55B70918.3050208@nteczone.com> 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=1438091328; bh=IrPoNnFaLOgPM46GasM2G9975RKOKzsH0WOE1bxKzM0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=vAFHA0uabwxjJnzMBGOuWh6aOJX9+Xi7xrxfuJggErm7ORc+4WbUHmAiuW3IcHeyk 9nwV6DU/SdPtLBV7qdebmhwd4guce6dwVAxtGhBd+xBOIaq3+e+o3GHlqyITrHiQow tXf5ZJyIP/yLz1MnuiW5tVFCZXlkW3+NLEvJr409Xwd+QjFkIWidNAmHqsgvSILveG Vg6XBhbWFdaeVwH5r263TPTOMjuwa/Jyu3TcKDhJxKHsAADEJdazbwqR+WTD03MdaA uf3t+0+Rdxnr9FUaNOham36Izl3tbo5L+2SckLkh051SFmVH3uS+DKokRihQ+BSRCA J7OFq1u3z8WBg== Archived-At: 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, 28 Jul 2015 13:48:52 -0000 Christian, I'm ok with what you say. but there may be more to say. Users of an endpoint can only determine their trust in the received advertisement based on their trust in the endpoint they are connected to. They may or may not know it is an MCU. And if they do know it is an MCU, they may not know where it gets its information or how it verifies it. It may be helpful to say something more about the responsibilities of MCUs. In particular, point out when they pass along received information they are implicitly endorsing it. So they SHOULD only do so when they can verify the identity of the source. Thanks, Paul On 7/28/15 12:46 AM, Christian Groves wrote: > Basically "all" the information in an advertisement is asserted by the > advertising endpoint. Nearly all the information provided in an > Advertisement would have to be configured by someone. They may input > different capture area, say the view is a room instead of a table etc. > How does the advertiser "vet" the information? > > Maybe we should take the approach of categorising who can set the > information as to the level of "trust"? > > E.g. The information asserted by an Advertising endpoint may be > configured by different sources. It is likely that attributes are set by > the sources below. > Endpoint owner set: > - Point of Capture > - Point on Line of Capture > - Area of Capture > - Mobility of Capture > - Audio Capture Sensitivity Pattern > - Description > - Presentation > - View > - Embedded Text > - Scene Information > - Scale Information > - Scene Description > > Participant Set: > - Language > - Person Information > - Person Type > - Priority > - Related to > > System set: > - MCC Attributes > > For endpoint owner and system set attributes the Consumer should > consider their trust in the advertiser. For participant set attributes > the Consumer should consider their trust in the advertiser and be aware > that the advertiser may not be able verify the information provided to > it by the participant irrespective of whether the participant has been > authenticated with the advertising endpoint. > > The attributes above could also be represented as a table. > > Thoughts? > > Regards, Christian > > On 25/07/2015 4:11 AM, Paul Kyzivat wrote: >> On 7/24/15 5:11 AM, Roni Even wrote: >>> Hi Christian, >>> This is just a concern we need to mention in the security section if >>> we allow unauthentcated participants to the conference . It is more >>> about supplying "true" v-card information to all participants even if >>> joined without authentication. >>> Roni >> >> Perhaps something like: >> >> "All descriptive information in an advertisement, including vcards, is >> asserted by the advertiser. Advertisers should vet received >> information before placing it in an advertisement. Consumers of >> advertisements should consider their trust in the advertiser when >> evaluating that information." >> >> Thanks, >> Paul >> >>> ________________________________________ >>> From: clue [clue-bounces@ietf.org] on behalf of Christian Groves >>> [Christian.Groves@nteczone.com] >>> Sent: Friday, July 24, 2015 11:13 AM >>> To: clue@ietf.org >>> Subject: Re: [clue] Unauthenticated participants >>> >>> On 23/07/2015 1:53 AM, Roni Even wrote: >>>> Is there a way to prevent it? So it allows anyone to claim a role >>>> in the >>>> conference or provide some job title? Any suggestions? >>> >>> I don't see that its much different from today's conferences. I can >>> participate and verbally say that I'm John Chambers or hold my business >>> card saying John Chambers up to the camera. The MCU will forward that >>> information with out caring about the contents. Vcard is just a >>> convenient textual way of doing the same thing. I don't think its up to >>> the MCU to try to determine whether the contents is correct or not. >>> >>> Regards, Christian >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Jul 28 21:27:58 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 A69E31A0461 for ; Tue, 28 Jul 2015 21:27:57 -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_40=-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 EajNS-YpXd_q for ; Tue, 28 Jul 2015 21:27:55 -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 B227C1A0439 for ; Tue, 28 Jul 2015 21:27:54 -0700 (PDT) Received: from ppp118-209-255-222.lns20.mel8.internode.on.net ([118.209.255.222]:54750 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZKIy8-000roZ-C0 for clue@ietf.org; Wed, 29 Jul 2015 14:27:52 +1000 To: clue@ietf.org References: <55ACE688.1000207@alum.mit.edu> <55AD1A7B.7060001@alum.mit.edu> <006701d0c496$a2ff8e60$e8feab20$@gmail.com> <55B1F3B3.2010706@nteczone.com> <760B7D45D1EFF74988DBF5C2122830C24D095D0A@szxpml507-mbs.exmail.huawei.com> <55B27FC3.1090602@alum.mit.edu> <55B70918.3050208@nteczone.com> <55B7883B.60901@alum.mit.edu> From: Christian Groves Message-ID: <55B85644.5050200@nteczone.com> Date: Wed, 29 Jul 2015 14:27:48 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B7883B.60901@alum.mit.edu> 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] 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: Wed, 29 Jul 2015 04:27:57 -0000 Hello Paul, They're valid points. Regards, Christian On 28/07/2015 11:48 PM, Paul Kyzivat wrote: > Christian, > > I'm ok with what you say. but there may be more to say. > > Users of an endpoint can only determine their trust in the received > advertisement based on their trust in the endpoint they are connected > to. They may or may not know it is an MCU. And if they do know it is > an MCU, they may not know where it gets its information or how it > verifies it. > > It may be helpful to say something more about the responsibilities of > MCUs. In particular, point out when they pass along received > information they are implicitly endorsing it. So they SHOULD only do > so when they can verify the identity of the source. > > Thanks, > Paul > > On 7/28/15 12:46 AM, Christian Groves wrote: >> Basically "all" the information in an advertisement is asserted by the >> advertising endpoint. Nearly all the information provided in an >> Advertisement would have to be configured by someone. They may input >> different capture area, say the view is a room instead of a table etc. >> How does the advertiser "vet" the information? >> >> Maybe we should take the approach of categorising who can set the >> information as to the level of "trust"? >> >> E.g. The information asserted by an Advertising endpoint may be >> configured by different sources. It is likely that attributes are set by >> the sources below. >> Endpoint owner set: >> - Point of Capture >> - Point on Line of Capture >> - Area of Capture >> - Mobility of Capture >> - Audio Capture Sensitivity Pattern >> - Description >> - Presentation >> - View >> - Embedded Text >> - Scene Information >> - Scale Information >> - Scene Description >> >> Participant Set: >> - Language >> - Person Information >> - Person Type >> - Priority >> - Related to >> >> System set: >> - MCC Attributes >> >> For endpoint owner and system set attributes the Consumer should >> consider their trust in the advertiser. For participant set attributes >> the Consumer should consider their trust in the advertiser and be aware >> that the advertiser may not be able verify the information provided to >> it by the participant irrespective of whether the participant has been >> authenticated with the advertising endpoint. >> >> The attributes above could also be represented as a table. >> >> Thoughts? >> >> Regards, Christian >> >> On 25/07/2015 4:11 AM, Paul Kyzivat wrote: >>> On 7/24/15 5:11 AM, Roni Even wrote: >>>> Hi Christian, >>>> This is just a concern we need to mention in the security section if >>>> we allow unauthentcated participants to the conference . It is more >>>> about supplying "true" v-card information to all participants even if >>>> joined without authentication. >>>> Roni >>> >>> Perhaps something like: >>> >>> "All descriptive information in an advertisement, including vcards, is >>> asserted by the advertiser. Advertisers should vet received >>> information before placing it in an advertisement. Consumers of >>> advertisements should consider their trust in the advertiser when >>> evaluating that information." >>> >>> Thanks, >>> Paul >>> >>>> ________________________________________ >>>> From: clue [clue-bounces@ietf.org] on behalf of Christian Groves >>>> [Christian.Groves@nteczone.com] >>>> Sent: Friday, July 24, 2015 11:13 AM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Unauthenticated participants >>>> >>>> On 23/07/2015 1:53 AM, Roni Even wrote: >>>>> Is there a way to prevent it? So it allows anyone to claim a role >>>>> in the >>>>> conference or provide some job title? Any suggestions? >>>> >>>> I don't see that its much different from today's conferences. I can >>>> participate and verbally say that I'm John Chambers or hold my >>>> business >>>> card saying John Chambers up to the camera. The MCU will forward that >>>> information with out caring about the contents. Vcard is just a >>>> convenient textual way of doing the same thing. I don't think its >>>> up to >>>> the MCU to try to determine whether the contents is correct or not. >>>> >>>> Regards, Christian >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >