Subject: [siprec] SIPREC privacy considerations

From: "Elwell, John" <[email-masked]>
Date: Fri, 5 Nov 2010 13:01:20 +0100

I have already pointed out the need for addressing privacy in the Requirements document.

I think we can address this to some extent, or possibly entirely, by including suitable statements in the Security Considerations section. This may or may not lead to the need for one or more additional requirements concerning privacy - my initial impression is that we probably don't need additional requirements.

Here is a straw man proposal for some Security Considerations text.

"Respecting the privacy rights and wishes of users engaged in CSs is of paramount importance. In many jurisdictions participants have a right to know that the session is being recorded or might be recorded, and have a right to opt out, either by terminating the CS or by demanding that the CS not be recorded. Therefore this document contains requirements for being able to notify users that a CS is being recorded and for users to be able to request that a CS not be recorded.

In a given deployment, not all users will be authorized to stop the recording of a CS (although any user can terminate a CS). Typically users within the domain that is carrying out the recording will be subject to policies of that domain concerning whether CSs are recorded. For example, in a call centre, agents will be subject to policies of the call centre and may or may not have the right to prevent the recording of a CS or part of a CS. Users calling into the call centre, on the other hand, will typically have to ask the agent not to record the CS. If the agent is unable to prevent recording, or if caller does not trust the agent, the only option generally is to terminate the CS.

Privacy considerations also extend to what happens to a recording once it has been created. Typical issues are who can access the recording (e.g., receive a copy of the recording, view the metadata, play back the media, etc.), for what purpose can the recording be used (e.g., for non-repudiation, for training purposes, for quality control purposes, etc.) and for how long the recording is to be retained before deletion. These are typically policies of the domain that makes the recording, rather than policies of individual users involved in a recorded CS, whether those users be in the same domain or in a different domain. Taking the call centre example again, agents might be made aware of call centre policy regarding retention and use of recordings as part of their employment contract, and callers from outside the call centre might be given some information about policy when notified that a CS will be recorded (e.g., through an announcement that says that calls may be recorded for quality purposes).

This document does not specify any requirements for a user engaged in a CS to be able to dictate policy for what happens to a recording, or for such information to be conveyed from an SRC to an SRS, since typical deployments would not need this. Instead, it is assumed that the SRS has access to policy applicable to its environment and can ensure that recordings are stored and used appropriately."

John (as individual)

---

From: Leon Portman <[email-masked]>
Date: Sun, 7 Nov 2010 12:53:48 +0800

I think it is very good. May be we should also mention that CS participant also will not define retention period of the recording. It also usually part of the external recording policy

Leon

On Nov 5, 2010, at 8:01 PM, "Elwell, John" <[email-masked]> wrote:

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

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 8 Nov 2010 13:53:40 +0800

I have not followed every thread on this list closely, so apologies if  
some of the points I make below have already been clarified.

One general comment: I think both the architecture document and the  
requirements document could be a little more clear on the scope of the  
use cases. My understanding is that siprec is only to be used when all  
call participants have been informed that the session is being  
recorded. This is a different/smaller set of uses than just putting  
lawful intercept out of scope, as the architecture document does (the  
requirements document seems to cite the IETF wiretapping policy, RFC  
2804, but I couldn't find it referenced in the text). It probably  
makes sense to declare that scoping restriction up front in the  
introduction in one or both documents.

Other comments inline...

On Nov 5, 2010, at 8:01 PM, Elwell, John wrote:

> I think we can address this to some extent, or possibly entirely, by  
> including suitable statements in the Security Considerations  
> section. This may or may not lead to the need for one or more  
> additional requirements concerning privacy - my initial impression  
> is that we probably don't need additional requirements.

In addition to indication of session recording (REQ-024), a potential  
additional requirement to consider is indication of the purpose of the  
recording. This is already often provided for call center calls (i.e.,  
"this call is being recorded for training purposes"), and it's  
generally a good privacy practice to inform people about why  
information is being collected about them. So a requirement like "The  
mechanism MUST provide a means of indicating to the participants  
involved in a CS the purpose for which their session is being recorded."

> "Respecting the privacy rights and wishes of users engaged in CSs is  
> of paramount importance.

Is there a difference between users and participants? Or should the  
same term be used throughout this section?

> In many jurisdictions participants have a right to know that the  
> session is being recorded or might be recorded, and have a right to  
> opt out, either by terminating the CS or by demanding that the CS  
> not be recorded. Therefore this document contains requirements for  
> being able to notify users that a CS is being recorded and for users  
> to be able to request that a CS not be recorded.
>
> In a given deployment, not all users will be authorized to stop the  
> recording of a CS (although any user can terminate a CS).

If this is true, it's possibly in conflict with REQ-022 and  
REQ-022bis. Those requirements require support for canceling and  
discarding a recording, although they don't specify who  is able to  
cancel and discard (this was briefly mentioned on the list before: http://www.ietf.org/mail-archive/web/siprec/current/msg00719.html) 
. I think this needs to be clarified and this security considerations  
text needs to be consistent with whatever the reality is. If only the  
domain that initiated or is storing the recording is able to discard  
the recording, that needs to be made clear. Obviously it's better for  
privacy if any participant can cancel and request that the recording  
be discarded, but the text above makes it sound like at best that sort  
of requirement could only be a SHOULD (right now -022 and -022bis are  
MUSTs).

> Typically users within the domain that is carrying out the recording  
> will be subject to policies of that domain concerning whether CSs  
> are recorded. For example, in a call centre, agents will be subject  
> to policies of the call centre and may or may not have the right to  
> prevent the recording of a CS or part of a CS. Users calling into  
> the call centre, on the other hand, will typically have to ask the  
> agent not to record the CS. If the agent is unable to prevent  
> recording, or if caller does not trust the agent, the only option  
> generally is to terminate the CS.
>
> Privacy considerations also extend to what happens to a recording  
> once it has been created. Typical issues are who can access the  
> recording (e.g., receive a copy of the recording, view the metadata,  
> play back the media, etc.), for what purpose can the recording be  
> used (e.g., for non-repudiation, for training purposes, for quality  
> control purposes, etc.) and for how long the recording is to be  
> retained before deletion. These are typically policies of the domain  
> that makes the recording, rather than policies of individual users  
> involved in a recorded CS, whether those users be in the same domain  
> or in a different domain. Taking the call centre example again,  
> agents might be made aware of call centre policy regarding retention  
> and use of recordings as part of their employment contract, and  
> callers from outside the call centre might be given some information  
> about policy when notified that a CS will be recorded (e.g., through  
> an announcement that says that calls may be recorded
> for quality purposes).
>
> This document does not specify any requirements for a user engaged  
> in a CS to be able to dictate policy for what happens to a  
> recording, or for such information to be conveyed from an SRC to an  
> SRS, since typical deployments would not need this.

I don't think it's the case that "typical deployments would not need  
this," but rather that in the use cases that siprec is designed for,  
the parties doing the recording don't pay any mind to the call  
participants' preferences about what happens to their recordings. I'm  
sure some participants would like to be able to specify what their  
recordings get used for, who has access to them, etc.

If the requirement that I proposed above about specifying the purpose  
for the recording gets added, that would provide a hook for one  
requirement related to what happens to stored recordings: that they  
only be used for the purpose that was indicated to the participants.  
This is obviously not technically enforceable, but also wouldn't be  
bad to have as a suggestion to the domains doing the recording.

> Instead, it is assumed that the SRS has access to policy applicable  
> to its environment and can ensure that recordings are stored and  
> used appropriately."

Again this seems to assume that the domain policy is consistent with  
participants' preferences. I don't think this is always true.

Alissa

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 8 Nov 2010 16:17:53 +0100

Alissa,

Thanks very much for your comments. I welcome the expert input on this subject. Below are my responses (as individual). 

> -----Original Message-----
> From: Alissa Cooper [mailto:[email-masked]] 
> Sent: 08 November 2010 05:54
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [siprec] SIPREC privacy considerations
> 
> recorded. 
[JRE] I am not sure this is quite the case. We have in the requirements document:
"REQ-024 The mechanism MUST provide a means of indicating to the
   participants involved in a CS that their session is being recorded."
So although we must define a mechanism, and although we might make such a mechanism mandatory to implement, this does not necessarily mean it will be mandatory to deploy. That is a choice left for the solution RFC - I think we would need stronger language in the requirements document to prevent that. Although I imagine some jurisdictions would make it mandatory to deploy, this would not apply in all jurisdictions.

> This is a different/smaller set of uses than just putting  
[JRE] I agree it would make sense to declare this important aspect of scope up front in both documents, but we need first to be clear in the WG what that scope is.

> involved in a CS the purpose for which their session is being 
[JRE] This seems to be worth considering, but how easy would it standardize a finite set of purposes? Of course, relying on an in-band announcement or video to convey the purpose is open-ended - it is left to the particular deployment what to provide. And for PSTN callers an in-band announcement will be the only possibility. This requires no standardization work. On the other hand, if we were to give an indication by signalling to SIP endpoints, for this to be useful we would need to standardize the values. Perhaps it is just a matter of establishing a registry and defining a small number of initial values, plus the mechanism for adding new values.

> same term be used throughout this section?
[JRE] No difference, will align.

> cancel and discard (this was briefly mentioned on the list 
> before: 
> http://www.ietf.org/mail-archive/web/siprec/current/msg00719.html) 
[JRE] It is certainly infeasible for PSTN callers/callees to make such requests (the only option open is to clear the call or ask the other participant to cancel recording). This probably would be the practical situation too in all-SIP scenarios where a party is in a different domain from the domain that is recording the session. For example, if a call centre has the policy of recording all calls (having notified the caller), it would typically not give the caller the opportunity to cancel recording. That is what REQ-023 means by "authorized participant", and perhaps that term needs to be used in REQ-022 and REQ-022bis too.

> recordings get used for, who has access to them, etc.
[JRE] So you would omit the words "since typical deployments would not need this"? Would you add something in its place, and if so what? Or are you suggesting that we do indeed need requirements concerning a user's ability to influence policy for a recording, or for an SRC to do this?

> bad to have as a suggestion to the domains doing the recording.
[JRE] So this would be a step in the direction of the user influencing policy. Would this be sufficient, or do you see a need for more?

> participants' preferences. I don't think this is always true.
[JRE] Perhaps not ALWAYS true, but in practical situations the user doesn't have much say, e.g., a call centre agent is typically bound to terms of employment, and a caller into a call centre is bound by as a condition for doing business over the phone. Similarly for a number of other common deployment scenarios. Cases where the user is allowed to have influence would appear to be a lot less common, and perhaps unnecessary for the initial SIPREC deliverable. So I would be happy to limit scope initially, rather than get involved in complex mechanisms supporting privacy options that might rarely be used.

John

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Tue, 9 Nov 2010 00:56:49 -0800

Excellent summary John, we should include most of this in the -05 draft. However the section on retention policy seems out of scope for SIPREC.

Ken

From: [email-masked] [mailto:[email-masked]] On Behalf Of Leon Portman
Sent: Saturday, November 06, 2010 9:54 PM
To: Elwell, John
Cc: [email-masked]
Subject: Re: [siprec] SIPREC privacy considerations

Leon

	

	
	
	Privacy considerations also extend to what happens to a recording once it has been created. Typical issues are who can access the recording (e.g., receive a copy of the recording, view the metadata, play back the media, etc.), for what purpose can the recording be used (e.g., for non-repudiation, for training purposes, for quality control purposes, etc.) and for how long the recording is to be retained before deletion. These are typically policies of the domain that makes the recording, rather than policies of individual users involved in a recorded CS, whether those users be in the same domain or in a different domain. Taking the call centre example again, agents might be made aware of call centre policy regarding retention and use of recordings as part of their employment contract, and callers from outside the call centre might be given some information about policy when notified that a CS will be recorded (e.g., through an announcement that says that calls may be recorded 
	for quality purposes).

	John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 9 Nov 2010 15:34:24 +0100

Ken,

You will have seen Alissa's comments and my response to those, and I see we have some coverage of these issues in the slides you just posted. If we adopt text along the lines I proposed, I think the main additional impact will be the need to make sure the scope is clear in the Intro section (and also reflected in the Intro section of the Architecture document), plus the fix mentioned to REQ-022 and REQ-022bis, and the issue of whether there should be any requirements regarding purpose of recording.

John (as individual)

> From: Ken Rehor (krehor) [mailto:[email-masked]] 
> Sent: 09 November 2010 08:57
> To: Leon Portman; Elwell, John
> Cc: [email-masked]
> Subject: RE: [siprec] SIPREC privacy considerations
> 
> Excellent summary John, we should include most of this in the 
> -05 draft. However the section on retention policy seems out 
> of scope for SIPREC.
> 
>  
> 
> Ken
> 
>  
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Leon Portman
> I think it is very good. May be we should also mention that 
> CS participant also will not define retention period of the 
> recording. It also usually part of the external recording policy
> 
>  
> 
> Leon
> 
>  
> 
> 
> On Nov 5, 2010, at 8:01 PM, "Elwell, John" 
> <[email-masked]> wrote:
> 
> 	I think we can address this to some extent, or possibly 
> entirely, by including suitable statements in the Security 
> Considerations section. This may or may not lead to the need 
> for one or more additional requirements concerning privacy - 
> my initial impression is that we probably don't need 
> additional requirements.
> 	
> 	"Respecting the privacy rights and wishes of users 
> engaged in CSs is of paramount importance. In many 
> jurisdictions participants have a right to know that the 
> session is being recorded or might be recorded, and have a 
> right to opt out, either by terminating the CS or by 
> demanding that the CS not be recorded. Therefore this 
> document contains requirements for being able to notify users 
> that a CS is being recorded and for users to be able to 
> request that a CS not be recorded.
> 	
> 	In a given deployment, not all users will be authorized 
> to stop the recording of a CS (although any user can 
> terminate a CS). Typically users within the domain that is 
> carrying out the recording will be subject to policies of 
> that domain concerning whether CSs are recorded. For example, 
> in a call centre, agents will be subject to policies of the 
> call centre and may or may not have the right to prevent the 
> recording of a CS or part of a CS. Users calling into the 
> call centre, on the other hand, will typically have to ask 
> the agent not to record the CS. If the agent is unable to 
> prevent recording, or if caller does not trust the agent, the 
> only option generally is to terminate the CS.
> 	
> 	Privacy considerations also extend to what happens to a 
> recording once it has been created. Typical issues are who 
> can access the recording (e.g., receive a copy of the 
> recording, view the metadata, play back the media, etc.), for 
> what purpose can the recording be used (e.g., for 
> non-repudiation, for training purposes, for quality control 
> purposes, etc.) and for how long the recording is to be 
> retained before deletion. These are typically policies of the 
> domain that makes the recording, rather than policies of 
> individual users involved in a recorded CS, whether those 
> users be in the same domain or in a different domain. Taking 
> the call centre example again, agents might be made aware of 
> call centre policy regarding retention and use of recordings 
> as part of their employment contract, and callers from 
> outside the call centre might be given some information about 
> policy when notified that a CS will be recorded (e.g., 
> through an announcement that says that calls may be recorded 
> 	for quality purposes).
> 	
> 	This document does not specify any requirements for a 
> user engaged in a CS to be able to dictate policy for what 
> happens to a recording, or for such information to be 
> conveyed from an SRC to an SRS, since typical deployments 
> would not need this. Instead, it is assumed that the SRS has 
> access to policy applicable to its environment and can ensure 
> that recordings are stored and used appropriately."
> 	
> 	John (as individual)