[MMUSIC] BUNDLE: Attempting to resolve security consideration

[Magnus Westerlund <[e-mail]>]

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


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