Subject: [dispatch] Updated PERC Charter proposal

From: Mary Barnes <[email-masked]>
Date: Fri, 22 May 2015 10:52:02 -0500

Hi all,

Below, please find an updated charter for PERC.  Magnus has updated the
charter to incorporate feedback from the DISPATCH WG mailing list
discussions and we've made a round of editorial changes.  It should be
ready for Ben to submit to the IESG for consideration as a new WG.  So,
please review and provide any final comments no later than 18:00 GMT on
Monday, May 25th (and yeah, I know it's a US holiday but folks in the US
have the rest of today to review and there really should be no surprises;)

Regards,
Mary
DISPATCH WG co-chair

=========================================================================

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 in
widespread use today. Many of the deployments use one or more centrally
located media distribution devices that perform selective forwarding of
mixed-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
metadata of the conference is kept private and only available to the set of
invited participants and other devices trusted by those participants with
their media.  At the same time, multi-party media conferences need source
authentication and integrity checks to protect against modifications,
insertions, and replay attacks.  Media distribution devices supporting
these conferences may also perform RTP header changes, and they often
consume and create RTCP messages for efficient media handling.

To date, deployment models for these multi-party media distribution devices
do not enable the devices to perform their functions without having keys to
decrypt the participants’ media, primarily using Secure RTP (RFC3711) to
provide session security.

This trust model has limitations and prevents or hampers deployment of
secure RTP conferencing in a multitude of cases, including outsourcing,
legal requirements on confidentiality, and utilization of virtualized
servers. Thus, a new architectural model and related specifications are
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 participants’ 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 provides
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 RTP header extensions.

The solution should be implementable by both SIP (RFC3261) and WebRTC (
draft-ietf-rtcweb-overview
<https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/>) endpoints.
How telepresence endpoints using the protocols defined in the CLUE working
group could utilize the defined security solution needs to be considered.
However, it is acknowledged that limitations may exist, resulting in
restricted functionality or need for additional adaptations of the CLUE
protocols.

This working group 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.  Document models considered for integrating the solution with WebRTC,
SIP and CLUE establishment of conferencing sessions.

4.    Specify any necessary extensions to SRTP.

5.   Define needed Key Management Functions that distribute 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 items that might require work in other WGs are DTLS extensions
(TLS WG) and RTP header extensions (AVTEXT WG). This work requires strong
collaboration with the security area. We will notify AVTCore, CLUE, MMUSIC,
RTCWEB, SIPREC, W3C WebRTC, and other related groups about this work.

Non-Goals

The PERC working group 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, and
document such consideration for WebRTC, SIP, and CLUE. The specification of
how a particular system integrates the security solution will happen
outside of this working group, in suitable venues.

The WG will not consider non-real-time usage, multicast-based media
distribution, or Security descriptions-based keying (RFC4568).

Goals and Milestones

TBD  Submit architecture or framework specification to IESG (Standards
Track)

TBD Submit documentation of how to integrate solution in SIP, WebRTC and
CLUE to IESG (Informational)

TBD  Submit SRTP protocol extension specification to IESG (Standards Track)

TBD  Submit Key-management protocol specification to IESG (Standards Track)

Input to the WG

Proposals already existing relating to this charter proposal:

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/

---

From: Adam Roach <[email-masked]>
Date: Fri, 22 May 2015 11:16:09 -0500

On 5/22/15 10:52, Mary Barnes wrote:
> Monday, May 25th (and yeah, I know it's a US holiday but folks in the 
> US have the rest of today to review and there really should be no 
> surprises;)

FWIW, it's also a holiday in many European countries (cf. 
<http://en.wikipedia.org/wiki/Whit_Monday#Observance>).

/a

---

From: "Roni Even" <[email-masked]>
Date: Sat, 23 May 2015 10:27:41 +0300

Hi,

The charter looks good to me,

One comment about the milestone, the first milestone is for architecture while the first bullet in the work to be done also mentions the RTP topologies, so I assume that the first milestone also includes new RTP topologies or will the RTP topologies to be used will only be topologies from draft-ietf-avtcore-rtp-topologies-update-07 <https://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-07>  ?

Roni Even

From: dispatch [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: 22 May, 2015 6:52 PM
To: DISPATCH
Cc: Barry Leiba; Ben Campbell
Subject: [dispatch] Updated PERC Charter proposal

Hi all,

Below, please find an updated charter for PERC.  Magnus has updated the charter to incorporate feedback from the DISPATCH WG mailing list discussions and we've made a round of editorial changes.  It should be ready for Ben to submit to the IESG for consideration as a new WG.  So, please review and provide any final comments no later than 18:00 GMT on Monday, May 25th (and yeah, I know it's a US holiday but folks in the US have the rest of today to review and there really should be no surprises;) 

Regards,

Mary

DISPATCH WG co-chair

 

Area: ART

Chairs: TBD

Mailing List: <using  <mailto:[email-masked]> [email-masked] for now> 

Motivation for new WG

RTP-based real-time multi-party interactive media conferencing is in widespread use today. Many of the deployments use one or more centrally located media distribution devices that perform selective forwarding of mixed-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 metadata of the conference is kept private and only available to the set of invited participants and other devices trusted by those participants with their media.  At the same time, multi-party media conferences need source authentication and integrity checks to protect against modifications, insertions, and replay attacks.  Media distribution devices supporting these conferences may also perform RTP header changes, and they often consume and create RTCP messages for efficient media handling.

To date, deployment models for these multi-party media distribution devices do not enable the devices to perform their functions without having keys to decrypt the participants’ media, primarily using Secure RTP (RFC3711) to provide session security. 

This trust model has limitations and prevents or hampers deployment of secure RTP conferencing in a multitude of cases, including outsourcing, legal requirements on confidentiality, and utilization of virtualized servers. Thus, a new architectural model and related specifications are 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 participants’ 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 provides 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 RTP header extensions.

The solution should be implementable by both SIP (RFC3261) and WebRTC ( <https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/> draft-ietf-rtcweb-overview) endpoints. How telepresence endpoints using the protocols defined in the CLUE working group could utilize the defined security solution needs to be considered. However, it is acknowledged that limitations may exist, resulting in restricted functionality or need for additional adaptations of the CLUE protocols. 

1.    Define a general architecture and RTP topology(s) that enables end-to-end media security for multi-party RTP conferencing.

3.  Document models considered for integrating the solution with WebRTC, SIP and CLUE establishment of conferencing sessions.

5.   Define needed Key Management Functions that distribute 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 items that might require work in other WGs are DTLS extensions (TLS WG) and RTP header extensions (AVTEXT WG). This work requires strong collaboration with the security area. We will notify AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and other related groups about this work. 

Non-Goals

The PERC working group 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, and document such consideration for WebRTC, SIP, and CLUE. The specification of how a particular system integrates the security solution will happen outside of this working group, in suitable venues. 

The WG will not consider non-real-time usage, multicast-based media distribution, or Security descriptions-based keying (RFC4568).

Goals and Milestones

TBD  Submit architecture or framework specification to IESG (Standards Track)

TBD Submit documentation of how to integrate solution in SIP, WebRTC and CLUE to IESG (Informational)

Input to the WG

 <https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/> 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-jones-avtcore-private-media-framework/
 <https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/> https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/

---

From: Mary Barnes <[email-masked]>
Date: Sat, 23 May 2015 11:09:49 -0500

Hi Roni,

My understanding of the charter is that the first milestone will encompass
deliverables 1. and 2, thus new RTP topologies that may be required would
be considered as part of that milestone.

Regards,
Mary.

On Sat, May 23, 2015 at 2:27 AM, Roni Even <[email-masked]> wrote:

> One comment about the milestone, the first milestone is for architecture
> while the first bullet in the work to be done also mentions the RTP
> topologies, so I assume that the first milestone also includes new RTP
> topologies or will the RTP topologies to be used will only be topologies
> from draft-ietf-avtcore-rtp-topologies-update-07
> <https://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-07>
> ?
>
>
>
> Roni Even
>
>
>
> *From:* dispatch [mailto:[email-masked]] *On Behalf Of *Mary
> Barnes
> *Sent:* 22 May, 2015 6:52 PM
> *To:* DISPATCH
> *Cc:* Barry Leiba; Ben Campbell
> *Subject:* [dispatch] Updated PERC Charter proposal
>
>
>
> Hi all,
>
>
>
> These conferences require security to ensure that the RTP media and
> related metadata of the conference is kept private and only available to
> the set of invited participants and other devices trusted by those
> participants with their media.  At the same time, multi-party media
> conferences need source authentication and integrity checks to protect
> against modifications, insertions, and replay attacks.  Media distribution
> devices supporting these conferences may also perform RTP header changes,
> and they often consume and create RTCP messages for efficient media
> handling.
>
>
>
> To date, deployment models for these multi-party media distribution
> devices do not enable the devices to perform their functions without having
> keys to decrypt the participants’ media, primarily using Secure RTP
> (RFC3711) to provide session security.
>
> <https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/>)
> endpoints. How telepresence endpoints using the protocols defined in the
> CLUE working group could utilize the defined security solution needs to be
> considered. However, it is acknowledged that limitations may exist,
> resulting in restricted functionality or need for additional adaptations of
> the CLUE protocols.
>
>
>
> The PERC working group 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, and document such consideration for WebRTC, SIP, and CLUE. The
> specification of how a particular system integrates the security solution
> will happen outside of this working group, in suitable venues.
>
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 May 2015 09:24:53 +0200

Mary Barnes skrev den 2015-05-23 18:09:
> Hi Roni,
>
> My understanding of the charter is that the first milestone will
> encompass deliverables 1. and 2, thus new RTP topologies that may be
> required would be considered as part of that milestone.

 From my perspective, the intention here is to ensure that the 
architecture makes clear which RTP topologies that are considered and 
supported for the solution. This includes both existing ones, as well as 
new ones if there are a need.

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: Magnus Westerlund <[email-masked]>
Date: Mon, 25 May 2015 14:58:48 +0200

Hi,

I have some additional proposed tweaks to the charter text:

OLD:
The solution should be implementable by both SIP (RFC3261) and WebRTC 
(draft-ietf-rtcweb-overview) endpoints.

NEW:
The solution should be implementable by both SIP (RFC3261) and WebRTC 
endpoints (draft-ietf-rtcweb-overview).

Comment:
I think we should actually refer to the definition of WebRTC endpoints 
that are in the overview document, thus the move of the reference.

OLD:
5.   Define needed Key Management Functions that distribute 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.

NEW:
5.   Define needed Key Management Functions that distribute the keys.
      The system needs to be able to bind the media to the identity of
      the sender of the media and/or the identity of the conference.

Comment: Suggest that we are explicit that we are binding the media to 
an asserted identity for a particular media stream sender.

Cheers

Magnus Westerlund

---

From: Göran Eriksson AP <[email-masked]>
Date: Mon, 25 May 2015 15:10:50 +0000

Hi,

I have some minor comments concerning the meaning of ³SIP² and ³WebRTC²
endpoints.

Sorry for the late response and for top-posting but it became a bit messy
to add inline:

1. The link to 
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ did not work?
2. The text uses ³SIP² and ³WebRTC² to describe the different kind of
end-points that are in scope.
   W3C WebRTC WG recognises the fact that the WebRTC end points can be
browser end points 
   (browser + web (client portion of) web app) or native WebRTC (or rather
rtcweb) clients and both are in scope for the W3C WG.
   The browser endpoint trust model is different from that of native
clients and it is also evolving.
   I think that clarity in how different endpoints trust model and
security framework look like and different is beneficial for several of
the deliverables, notably 2,3 and 5.

3. The charter says it will ³notify² W3C WebRTC about this activity; what
do the WG expect to get back and why not Œcoordinate¹? And are there other
W3C WG¹s that are relevant?

Again, sorry for not being able to give this feedback previously. If all
of the above is clear to anyone except me, then I do apologise for having
missed that. 
In any case, I personally see these comments as minor and about
clarifications, neither which should prevent the charter from being
submitted to IESG.

Best Regards
Göran

-----Original Message-----
From: Mary Barnes <[email-masked]>
Date: Friday 22 May 2015 17:52
To: Dispatch <[email-masked]>
Cc: Barry Leiba <[email-masked]>, Ben Campbell <[email-masked]>
Subject: [dispatch] Updated PERC Charter proposal

>ready for Ben to submit to the IESG for
> consideration as a new WG.  So, please review and provide any final
>comments no later than 18:00 GMT on Monday, May 25th (and yeah, I know
>it's a US holiday but folks in the US have the rest of today to review
>and there really should be no surprises;)
>
>
>Regards,
>Mary
>DISPATCH WG co-chair
>
>
>
>
>Mailing List: <using
>[email-masked]
> for now> 
>RTP-based real-time multi-party interactive media
> conferencing is in widespread use today. Many of the deployments use one
>or more centrally located media distribution devices that perform
>selective forwarding of mixed-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
>metadata of the conference is kept private and only available to the set
>of invited participants and other devices trusted by those participants
>with their media.  At the same time, multi-party
> media conferences need source authentication and integrity checks to
>protect against modifications, insertions, and replay attacks.  Media
>distribution devices supporting these conferences may also perform RTP
>header changes, and they often consume and create
> RTCP messages for efficient media handling.
>
>
>To date, deployment models for these multi-party
> media distribution devices do not enable the devices to perform their
>functions without having keys to decrypt the participants¹ media,
>primarily using Secure RTP (RFC3711) to provide session security.
>
>
>This trust model has limitations and prevents or
> hampers deployment of secure RTP conferencing in a multitude of cases,
>including outsourcing, legal requirements on confidentiality, and
>utilization of virtualized servers. Thus, a new architectural model and
>related specifications are 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 participants¹
>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 provides 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 RTP header extensions.
>
>The solution should be implementable by both SIP
> (RFC3261) and WebRTC (draft-ietf-rtcweb-overview
>CLUE working group could utilize the defined security solution needs to
>be considered. However, it is acknowledged that limitations may exist,
>resulting in restricted functionality or
> need for additional adaptations of the CLUE protocols.
>
>1.
>    Define a general architecture and RTP topology(s) that enables
>2.
>    Define the trust model and describe the resulting security properties.
>4.
>    Specify any necessary extensions to SRTP.
>5.
>   Define needed Key Management Functions that distribute 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 items that might require work in other
>WGs are DTLS extensions (TLS WG) and RTP
> header extensions (AVTEXT WG). This work requires strong collaboration
>with the security area. We will notify AVTCore, CLUE, MMUSIC, RTCWEB,
>SIPREC, W3C WebRTC, and other related groups about this work.
>
>
>Non-Goals
>
>The PERC working group 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, and document such consideration for WebRTC,
>SIP, and CLUE. The specification of how
> a particular system integrates the security solution will happen outside
>of this working group, in suitable venues.
>
>
>The WG will not consider non-real-time usage, multicast-based
> media distribution, or Security descriptions-based keying (RFC4568).
>
>Goals and Milestones
> 
>TBD Submit documentation of how to integrate solution
> in SIP, WebRTC and CLUE to IESG (Informational)
>
><https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/
><https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framew
>ork/>https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/
>
> <https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/>
>
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 May 2015 11:32:32 +0200

Hi,

I hope others can comment on this also.

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ did not work?

It works fine for me.

> the deliverables, notably 2,3 and 5.

The use of WebRTC endpoints where deliberate by my and intended to cover 
not only browsers but anything meeting the WebRTC endpoint definition. 
So the question, does this need to be made more explicit in the charter?

> W3C WG¹s that are relevant?

I think the expectation is that in the end W3C and likely RTCWEB WG 
agrees to integrate the PERC solution into their specifications so that 
one can actually use it with WebRTC. In intermediate step I think it 
will be a question of notifying for example when there exist a proposed 
blue-print for integration. This may be an example of where coordinate 
might be needed.

I could see that we could change the last sentence in the collaboration 
part from:
"We will notify AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and 
other related groups about this work."

to
"We will notify, and when needed coordinate with, AVTCore, CLUE, MMUSIC, 
RTCWEB, SIPREC, W3C WebRTC, and other related groups about this work."

Opinions?

Cheers

Magnus Westerlund

---

From: Mary Barnes <[email-masked]>
Date: Fri, 29 May 2015 09:53:50 -0500

On Fri, May 29, 2015 at 4:32 AM, Magnus Westerlund <
[email-masked]> wrote:

> not only browsers but anything meeting the WebRTC endpoint definition. So
> the question, does this need to be made more explicit in the charter?

[MB] I think this is fine as is in the charter - certainly it needs to be
clear in the deliverables but that's a detail we can deal with there. [/MB]

> I think the expectation is that in the end W3C and likely RTCWEB WG agrees
> to integrate the PERC solution into their specifications so that one can
> actually use it with WebRTC. In intermediate step I think it will be a
> question of notifying for example when there exist a proposed blue-print
> for integration. This may be an example of where coordinate might be needed.
>
> [MB] I think the suggested change is fine. [/MB]