Re: [dispatch] Updated PERC Charter proposal

["Roni Even" <[e-mail]>]

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 

> -----Original Message-----
> From: dispatch [mailto:[e-mail]] On Behalf Of Magnus
> Westerlund
> Sent: 03 June, 2015 3:59 PM
> To: Hutton, Andrew; Ram Mohan R (rmohanr)
> Cc: [e-mail]
> Subject: Re: [dispatch] Updated PERC Charter proposal
> 
> 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
> 
> ----------------------------------------------------------------------
> 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]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch