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

[Magnus Westerlund <[e-mail]>]

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

> On Thu, Oct 13, 2016 at 2:09 AM, Magnus Westerlund
> <[e-mail] <mailto:[e-mail]>>
> wrote:
>
>     Den 2016-10-13 kl. 02:51, skrev Eric Rescorla:
>
>
> 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.

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

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?

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

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

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