IETF Logo Mail Archive

[clue] Comments on CaptureID and security

Roni Even <roni.even@huawei.com> Wed, 18 January 2017 08:34 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 68A731294A8 for <clue@ietfa.amsl.com>; Wed, 18 Jan 2017 00:34:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.419
X-Spam-Level:
X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 VsYZt-Yzdx7e for <clue@ietfa.amsl.com>; Wed, 18 Jan 2017 00:34:10 -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 1EF64120727 for <clue@ietf.org>; Wed, 18 Jan 2017 00:34:09 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DET09918; Wed, 18 Jan 2017 08:34:05 +0000 (GMT)
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 18 Jan 2017 08:34:03 +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; Wed, 18 Jan 2017 16:33:26 +0800
From: Roni Even <roni.even@huawei.com>
To: "clue@ietf.org" <clue@ietf.org>
Thread-Topic: Comments on CaptureID and security
Thread-Index: AdJxYyu3dvmMy6+lR4Sf9Fep5IDFDA==
Date: Wed, 18 Jan 2017 08:33:26 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.201.112.60]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD76DEFFDGGEMM506MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.587F287E.00C0, 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: bd2cee618da927d6ce9f243526e0fd1f
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/mzcaLgUuqDsEW1-8mWiG5oahiGA>
Cc: Jonathan Lennox <jonathan@vidyo.com>
Subject: [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: Wed, 18 Jan 2017 08:34:13 -0000

Hi,
We got the following comments from Magnus when he reviewed the registration, he also had similar comments during IETF LC


"This registration 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 sensetive, 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 that the field should have anonymous labels, that do not contain privacy information. Then one should be clear on what requirements one put on transporting these fields 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. 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.



I recommended that registration is hold off for the RTP header extension parts (IANA review request #944570), where this gets even worse by the fact that even if RTP and RTCP is confidentiality protected, the RTP header extension is not per default confidentiality protected, and there is a additional protection mechanism that needs to be implemented."





The major point are:



1.       We need to specify the considerations for creating CaptureID, the data model talks in general about securing the CLUE message, the CLUE protocol and framework are silent about this parameter. Any suggestions? Also should this be specified in the RTP mapping or in the CLUE protocol?

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#section-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.

"


Thanks
Roni

v2.23.0 | Report a Bug | By Email