Re: [clue] Comments on CaptureID and security

Roni Even <roni.even@huawei.com> Mon, 13 February 2017 09:53 UTC

Return-Path: <roni.even@huawei.com>
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 B8E7D1293FD for <clue@ietfa.amsl.com>; Mon, 13 Feb 2017 01:53:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFii51PsW1ci for <clue@ietfa.amsl.com>; Mon, 13 Feb 2017 01:53:48 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02FB31293DF for <clue@ietf.org>; Mon, 13 Feb 2017 01:53:46 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAN60119; Mon, 13 Feb 2017 09:53:44 +0000 (GMT)
Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 13 Feb 2017 09:53:19 +0000
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0301.000; Mon, 13 Feb 2017 17:53:14 +0800
From: Roni Even <roni.even@huawei.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "clue@ietf.org" <clue@ietf.org>
Thread-Topic: [clue] Comments on CaptureID and security
Thread-Index: AQHShWijSmQVYqqcLEWleHO7iQ8uOqFmr2Tg
Date: Mon, 13 Feb 2017 09:53:13 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD773733@DGGEMM506-MBX.china.huawei.com>
References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD76DF3C@DGGEMM506-MBX.china.huawei.com> <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> <208e2d66-b7bf-8167-7c3d-6841df84192e@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD773571@DGGEMM506-MBX.china.huawei.com> <fb499e78-8715-5f3f-025a-dff04d154301@alum.mit.edu>
In-Reply-To: <fb499e78-8715-5f3f-025a-dff04d154301@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.201.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58A18228.0254, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 98a7b41afac6edef6b4b1affb1275325
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/d8D0dIW9vYG5UFqAelnOM4DK2N4>
Subject: Re: [clue] Comments on CaptureID and security
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, 13 Feb 2017 09:53:51 -0000

Paul,
My understanding is Inline
Roni

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: יום א 12 פברואר 2017 21:46
> To: Roni Even; clue@ietf.org
> Subject: Re: [clue] Comments on CaptureID and security
> 
> Roni,
> 
> On 2/12/17 5:07 AM, Roni Even wrote:
> > Paul,
> > From RFC5764
> > "RTP and RTCP traffic MAY be multiplexed on a single UDP port
> >    [RFC5761].  In this case, both RTP and RTCP packets may be sent over
> >    the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions
> >    needed.  This improves the cryptographic performance of DTLS, but may
> >    cause problems when RTCP and RTP are subject to different network
> >    treatment (e.g., for bandwidth reservation or scheduling reasons)."
> 
> My understanding of RTP/RTCP is minimal, so my questions may not make
> any sense. But as best I understand, when RTP/RTCP is run over DTLS it isn't
> sent as DTLS encrypted payload. Rather, it reuses the DTLS negotiated keys
> but then encrypts the RTP/RTCP data independently
[Roni Even] using SRTP which defines which part of the RTP / RTCP packets are encrypted
 and selectively, so some
> parts are encrypted and other parts are not.
> 
> Based on that, my question is whether, when multiplexing RTP and RTCP and
> running them over DTLS, it is automatic that the RTCP pieces are encrypted,
[Roni Even] I do not think that it is implied, dtls pass the packets to the srtp layer which decide how to secure the RTP and RTCP
> or if it is necessary to negotiate something explicit in the SDP (apart from
> what is negotiated for the RTP) to cause the RTCP data to be encrypted.
> 
> 	Thanks,
> 	Paul
> 
> > Roni
> >
> >> -----Original Message-----
> >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat
> >> Sent: יום ד 18 ינואר 2017 18:26
> >> To: clue@ietf.org
> >> Subject: Re: [clue] Comments on CaptureID and security
> >>
> >> I have a side question on this: if RTCP is being multiplexed with
> >> RTP, and the RTP is being encrypted, is the RTCP also implicitly
> >> encrypted, or is it still an independently negotiated feature?
> >>
> >> (Yes, I realize that doesn't solve the general problem for CLUE.)
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >> On 1/18/17 6:53 AM, Magnus Westerlund wrote:
> >>> Hi,
> >>>
> >>> Yes, I think encrypting the CaptureID avoids the negative impacts
> >>> that bad construction can have that I can think of. Thus, I support
> >>> going in that direction.
> >>>
> >>> When it comes to the security solution I would recommend copying the
> >>> text and then make the edits. There is at least two additions, the
> >>> MUST encrypt RTCP, and the MUST implement RFC 6904 and use it to
> >>> encrypt the CaptureID header extension. Please be explicit and clear
> >>> in the CLUE level document on what security solutions that needs to
> >>> be implemented and use.
> >>>
> >>> Reasons for copying the text, is that there are differences between
> >>> RTCWeb and CLUE, and in addition I think the implementation
> >>> considerations and potential needs to later revise the specification
> >>> are different. I am not certain CLUE will want to be required to
> >>> follow any changes that RTCWeb does in the future.
> >>>
> >>> I would also note that I think you need at least to put in a short
> >>> paragraph about the CaptureID value. Something like this.
> >>>
> >>> The construction of the CaptureID value is implementation dependent
> >>> and is not tightly restricted. Therefore there exist a risk that the
> >>> CaptureID contains privacy sensitive information or otherwise
> >>> revealing information about the communication session to third
> >>> parties. Therefore confidentiality protection is always applied to
> >>> avoid this
> >> risk.
> >>>
> >>> Cheers
> >>>
> >>> Magnus
> >>>
> >>> Den 2017-01-18 kl. 10:44, skrev Roni Even:
> >>>> Hi, The text I added to the -11 version "The CaptureID is created
> >>>> as part of the CLUE protocol.  The CaptId SDES item is used to
> >>>> convey the same CaptureID value in the SDES item.  When sending the
> >>>> SDES item the security considertion specied in the security section
> >>>> of [RFC7941] are applicable and this SDES item MUST use similar
> >>>> security as the CLUE protocol messages carried in the CLUE data
> channel."
> >>>>
> >>>> Say that  " this SDES item MUST use similar security as the CLUE
> >>>> protocol messages carried in the CLUE data channel." The CLUE data
> >>>> channel document
> >>>> https://tools.ietf.org/html/draft-ietf-clue-datachannel-14#section-
> >>>> 4
> >>>> point at
> >>>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#secti
> >>>> on
> >>>> -7
> >>>> pointing to
> >>>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10
> >>>>
> >>>> So we can reference the rtcweb security architecture or use the
> >>>> text I copied from there to define a security profile
> >>>>
> >>>> As for the second item I agree that if we encrypt the content in
> >>>> the CLUE data channel that includes the captureID, we need also to
> >>>> encrypt RTCP with the captureID SDES item and it does not matter
> >>>> how we create the captureID value, so maybe if we mandate
> >>>> encrypting the SDES item there is no strong need for specifying how
> >>>> to create CaptureID . Note that the CaptureID is not use to provide
> >>>> human-readable textual information which is in the description
> >>>> attribute.
> >>>>
> >>>> Roni
> >>>>
> >>>>> -----Original Message----- From: Magnus Westerlund
> >>>>> [mailto:magnus.westerlund@ericsson.com] Sent: יום ד 18 ינואר 2017
> >>>>> 10:45 To: Roni Even; clue@ietf.org Cc: Jonathan Lennox Subject: Re:
> >>>>> Comments on CaptureID and security
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> A comment about the below. I have an issue raised against the
> >>>>> below quoted text from the rtcweb-security-architecture in the
> >>>>> RTCWeb WG, as it fails to specify if RTCP encryption is mandatory
> >>>>> to use or not. There are protection profiles that only have
> >>>>> confidentiality protection for RTP, and not for RTCP. I would
> >>>>> recommend requiring confidentiality protection also of RTCP.
> >>>>>
> >>>>> The second note on the below is that depending on the outcome of
> >>>>> the security requirements for the CaptureID RTP header extension,
> >>>>> you might in addition have to require RFC 6904, implementation and
> >>>>> usage for the CaptureId header extension field. Or rather if you
> >>>>> write nothing it will by default be required if you encrypt RTCP,
> >>>>> due to RFC 7941. But, I really recommend that you are explicit on
> >>>>> this matter. It comes down to what security risks the field
> >>>>> entails. What information will it leak to a third party viewer of
> >>>>> the RTP/RTCP stream they can capture.
> >>>>>
> >>>>> Cheers
> >>>>>
> >>>>> Magnus
> >>>>>
> >>>>> Den 2017-01-18 kl. 09:33, skrev Roni Even:
> >>>>>> 2.       What do we want to say about supported security profile?
> >>>>>> For example does the following directive from
> >>>>>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#se
> >>>>>> ct
> >>>>>> ion-5.5
> >>>>>>
> >>>>>>
> >>>>>>
> >>> looks good for CLUE?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> “Implementations MUST implement SRTP [RFC3711
> >>>>>> <https://tools.ietf.org/html/rfc3711>].  Implementations MUST
> >>>>>>
> >>>>>> implement DTLS [RFC4347 <https://tools.ietf.org/html/rfc4347>]
> >>>>>> and DTLS-SRTP [RFC5763
> >>>>>> <https://tools.ietf.org/html/rfc5763>][RFC5764] for
> >>>>> SRTP
> >>>>>>
> >>>>>> keying.  Implementations MUST implement
> >>>>>>
> >>>>>> [I-D.ietf-tsvwg-sctp-dtls-encaps
> >>>>>> <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#r
> >>>>>> ef
> >>>>>> -I-
> >>>>>
> >>>>>>
> >>> D.ietf-tsvwg-sctp-dtls-encaps>].
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> All media channels MUST be secured via SRTP.  Media traffic MUST
> >>>>>> NOT
> >>>>>>
> >>>>>> be sent over plain (unencrypted) RTP; that is, implementations
> >>>>>> MUST
> >>>>>>
> >>>>>> NOT negotiate cipher suites with NULL encryption modes.
> >>>>>> DTLS-SRTP
> >>>>>>
> >>>>>> MUST be offered for every media channel.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> All data channels MUST be secured via DTLS.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> All implementations MUST implement DTLS 1.0, with the cipher
> >>>>>> suite
> >>>>>>
> >>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256
> curve
> >>>>>>
> >>>>>> [FIPS186
> >>>>>> <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#r
> >>>>>> ef
> >>>>>> -
> >>>>>
> >>>>>>
> >>> FIPS186>].
> >>>>>> The DTLS-SRTP protection profile
> >>>>>>
> >>>>>> SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.
> >>>>>>
> >>>>>> Implementations SHOULD implement DTLS 1.2 with the
> >>>>>>
> >>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
> >>>>>>
> >>>>>> Implementations MUST favor cipher suites which support PFS over
> >>>>>> non-
> >>>>>>
> >>>>>> PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher
> >>>>>> suites.
> >>>>>>
> >>>>>> “
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> 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