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

["Paul E. Jones" <[e-mail]>]

Magnus,

I apologize for taking so long to get back to you.  Please see my 
responses below.

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

I agree we should have further discussion on this.

Two reasons we took the approach we did were:
1) Attempt to not deviate from the procedures in RFC 3711 that rely on 
SSRC and sequence number
2) View we take on how the conference server operates as a "switch"


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

The requirements are in the separate requirements document.  This 
document was intended to present one possible direction, but I 
appreciate there are different views.


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

You're right that we did not consider a need for end-to-end security of 
RTCP or header extensions.  Our objective was to ensure that media was 
secured.  The need to secure RTCP end-to-end would present certain 
challenges for aggregating RTCP information.  If we support encryption 
end-to-end of portions, that might be OK, but we didn't have a need for 
that.  You mentioned having location information in RTP or RTCP.  Are 
there truly requirements for that?  Is that for the benefit of emergency 
services to get location of a caller while moving?


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

This is needed, but we just did not put that in the scope of this text.  
You're right, though, that a complete solution will need to consider 
those aspects.


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

Agreed, but should it be discussed in the framework or in a separate 
draft?  I expect before this work is done that there would be one or 
more drafts covering the signaling, identity, etc. issues.


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

Perhaps motivation text is lacking there, but it was to simplify the 
work on the endpoint.  If the endpoint makes a call point-to-point or 
calls into a conference server, we want the endpoint to follow the same 
logic at the media layer.  Using a single DTLS connection makes things 
pretty transparent to the endpoint.

You also present a possible solution that we should consider.

Dan Wing and Tiru Ready  also suggested that perhaps we might want to 
terminate the DTLS on the server, but then use another secure mechanism 
to convey the EKT Key.  That mechanism can avoid the need to forward 
every DTLS message to the KMF.

Note that we are assuming in the framework that the DTLS-SRTP connection 
would never be used for sending application data, such as the WebRTC 
Data Channel.  I sent a separate message a while back about having a 
thin shim layer to allow muxing, proposing 0x04 as the multiplexing code 
point.  I think we seriously should consider that if we will have more 
than one DTLS connection.


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

As you'll note from the most recent document, I didn't do that due to 
lack of time; it was just a minor revision.  However, I am open to 
collaborating with people to help drive forward some kind of solution 
and would welcome a collaborative engagement with interested people.

Paul