Re: [clue] Last Call: <draft-ietf-clue-rtp-mapping-10.txt> (Mapping RTP streams to CLUE Media Captures) to Proposed Standard
Paul Kyzivat <paul.kyzivat@comcast.net> Mon, 16 January 2017 20:11 UTC
Return-Path: <paul.kyzivat@comcast.net>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C27129610 for <clue@ietfa.amsl.com>; Mon, 16 Jan 2017 12:11:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Level:
X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 rkesT4xWIgEX for <clue@ietfa.amsl.com>; Mon, 16 Jan 2017 12:11:25 -0800 (PST)
Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (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 02093129640 for <clue@ietf.org>; Mon, 16 Jan 2017 12:01:30 -0800 (PST)
Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-09v.sys.comcast.net with SMTP id TDRqcA0DJ5lLvTDT8chD6I; Mon, 16 Jan 2017 20:01:30 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484596890; bh=vC6k8jtUkqrvlsTb+ep6k6LG2OF3YVr9S0oiGSc/RrY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=OYZkPbHnlu4uBbpXqroVQ+uDh4fPGuiF3a32QhuPZhaxxwlvyz/K65mmrAACTtG/h mtV6qbrluDJmQUBgZNLP4shYAenI10015cJBNJpoFwC+36JOp/LBm8cqQnUESOTJxC WB5q9w5sT7DJ0tOdpy3ZuIbx9n/lyaKT451IDNIn1X5bH5VPzEJ6RgyviLKGQtmJWC 6JJduN912PbgiPh4UDK3HvntAlvyapFYdW7BAOHByPQ9666UFmFiXg9sf/so6XtllW KSPHxMVDMA0XwG3DvP5K7udRXPx+QeEx+hf3RETKM35wYf2CmkcijhwPaBE+goUjr+ llyhIf9wK3gVg==
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-03v.sys.comcast.net with SMTP id TDT7c6dq3wJd1TDT7cKk2C; Mon, 16 Jan 2017 20:01:30 +0000
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Roni Even <ron.even.tlv@gmail.com>, ietf@ietf.org
References: <148244150608.26135.13003140554574277685.idtracker@ietfa.amsl.com> <e62d8fea-692f-2463-3fce-e9bfbc87293c@ericsson.com> <001901d26ef5$5c91af20$15b50d60$@gmail.com> <18e96e7e-51f4-2a38-a267-110f7f60f9aa@ericsson.com>
From: Paul Kyzivat <paul.kyzivat@comcast.net>
Message-ID: <6c1e7532-d4aa-8529-efa7-57c809afe63d@comcast.net>
Date: Mon, 16 Jan 2017 15:01:29 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <18e96e7e-51f4-2a38-a267-110f7f60f9aa@ericsson.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/Y0n7SQbzuMcm52yagr6k87k7GHc>
Cc: clue@ietf.org, clue-chairs@ietf.org, draft-ietf-clue-rtp-mapping@ietf.org
Subject: Re: [clue] Last Call: <draft-ietf-clue-rtp-mapping-10.txt> (Mapping RTP streams to CLUE Media Captures) to Proposed Standard
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jan 2017 20:11:27 -0000
On 1/16/17 8:56 AM, Magnus Westerlund wrote: > Den 2017-01-15 kl. 07:05, skrev Roni Even: >> Hi Magnus, >> CaptureID here is just conveying the value defined in the CLUE data model >> and CLUE protocol defines the security consideration for conveying the >> adertized and configured values. >> So any security on creating is done in the protocol document > > Yes, it is containing a value. And the data model and protocol documents > defines the protocol level security requirements and solution. However, > as the CaptureID is taken out of the context of the CLUE protocol, and > put into RTP/RTCP there needs to be consideration for the implications > of that action. Good point. When used within the CLUE protocol the captureID is protected by DTLS. RTP/RTCP presents new concerns. Thanks, Paul > As I don't find any recommendation for how an implementation generates > CaptureIDs I could not determine the security sensitivity of the field. > That is why I am asking about that aspect. Please provide an analysis of > what it may contain, i.e. worst case, and the appropriate recommendation > for appropriately securing that field. > >> >> As for the header extension, I will add some text > > And I think this is relevant also for SDES items in general, not only > for the header extension. The security risks and fundamental > requirements are shared anyway. > > Cheers > > Magnus > >> Roni >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Magnus Westerlund >>> Sent: Friday, January 13, 2017 2:22 PM >>> To: ietf@ietf.org >>> Cc: draft-ietf-clue-rtp-mapping@ietf.org; clue-chairs@ietf.org; >> clue@ietf.org >>> Subject: Re: [clue] Last Call: <draft-ietf-clue-rtp-mapping-10.txt> >> (Mapping RTP >>> streams to CLUE Media Captures) to Proposed Standard >>> >>> Hi, >>> >>> As one of IANA's expert reviewers for the two registries that this >> document >>> attempts to register in, I want to provide some feedback on individual >> basis and >>> directly. >>> >>> The SDES item registration of the CaptureID is fine with the exception >> that it isn't >>> clear on the security consideration for the CaptureID field as SDES >>> item. >> I fail to >>> find any limitations or even recommendations for how the value is >>> created >> by >>> the implementation. Nor does the security considerations discuss the >> potential >>> risk that the capture ID is privacy sensitive, like "Adrian's Mic" >>> rather >> than AC0 >>> as in the example in the data model document. The data model document is >>> fairly clear on the need for confidentiality and authorization for the >> whole data >>> model document. However, this thinking has not been raised and clarified >> in this >>> specific move of the information into the RTP protocol. >>> >>> So, I would recommend a discussion in general if the field should have >>> anonymous labels, that do not contain privacy information. Then one >>> needs >> to >>> be clear on what requirements that puts on transporting this field in >>> RTP. >> And >>> that depends on how certain one can be that it is anonymous or that >>> it may >>> contain sensitive information and therefore should be confidentiality >> protected. >>> In all cases this field needs integrity and source authentication. Which >> should be >>> made explicit in the security consideration. The clue mapping require >>> implementation of SRTP with DTLS-SRTP keying, however, it fails to be >> specific >>> on which protection profiles that are to be supported, both for the SRTP >> as well >>> as the crypto functions for the key handshakes in DTLS-SRTP. Thus, I >>> can't >> be >>> certain if the CaptureID will be confidentiality protected or not >>> even in >> RTCP. >>> >>> When it comes to the RTP Header Extension case, the RFC 7941 is very >> explicit >>> about the requirement on doing this security consideration. And I note >> that with >>> the above analysis of what requirements to put, one can ensure that the >> right >>> requirements on the CLUE system to protect any RTP header extension with >> the >>> CaptureID is done. I do note that if confidentiality protection is >>> needed, >> this >>> means additional implementation requirement. Such needs to be defined in >> this >>> or referenced document if that is the case. >>> >>> This should be fairly straight forward to fix, but needs to be done. >>> >>> Cheers >>> >>> Magnus >>> >>> Den 2016-12-22 kl. 22:18, skrev The IESG: >>>> >>>> The IESG has received a request from the ControLling mUltiple streams >>>> for tElepresence WG (clue) to consider the following document: >>>> - 'Mapping RTP streams to CLUE Media Captures' >>>> <draft-ietf-clue-rtp-mapping-10.txt> as Proposed Standard >>>> >>>> The IESG plans to make a decision in the next few weeks, and solicits >>>> final comments on this action. Please send substantive comments to the >>>> ietf@ietf.org mailing lists by 2017-01-12. Exceptionally, comments may >>>> be sent to iesg@ietf.org instead. In either case, please retain the >>>> beginning of the Subject line to allow automated sorting. >>>> >>>> Abstract >>>> >>>> >>>> This document describes how the Real Time transport Protocol >>>> (RTP) is >>>> used in the context of the CLUE protocol. It also describes the >>>> mechanisms and recommended practice for mapping RTP media streams >>>> defined in SDP to CLUE Media Captures. >>>> >>>> >>>> >>>> >>>> The file can be obtained via >>>> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ >>>> >>>> IESG discussion can be tracked via >>>> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ballot/ >>>> >>>> >>>> No IPR declarations have been submitted directly on this I-D. >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> >>> Magnus Westerlund >>> >>> ---------------------------------------------------------------------- >>> Services, Media and Network features, Ericsson Research EAB/TXM >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> Färögatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> > >
- [clue] Last Call: <draft-ietf-clue-rtp-mapping-10… The IESG
- Re: [clue] Last Call: <draft-ietf-clue-rtp-mappin… Magnus Westerlund
- Re: [clue] Last Call: <draft-ietf-clue-rtp-mappin… Paul Kyzivat
- Re: [clue] Last Call: <draft-ietf-clue-rtp-mappin… Roni Even
- Re: [clue] Last Call: <draft-ietf-clue-rtp-mappin… Magnus Westerlund
- Re: [clue] Last Call: <draft-ietf-clue-rtp-mappin… Paul Kyzivat