Subject: Re: [dispatch] Updated PERC Charter proposal

From: Magnus Westerlund <[email-masked]>
Date: Mon, 1 Jun 2015 11:47:48 +0200

Hi,

I have edited the proposed change into the Google Doc. Any more feedback 
on this?

Cheers

Magnus

Mary Barnes skrev den 2015-05-29 16:53:
>
>
> On Fri, May 29, 2015 at 4:32 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,
>
>     I hope others can comment on this also.
>
>     Göran Eriksson AP skrev den 2015-05-25 17:10:
>
>         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?
>
>
>     It works fine for me.
>
>         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.
>
>
>     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?
>
> [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]
>
>
>
>
>         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?
>
>
>     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?
>
> [MB] I think the suggested change is fine. [/MB]
>
>
>     Cheers
>
>     Magnus Westerlund
>
>     ----------------------------------------------------------------------
>     Services, Media and Network features, Ericsson Research EAB/TXM
>     ----------------------------------------------------------------------
>     Ericsson AB                 | Phone +46 10 7148287
>     <tel:%2B46%2010%207148287>
>     Färögatan 6                 | Mobile +46 73 0949079
>     <tel:%2B46%2073%200949079>
>     SE-164 80 Stockholm, Sweden | mailto: [email-masked]
>     <mailto:[email-masked]>
>     ----------------------------------------------------------------------
>
>

-- 

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: Göran Eriksson AP <[email-masked]>
Date: Mon, 1 Jun 2015 10:06:10 +0000

>I have edited the proposed change into the Google Doc. Any more feedback

No, Mary’s statement on deliverables and You addition addresses my
concerns well enough at this pint, :-).

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 2 Jun 2015 15:56:01 +0000

The proposed charter looks good.

 One question -

As defined in SIPREC WG requirement document RFC6341 recording of
multimedia sessions is a critical requirement in many business
   communications environments, such as call centers and financial trading
floors.  Note that this is active recording where the participants
Of the session will be informed and they can choose to not being recorded.
(like SIPREC WG has defined today).

if PERC based conferencing is used in such deployments, we would then have
a requirement to record those sessions.

This would bring in a requirement to record PERC sessions. Would this be
right place to add this ?

regards,
Ram

-----Original Message-----
From: Magnus Westerlund <[email-masked]>
Date: Monday, 1 June 2015 3:17 pm
To: Mary Barnes <[email-masked]>
Cc: Ben Campbell <[email-masked]>, DISPATCH <[email-masked]>, Barry
Leiba <[email-masked]>
Subject: Re: [dispatch] Updated PERC Charter proposal

>_______________________________________________
>dispatch mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dispatch

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 2 Jun 2015 09:21:40 -0700

> right place to add this ?

I don't agree that there is a requirement to add this.

The way you record PERC sessions is by bringing them into the call at
the signaling level. There's no PERC-level accommodation needed.

-Ekr

> >> <[email-masked] <mailto:[email-masked]
> >>
> >> wrote:
> >>
> >>     Hi,
> >>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 02 Jun 2015 10:38:36 -0600

> the signaling level. There's no PERC-level accommodation needed.

Who is "them"? Do you mean "recording resources" of some kind would be 
added as participants to the call? Just trying to clarify the model...

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 2 Jun 2015 09:40:25 -0700

> added as participants to the call? Just trying to clarify the model...

Yes.

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Jun 2015 14:38:47 -0400

At some level this would "work", but it might require rethinking the 
whole approach to recording in an enterprise where recording is an 
important part of the business.

IIUC, with PERC there is still likely to be a conference focus, for 
signaling, much as without PERC. But the details of how the media is 
handled will be different. Such a focus could automatically bring in a 
recorder as a participant. That is already one of the models covered by 
siprec. But PERC would prevent the focus and the PERC 'mixer" from 
directly serving as the SRC.

	Thanks,
	Paul

As long as PERC conferences are

