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

Hi,

My intention was not to claim we have consensus. I just wanted to put forward some text to see whether it’s something we can work on.

Or, would you prefer to not saying anything?

Regards,

Christer

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: 12 October 2016 19:57
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>; Paul Kyzivat <pkyzivat@alum.mit.edu>; mmusic@ietf.org; Cullen Jennings <fluffy@iii.ca>
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 - Magnus' comments - MID security

I don't think there is anything like consensus for a 2919-level RECOMMENDED to encrypt the MID.

On Wed, Oct 12, 2016 at 4:47 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
Pull request created.

https://github.com/cdh4u/draft-sdp-bundle/pull/11

Regards,

Christer

On 12/10/16 12:32, "mmusic on behalf of Christer Holmberg"
<mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org> on behalf of christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
wrote:

>Hi,
>
>Based on the discussions, and input that has been provided, are people ok
>with adding the text Magnus suggested (see below) to the Security
>Considerations of BUNDLE?
>
>Regards,
>
>Christer
>
>
>>>> 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.
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org<mailto:mmusic@ietf.org>
>https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic