Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration
Eric Rescorla <ekr@rtfm.com> Fri, 03 March 2017 13:50 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 C2BA512954A for <mmusic@ietfa.amsl.com>; Fri, 3 Mar 2017 05:50:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] 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 KVxCi3Vpg0f9 for <mmusic@ietfa.amsl.com>; Fri, 3 Mar 2017 05:50:35 -0800 (PST)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 3AF461294F5 for <mmusic@ietf.org>; Fri, 3 Mar 2017 05:50:35 -0800 (PST)
Received: by mail-yw0-x22e.google.com with SMTP id p77so80214247ywg.1 for <mmusic@ietf.org>; Fri, 03 Mar 2017 05:50:35 -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=8/TsnpgZ1G/2Q/35JG20NwD5K0pL/mQOAp9YgiSB9ss=; b=gFfI07u9dmfZjI0/Cgo80wSr/MUqjmi7rTw0RJwv5fUtFO2sHcfnEYs7ZKuQPr1cT7 47kYCMybIhzmuu8K2MfNTehQgbhc1JUn7JWAc5RwXm1K4HI9TXUzfR2h29FaC2Djc6b6 NndLe/vOjXXG1aCwEq2iB9JS+HVhkNXPCy81PucQN5Ee5AFh6x52KsPfi6QZYr3iVNoN QN4bls3IC6bOLjVjub4FQaaKXWkP+LYhW94QNaQdR2JD3VuUzrPhofnFq0HW7tUshoPq nMJy/FEGiSTP8LrUo5Yv/ZA0aooAbYzJgOT9H5XrAHtHekHWCJQLvwmkNEYXhgwxW9lB epAQ==
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=8/TsnpgZ1G/2Q/35JG20NwD5K0pL/mQOAp9YgiSB9ss=; b=hYTgb/HPM0tGbCh0k1WT6CJ3cBHVYH9kCxhSu+PlApWpWMxF+hnhL816XIqY2EXNFF kIYLxdwYQ+TizukB0CSY+dgjqtCn2srB9ohMTUtCX2qHV9Ss4u+TJ+RupvuUNIEl9FMj Z+/CW0Q7IduYurcoWtYcrWLEkPAOo9G64oYITiD9KpmxaeqnxuuezNHNU2k6m9MIEzNf PBEsczt3bdpmxrj1+bzeUSrn9c7x2h6kbjI9M91cQepOxAmRw7O3ubbpPnscwYXvQOmK 6uZBTyM3J3fk17qBl3oMOiozsMUg/xJpqFkAGvFThO+7pKscWWUSnWhEBWu6JkBwmyIN 1QkQ==
X-Gm-Message-State: AMke39lmmiSPnyr/nu5S5cFEjGGSDx8e7qLq54UydQxY0thwC+vUt2J3f6EmkRVd+n8jXSc2lb72pR/JFtm62Q==
X-Received: by 10.37.171.66 with SMTP id u60mr1811257ybi.64.1488549034369; Fri, 03 Mar 2017 05:50:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Fri, 3 Mar 2017 05:49:53 -0800 (PST)
In-Reply-To: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com>
References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 03 Mar 2017 08:49:53 -0500
Message-ID: <CABcZeBMTW48fj=1EMJ3uJCdVqEiYuPk+rDy6h_7W=jh0fu7tNQ@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary="94eb2c0c30f06cc1400549d3d42a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/PHE9w-ydNRHqgf3SGiavYgv9GNw>
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: Fri, 03 Mar 2017 13:50:38 -0000
On Fri, Mar 3, 2017 at 8:24 AM, Magnus Westerlund < 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. -Ekr The > algorithm is also designed to keep down the length of the MID SDES > item to preserve the MTU in RTP packets. > > The value of the identification-tag for a particular media > description is generated by first determining the unsigned integer > index of the corresponding m= line in the SDP. The first m= line in > the SDP gets index 0, then each subsequent m= line present in the SDP > gets an index value one value higher the previous line. The index > value is then encoded to create the identification-tag value. The > encoding is done in following the algorithm. The integer reminder of > a division by 64 of the index, i.e. MOD 64, is determined. The > reminder is encoded into an UTF-8 (ASCII) character by looking up the > character from the reminder using Table 1 in [RFC4648]. This > character is added to the front of the output string. After that the > index is updated to the result of the index divided by 64. If the > index becomes 0, then conclude the encoding. If not, then go back > and the step calculating the reminder. This algorithm is below > described using pseudo code. > > # Initialization > work-index = index > # index is the index value to encode as unsigned integer > output = "" # Output string > > # The below must be performed once to encode index=0 > do { > reminder = work-index MOD 64 > next-char = TableLookup(reminder) > output = concat(next-char,output) > work-index = work-index / 64 > } while (work-index >0) > > Examples of input and output: > > Input Output > 0 A > 1 B > 42 q > 56 4 > 63 / > 64 BA > 65 BB > 256 EA > 4095 // > This seems way over-prescriptive. > 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. > > 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. > > The identfication-tag, when included in the RTP MID SDES item, > 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. However, the implementation's method for generating > identfication-tags could enable fingerprinting of the implementation > 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 > 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. At least to prevent third parties from modifying > the identification-tag value. > > To avoid the security risks associated with tracking of > implementations, there is RECOMMENDED algorithm for generating > identification-tags in Section 14.1. "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 mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >
- [MMUSIC] BUNDLE: Attempting to resolve security c… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Eric Rescorla
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Eric Rescorla
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Iñaki Baz Castillo
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Eric Rescorla
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Eric Rescorla
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Iñaki Baz Castillo
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Eric Rescorla
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Eric Rescorla
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Eric Rescorla
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Eric Rescorla
- Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resol… Christer Holmberg