Subject: Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC)

From: "Ben Campbell" <[email-masked]>
Date: Thu, 09 Apr 2015 16:29:03 -0500

For the record, I'd love to see this get chartered. I think the charter 
is on the right track. It might be worth mentioning the drafts in the 
charter as "inputs" to the work.

Is anyone else interested in working on this?

/Ben

On 25 Mar 2015, at 18:27, Magnus Westerlund wrote:

> Dispatch,
>
> AVTCORE WG has discussed a couple of proposals that discusses 
> end-to-end
> security in centralized RTP based conferences.
>
> Drafts for these Proposals:
> https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/
> https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framework/
> https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/
>
> In these discussions one has reached the conclusion that this work
> requires its own venue to continue the work. Therefore a number of
> interested has put together a initial draft charter for a new WG.
>
> Please review and provide feedback.
>
>
> Name: Privacy Enhanced RTP Conferencing (PERC)
> Area: ART
> Chairs: TBD
> Mailing List: <using [email-masked] for now>
>
> Motivation for new WG
> ---------------------
>
> RTP-based real-time multi-party interactive media conferencing is 
> today
> in widespread use. Many of the deployments uses one or more centrally
> located media distribution devices that perform selective forwarding 
> or
> mixes media streams received from the participating endpoints. The 
> media
> transport protocol commonly used is RTP (RFC3550). There are various
> signaling systems used to establish these multi-party conferences.
>
> These conferences require security to ensure that the RTP media and
> related meta data of the conference is kept private to the set of
> invited participants and only other devices trusted by those
> participants with their media.  At the same time, multi-party media
> conferences do need source authentication and integrity checks to
> protect against modifications, insertions or replay attacks.  Media
> distribution devices supporting these conferences may also perform RTP
> header changes and often consume and create RTCP messages for 
> efficient
> media handling.
>
> To date, deployment models for these multi-party media distribution
> devices do not enable them to perform their functions without having
> keys to decrypt the participants’ media, primarily using Secure RTP
> (RFC3711) to provide session security.
>
> A new architecture model and related specifications is needed, with a
> focused effort from the RTP and Security communities.
>
> WG Objectives
> -------------
>
> This WG will work on a solution that enables centralized SRTP based
> conferencing where the central device distributing the media is not
> required to be trusted with the keys to decrypt the participant’s 
> media.
> The media must be kept confidential and authenticated between an
> originating endpoint and the explicitly allowed receiving endpoints or
> other devices.  Further it is desired that a solution still provide
> replay protection so that the media distribution devices can’t 
> replay
> previous parts of the media.
>
> The solution must also provide security for each hop between endpoints
> and multi-party media distribution devices and between multi-party 
> media
> distribution devices. The RTCP messages and RTP header extensions
> required for the media distribution device to perform the selective
> media forwarding may require both source authentication and integrity 
> as
> well as confidentiality. The solution may also consider providing
> end-to-end security for a subset of the RTCP messages or header 
> extensions.
>
> The solution should be usable from both SIP and WebRTC endpoints that
> implement the extension defined by this WG.
>
> This WG will perform the following work:
>
> 1.    Define a general architecture and RTP topology(s) that enables
>    end-to-end media security for multi-party RTP conferencing.
>
> 2.    Define the trust model and describe the resulting security
>    properties.
>
> 3.    Specify any necessary extensions to SRTP.
>
> 4.    Define a Key Management Function that distributes the keys. The
>    system needs to be able to bind the media to the sender of the
>    media’s identity and/or the identity of the conference.
>
> Collaboration
> -------------
>
> If there is identification of missing protocols or functionalities, 
> such
> work can be requested to be done in another working group with a
> suitable charter or by requests for chartering it in this WG or 
> another
> WG. Potential work that might require work in other WGs are DTLS
> extensions (TLS) as well as RTP header extensions (AVTEXT). This
> requires strong collaboration with the security area. We will notify
> SIPREC, W3C WebRTC, AVTCore, and other related groups about this work.
>
> Non-Goals
> ---------
>
> The WG is not chartered to extend any signaling system used to 
> establish
> the RTP based conferences. It will however, need to consider in its
> architecture how the solution may integrate with these systems.
>
> Will not consider non-real-time usages, multicast based media
> distribution, or Security descriptions-based keying.
>
> Goals and Milestones
> --------------------
>
> TBD  Submit architecture or framework specification to IESG (Standards
> Track)
>
> TBD  Submit protocol specification(s) to IESG (Standards Track)
>
>
>
>
> Cheers
>
> Magnus Westerlund
> (AVTCORE WG chair)
>
>
> ----------------------------------------------------------------------
> 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]
> ----------------------------------------------------------------------
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Apr 2015 14:03:37 +0200

> Is anyone else interested in working on this?

To be clear, one benefit of getting the work out of my WG (AVTCORE) is
that I can be an active contributor, rather than a chair of this.

I do hope that people speak up, we had close to 20 persons in the room
when we had a drafting session of the charter in Dallas.

Cheers

Magnus

>> AVTCORE WG has discussed a couple of proposals that discusses end-to-end
>> RTP-based real-time multi-party interactive media conferencing is today
>> located media distribution devices that perform selective forwarding or
>> mixes media streams received from the participating endpoints. The media
>> header changes and often consume and create RTCP messages for efficient
>> media handling.
>>
>> required to be trusted with the keys to decrypt the participant’s media.
>> replay protection so that the media distribution devices can’t replay
>> and multi-party media distribution devices and between multi-party media
>> media forwarding may require both source authentication and integrity as
>> If there is identification of missing protocols or functionalities, such
>> suitable charter or by requests for chartering it in this WG or another
>> The WG is not chartered to extend any signaling system used to establish

-- 

Magnus Westerlund

---

From: Simon Perreault <[email-masked]>
Date: Fri, 10 Apr 2015 08:19:52 -0400

> Is anyone else interested in working on this?

Most definitely.

Simon

---

From: Robert Sparks <[email-masked]>
Date: Fri, 10 Apr 2015 09:37:19 -0500

So, I think this should get chartered.
I have a couple of charter-bashing questions/comments.

It would be good to be clear what any interactions with the work in CLUE 
might be.

What is the motivation for declaring any extensions to signalling 
systems out of scope? (Not saying I see any that need to be created, but 
I'm surprised that it's not something that the group might need to 
investigate rather than making that call at chartering time)?

RjS

On 4/9/15 4:29 PM, Ben Campbell wrote:
> For the record, I'd love to see this get chartered. I think the 
> charter is on the right track. It might be worth mentioning the drafts 
> in the charter as "inputs" to the work.
>

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 10 Apr 2015 10:57:28 -0500

On 10 Apr 2015, at 9:37, Robert Sparks wrote:

> systems out of scope? (Not saying I see any that need to be created, 
> but I'm surprised that it's not something that the group might need to 

I'm curious how that limitation interacts with the key-management 
deliverables. If there are assumptions underlying these, it would be 
good to explicitly state them in the charter.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 13 Apr 2015 10:33:32 +0200

> It would be good to be clear what any interactions with the work in CLUE

I hope someone more active than me can step in an give their view here.
To me this should be possible to use with CLUE. I don't know if that
will be possible without any extensions to the clue part.

> investigate rather than making that call at chartering time)?

My reasons is to keep this WG focused on what it actually needs to
produce and not get completely tied up in discussion of exactly how one
will integrate this into ones signalling system. So I know people want
this in WebRTC and SIP based conferences. I haven't heard anyone saying
CLUE, but that is likely. These integrations are quite different,
especially in what pieces you will trust when it comes to client
software. Thus, my view was that WG working with signalling systems is
the ones that should provide any necessary integration towards the
framework.

I do note that this consideration of integration is mentioned in this
paragraph under Non-Goals:

"The WG is not chartered to extend any signaling system used to
establish the RTP based conferences. It will however, need to consider
in its architecture how the solution may integrate with these systems."

But, I guess one could be more explicit and require the WG to consider
how one integrate into WebRTC, SIP and CLUE so that the framework is
functional for these systems.

When it comes to the key-management function, I think there exists an
assumption here. That is that signalling and its nodes can't be trusted,
only possible be used as a transport for key-management system
information. But that will require that the communication fails if
someone strips or modify such information.

Does this help clarify the situation.

Cheers

Magnus Westerlund

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Apr 2015 09:49:50 -0400

> will be possible without any extensions to the clue part.

I *think* there will be a problem: that a mixer won't be able to insert 
the clue capture-id into the RTP/RTCP.

Roni and Jonathan should be able to be more definitive about this.

	Thanks,
	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 Apr 2015 15:11:18 +0000

On Apr 13, 2015, at 9:49 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

I *think* there will be a problem: that a mixer won't be able to insert the clue capture-id into the RTP/RTCP.

PERC will need the ability for the middleboxes to insert hop-by-hop header extensions and RTCP SSRC values — BUNDLE will need this for the mid values.

Once we work out how to do this securely, the same mechanism should work for capture-id for CLUE.

I think this is within the domain of what PERC is intending to trust middleboxes to do.

—
Jonathan Lennox
[email-masked]<mailto:[email-masked]>

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 Apr 2015 15:24:29 +0000

On Apr 13, 2015, at 11:11 AM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:

Should be “SDES” values, sorry.

—
Jonathan Lennox

---

From: Robert Sparks <[email-masked]>
Date: Mon, 13 Apr 2015 10:42:16 -0500

On 4/13/15 10:24 AM, Jonathan Lennox wrote:
>>> I *think* there will be a problem: that a mixer won't be able to 
>>> insert the clue capture-id into the RTP/RTCP.
>>>
>> PERC will need the ability for the middleboxes to insert hop-by-hop 
>> header extensions and RTCP SSRC values — BUNDLE will need this for 
>> the mid values.
>
If SDES is an assumption, it should land in the charter.
I hope it's not an assumption, and that you'll be able to use other tools.
>> [email-masked] <mailto:[email-masked]>
>>
>
>
>

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 Apr 2015 15:51:44 +0000

On Apr 13, 2015, at 11:42 AM, Robert Sparks <[email-masked]<mailto:[email-masked]>> wrote:

Oh, this stupid name collision.

I mean RTCP SDES packets, “Source Description” (as defined in RFC 3550), not SDP Security Descriptions (RFC 4568).

I think Security Descriptions should absolutely not be used for PERC, I think it would completely break the security model (barring magical secure side-channels).

---

From: Robert Sparks <[email-masked]>
Date: Mon, 13 Apr 2015 11:27:33 -0500

On 4/13/15 10:51 AM, Jonathan Lennox wrote:
> I mean RTCP SDES packets, “Source Description” (as defined in RFC 
> 3550), not SDP Security Descriptions (RFC 4568).
>
> I think Security Descriptions should absolutely not be used for PERC, 
> I think it would completely break the security model (barring magical 
> secure side-channels).
Good - thanks for the clarification.

---

From: Adam Roach <[email-masked]>
Date: Mon, 13 Apr 2015 16:31:58 -0500

> Is anyone else interested in working on this?

We're definitely interested in implementing client functionality to 
support the requirements outlined in 
draft-jones-avtcore-private-media-reqts. I am willing to provide 
feedback on the work and to convey information back from our 
implementation team as the specifications progress.

> investigate rather than making that call at chartering time)?

I think that the expertise required to make PERC successful is somewhat 
different than that involved in extending SIP in a sensible fashion. I 
would prefer this WG talk about the nature of the information that needs 
to be exchanged in order to make the system work, and then have a 
separate effort that discusses how to encode it at the signaling layer. 
I suspect that the majority of this information will be conveyed in SDP 
for SIP and JSEP, and that the corresponding specification work would 
take place in MMUSIC. From that perspective, it would probably be good 
to mention MMUSIC in the "Collaboration" section of the charter.

Based on the architecture as proposed in the drafts, there will probably 
be one or more new interfaces that don't presently exist (e.g. to convey 
identity information from the key server to the participants). These 
aren't extensions to "any signaling system used to establish the RTP 
based conferences," and there aren't existing protocols that clearly 
handle them (as far as I know). I think the charter should be clear on 
whether development of protocols for these interfaces are in scope. If 
they're not, we should at least have some idea of where they *will* be 
developed.

> insert the clue capture-id into the RTP/RTCP.

One of the really important characteristics of the current proposals is 
that they allow the MCU (not really a mixer, more of a switcher) to 
read, add, modify, and remove RTP header extensions. There is a 
mechanism for end-to-end encryption of some extension headers if the 
endpoints require that property, but it's optional.

/a

---

From: Christian Groves <[email-masked]>
Date: Tue, 14 Apr 2015 10:27:45 +1000

Hello,

Please see below [CNG].

Regards, Christian
> the ones that should provide any necessary integration towards the
[CNG] I don't see CLUE being a lot different from normal SIP based 
conferences apart from the RTP header issue raised by Paul K. All CLUE 
is really doing is providing metadata to endpoints to allow them to 
select media captures more intelligently. If an endpoint is using 
private media there may be some consideration of "how much" CLUE 
metadata to provide to a 3rd party switch.
> in its architecture how the solution may integrate with these systems."
[CNG] I think this is the important thing. Whilst the proposed WG may 
not actually do extensions, I think its important to consider how PERC 
will be integrated and this should be documented up front as part of the 
architecture. I think that will be an aid to further discussions.

---

From: Christian Groves <[email-masked]>
Date: Tue, 14 Apr 2015 10:35:22 +1000

Hello Jonathon,

On 14/04/2015 1:11 AM, Jonathan Lennox wrote:
> header extensions and RTCP SSRC values — BUNDLE will need this for the 
> mid values.
>

[CNG] Is this something we need to address in 
draft-ietf-clue-rtp-mapping, e.g. the captureID shouldn't be encrypted 
to facilitate switching? Any CLUE endpoint type may use the CaptureID 
header extension. I guess we don't want the situation where an endpoint 
encrypts the captureID and then a middlebox appends another captureID to 
switched RTP stream.

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Apr 2015 09:59:58 -0400

> metadata to provide to a 3rd party switch.

You highlight an interesting point.

If the goal is for the participants to conference without trusting the 
intermediary that does the "switching", then they may also not trust 
that intermediary to see the clue metadata that describes the media and 
the participants. There might need to be a way for the advertisements by 
the endpoints to be encrypted, so that the intermediary can only collect 
them and pass them on to the other endpoints.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 14 Apr 2015 20:05:35 +0000

Ben,

It perhaps goes without saying that I'm interested in working on this.

Paul

------ Original Message ------
From: "Ben Campbell" <[email-masked]>
To: "Magnus Westerlund" <[email-masked]>
Cc: "DISPATCH list" <[email-masked]>
Sent: 4/9/2015 5:29:03 PM
Subject: Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP 
Conferencing (PERC)

---

From: Adam Roach <[email-masked]>
Date: Thu, 16 Apr 2015 13:02:39 -0500

On 4/14/15 08:59, Paul Kyzivat wrote:
> that intermediary to see the clue metadata that describes the media 
> and the participants. There might need to be a way for the 
> advertisements by the endpoints to be encrypted, so that the 
> intermediary can only collect them and pass them on to the other 
> endpoints.

These are sent in RTP header extensions, right? RFC6904 lets you encrypt 
selected header extensions end-to-end. In the current PERC proposals, 
anything encrypted with RFC6904 would be visible to the participants, 
but not to the MCU.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Apr 2015 14:23:56 -0400

> anything encrypted with RFC6904 would be visible to the participants,

No. The advertisements are send over a data channel. In a conference 
usage, they (and the RTP media) are sent to the mixer. Then the mixer 
can consolidate the advertisements it has received, and the 
corresponding media, in any manner it wants. The consolidated 
advertisements are sent out to the participants.

The mixer needs to respond to the advertisements. Doing so it indicates 
which media it wants to receive, which will affect what media it can 
offer. Superficially it is hard to conceive of how a mixer could do its 
job without being able to decode the advertisements it receives.

One possibility for a mixer is to "pass through" a merge of all the 
advertisements it receives to all the other participants - effectively 
treating them as blobs that are combined together. *In principle* it 
might be possible for the mixer to do this without being able to read 
the substance of those advertisements.

But that would certainly require some major redesign of the CLUE 
mechanisms. And even then it wouldn't work for more common usages such 
as where the mixer is making the decisions about switching sources based 
on voice activity.

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Apr 2015 11:28:36 -0700

I'm still trying to wrap my head around this problem, but in a general case,
it may not be possible for PERC to support every possible advanced
conferencing
feature and that's OK. Security without any compromises is rare.

And since I haven't said this already: I'm in favor of this effort.

-Ekr

On Thu, Apr 16, 2015 at 11:23 AM, Paul Kyzivat <[email-masked]>
wrote:

> usage, they (and the RTP media) are sent to the mixer. Then the mixer can
> consolidate the advertisements it has received, and the corresponding
> media, in any manner it wants. The consolidated advertisements are sent out
> to the participants.
>
> which media it wants to receive, which will affect what media it can offer.
> Superficially it is hard to conceive of how a mixer could do its job
> without being able to decode the advertisements it receives.
>
> treating them as blobs that are combined together. *In principle* it might
> be possible for the mixer to do this without being able to read the
> substance of those advertisements.
>
> mechanisms. And even then it wouldn't work for more common usages such as
> where the mixer is making the decisions about switching sources based on
> voice activity.
>
>         Thanks,
>         Paul
>
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 16 Apr 2015 13:29:38 -0500

On 4/16/15 13:23, Paul Kyzivat wrote:
> The advertisements are send over a data channel.

Is this like a "data channel" in the same sense that WebRTC uses that 
term? If so, I think there are some good ways to handle this in line 
with PERC's goals (there are reasonable ways to ensure that the data 
channels terminate at the trusted key management node rather than the 
mixer).

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Apr 2015 14:59:40 -0400

On 4/16/15 2:29 PM, Adam Roach wrote:
> term?

Yes. Chosen in order to facilitate the possibility of WebRTC clients for 
CLUE.

> If so, I think there are some good ways to handle this in line

I fear we are talking past one another.

Conceivably it would be possible to separate the signaling logic of clue 
from the media mixing logic, so that there could be a *trusted* entity 
that manages the keys and also does the mixing of clue advertisements, 
but that offloads the actual media "mixing" (switching in this case) to 
an untrusted media box.

But it will require some careful thought, and probably changes to clue.

I guess that would be a CLUEv2, and we shouldn't get too hung up on it 
right now.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Apr 2015 15:00:30 -0400

> feature and that's OK. Security without any compromises is rare.

I agree.

	Thanks,
	Paul

> On Thu, Apr 16, 2015 at 11:23 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>                         systems out of scope? (Not saying I see any that
>                         need to be
>                         created, but
>     usage, they (and the RTP media) are sent to the mixer. Then the
>     mixer can consolidate the advertisements it has received, and the
>     The mixer needs to respond to the advertisements. Doing so it
>     indicates which media it wants to receive, which will affect what
>     media it can offer. Superficially it is hard to conceive of how a
>     mixer could do its job without being able to decode the
>     advertisements it receives.
>
>     advertisements it receives to all the other participants -
>     effectively treating them as blobs that are combined together. *In
>     principle* it might be possible for the mixer to do this without
>     being able to read the substance of those advertisements.
>
>     mechanisms. And even then it wouldn't work for more common usages
>     such as where the mixer is making the decisions about switching
>     sources based on voice activity.
>
>              Thanks,
>              Paul
>
>
>     _________________________________________________
>     dispatch mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/dispatch
>     <https://www.ietf.org/mailman/listinfo/dispatch>
>
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 17 Apr 2015 11:05:51 +1000

Hello Paul and Adam,

On 17/04/2015 4:59 AM, Paul Kyzivat wrote:
> Yes. Chosen in order to facilitate the possibility of WebRTC clients 
> for CLUE.
>
[CNG] The CLUE datachannel currently is terminated at the mixer. It 
needs to have access to the Advertisements in order for it to formulate 
the Advertisements that sent to other CLUE enabled endpoints.
> Conceivably it would be possible to separate the signaling logic of 
> clue from the media mixing logic, so that there could be a *trusted* 
> entity that manages the keys and also does the mixing of clue 
> advertisements, but that offloads the actual media "mixing" (switching 
> in this case) to an untrusted media box.

> But it will require some careful thought, and probably changes to clue.
[CNG] It depends on your ambition level. CLUE v1 can still be used 
albeit in a simpler form. E.g. An endpoint using PERC probably shouldn't 
send XCARD information information about the participants. Basically it 
shouldn't send any metadata it doesn't want a mixer to access. There's 
still quite a few attributes that would be useful for capture selection 
and rendering that I couldn't see a problem with a mixer having access to.
If you want to pass XCARD information etc. securely through a mixer to a 
remote CLUE endpoint via CLUE then that's going to need work in CLUE.
> I guess that would be a CLUEv2, and we shouldn't get too hung up on it 
[CNG] I do think its still worthwhile discussing as part of the 
architecture how mixing is controlled in a PERC architecture. I think 
its important we're on the same page. CLUE may have a role here.

BTW I do support this work.

Regards, Christian