Re: [AVTCORE] Design choice comments on draft-jones-avtcore-private-media-framework-00

[Magnus Westerlund <[e-mail]>]

Hi,

Please see inline.

On 2015-02-19 17:04, Paul E. Jones wrote:
> Magnus,
> 
>> Hi,
>> (As individual)
>>
>> I have just reviewed the draft and are supportive of work in this field.
>> However, I have some really high level comments in regards to the design
>> choices.
>>
>> 1. Supported RTP topologies
>>
>> I think you will need to discuss a bit more which RTP topologies that
>> the framework should support. The current draft supports only basic
>> transport translators (Relay) to my understanding, because of it
>> preventing rewriting of RTP sequence number as well as the SSRC. Thus,
>> all RTP streams sent to the server must be forwarded to all other
>> participants.
>>
>> I believe the intention of the document is to support at least Selective
>> Forwarding Middlebox (SFM). However, to support such a topology and be
>> able to suspend delivery of some media streams, then RTP sequence number
>> rewriting becomes a requirement to keep the media streams compliant with
>> current RTP specification.
>>
>> Also people who have been building conferencing middleboxes also uses
>> other topologies, for example the RTP mixer in also used to build
>> switching mixers. Where an SSRC can represent a role rather than a
>> original sender.
>>
>> I think there is need to have some discussion of which RTP topologies
>> this type of solution intends to support so that one can determine which
>> RTP field behaviours that is to be expected and need to be dealt with.
>>
>> I would appreciate your view of what you see as needed to be supported.
> 
> I agree that we will need to elaborate a bit more on that, but it's not
> clear to me if any of the existing topologies that are defined match
> exactly.  The desire to prevent changes to the RTP headers means that
> something else is needed in order to properly forward media (e.g., a
> header extension) and account for packet loss, handle congestion issues,
> etc.

Lets discuss this more, but I like to state my personal position here. I
much rather see the security solution take the current RTP into account,
rather than forcing us to redefine RTP and make changes to how existing
and working mechanisms function. In this case I am especially concerned
your disregard to ensure that the RTP sequence numbers will be sent
without sender side gaps in the sequence. This as it impacts the
existing packet loss detection and reporting mechanisms.

> 
> We've been more focused on what we want to accomplish than trying to fit
> the solution into a specific topology.  I think we can get there, but we
> need more discussion as a group.

I think that is fine, but you appear to have jumped to conclusions and
suggested technical solutions that consider the security goals but not
the RTP implications. Thus, I would suggest that you focus on making
clear the high level security requirements and then factor in the
existing RTP and its impact on possible solutions.

> 
> 
> 
>>  2. Additional privacy concerns in RTP/RTCP.
>>
>> The proposed framework protects the RTP payloads and their media content
>> from the middle. However, the document fails to discuss if privacy
>> protection is needed either for the RTP header extensions themselves or
>> if any RTCP packets or their content is privacy sensitive.
>>
>> The RTP header extensions that are defined in IETF, as well as the two
>> 3GPP has registered appears to be privacy sensitive in any way. However,
>> the big picture issue is that RTP header extensions do not require to be
>> standardized. The registration requires only an Expert Review, and they
>> are trivial to use for proprietary extension. So we have no idea what
>> might be showing up here. I could easily believe that someone would for
>> example include a geolocation attached to a video stream to capture
>> where for example a airborne drone where when capturing the video.
>> Suddenly you have data that is privacy sensitive and may require end to
>> end protection.
>>
>> In RTCP you already today have some parts that are privacy sensitive.
>> For example all the SDES items with the exception of CNAME (if generated
>> correctly) can contain privacy sensitive data. Also the APP RTCP packet
>> type might contain data that needs to be protected end to end.
>>
>> Thus I think you need to consider if there are need for additional
>> protection mechanisms to realize the goals of this framework. To me it
>> appears that this are reasonably straightforward SRTP extensions that
>> could solve these issues if they are considered necessary to resolve.
>> Even if the initial solution doesn't provide a fully specified solution,
>> I think it is important to ensure that the framework do support a
>> solution to specified at a later stage.
> 
> The intention was the RTP header extensions and RTCP could optionally be
> encrypted using the SRTP keys exchanged as they are today.  This would
> be done hop-by-hop.  This does not provide for end-to-end privacy, of
> course.  That fits with the goals we've stated in the requirements
> document.  We're not trying to hide the fact that two people
> communicated, for example, but we do not want to disclose what is being
> communicated.
> 
> If there is truly a need to encrypt end-to-end such that middle boxes
> cannot gain access to some RTP header extensions or some RTCP data
> fields, I would assert we need to define a way to allow some header
> extensions and some RTCP header fields to be visible hop-by-hop.  We do
> want to enable middleboxes to be able to collect and use RTCP
> statistics, for example.  We also want to allow them to have access to
> any header extension that help facilitate packet forwarding and processing.

