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

[Eric Rescorla <[e-mail]>]

On Fri, Mar 10, 2017 at 1:51 AM, Magnus Westerlund <
[e-mail]> 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
>> <[e-mail] <mailto:[e-mail]>>
>>
>> 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  [phone]
>>     <tel:%2B46%2010%207148287>
>>     Färögatan 6                 | Mobile [phone]
>>     <tel:%2B46%2073%200949079>
>>     SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>>     <mailto:[e-mail]>
>>     ------------------------------------------------------------
>> ----------
>>
>>
>>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
>
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>