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

[Eric Rescorla <[e-mail]>]

On Fri, Mar 3, 2017 at 8:24 AM, Magnus Westerlund <
[e-mail]> 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  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>