On 6/2/15 12:40 PM, Eric Rescorla wrote:
>
>
> On Tue, Jun 2, 2015 at 9:38 AM, Peter Saint-Andre - &yet
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Who is "them"? Do you mean "recording resources" of some kind would
>     be added as participants to the call? Just trying to clarify the
>     model...
>
>
> Yes.
>
> -Ekr
>
>
>
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 3 Jun 2015 03:10:19 +0000

Hi Paul,

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Wednesday, 3 June 2015 12:08 am
To: "[email-masked]" <[email-masked]>
Subject: Re: [dispatch] Updated PERC Charter proposal

>handled will be different

Yes. The way PERC handles media would likely bring in differences on how
recording needs to be done.
IIUC PERC also brings in a model where in the conference cloud is less
trusted and hence there needs
to be some thinking on how recording needs to be handled in general.

>. Such a focus could automatically bring in a

Yes. That¹s exactly where I am coming from as well. The conference model
where a mixer acts as SRC that SIPREC defines today will not work with
PERC. 
I am trying to see if there is an interest in looking at this problem.
Given that recording is critical in many business I believe there
is some value in looking at it.

Regards,
Ram

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 3 Jun 2015 08:42:33 +0000

I agree there is some value in exploring the recording use case it is one of the first questions everybody asks when discussing PERC.

Hope we are allowed to consider this.

Andy 

> On 3 Jun 2015, at 04:10, Ram Mohan R (rmohanr) <[email-masked]> wrote:
> 
> Hi Paul,
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jun 2015 05:37:40 -0700

On Tue, Jun 2, 2015 at 11:38 AM, Paul Kyzivat <[email-masked]> wrote:

> At some level this would "work", but it might require rethinking the whole
> approach to recording in an enterprise where recording is an important part
> of the business.
>
> siprec. But PERC would prevent the focus and the PERC 'mixer" from directly
> serving as the SRC.
>

I don't really understand the problem here. The *signaling* server needs to
bring
the recorder in, but that's intentional: the whole point of PERC is that
you have
to be a first-class participant in order to be any part of the call.

In any case, I'm not opposed to exploring whether PERC can support some kind
of (consensual) recording, but I'm definitely opposed to making it a charter
requirement that it do so.

-Ekr

        Thanks,
> https://www.ietf.org/mailman/listinfo/dispatchI do
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 3 Jun 2015 14:58:54 +0200

Hutton, Andrew skrev den 2015-06-03 10:42:
> I agree there is some value in exploring the recording use case it is
> one of the first questions everybody asks when discussing PERC.

 From my perspective there are two ways of doing recording of media 
content in PERC.

1. Invite the recorder as a full fledged authenticated session 
participant that use the normal way of getting the keys to the media as 
any other endpoint.

2. The recorder only stores the encrypted media content, thus being a 
semi-trusted entity to that are allowed to get a copy or be integrated 
into the central forwarders. At the time one wants to access the 
recorded content one will have to request the relevant keys from the 
key-management function, that will also have to have stored the relevant 
group keys for the session to enable decryption.

I would claim that the second one is the securer, and enables better 
tracking of who access recordings of a secured conference.

> Hope we are allowed to consider this.

The charter talks about informing and coordinating with SIPREC. This to 
have an exchange about the possibilities. However, it is not a work item 
of the PERC WG to specify a solution for recording. I would expect any 
technical work on solving PERC recording would need to be chartered in 
the most relevant WG. I think the ones interested in recording should be 
active in the WG work to ensure that the developed solution do support 
recording. If there are contention between the goals, then we will need 
to have a serious discussion. But, remember that we have clear goals of 
ensuring end to end security, thus compromises to the security model to 
fit recording will be unlikely to be accepted.

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jun 2015 06:02:42 -0700

I like Magnus's position here and I appreciate him stating it so clearly.

-Ekr

On Wed, Jun 3, 2015 at 5:58 AM, Magnus Westerlund <
[email-masked]> wrote:

> From my perspective there are two ways of doing recording of media content
> in PERC.
>
> 1. Invite the recorder as a full fledged authenticated session participant
> that use the normal way of getting the keys to the media as any other
> endpoint.
>
> semi-trusted entity to that are allowed to get a copy or be integrated into
> the central forwarders. At the time one wants to access the recorded
> content one will have to request the relevant keys from the key-management
> function, that will also have to have stored the relevant group keys for
> the session to enable decryption.
>
> have an exchange about the possibilities. However, it is not a work item of
> the PERC WG to specify a solution for recording. I would expect any
> technical work on solving PERC recording would need to be chartered in the
> most relevant WG. I think the ones interested in recording should be active
> in the WG work to ensure that the developed solution do support recording.
> If there are contention between the goals, then we will need to have a
> serious discussion. But, remember that we have clear goals of ensuring end
> to end security, thus compromises to the security model to fit recording
> will be unlikely to be accepted.
>
> Cheers
>
> Magnus Westerlund
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 03 Jun 2015 09:02:55 -0500

This sounds reasonable. Given Magnus's earlier proposal to add 
"...coordinate with...SIPREC...," I don't think any further changes are 
needed in the charter to accommodate recording.

/a

On 6/3/15 08:02, Eric Rescorla wrote:
> On Wed, Jun 3, 2015 at 5:58 AM, Magnus Westerlund 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     >From my perspective there are two ways of doing recording of
>     media content in PERC.
>
>     participant that use the normal way of getting the keys to the
>     media as any other endpoint.
>
>     2. The recorder only stores the encrypted media content, thus
>     being a semi-trusted entity to that are allowed to get a copy or
>     be integrated into the central forwarders. At the time one wants
>     to access the recorded content one will have to request the
>     relevant keys from the key-management function, that will also
>     have to have stored the relevant group keys for the session to
>     enable decryption.
>
>     I would claim that the second one is the securer, and enables
>     better tracking of who access recordings of a secured conference.
>
>
>     The charter talks about informing and coordinating with SIPREC.
>     This to have an exchange about the possibilities. However, it is
>     not a work item of the PERC WG to specify a solution for
>     recording. I would expect any technical work on solving PERC
>     recording would need to be chartered in the most relevant WG. I
>     think the ones interested in recording should be active in the WG
>     work to ensure that the developed solution do support recording.
>     If there are contention between the goals, then we will need to
>     have a serious discussion. But, remember that we have clear goals
>     of ensuring end to end security, thus compromises to the security
>     model to fit recording will be unlikely to be accepted.
>
>     Cheers
>
>     Magnus Westerlund
>
>     SE-164 80 Stockholm, Sweden | mailto:
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 3 Jun 2015 15:27:21 +0000

Hi Magnus,

-----Original Message-----
From: Magnus Westerlund <[email-masked]>
Date: Wednesday, 3 June 2015 6:28 pm
To: "Hutton, Andrew" <[email-masked]>, Cisco Employee
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dispatch] Updated PERC Charter proposal

>group keys for the session to enable decryption.

This is some thing similar to what I was visualising as well. The recorder
and KMS needs interactions to get access to recordings.

>the most relevant WG.

I am not too worried about where it is done as long as we are doing it.
Perhaps SIPREC may be a place given that it was already doing recording
for existing models.

>I think the ones interested in recording should be
>recording. 

Agree.

Regards,
Ram
>If there are contention between the goals, then we will need

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Jun 2015 11:57:15 -0400

> tracking of who access recordings of a secured conference.

These sound reasonable to me. IIUC, (2) could be complicated because 
each time a new participant joins or leaves there must be new keys.

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jun 2015 09:02:42 -0700

On Wed, Jun 3, 2015 at 8:57 AM, Paul Kyzivat <[email-masked]> wrote:

> These sound reasonable to me. IIUC, (2) could be complicated because each
> time a new participant joins or leaves there must be new keys.
>

Not on joins, only on leaves.

-Ekr

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 4 Jun 2015 05:39:09 +0530

I also agree to consider the requirement to see how SIPREC & PERC will 
work together as it is important for Enterprise usecases.  

> From: dispatch [mailto:[email-masked]] On Behalf Of Hutton,
> Andrew
> Sent: Wednesday, June 03, 2015 2:13 PM
> To: Ram Mohan R (rmohanr)
> Cc: [email-masked]
> >>>        The way you record PERC sessions is by bringing them into
> the
> >>>        call at

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 04 Jun 2015 15:12:25 -0500

> work together as it is important for Enterprise usecases.

(Trying to separate this out from the mechanism discussion over the last 
couple of days...)

Is the charter text about coordinating with SIPREC insufficient for this 
purpose?

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 5 Jun 2015 05:02:47 +0000

Proposed text WFM and I assume SIPREC WG would accomodate this discussions
and any deliverables around it.

Regards,
Ram

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Friday, 5 June 2015 1:42 am
To: Parthasarathi R <[email-masked]>
Cc: "Hutton, Andrew" <[email-masked]>, Cisco Employee
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dispatch] Updated PERC Charter proposal

---

From: "Roni Even" <[email-masked]>
Date: Sun, 7 Jun 2015 20:59:24 +0300

Hi,
My personal view is that if there is a requirement to record a multipoint
conference as specified in section 3.1.5 of RFC7245, you should not use a
PERC conferencing server for conferencing. 

Magnus two cases are correct but will not supply a good recording solution.

My view is that the recorded content should be managed by the conference
server (it will be the SRC as defined in SIPREC)  and not by a conference
participants, so in the first case where the recorder is a participant it
will not have a full view of the conference but will get what the PERC
server sends it as a regular participant invited by another participant
(e.g. not aware of side conference or get only part all the media streams in
the conference). The PERC server cannot define the recorder as a special
user since this will contradict the requirement that it is not trusted to
render the media.
In the second case, if the PERC server send the media to the recorder
encrypted this phase will work but why should the recorder get the keys from
the KMF if the decision to send the media to it was done by the non-trusted
PERC server.

Roni Even 

> From: dispatch [mailto:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: 03 June, 2015 3:59 PM
> To: Hutton, Andrew; Ram Mohan R (rmohanr)
> Cc: [email-masked]
content
> 1. Invite the recorder as a full fledged authenticated session participant
that
> use the normal way of getting the keys to the media as any other endpoint.
> 
semi-
> trusted entity to that are allowed to get a copy or be integrated into the
central
> forwarders. At the time one wants to access the recorded content one will
have
> to request the relevant keys from the key-management function, that will
also
> have to have stored the relevant group keys for the session to enable
> decryption.
> 
tracking of
> who access recordings of a secured conference.
> 
> >
have
> an exchange about the possibilities. However, it is not a work item of the
PERC
> WG to specify a solution for recording. I would expect any technical work
on
> solving PERC recording would need to be chartered in the most relevant WG.
I
> think the ones interested in recording should be active in the WG work to
> ensure that the developed solution do support recording. If there are
> contention between the goals, then we will need to have a serious
discussion.
> But, remember that we have clear goals of ensuring end to end security,
thus
> compromises to the security model to fit recording will be unlikely to be
> accepted.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 8 Jun 2015 10:26:24 +0200

EKR,

Eric Rescorla skrev den 2015-06-03 18:02:
>
> On Wed, Jun 3, 2015 at 8:57 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:

> Not on joins, only on leaves.

Are you certain?

This may depend on how the solution is done, but if one takes the 
proposal so far, where each participant gets a copy of the current 
session master EKT key, then gets each participants transmission key 
wrapped by EKT master. If attacker can get access to the media packet 
prior to it joins the session, then as it joins the session it can later 
decrypt the EKT packets recorded. Thus, you can potentially do the 
equivalent of listening at the door before you enter the room, but only 
after you have joined.

Cheers

Magnus Westerlund