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

Eric Rescorla <ekr@rtfm.com> Fri, 10 March 2017 15:32 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 EB34712963D for <mmusic@ietfa.amsl.com>; Fri, 10 Mar 2017 07:32:24 -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 LdDf5b8O0SIF for <mmusic@ietfa.amsl.com>; Fri, 10 Mar 2017 07:32:22 -0800 (PST)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 CB3F3129638 for <mmusic@ietf.org>; Fri, 10 Mar 2017 07:32:18 -0800 (PST)
Received: by mail-yw0-x236.google.com with SMTP id p77so25761075ywg.1 for <mmusic@ietf.org>; Fri, 10 Mar 2017 07:32:18 -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=EEWcB5beUBuyZfULiiI+Z67JRElyruFFoFjK7jzcZi4=; b=H+B6EhR13hHxGpN92wK02WgJ8WT7ZE7KCUjh0aBBjixcnvhVGlfjLwGVF1T+s2gtVV lO6mcG9XfK0Mi7j3MriWMgsNJXbRBA2MJWtQ2hYMgpduXHNRkUQXnUGL/5l0aw/4UjPS PipZdI+S7Yo/33IfstSYgj7Xx0tbnkKvXuyrU0BaflyaFuYVp/zlUBE23oNCbBsj2NS0 THIS1NyhJuoO8Z7rAfKtv1DbB6tpw7ZeQbZBzFnWcVXGwQlEgdFb4THp6kKrQurnlYUj QfykyUkCmyHosYJJ0k0MH82lvJAX+B2KPzFggIzxim54h7N/pOu7exkGwduymW2gUi3x xOmA==
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=EEWcB5beUBuyZfULiiI+Z67JRElyruFFoFjK7jzcZi4=; b=NkK5VLeWr5EpR0cqYEQWx3z9iJ9rQKYN0Fr21bpxp0W6LLDZxLyhPjp2HES3NPOPfc JGJAdzTWn0GbjeHWkI7x5Wp2aFSs2rmoAfE0+0770SBHDhkQu7DcDvYZy7MZ3o6S9ezM gyH5QznCD70iHO5+k7Z1K1+o4dUEiuQCRaz9UGwAtyV7ZgbGLcEBVzhOEZ1+dp4wVkLv acFbmtNrcy5n/CNlN74kkHkfltI15ZyzNS9ETmJ6835rPKKwmEEgtiC9NgELip+O9Pn/ hHz0jVRCeDoXtlg8YGvwzmmdR3tXIsNFybpQ69z3eth7euat8ZV6hsslu0+E+ZJ55KOH xyXw==
X-Gm-Message-State: AMke39kkELkQyqIODUrI03cPpRTLvd2s1KlnfBwaUiZjvMkDAO1B8F7/10flKHwwIKNMyah34XHlH4LKQOS3Mg==
X-Received: by 10.13.240.196 with SMTP id z187mr8529443ywe.337.1489159937973; Fri, 10 Mar 2017 07:32:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Fri, 10 Mar 2017 07:31:37 -0800 (PST)
In-Reply-To: <29d1f31b-402c-5f31-8eee-f1f066ddce29@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> <CABcZeBM6LMJB2f10+F1jQNinKe4nkNGCRpT6VN1tZPXCLskxHQ@mail.gmail.com> <f390877e-d6be-11cd-8a35-f68546ae4115@ericsson.com> <CABcZeBNAU0eo+nP02LRjP3Cybtrm487wQMtq34zhmeaB+=uHiQ@mail.gmail.com> <29d1f31b-402c-5f31-8eee-f1f066ddce29@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 10 Mar 2017 07:31:37 -0800
Message-ID: <CABcZeBP_c90N+bWiQXTg8-VvwY4Vme1T0v88DQ4DSW_KnG_Cuw@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary=94eb2c034eb01e0238054a621136
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/PM_IO67DSNlT_oR2ql9iNN8oXKI>
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, 10 Mar 2017 15:32:25 -0000

On Fri, Mar 10, 2017 at 1:51 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> Hi,
>
> EKR, I think I understood your issue with the SDP MID usage. I
> restructured the section to move the issues with moving the MID into RTP
> layer as the second paragraph and made it clear that this is a new security
> consideration compared to before in the introduction.
>
> Regarding the integrity and authenticity I have made some small changes. I
> don't see how removing the requirements help, even if they are normally
> resolved when using an existing mechanism. I guess this is is a matter of
> view. I am not comfortable with simple assuming that people will use a
> security mechanism and therefore this is not an issue. And it makes future
> work to analyses potential mechanism a bit harder as one have to redo more
> analysis, such as in PERC.
>

What I am trying to do is to avoid confusing people who think that SRTP is
fine but
some other mechanism which they might actually use is not fine. With that
said,
I consider your current text to be clear enogh on this point.


>
> Anyway here is an updated text. I have sent the XML of this one to
> Christer and he has told me he will update the PR he already have.
>
>
> 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, with the exception of
>

e.g. has a comma after it.



>    the usage of the MID SDES item as discussed below.  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.  In cases
>    where one would have applied different security policies on the
>    different RTP streams being bundled, or where the parties having
>    access to the security contexts would have differed between the RTP
>    stream additional analysis of the implications are needed before
>    selecting to apply BUNDLE.
>
>    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 and other security mechanisms protecting the whole
>    RTP/RTCP packets will provide the necessary protection.
>
>    When the BUNDLE extension is used, a single set of security
>    credentials over the bundled media descriptions will need to be used,
>    at least per direction or endpoint.


Actually, why does this have to be the case? I mean, we require it, but
if you have the MID extension, you could easily not do this.



> When using SRTP this will be the
>    case, at least for the IETF defined key-management solutions due to
>    their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their
>    classification in [I-D.ietf-mmusic-sdp-mux-attributes].
>
>    "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.
>
>
> Den 2017-03-07 kl. 18:47, skrev Eric Rescorla:
>
>>
>>
>> On Tue, Mar 7, 2017 at 1:45 AM, Magnus Westerlund
>> <magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>>
>>
>> wrote:
>>
>>     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.
>>
>>
>> Yeah, this seems more confusing than illuminating. There are lots of
>> theoretical
>> risks that might happen if we had some new security mechanism with unknown
>> properties.
>>
>>
>>
>>         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.
>>
>>
>> That's what I meant by "MID extension". Sorry for the confusion.
>>
>>
>>
>>     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?
>>
>>
>> But it still seems to be false because of the MID signaling in SDP.
>>
>> I also don't understand the last line.
>>
>> -Ekr
>>
>>
>>               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
>>     <tel:%2B46%2010%207148287>
>>     Färögatan 6                 | Mobile +46 73 0949079
>>     <tel:%2B46%2073%200949079>
>>     SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>>     <mailto:magnus.westerlund@ericsson.com>
>>     ------------------------------------------------------------
>> ----------
>>
>>
>>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
>
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>