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

[Cullen Jennings <[e-mail]>]

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

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?



> On Oct 6, 2016, at 7:39 AM, Magnus Westerlund <[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]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic