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

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Oct 2016 12:49:29 +0000

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"
<[email-masked] on behalf of [email-masked]> 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  +46 10 7148287
>> Färögatan 6                 | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: [email-masked]
>> ----------------------------------------------------------------------
>>
>>
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 6 Oct 2016 15:39:05 +0200

> applied to the RTP SDES header extension for MID and to the RTCP SDES MID

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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 6 Oct 2016 15:59:11 -0600

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 <[email-masked]> wrote:
> 
> 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
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 7 Oct 2016 10:41:52 +0200

> I'm not getting the problem here and mandating 6904 is not an easy

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.

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

>>> 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.
>>
>> 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
>> 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
>>
>> Färögatan 6                 | Mobile +46 73 0949079 SE-164 80
>> Stockholm, Sweden | mailto: [email-masked]
>> mmusic mailing list [email-masked]

-- 

Magnus Westerlund

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 7 Oct 2016 13:32:18 +0000

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

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.

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
<[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Any opinions?

Cheers

Magnus Westerlund

Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079 SE-164 80
Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------

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

--

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

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

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 7 Oct 2016 11:23:38 -0700

> On Oct 7, 2016, at 1:41 AM, Magnus Westerlund <[email-masked]> wrote:
> 

I'm still not getting the fingerprint problem. How is this different than PT and SSRC. Yes, I agree the MID and RID - which were always intended to go in the RTP packet need to be generated not to have sensitive information in them.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Oct 2016 11:33:47 -0700

ISTM that there are two risks:
1. That people might use structured RIDs, MIDs, etc. and that that will
leak a lot of information about
2. That just the structure of the media streams is a fingerprinting risk.

The first of these seems addressable by guidance about how to construct
these IDs. I note that we
have only very limited guidance on how to construct ICE ufrag/passwords....
The second seems
not that interesting as I bet you can get a lot by other metadata (packet
size, PT, etc).

-Ekr

On Fri, Oct 7, 2016 at 1:41 AM, Magnus Westerlund <
[email-masked]> wrote:

> 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.
>
>
> 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.
>
> 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
>
>
>
>
>>
>>
>>> <[email-masked]> wrote:
>>>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Oct 2016 10:37:16 +0200

Den 2016-10-07 kl. 15:32, skrev Jonathan Lennox:
>
>> On Oct 7, 2016, at 4:41 AM, Magnus Westerlund
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> 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.
>
>    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.
>

Okay, forgot about that requirement. However, I don't think that really 
contradicts what was written. The proposed text recommends use of 
encryption of RTCP. RFC7904 mandates that if RTCP is encrypted then RTP 
header extension must also be encrypted. There should be a reference to 
this requirement in the text below, so I will update the text proposal.

Due to the security risks associated with the MID values in RTP and RTCP 
it is RECOMMENDED that the MID SDES item is confidentiality protected as 
well as source authenticated. The SDES RTP header extensions [RFC7904] 
requires encryption of the header extension in cases when the RTCP 
encrypts the SDES item. 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.

>> 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
>>
>>
>>>
>>>
>>>
>>>> <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>> <mailto:[email-masked]>
>>>> mmusic mailing list [email-masked] <mailto:[email-masked]>
>> <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Oct 2016 10:48:50 +0200

> have only very limited guidance on how to construct ICE

So, the difference here from stuff that normally exists in SDP is that 
it goes in many RTP packets in the clear compared to only over the 
signaling path. The ICE ufrag is in that sense equivalent as that is 
also sent in the clear and in all ICE connectivity checks.

The second seems
> not that interesting as I bet you can get a lot by other metadata
> (packet size, PT, etc).

Well, yes there are some other leakages. However, we don't need to 
increase the exposure, just because there are shortcomings today.

So lets review what the current proposal is:

1. Bundle RECOMMENDS encryption of the MID values, do you think that is 
unnecessary? Should we have no recommendation about confidentiality 
protection at all?

2. The above point is not relevant in a WebRTC perspective. In WebRTC we 
already have mandated encryption of RTCP. Thus, RFC 7904 mandates that 
we also encrypt the MID RTP header extension. Thus, for WebRTC we 
already have a result, that is not possible to change without revising 
RFC 7904 and argue that the conclusion there is wrong, which I don't 
think it is. If we protect information RTCP, it should be protected also 
in RTP headers.

So, anything you like to change here?

Cheers

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Oct 2016 09:32:22 +0000

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Oct 2016 11:47:12 +0000

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"
<[email-masked] on behalf of [email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Oct 2016 09:57:22 -0700

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Oct 2016 19:54:33 +0000

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:[email-masked]] On Behalf Of Eric Rescorla
Sent: 12 October 2016 19:57
To: Christer Holmberg <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]; Cullen Jennings <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Pull request created.

Regards,

Christer

On 12/10/16 12:32, "mmusic on behalf of Christer Holmberg"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Oct 2016 17:51:16 -0700

On Wed, Oct 12, 2016 at 12:54 PM, Christer Holmberg <
[email-masked]> wrote:

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

I don't think we need to say anything normative.

-Ekr

>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* mmusic [mailto:[email-masked]] *On Behalf Of *Eric
> Rescorla
> *Sent:* 12 October 2016 19:57
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* Magnus Westerlund <[email-masked]>; Paul Kyzivat <
> [email-masked]>; [email-masked]; Cullen Jennings <[email-masked]>
> *Subject:* Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32
> - Magnus' comments - MID security
>
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 13 Oct 2016 11:09:07 +0200

Den 2016-10-13 kl. 02:51, skrev Eric Rescorla:
>
>
> On Wed, Oct 12, 2016 at 12:54 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     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.____
>
>     __ __
>

Can you please be a bit more constructive here?

I hope you are not disagreeing with a RECOMMEND for source 
authentication at least? Having third party attackers being able to 
change the MID on path that is a quite serious attack, so integrity and 
source authentication I think is well motivated.

Regarding the aspects regarding privacy and information leakage. You 
previously indicated that you agree that we should at least avoid 
structured MIDs to avoid that implementation specifics or hardware 
addresses of source devices leaks this way. This would mean that BUNDLE 
should contain guidance on how to construct them so this is avoided. 
This is currently not included. I have no problem with including such 
recommendations. Do you have a proposal for how to construct them?

When we come to the last aspect regarding confidentiality protection of 
the MID identifiers I can understand the hesitance over this. For some 
use cases I agree the information leakage is in principal zero, as the 
fact that the streams are there are present through SSRCs, PTs etc. 
However, especially for multiple  streams originating from a endpoint, 
rather than a conference mixer, this do exposes information. Here the 
above discussed recommendations do matters for what information can be 
leaked. For example if we would sequentially assign identifers, then we 
exposes the potential sub-selection of streams the signalling agrees on 
at the RTP layer. If we use random values this exposure can be avoid.

I proposed encryption as method that would ensure that we had random 
identifiers of good properties. But, what is your proposal for how these 
identifiers should be construct to minimize the exposure of information?

I also asked the question if there was issues with encrypting this from 
a functional perspective? Unless I receive an answer I will assume not, 
and that it is primarily a hesitant to start using RFC6904.

 From my perspective, lets settle the guidance for construction, then we 
can document what the potential remaining risks are in the security 
consideration. I personally think it is more important to document the 
risks than absolutely have the RFC2119 recommendation here.

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Oct 2016 05:12:38 -0700

> Can you please be a bit more constructive here?

I think I am being constructive. I'm trying to get the draft finished, and
this seems to be poorly motivated.

I hope you are not disagreeing with a RECOMMEND for source authentication
> at least? Having third party attackers being able to change the MID on path
> that is a quite serious attack, so integrity and source authentication I
> think is well motivated.
>

There seem to be two cases:

1. You're using SRTP (and this should also include SRTCP).
2. You're not using SRTP.

In case #1, then the MID should be integrity protected because it's part of
the packet. If not, then I don't think a partial solution helps.

> addresses of source devices leaks this way.

No, that's not what I said. Rather, I said:

"The first of these seems addressable by guidance about how to construct
these IDs. I note that we
have only very limited guidance on how to construct ICE ufrag/passwords...."

If you think this kind of identifier-generation tracking is an issue, I
would suggest doing a broader survey
first, rather than focusing on this case.

-Ekr

This would mean that BUNDLE should contain guidance on how to construct
> them so this is avoided. This is currently not included. I have no problem
> with including such recommendations. Do you have a proposal for how to
> construct them?
>
> the MID identifiers I can understand the hesitance over this. For some use
> cases I agree the information leakage is in principal zero, as the fact
> that the streams are there are present through SSRCs, PTs etc. However,
> especially for multiple  streams originating from a endpoint, rather than a
> conference mixer, this do exposes information. Here the above discussed
> recommendations do matters for what information can be leaked. For example
> if we would sequentially assign identifers, then we exposes the potential
> sub-selection of streams the signalling agrees on at the RTP layer. If we
> use random values this exposure can be avoid.
>
> I also asked the question if there was issues with encrypting this from a
> functional perspective? Unless I receive an answer I will assume not, and
> that it is primarily a hesitant to start using RFC6904.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 13 Oct 2016 15:18:06 +0200

Den 2016-10-13 kl. 14:12, skrev Eric Rescorla:

> On Thu, Oct 13, 2016 at 2:09 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> I think I am being constructive. I'm trying to get the draft finished,
> and this seems to be poorly motivated.
>

Yes, I am also trying to get it finished by ensuring that we actually 
have a security consideration section that discuss the potential issues.

>     change the MID on path that is a quite serious attack, so integrity
>     and source authentication I think is well motivated.
>
>
> In case #1, then the MID should be integrity protected because it's part
> of the packet. If not, then I don't think a partial solution helps.
>

Yes, I agree that if you are using the SRTP/SRTCP then this is not an 
issue. But, as we clearly point out in RFC 7201 SRTP is not the only 
solution. Thus, I at least try to ensure that any security 
considerations around RTP do discuss the requirements rather than 
mandating a single solution.

Do you have a problem with actually saying that source authentication is 
something that one really should do?

> first, rather than focusing on this case.

Okay, then I misunderstood your intention with bringing up ICE.

As that broader survey is quite a significant work and something that 
likely spans at least from the transport flow structure, across the RTP 
streams up to the signaling this is quite an undertaking if one want to 
investigate what possibilities exist just for the media protocol part of 
a WebRTC system. No something I will promise to do. I will once more 
remark that our steps from single media streams to multi-stream, 
multi-party setups has changed what we exposes at the different layers.

But, I can agree that BUNDLE is likely not the most appropriate point to 
tackle the fingerprinting issue. So unless someone else is of the 
opinion that is needs to be tackled in BUNDLE i will drop this for now.

However, that doesn't remove the need for an updated MID related 
security consideration. The MID security part in current version is the 
following:

    The identification-tag MUST NOT
    contain any user information, and applications SHALL avoid generating
    the identification-tag using a pattern that enables application
    identification.

This completely ignores the issues with on path modifications. That at 
least needs to be added.

Okay, dropping the fingerprint, I still think the security consideration 
should say something 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 for 
privacy reasons nor hardware based identifiers that would enable 
tracking of the sending end point.

The identification-tag is used to route the media stream to the right 
application functionality, thus is important that the value received is 
the one intended by the sender. Malicious modifications can result in 
that a media stream is wrongly attributed or fails to be played. Thus, 
integrity and the authenticity of the source are RECOMMENDED to the 
attacks on the application. Note, that the SDES RTP header extensions 
[RFC7941] requires encryption of the header extension in cases when the 
RTCP encrypts the SDES item. Security 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.

Is the above more acceptable?

Cheers

Magnus Westerlund