Re: [clue] Comments on CaptureID and security

Roni Even <roni.even@huawei.com> Sun, 22 January 2017 05:10 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 B6B6B1295BC for <clue@ietfa.amsl.com>; Sat, 21 Jan 2017 21:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.42
X-Spam-Level:
X-Spam-Status: No, score=-7.42 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=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPokM_CA2vfL for <clue@ietfa.amsl.com>; Sat, 21 Jan 2017 21:10:22 -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 90BBB1295A5 for <clue@ietf.org>; Sat, 21 Jan 2017 21:10:21 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZG34066; Sun, 22 Jan 2017 05:10:19 +0000 (GMT)
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 22 Jan 2017 05:10:18 +0000
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Sun, 22 Jan 2017 13:10:11 +0800
From: Roni Even <roni.even@huawei.com>
To: Christian Groves <Christian.Groves@nteczone.com>, "clue@ietf.org" <clue@ietf.org>
Thread-Topic: [clue] Comments on CaptureID and security
Thread-Index: AQHScuZudDFZmzcLYEO2lSU6qAFVp6FD9TBA
Date: Sun, 22 Jan 2017 05:10:10 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76E7AC@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> <eb47e203-32f8-e0bc-d58c-ef6b2cf121be@nteczone.com>
In-Reply-To: <eb47e203-32f8-e0bc-d58c-ef6b2cf121be@nteczone.com>
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.58843EBB.0151, 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/l_QK3DzTi3fsiDdcRUVolpXR4y0>
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: Sun, 22 Jan 2017 05:10:24 -0000

Hi Christian,
I am not sure if it is needed for switching but if it does this is something for PERC to say that it needs to be secured using the hop by hop key
Roni

> -----Original Message-----
> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves
> Sent: יום ו 20 ינואר 2017 08:28
> To: clue@ietf.org
> Subject: Re: [clue] Comments on CaptureID and security
> 
> Do we need to consider PERC when making that recommendation? An MDF
> would need access to the CaptureID in order to making switching decisions in
> CLUE is used.
> 
> Regards, Christian
> 
> 
> On 18/01/2017 10:53 PM, 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#section
> >> -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#sect
> >>>> 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#ref
> >>>> -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#ref
> >>>> -
> >>>
> >>>>
> > 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