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

[Christer Holmberg <[e-mail]>]

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?

Regards,

Christer





On 07/09/16 17:36, "mmusic on behalf of Paul Kyzivat"
<[e-mail] on behalf of [e-mail]> wrote:

>Magnus,
>
>Thanks for highlighting your main issue - leakage across layers from SDP
>to RTP. I see how that could be a different sort of vulnerability.
>Encrypting RTP headers sounds like a better answer than obfuscating
>specific ids in the SDP.
>
>	Thanks,
>	Paul
>
>On 9/7/16 7:17 AM, Magnus Westerlund wrote:
>> Den 2016-09-06 kl. 21:22, skrev Paul Kyzivat:
>>> On 9/6/16 9:43 AM, Magnus Westerlund wrote:
>>>
>>>>> Note the following text in section 14.2:
>>>>>
>>>>>     "The identification-tag MUST NOT contain any user information,
>>>>>and
>>>>> applications SHALL avoid generating
>>>>>     the identification-tag using a pattern that enables application
>>>>> identification.²
>>>>>
>>>>
>>>> Yes, but when it comes to profiling I think the above is to unspecific
>>>> to prevent profiling. One option is a very basic algorithm that
>>>>everyone
>>>> will implement identically. However, the ordering of the m= line and
>>>> their media types etc etc may still allow fingerprinting of a device.
>>>> One could define it to be cryptographically random 3 character tags.
>>>> Then it would likely be difficult to get anything from it. The issue
>>>> here is really that one moves the tags from a context where the tags
>>>>is
>>>> a minor issue, as the full SDP provides so much profiling
>>>>possibilities,
>>>> to a RTP where it can be provided to completely different set of
>>>> attackers.
>>>
>>> IMO this is becoming ridiculous. Using cryptographically random tags
>>> would be annoying to implement, and would make the SDP even harder to
>>> read.
>>>
>>> I've been annoyed at the examples using small integers because that
>>> makes them hard to read. I'd be more inclined to use mnemonics, at
>>>least
>>> for examples, if not for production code.
>>
>> The point I tried to raise above is that the text in draft is
>> insufficient to prevent information leakage. This because at least the
>> implementation for the MIDs will be detectable unless one actually
>> specify it very strictly. It might be that the possibility to identify
>> the implementation is a very  minor issue here and also something that
>> is likely leaking in so many other ways.
>>
>> The more serious issue is being able to identify specific devices based
>> on the MID values. So how many MIDs that are being used or at least
>> offered will depend on the endpoints configuration in combination with
>> the software.
>>
>>>
>>> Are we getting to the point where we need to define an SDP Obfuscator
>>> (along with a SIP Obfuscator)?
>>
>> Well, that is a separate problem from the one I am bringing up here. My
>> main concern here is that due to the RTP header extension there is
>> information that exist in SDP that are leaking to some degree to the RTP
>> layer where it becomes observable by another set of potential attackers.
>>
>> The first mechanism that can be applied which will ensure protection
>> towards third parties is to use RTP header extension encryption
>> [RFC6904]. Then this information only leaks to nodes inside the security
>> context. And they likely anyway have access to the SDP. Thus removing
>> the issue.
>>
>> From my perspective mandating the use of RFC 6904 to encrypt the MID RTP
>> header extension might be the simplest choice here and provides better
>> protection against third parties. It may not give as good protection
>> against semi trusted entities. But, they already have so much other
>> information that this doesn't matter at this point.
>>
>>>
>>> If that is what we need then I think we would be better off doing it
>>> that way than doing it piecemeal, one token at a time.
>>>
>>
>> The SDP and SIP layer issues in regards to these tracking possibilities
>> are much harder, and clearly needs a more all encompassing approach.
>> What I think is important here is the leakage to another layer. That
>> should be prevented.
>>
>> 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