Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration

Eric Rescorla <ekr@rtfm.com> Sat, 04 March 2017 20:29 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE2D1295AE for <mmusic@ietfa.amsl.com>; Sat, 4 Mar 2017 12:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 X7_PIKnzEABE for <mmusic@ietfa.amsl.com>; Sat, 4 Mar 2017 12:29:26 -0800 (PST)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AAF6129510 for <mmusic@ietf.org>; Sat, 4 Mar 2017 12:29:26 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id v76so92961ywg.0 for <mmusic@ietf.org>; Sat, 04 Mar 2017 12:29:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Zza6O6iuzfBF6BZ/TXAzSrSCWgnILcuIDZDebBhjtBM=; b=RFpyElTkORNbOxwihY2AaN4x3hTBpctpO+k+BZq5OSjoT+HOpv6xHFBrYKhaLC0yIo EwZ3v6+J4q1+h5QaHebs7Vk7VfZblKA0g59jd1XYUnos5rJ23/YblVkcgGZXAxRjMZmH A5A9etFfmPYMLGP4qgvvHq0VI/LeIC3feXQKmqDpwUXdgpZL6DnE5w9ikRy2Oyx3mKTE IUDKr/0CAYSVK9jsoQI/bP1TNoyredLhNW4i8e6RN29iDF4Sqzz+EUaF1/Rj7P83Vma+ /JIo0CmufdBIt+vYK9/HnydQ827rMTu96PtZxhOtjF2uq3PmdkcyWsYhy6MRQ80QD5mh RorQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Zza6O6iuzfBF6BZ/TXAzSrSCWgnILcuIDZDebBhjtBM=; b=j0CBMtE0pw8VuoXsS0PvVTftmYFZ3QBsy1bY+roP+Wqun3EwEhZ4G7HuQ0EgV+eWJp 7zcd/uVd+bZWvOvVNhlXPzYYKMzarUJwlA6GgopMC5UGSwzotW5BbDQ1idd8htrm3/g5 2JseSznZGmvw1o1kJzyqutpVe4K60nUw1c77GGOIQUVNHPwCB1PwPzPBNnoeBYvwbQCW kCiSp8bBzIrSgDJ8m+ocjChAVk+DEsGOqLLD/KY6HpKXfNeqlNfPlbplULgDfcyUqxno b7andT8IR/BQ/PoaV5Ubl2YYr1zcOnUSxPRwFd5qBiQdh1YyeP1NEUfFiuw/ZPx1hDvL im4Q==
X-Gm-Message-State: AMke39kerGeYUMbwuXWRw9C0skBfy4dpcc/pTzo9xNSp0jQCXFbemuHxCWVfib1ZtQ4G5xihpD1+qJsHPXCe7A==
X-Received: by 10.13.250.67 with SMTP id k64mr6085229ywf.125.1488659365570; Sat, 04 Mar 2017 12:29:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Sat, 4 Mar 2017 12:28:45 -0800 (PST)
In-Reply-To: <0827af95-b755-9730-6605-5146967760e7@ericsson.com>
References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <CABcZeBMTW48fj=1EMJ3uJCdVqEiYuPk+rDy6h_7W=jh0fu7tNQ@mail.gmail.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 4 Mar 2017 12:28:45 -0800
Message-ID: <CABcZeBPcqz+NzKp=c5zZd_aDqYHjC6AhOyBMjsOdpKEjGF08qw@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary=94eb2c07f34aaed0770549ed8415
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/JedYAv2OHLtRgEUnxbxCa1JHftk>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "mmusic \(E-mail\)" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Mar 2017 20:29:29 -0000

I certainly think we have to remove the 14.1 reference. Other comments
below.
With these comments, I would find this text acceptable.

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.

   When the BUNDLE extension is used, a single set of security
   credentials might be used for all media streams specified by a BUNDLE
   group.

Isn't this actually required? Both a=fingerprint and a=crypto are
of type TRANSPORT.


   When the BUNDLE extension is used, the number of SSRC values within a
   single RTP session increases, which increases the risk of SSRC
   collision.  [RFC4568] describes how SSRC collision may weaken SRTP
   and SRTCP encryption in certain situations.

