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

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 11 Mar 2015 05:01:39 +0000

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Mar 2015 14:46:39 +0100

Paul,

Please see inline.

On 2015-03-11 06:01, Paul E. Jones wrote:
>>>  I agree that we will need to elaborate a bit more on that, but it's not
>> 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,

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.

>>>  the solution into a specific topology. I think we can get there, but we

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
>>>  communicated, for example, but we do not want to disclose what is being
>>>  communicated.
>>>
>>>  extensions and some RTCP header fields to be visible hop-by-hop. We do
>> extensions as well as many type of RTCP packets to be only protected hop

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
>> that there is a set of trusted participants and the need for a mechanism

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

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

>>>  that would be tunneled (via a protocol we've defined but not published)
>>>  piece of data that indicates what the conference identifier is. I would

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.

> than one DTLS connection.

Clearly something to think about.

> 
> 
>>>  So, the framework is clearly not complete even on the media side. There
>>>  signaling that happens before this point separate. The reason is that I

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Mar 2015 15:01:30 -0700

> applied. Thus, I see an issue with having this work restrict how the

[BA] Preventing a MANE/SFU from modifying the SSRC or sequence number field is not a minor restriction - it will break the majority of existing MANE/SFU implementations, and there are no good workarounds. 
AFAIK, the vast majority of existing MANE/SFU implementations modify the SSRC field and implementations supporting SRST modify the sequence number field when dropping an SVC layer.  
Also, SSRC field modification is not just for MANE/SFU implementations that support scalable video coding; there are also simulcast implementations that do this (I believe that the Hangouts SFU is one of them). 
To my mind, a problem this fundamental indicates that there is insufficient understanding of how MANE/SFU implementations operate today.

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 17 Mar 2015 02:29:18 +0000

Magnus,

>keeping the SSRC. I fail to see why that occurred, it didn't appear to

I assume you might be referring to PM-06.  That has been there for a 
while, existing as PM-10 in the -00 draft.  The reason is just that we 
need an end-to-end cryptographic context.  Appreciating that this could 
be made to be less SRTP-centric (e.g., something we could implement with 
something like Aero), perhaps this might be a better PM-06?

PM-06: A cryptographic context suitable for enabling end-to-end 
authenticated encryption MUST be defined. Note that in SRTP, the 
cryptographic context includes the SSRC, sequence number and rollover 
counter (ROC).

>idea just because it might look hard and they can't think of an

We did not dismiss it for reasons of difficulty.  Rather, we were only 
focused on ensuring end-to-end media privacy (i.e., voice and video 
content) and did not have a a requirement for ensuring that control 
information be encrypted end-to-end.  That said, it is more challenging 
when there is a need for intermediary to act on some parts of the 
control information and not other parts.

>AVTCORE has big issues gathering critical mass on security related 

All good points.  I think it's worth the group's time to discuss the 
problem we're trying to solve at a high level and fight the right home 
for it if avtcore is not the most appropriate place.

Finding security experts on any vertical topic is always a challenge and 
not unique to avtcore.  In an ideal world, there would be folks who are 
"dedicated" to security matters in all areas, but that's difficult to do 
since people have other work and already don't have enough time in the 
day.  Still, I agree we need an appropriate review of the work.

>WG mailing list ahead of time so people can prepare.

I'll try to do that, but the way things have been going in my work 
day-to-day, it might be quite late this week or early next week (e.g., 
Sunday night).

Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Mar 2015 15:49:35 +0100

> cryptographic context includes the SSRC, sequence number and rollover

Yes, I reacted to the change of the requirement appearing to mandate the
SSRC was inmutable in the middlebox. An endpoints crypto context can be
SSRC driven, as long as all components does not require that the value
stay the same from sender to receiver.

For example, if one would key with EKT, then as long as the EKT messages
are kept with the RTP payloads, even if the RTP headers are changed and
the SSRC different the EKT could provide the key for this specific
stream, and it makes sense for the receiving endpoint to look up the
context based on the local SSRC.

> control information and not other parts.

Sure, lets just continue to discuss both the actual needs for this as
well as the potential to solve it.

> for it if avtcore is not the most appropriate place.

Agreed, for the moment this is in AVTCORE and there is definitely need
for RTP expertise in this work.

> day.  Still, I agree we need an appropriate review of the work.

Yes, lets consider how we best can achieve getting the needed people
engaged in this matter.

> day-to-day, it might be quite late this week or early next week (e.g.,

Thanks

Magnus Westerlund