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

[Magnus Westerlund <[e-mail]>]

Paul,

Please see inline.



On 2015-03-11 06:01, Paul E. Jones wrote:
> 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

I can understand this, but I think it is SRTP extensions that has to
adapt rather than placing quite many constraint on the RTP side.

> 2) View we take on how the conference server operates as a "switch"

Well, the switching operation appears to have been implemented in
several different ways. I see the motivation for the different methods
applied. Thus, I see an issue with having this work restrict how the
middlebox work.


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

Yes, but the document is called a framework. I did notice that you
updated the requirements document to create an explicit requirement on
keeping the SSRC. I fail to see why that occurred, it didn't appear to
be motivated at all.

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

I want people to think about this issues, an not immediately dismiss the
idea just because it might look hard and they can't think of an
immediate need for it.

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

Good, I am looking forward to more discussion on the subject.

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

I think there need to be something high level that discuss the trust
model and what entities that involved and what requirements exists on
the different entities and their interactions. Then one point to
specific pieces for how to fulfil these requirements.

This is touching on an issue that I think we need to discuss. Is really
AVTCORE the right WG for this? I have been away so I missed the earlier
steps, but from my personal perspective we have a lot of data that
AVTCORE has big issues gathering critical mass on security related topics.

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

Thanks for the background. I have to think about this a bit. What needs
to be clear is how the client verifies that it reach the appropriate KMF
and is not man in the middled.

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

Clearly something to think about.

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

Okay, I hope that the AVTCORE agenda discussion that you have requested
will focus on the most important high level bits. I think you need to
consider to actually send the questions you intended to discuss to the
WG mailing list ahead of time so people can prepare.

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