Re: [rtcweb] BUNDLE: Attempting to resolve security consideration
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 07 March 2017 09:46 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE85129477; Tue, 7 Mar 2017 01:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 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, 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 N7wHv02395NE; Tue, 7 Mar 2017 01:46:18 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 9892E129466; Tue, 7 Mar 2017 01:46:17 -0800 (PST)
X-AuditID: c1b4fb30-84e7298000007a5b-a4-58be8167da3b
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 92.6F.31323.7618EB85; Tue, 7 Mar 2017 10:46:16 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.319.2; Tue, 7 Mar 2017 10:45:53 +0100
To: Eric Rescorla <ekr@rtfm.com>
References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <CABcZeBMTW48fj=1EMJ3uJCdVqEiYuPk+rDy6h_7W=jh0fu7tNQ@mail.gmail.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> <CABcZeBPcqz+NzKp=c5zZd_aDqYHjC6AhOyBMjsOdpKEjGF08qw@mail.gmail.com> <a7070e7a-81dc-ab68-c59b-d4df367029c2@ericsson.com> <CABcZeBM6LMJB2f10+F1jQNinKe4nkNGCRpT6VN1tZPXCLskxHQ@mail.gmail.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <f390877e-d6be-11cd-8a35-f68546ae4115@ericsson.com>
Date: Tue, 07 Mar 2017 10:45:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CABcZeBM6LMJB2f10+F1jQNinKe4nkNGCRpT6VN1tZPXCLskxHQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM2J7lG5G474Ig4+zmS1WvD7HbjF1+WMW i7X/2tkdmD2WLPnJ5DH5cRtzAFMUl01Kak5mWWqRvl0CV8bbBomCvQ4V88+9ZmpgfGDYxcjJ ISFgIvH442kmEFtIYB2jxPtL6l2MXED2MkaJ/k9NbCAJYQEvibZtE5lBbBEBBYlff06wQBQ1 MEs8/jIZqIiDg1nAR2Lhs0SQGjYBC4mbPxrBenkF7CUmfD0GtoBFQEWivecAK4gtKhAjsbf/ PhNEjaDEyZlPWEBsToFAiW/fb4LVMAPNmTn/PCOELS/RvHU2M8Sh2hINTR2sExgFZiFpn4Wk ZRaSlgWMzKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAsPz4JbfBjsYXz53PMQowMGoxMNb ULk3Qog1say4MvcQowQHs5II756sfRFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEec1W3g8XEkhP LEnNTk0tSC2CyTJxcEo1MG7tn/Cz36vsA0/V8qULeNK2l8x7uzTTNXv2vds8xo/aM19V6Zw/ 9Z2rI5Upq+74Qm+JqYX+Dpz/nruf/Fl/de2x+Smv/F3mvH50wan1Vt+llPCdWrpbWFlqVkzt etd5MtWR65z3gfnFa3lFN0Rt23B3dolKhE32tudXSjbZu7w2/DBbOU87NluJpTgj0VCLuag4 EQBRRqQDSwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/QCEB6ixH9iX2VyqAlgv1eP2X9u0>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "mmusic (E-mail)" <mmusic@ietf.org>
Subject: Re: [rtcweb] BUNDLE: Attempting to resolve security consideration
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2017 09:46:20 -0000
Hi, Please see inline. Den 2017-03-06 kl. 14:36, skrev Eric Rescorla: > > I think you are correct assuming that one is using SRTP. All the > IETF key-management scheme follows this, although a=mikey is > IDENTICAL. If one uses other security mechanisms, then this is still > relevant to capture. > > > Which security mechanisms are you thinking of here? I didn't have any specific security mechanism in mind. I simply want to make clear the requirements that arises due to the new mechanisms that BUNDLE creates. As you commented I can only think of mechanism that protects the whole packet. > > > To avoid the security risks associated with tracking of > implementations, there is RECOMMENDED algorithm for generating > identification-tags in Section 14.1. > > See above. > > > 16. Security Considerations > > The security considerations defined in [RFC3264] and [RFC5888] apply > to the BUNDLE extension. Bundle does not change which information > flows over the network but only changes which addresses and ports > that information is flowing on and thus has very little impact on the > security of the RTP sessions. > > > Is this precisely true? Do you ever use the MID extension w/o BUNDLE? > It certainly changes which ICE checks you do. > So lets start with the question of MID without using BUNDLE. As MID is used in grouping of media lines use cases, i.e. RFC 5888 there are certainly uses. However, there exist no need to signal MIDs on RTP session level in those cases as there already exist a one to one mapping between the MID and the transport addresses used for that RTP session. Only with BUNDLE do the RTP streams from the different m= lines start sharing transport context. So strictly the above is incorrect. What was multiple security context due to different RTP sessions, or other sessions are now moved into a single context. I think we could reformulate this to say: The security considerations defined in [RFC3264] and [RFC5888] apply to the BUNDLE extension. Bundle does not change which information, e.g. RTP streams, that flows over the network. Primarily it changes which addresses and ports, and thus in which (RTP) sessions that the information is flowing in. This affects the security contexts being used and can cause previously separated information flows to share security context. This has very little impact on the performance of the security mechanism of the RTP sessions, however which actors that are present in a particular security context may require additional thoughts when applying Bundle. Is this better? > > > When the BUNDLE extension is used, a single set of security > credentials might be used for all media streams specified by a BUNDLE > group. When using SRTP this is further required at least for the > IETF defined key-management solutions due to their SDP attributes > (a=crypto, a=fingerprint, a=mikey) classification in > [I-D.ietf-mmusic-sdp-mux-attributes]. But for other security > solutions, this may require further consideration. > > The identfication-tag, independent of transport, RTCP SDES packet or > RTP header extension, can expose the value to parties beyond the > signaling chain. Therefore, the identification-tag values MUST be > generated in a fashion that does not leak user information, e.g., > randomly or using a per-bundle group counter, and SHOULD be 3 bytes > or less, to allow them to efficiently fit into the MID RTP header > extension. However, the implementation's method for generating > identification-tags could enable fingerprinting of the implementation > making it vulnerable to targeted attacks. > > > I would say "Note that if implementations use different methods for > generating > ... this could..." > Yes, I will use this. > > The identication-tag is > > > Still misspelled. Yes, there was actually two misspelled instances left, and I had corrected one. Full section text after corrections: 16. Security Considerations The security considerations defined in [RFC3264] and [RFC5888] apply to the BUNDLE extension. Bundle does not change which information, e.g. RTP streams, that flows over the network. Primarily it changes which addresses and ports, and thus in which (RTP) sessions that the information is flowing in. This affects the security contexts being used and can cause previously separated information flows to share security context. This has very little impact on the performance of the security mechanism of the RTP sessions, however which actors that are present in a particular security context may require additional thoughts when applying Bundle. When the BUNDLE extension is used, a single set of security credentials might be used for all media streams specified by a BUNDLE group. When using SRTP this is further required at least for the IETF defined key-management solutions due to their SDP attributes (a=crypto, a=fingerprint, a=mikey) classification in [I-D.ietf-mmusic-sdp-mux-attributes]. But for other security solutions, this may require further consideration. The identification-tag, independent of transport, RTCP SDES packet or RTP header extension, can expose the value to parties beyond the signaling chain. Therefore, the identification-tag values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-bundle group counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the MID RTP header extension. Note that if implementations use different methods for generating identification-tags this could enable fingerprinting of the implementation making it vulnerable to targeted attacks. The identification-tag is exposed on the RTP stream level when included in the RTP header extensions, however what it reveals of the RTP media stream structure of the endpoint and application was already possible to deduce from the RTP streams without the MID SDES header extensions. As the identification-tag is also used to route the media stream to the right application functionality it is also important that the value received is the one intended by the sender, thus integrity and the authenticity of the source are important to prevent denial of service on the application. Existing SRTP configurations requires integrity protection of both RTCP and RTP header extensions. "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items" [RFC7941] security consideration requires that when RTCP is confidentiality protected that any SDES RTP header extension carrying an SDES item, like the MID RTP header extension, is also protected using commensurate strength algorithms. However, assuming the above requirements and recommendations are followed there are no known significant security risks with leaving the MID RTP header extension without confidentiality protection. Thus, the requirements in RFC 7941 MAY be ignored for the MID RTP header extension. Security mechanisms for RTP/RTCP are discussed in Options for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can provide the necessary security functions of ensuring the integrity and source authenticity. -- 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 ----------------------------------------------------------------------
- [rtcweb] BUNDLE: Attempting to resolve security c… Magnus Westerlund
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Eric Rescorla
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Magnus Westerlund
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Eric Rescorla
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Magnus Westerlund
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Iñaki Baz Castillo
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Eric Rescorla
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Eric Rescorla
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Iñaki Baz Castillo
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Magnus Westerlund
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Eric Rescorla
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Magnus Westerlund
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Eric Rescorla
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Magnus Westerlund
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Magnus Westerlund
- Re: [rtcweb] [MMUSIC] BUNDLE: Attempting to resol… Magnus Westerlund
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Eric Rescorla
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Magnus Westerlund
- Re: [rtcweb] BUNDLE: Attempting to resolve securi… Eric Rescorla
- Re: [rtcweb] [MMUSIC] BUNDLE: Attempting to resol… Christer Holmberg