Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 - Magnus' comments - MID security

[Jonathan Lennox <[e-mail]>]

On Oct 7, 2016, at 4:41 AM, Magnus Westerlund <[e-mail]<mailto:[e-mail]>> wrote:

Den 2016-10-06 kl. 23:59, skrev Cullen Jennings:

I'm not getting the problem here and mandating 6904 is not an easy
thing to do.

So, lets be clear on what I have proposed. For bundle in general it is RECOMMENDED to encrypt MIDs in RTP header extensions. I have also proposed that for RTCWeb implementation and use should be mandated. I was not clear in what applies when an WebRTC endpoint talks to a legacy endpoint what is expected here. I guess this is the thorny issue.

RFC 7904 (SDES header extensions) says:


   In RTP sessions where any type of confidentiality protection is
   enabled for RTCP, the SDES item header extensions MUST also be
   protected.  This implies that to provide confidentiality, users of
   the Secure Real-time Transport Protocol (SRTP) need to implement and
   use encrypted header extensions per [RFC6904<https://tools.ietf.org/html/rfc6904>].

This was after a fair bit of back-and-forth with the security ADs.  MID is a 7904 header extension, so I don’t think BUNDLE can override this MUST.


I'm not getting what the issue is here. If mid are random, or are
just a count of n'th m-line in the sdp, what is the problem with
exposing them to people are getting the media?

The issue is that these identifiers are going from having only been visiable in the signalling messages to be visible also on the RTP media plane. And without RFC6904 even if one uses SRTP, these values are exposed. This have several different effects as I see it. So if the generation algorithm are not strictly defined, the implementation gets possible to fingerprint. In addition the device gets to be fingerprinted based on the number of streams offered and their identifiers. Thus, it is not only what is actually used that is exposed, but what was originally offered, i.e. the full offer leaks into unencrypted domain on the media plane. Note, this later can't be dealt with any mid id creation rules, it will still leak. Thus devices that have more exotic configurations when it comes to media streams, i.e. number of cameras etc this can still be fingerprinted by passive attacks from third parties.

It is the passive attack from third parties that has me worried here. A peer in the signalling has massively more powerful fingerprinting, but that requires one to be in the signalling context, not passively observe traffic that goes past.


Cheers

Magnus





On Oct 6, 2016, at 7:39 AM, Magnus Westerlund
<[e-mail]<mailto:[e-mail]>> wrote:

Den 2016-10-06 kl. 14:49, skrev Christer Holmberg:

Hi,

Magnus suggested usage of RFC 6904 for encryption of the RTP SDES
header extension for MID. I guess it would be a SHUOLD?

In addition, we would say that a corresponding level of security
must be applied to the RTP SDES header extension for MID and to
the RTCP SDES MID item.

Any opinions?

I think this is fine solution to this issue. I would probably
formulate the security considerations like this.

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 combined with hardware configuration can enable
fingerprinting of the endpoint device and thus its user. 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.

Due to the security risks associated with the MID values in RTP and
RTCP it is strongly RECOMMENDED that the MID SDES item is both
confidentiality protected as well as source authenticated when
transported in either RTCP or RTP header extensions. The security
mechanisms used SHALL provide corresponding levels of security for
both RTP header extensions and RTCP. Confidentiality mechanisms for
RTP/RTCP are discussed in Options for Securing RTP Sessions
[RFC7201], for example SRTP [RFC3711] with SRTCP encryption enabled
combined with [RFC6904] can provide the necessary security
functions.


Cheers

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]<mailto:[e-mail]>
----------------------------------------------------------------------



_______________________________________________
mmusic mailing list [e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mmusic




--

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]<mailto:[e-mail]>
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mmusic