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

Eric Rescorla <ekr@rtfm.com> Mon, 06 March 2017 13:37 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 E9FCF1296F0 for <mmusic@ietfa.amsl.com>; Mon, 6 Mar 2017 05:37:00 -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 7ib-gZ_KHL3u for <mmusic@ietfa.amsl.com>; Mon, 6 Mar 2017 05:36:57 -0800 (PST)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 E455A1296ED for <mmusic@ietf.org>; Mon, 6 Mar 2017 05:36:55 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id v76so19450137ywg.0 for <mmusic@ietf.org>; Mon, 06 Mar 2017 05:36:55 -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=miDHS0peHBcBfuU7wJR+l1kzi0cEfv7VWSGDQE/tbCY=; b=pTl8XFK2NrP8vNqVuHfAET0GSBc9zyxYnM2jEA1fF/Rwf3aAACFJ9FDTADOhxQUjgU sDCvZURGCmhsiKWBx126B+0Op/aVQVQheYO27+tOg6/nswA29v1uIWWDcjRU4LVYDkoQ VXriBnQ4ljE3oQoNIXjJN6ITz5ExSggEawq45MxfnwtyA3YyqBebmX1by4Pn4KslBkZy 34wwcooMlpzgI2IZtnRba8kVxsVseusX/8sobIDauJFVvaNzLEOFZfvcOs85ilg7lf2v OjzSAXh7RvjugY8inTsCAolzf3zJ72+a5Q8pZKNinlocd0muEGwZivujcJ0vxPUzojw9 TtCA==
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=miDHS0peHBcBfuU7wJR+l1kzi0cEfv7VWSGDQE/tbCY=; b=Op1o3A3lWPuA92s/Ip+tuaxKlRjtRuGh0UzeOiBltIjptyCyysXNpjOZA/lnbq6b7j ZvMniLItKNlMVQy3qioVzYIjKXt45SrASWQaehQ+d486/NCK91bZfrOK29KrHPeHZnib cJJ+EIt196eOe6dAcpBYsiBb0N+D8ZZT+l9YFhDW3MJznNVHFZl0frunM25v6Au4qhpF zgNWbpOT1GRpk7w5G9Cwr7NSX7F038ZNAq4CU0dlmx+mZ4G4FWrZ34Hco9T3cFLxZTxk QODJqjhVxRWQnl6q60XVla8TE/hw7K/BmDQenxyhJj7VMXe1DDLVFHcYoGZ9rfsbH17j Cvtw==
X-Gm-Message-State: AMke39lG5itrf8MiV6EhAnR7ILXkL71wGmYNIivpBAW5YGHhEI7jg54AS0fjG1Bgb337CsQ7Rzgr5eKzwfaCng==
X-Received: by 10.37.224.81 with SMTP id x78mr10699989ybg.80.1488807414986; Mon, 06 Mar 2017 05:36:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Mon, 6 Mar 2017 05:36:14 -0800 (PST)
In-Reply-To: <a7070e7a-81dc-ab68-c59b-d4df367029c2@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> <CABcZeBPcqz+NzKp=c5zZd_aDqYHjC6AhOyBMjsOdpKEjGF08qw@mail.gmail.com> <a7070e7a-81dc-ab68-c59b-d4df367029c2@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 6 Mar 2017 05:36:14 -0800
Message-ID: <CABcZeBM6LMJB2f10+F1jQNinKe4nkNGCRpT6VN1tZPXCLskxHQ@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary=94eb2c0873581c370d054a0ffdb8
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/CF0Npl2KphgGRiSM0JZ8Hesr1y8>
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: Mon, 06 Mar 2017 13:37:01 -0000

On Mon, Mar 6, 2017 at 5:07 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> Thanks,
>
> I have updated the text, new text at the bottom after replies.
>
>
> Den 2017-03-04 kl. 21:28, skrev Eric Rescorla:
>
>> 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.
>>
>
> 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?


   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.
>>
>
> I don't think this paragraph is that relevant. I would lean towards
> removing it. With DTLS-SRTP that per direction specific transport keys even
> an SSRC collision is not an issue, assuming that crypto end-point is not
> actually trying to forward two different RTP streams using the same SSRC,
> which would be so broken also on RTP level, in addition to revealing the
> plaintext for some ciphers.
>
> We actually don't have a mechanism that always work for preventing SSRC
> collisions by ensuring agreement of SSRC usage.


I am fine to remove this paragraph.


>>    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"
>>
>
> Yes.
>
>
>>    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?
>>
>>
> Applies to other security mechanisms than SRTP.


What such mechanisms are there? The only ones I know of that people have
proposed
just encapsulate the entire 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.


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


>   The identication-tag is
>

Still misspelled.

-Ekr


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