I fully agree that there MUST be possibility to have both RTP header
extensions as well as many type of RTCP packets to be only protected hop
by hop. The core of my comment is rather that the solution appear to
need to take into account the likely need for end-to-end protection of
other RTP/RTCP fields and actively discuss in its security
considerations the privacy risk from some existing RTP/RTCP protocol
elements, specifically the RTCP SDES items.

> 
> 
>>
>> 3. What must be in the trusted zone?
>>
>> Looking at the description it looks like the solution is missing one
>> important part in the trusted zone. That is the list of identities or
>> secret that enables an invited / allowed participant to participate in a
>> particular conference. That functionality is key component of the
>> security solution. How else is the KMF going to be able to determine
>> which asserted identities that are allowed to get the EKT, thus being
>> able to get access to the media.
>>
>> I understand the need for having solution agility when it comes to
>> identity solutions, however the functionality and the requirement on it
>> I think needs to be described in this type of framework.
> 
> This framework is only focused on the media aspects.  The approach we're
> taking here is that there is some kind of exchange that happens between
> the endpoint and the KMF or some other trusted entity that exists in the
> signaling plane.  It is through this signaling that a determination is
> made as to what endpoint can have access to the keys for a particular
> conference.  We expect that fingerprint for the endpoint certificate
> would be exchanged with the KMF and vice versa.

I think that is not sufficient as it can not ensure the security goals
of providing confidentiality. Without explicitly discussing the fact
that there is a set of trusted participants and the need for a mechanism
to verify that a endpoint is representing that such a participant the
solution is flawed.

I fully understand that there is need to enable multiple technical
solutions for verifying that identity, however if the intention is to
provide a framework for solving this issue, the requirement on parts
that are outside of this WGs main expertise, namely RTP must still be
discussed.

> 
> When the DTLS connection is made to the switching conference server,
> that would be tunneled (via a protocol we've defined but not published)
> from the switching conference server to the KMF.  Effectively, the
> endpoint and KMF establish a DTLS connection.  The KMF would recognize
> the user as belonging to a particular conference and provide the SRTP
> keys (using DTLS-SRTP procedures) and the EKT key (via the EKT
> procedures).  One thing I would like to add to the EKT draft is some
> piece of data that indicates what the conference identifier is.  I would
> like the endpoint to convey that information as part of the EKT
> exchange, but no such field exists today.  I would also like the
> conference server to convey the conference identifier for comparison.

I do wonder about this part of the solution. Why the structure you have
selected? Another potential solution is clearly to run two different
DTLS-SRTP handshakes, one directly between endpoint and KMT, the other
between the endpoint and server. Once more I think you jumped into
solution without motivating why you think the proposed solution is the
appropriate.

> 
> So, the framework is clearly not complete even on the media side.  There
> are some editor's notes and perhaps additional items (like the field for
> the conference identifier).  However, I would prefer to keep the
> signaling that happens before this point separate.  The reason is that I
> can imagine that a number of different mechanisms might exists.  For a
> WebRTC client, for example, the signaling might be entirely proprietary.
>  For SIP devices, we then also have to worry with securing the signaling
> exchanges  That's important, but I think that can be done in parallel
> and independently of this media-focused draft.

Fully agree about the need for different signalling mechanism. However,
to me it appears there need to be one or a small set of solution or at
least hooks for how the KMT can verify the endpoint's right to be in
particular session.

I hope that you can take this discussion into account and improve your
framework document to clearer on what you see as the minimal necessary
functions in a solution. And when having established that can go into a
discussion of proposed solutions to realize that.


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