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

[Magnus Westerlund <[e-mail]>]

On 2015-03-17 03:29, Paul E. Jones wrote:
> Magnus,
> 
>>>  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.
> 
> 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).

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.

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

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

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

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

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

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

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

Thanks



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