This seems like it's only true in a very limited sense of situations.
In both SDES and DTLS-SRTP, keys are directional, so an SSRC collision
would require that one direction generate colliding SSRCs. That's
certainly possible, but should be straightforward to avoid in most
architectures. In any case, the base rate SSRC collision is far to
high to rely on statistics to prevent it.


   The identfication-tag, when included in the RTP MID SDES item,

This is at typo.

   independent of transport, RTCP SDES packet or RTP header extension,
   can expose the value to parties beyond the signaling chain.
   Therefore, the identification-tag MUST NOT contain any user related
   information.

You should just use the JSEP language here.

   o  An "a=mid" line, as specified in [RFC5888], Section 4.  All MID
      values MUST be generated in a fashion that does not leak user
      information, e.g., randomly or using a per-PeerConnection counter,
      and SHOULD be 3 bytes or less, to allow them to efficiently fit
      into the RTP header extension defined in

   However, the implementation's method for generating
   identfication-tags could enable fingerprinting of the implementation

typo in "identification"


   making it vulnerable to targeted attacks.  The identication-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 deduct from

I assume you mean "deduce"

   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.

Is there any condition when you are using SRTP that these values are
not integrity protected? If not, what is the issue here?


   At least to prevent third parties from modifying
   the identification-tag value.

This is not a sentence.

   To avoid the security risks associated with tracking of
   implementations, there is RECOMMENDED algorithm for generating
   identification-tags in Section 14.1.

See above.

   "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.



On Fri, Mar 3, 2017 at 7:06 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> Den 2017-03-03 kl. 14:49, skrev Eric Rescorla:
>
>>
>>
>> On Fri, Mar 3, 2017 at 8:24 AM, Magnus Westerlund
>> <magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>>
>>
>> wrote:
>>
>>     Hi,
>>
>>     Last IETF meeting we had discussions regarding the security
>>     considerations for the MID RTP header extensions regarding the need
>>     for encrypting the RTP header. On Christer's request I have
>>     attempted to capture what I believed was the outcome of this
>>     discussion into a text proposal.
>>
>>     So the intention of the text is to capture the security
>>     considerations, i.e. known risks and what we believe is necessary to
>>     mitigate these risks. The conclusion of the discussion was that
>>     encrypting the MID in RTP header extensions is not necessary, and
>>     thus we have a conflict with the requirements in RFC 7941. I have
>>     attempted to motivate and on that basis wavier this requirement for
>>     this particular RTP SDES header extension. This is captured in last
>>     paragraph of section 16.
>>
>>     The risk of implementation tracking lead us into a discussion around
>>     a algorithm for generating MID Values. I have drafted a proposal for
>>     such an algorithm in a new Section 14.1 inserted prior to the
>>     existing one.
>>
>>     I note that in RTCWeb WG we did discuss that the encryption wavier
>>     would be done in the security architecture. However, I believe in
>>     retrospect that not covering this in BUNDLE in a common fashion
>>     would be confusing and likely cause questions in regards to the
>>     requirements of RFC 7941 when BUNDLE is used in other context than
>>     WebRTC.
>>
>>     So please review and provide feedback. I know Christer wants to
>>     close this issue.
>>
>>
>>     14.1.  Generating Identification-tags
>>
>>        The identification-tag is exposed on the network layer due to the
>>        SDES item and RTP header extension defined below.  As this exposes
>>        the identification-tag beyond contexts where it is normally
>> exposed,
>>        i.e.  signalling layer additional potential for implementation
>>        identification exists.  To avoid such risks a RECOMMENDED to be
>> used
>>        algorithm for how the identification-tag value is generated is
>>        specified below.  Using this one will ensure that one can't
>> identify
>>        which of the implementations using this algorithm it is.
>>
>>
>> If you mean which stack, I do not believe that this is actually that
>> useful a design
>> consideration. There are going to be a very large number of ways to
>> fingerprint
>> stacks. As the rest of the text seems predicated on that design
>> objective, I do
>> not think we should make this change.
>>
>>
> Okay, what is your view on Section 16, if we remove the first sentence of
> the last paragraph that references 14.1?
>
> We need to get the security considerations in BUNDLE into reasonable shape
> so that we actually can get BUNDLE published.
>
> Cheers
>
>
> 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
> ----------------------------------------------------------------------
>
>