Subject: Re: [siprec] Comments on only the security part ofdraft-ietf-siprec-req-04

From: "Alissa Cooper" <[email-masked]>
Date: Mon, 22 Nov 2010 12:11:02 -0500

There is some good case law out there that holds that if a call participant is notified of a recording and chooses not to hang up, he has implicitly consented to the recording. Pages 11-13 of this memo may be of some help: http://www.cdt.org/privacy/20080708ISPtraffic.pdf. But I still think it's unwise to get hung up on the fact that some states only require one party's consent (as the memo demonstrates, a call between a one-party state and a two-party state can fall under the two-party rules). I thought we had good agreement in the meeting about the current requirement and the MUST in the eventual solution doc (which, several people acknowledged, will may be violated whether it's in there or not, which means it's worth having).

Alissa

  _____  

From: Brian Rosen [mailto:[email-masked]]
To: Elwell, John [mailto:[email-masked]]
Cc: [email-masked] [mailto:[email-masked]], 'Leon Portman' [mailto:[email-masked]]
Sent: Mon, 22 Nov 2010 11:51:20 -0500
Subject: Re: [siprec] Comments on only the security part ofdraft-ietf-siprec-req-04

It's a bit confusing to me.
  
  The rules in the US states are deemed "CONSENT" laws, not notice.  There are one party and two party consent laws, depending on which state you are in.  In my 10 minutes of looking around, I was unable to determine if notice is required or not.  
  
  I do think our charter requires notice, although the wording is a bit lacking in that it says "includes mechanisms to alert users to the fact that a session they are participating in is being recorded".  Notice it says "users" and not "all users".  I think we had best treat this as all users.
  
  Our mechanisms probably have to differentiate between consent and notification.
  
  It does beg the question of whether an in band audio statement that this call may be recorded is an adequate mechanism.  It is certainly what we have now.  I would think we want a signaling mechanism.  An in band notice could also be used.
  
  Brian

  On Nov 22, 2010, at 6:27 AM, Elwell, John wrote:
  
  > Deepanshu,
  > 
  > The latter formulation seems better. There was mention in the face-to-face of some US states that require only one party to be notified, and this would seem to address that point.
  > 
  > John
  > 
  >> -----Original Message-----
  >> From: Deepanshu [mailto:[email-masked]] 
  >> Sent: 22 November 2010 11:18
  >> To: Elwell, John; 'Cullen Jennings'; 'Leon Portman'
  >> Cc: [email-masked]
  >> Subject: RE: [siprec] Comments on only the security part 
  >> ofdraft-ietf-siprec-req-04
  >> 
  >> As I mentioned in some of my previous mail the requirement can be
  >> re-formulated to violate condition 2 as follows.
  >> 
  >> "It SHALL be possible to establish an RS notifying some of the CS
  >> participants"
  >> 
  >> Or
  >> 
  >> "It SHALL NOT be possible to establish an RS without 
  >> notifying any of the CS
  >> participants"
  >> 
  >> 
  >> That will enable implementation to choose whom to notify and 
  >> whom to not. It
  >> will make our solution comprehensive and flexible instead of forcing a
  >> implementation which cannot fulfill the current industry needs.
  >> 
  >> Regards
  >> 
  >> 
  >> Deepanshu Gautam
  >> Tel: +86 25 56620008, Mob: +86 13585147627
  >> 
  >> -----Original Message-----
  >> From: Elwell, John [mailto:[email-masked]] 
  >> Sent: 2010年11月22日 18:37
  >> To: Deepanshu; 'Cullen Jennings'; 'Leon Portman'
  >> Cc: [email-masked]
  >> Subject: RE: [siprec] Comments on only the security part
  >> ofdraft-ietf-siprec-req-04
  >> 
  >> Deepanshu,
  >> 
  >> It is not clear to me why you think condition 2:
  >> "2. Without any of the recipient parties knowing about the delivery to
  >>      the third party" 
  >> would be violated. If parties are not notified, condition 2 
  >> seems to apply.
  >> 
  >> John
  >> 
  >> 
  >>> -----Original Message-----
  >>> From: [email-masked] 
  >>> [mailto:[email-masked]] On Behalf Of Deepanshu
  >>> Sent: 22 November 2010 01:42
  >>> To: 'Cullen Jennings'; 'Leon Portman'
  >>> Cc: [email-masked]
  >>> Subject: Re: [siprec] Comments on only the security part 
  >>> ofdraft-ietf-siprec-req-04
  >>> 
  >>> 
  >>> About Req-72
  >>> I have been trying to convince group about the need of 
  >>> "Notification to the
  >>> CS participants been optional for implementations" and I 
  >>> thought the group
  >>> was convinced 
  >>> (http://www.ietf.org/mail-archive/web/siprec/current/msg00976.
  >>> html) until something happened in Beijing meeting as stated 
  >>> below (I had to
  >>> cancel my registration due to some family tragedy).
  >>> 
  >>> I'm banging on this point again and again because I think 
  >>> this WILL be there
  >>> in the solution one way or the other. Agent Monitoring System
  >>> (http://www.ietf.org/mail-archive/web/siprec/current/msg00890.
  >>> html) is the
  >>> integral part of any recording systems.
  >>> 
  >>> About this being a wiretapping
  >>> (http://www.ietf.org/mail-archive/web/siprec/current/msg00878.html).
  >>> Condition no. 2 in section 3 of 2804 can be violated to avoid 
  >>> it being a
  >>> wiretapping.
  >>> 
  >>> Regards
  >>> 
  >>> 
  >>> Deepanshu Gautam
  >>> Tel: +86 25 56620008, Mob: +86 13585147627
  >>> -----Original Message-----
  >>> From: [email-masked] 
  >>> [mailto:[email-masked]] On Behalf Of
  >>> Cullen Jennings
  >>> Sent: 2010年11月19日 22:17
  >>> To: Leon Portman
  >>> Cc: [email-masked]
  >>> Subject: Re: [siprec] Comments on only the security part
  >>> ofdraft-ietf-siprec-req-04
  >>> 
  >>> 
  >>> Thanks for the answers. One point inline ....
  >>> 
  >>> On Nov 10, 2010, at 7:22 PM, Leon Portman wrote:
  >>> 
  >>>> Cullen, Hi
  >>>> 
  >>>> Thank you very much for the review.
  >>>> 
  >>>> Please see below some answers.
  >>>> 
  >>>> Regards
  >>>> 
  >>>> Leon
  >>>> 
  >>>> -----Original Message-----
  >>>> From: [email-masked] 
  >>> [mailto:[email-masked]] On Behalf
  >>> Of Cullen Jennings
  >>>> Sent: Wednesday, November 10, 2010 8:24 AM
  >>>> To: [email-masked]
  >>>> Subject: [siprec] Comments on only the security part of
  >>> draft-ietf-siprec-req-04
  >>>> 
  >>>> 
  >>>> John asked for comments on the security requirements. In 
  >>> short I think
  >>> they all need work. I don't see anything that should be that 
  >>> hard to get
  >>> sorted. 
  >>>> 
  >>>> Req 29 - this does not say anything that is not in the 
  >>> relevant BCPs - you
  >>> don't need this req but as far as apple pie goes it is fine
  >>>> 
  >>>> Req 30 - I have no idea why you need this - sounds like a 
  >>> solution not a
  >>> requirement 
  >>>> 
  >>>> [LP] We had a lot of discussion about this in the mailing 
  >>> list. The main
  >>> reasons for RS indication in SIP session where for both for 
  >>> routing: to find
  >>> available SRSs for example and for better separation between 
  >>> RS and CS. I
  >>> agree that it is very implementation dependant. For example, 
  >>> if we will have
  >>> metadata elements in RS INVITE, we will know it is RS and not 
  >>> CS. But it can
  >>> require SIP body examination, which is not efficient.
  >>>> I don't think it belongs to security section.
  >>> 
  >>> Hmm - I don't get it. Is't that was the SIP request URI is 
  >> for? If the
  >>> proposal is to do routing based on SIP option tags, I think 
  >>> that is really
  >>> really bad idea. If the plan is to define new SIP routing 
  >>> mechanism, I think
  >>> that is way outside the scope of this WG charter. It seems 
  >>> that you want the
  >>> routing to work with existing SIP routing systems. 
  >>> 
  >>> 
  >>>> 
  >>>> Req 32 - see 29. More interesting is the req about being 
  >>> able to use the
  >>> same key
  >>>> 
  >>>> [LP] This is our current understanding of best security 
  >>> best practice.
  >>> Using separate keys requirement will also protect from 
  >>> passive sniffing
  >>> attacks for recording of paused parts of the conversation 
  >> for example.
  >>>> 
  >>>> Req-33 - no idea what this mean in the security context 
  >>>> [LP] it is related to privacy and access rights. If we 
  >>> don't know who is
  >>> recorded (by relation to CS), then how we can manage access rights?
  >>>> However may be the text is not clear. We don't want always 
  >>> direct relation
  >>> to CS but at least to participants identities
  >>>> 
  >>>> Req 40 - This looks like a sentence like I would type. I 
  >>> have no idea what
  >>> it means 
  >>>> [LP]
  >>>> Yes, looks like typing mistake. Should be:
  >>>> "The mechanism SHALL provide means for an SRS to SRC 
  >>> authentication on RS
  >>> initiation"
  >>>> 
  >>>> Req 41 - Yes, the first requirement I understand. So what 
  >>> do you use this
  >>> Authentication for. I assumed it is used for Authorization. 
  >>>> [LP] yes, we don't need Req 40. 40 and 41 are the same, how 
  >>> I understand
  >>> them
  >>>> 
  >>>> Req 50 - Don't get it. Seems related to 41 
  >>>> [LP] My understanding that we decided not to handle 
  >>> authorization but only
  >>> authentication (no fine authorization roles)
  >>>> Req 60 - see 29
  >>>> 
  >>>> [LP] Yes, it is standard stuff 
  >>>> Req 61 - see 29 
  >>>> 
  >>>> Req 70 -see 29 
  >>>> 
  >>>> req 71 - see 29
  >>>> 
  >>>> Req 72 - This is a violation of your charter but it does 
  >>> seem to reflect
  >>> the consensus of the WG. You should recharter to do wiretap.
  >>>> [LP] Yes, I agree that we MUST have Req-22 (mechanism for 
  >>> indication). If
  >>> some implementation will not implement it (or disable in 
  >>> configuration), we
  >>> should not put it in the req. And during the SIPREC 
  >> meeting, there was
  >>> agreement that we will presenet it as MUST in solution draft 
  >>> as well. We
  >>> definitely don't want to be wiretap.
  >>>> 
  >>>> Req 73 - This is a fascinating one. Confidentiality where? Are you
  >>> transferring unprotected keys across the RS? I look foreword to the
  >>> explanation, I'm sure it will be fascinating. 
  >>>> [LP] this is why we want separate keys for RS. Then CS keys 
  >>> will remain
  >>> shared only between CS participants.
  >>>> 
  >>>> _______________________________________________
  >>>> siprec mailing list
  >>>> [email-masked]
  >>>> https://www.ietf.org/mailman/listinfo/siprec
  >>> 
  >>> _______________________________________________
  >>> siprec mailing list
  >>> [email-masked]
  >>> https://www.ietf.org/mailman/listinfo/siprec
  >>> 
  >>> 
  >>> _______________________________________________
  >>> siprec mailing list
  >>> [email-masked]
  >>> https://www.ietf.org/mailman/listinfo/siprec
  >>> 
  >> 
  >> 
  >> 
  > _______________________________________________
  > siprec mailing list
  > [email-masked]
  > https://www.ietf.org/mailman/listinfo/siprec
  
  _______________________________________________
  siprec mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/siprec

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Nov 2010 22:08:02 +0100

Alissa,

We certainly seemed to be moving towards agreement in the meeting on having a MUST in the eventual solution, although the draft minutes do say discussion to continue on the list - there were people not present at the meeting who I knew had an opinion on the matter.

However, the present words in req-04:
"REQ-024 The mechanism MUST provide a means of indicating to the
   participants involved in a CS that their session is being recorded."
do seem to be adequate, in which case, if we leave these unchanged, we can address the solution issue in due course.

John 

> From: Alissa Cooper [mailto:[email-masked]] 
> Sent: 22 November 2010 17:11
> To: Brian Rosen; Elwell, John
> Cc: [email-masked]; 'Leon Portman'
> There is some good case law out there that holds that if a 
> call participant is notified of a recording and chooses not 
> to hang up, he has implicitly consented to the recording. 
> Pages 11-13 of this memo may be of some help: 
> http://www.cdt.org/privacy/20080708ISPtraffic.pdf. But I 
> still think it's unwise to get hung up on the fact that some 
> states only require one party's consent (as the memo 
> demonstrates, a call between a one-party state and a 
> two-party state can fall under the two-party rules). I 
> thought we had good agreement in the meeting about the 
> current requirement and the MUST in the eventual solution doc 
> (which, several people acknowledged, will may be violated 
> whether it's in there or not, which means it's worth having).
> 
> Alissa
> 
> 
> 
> 
> 
> ________________________________
> 
> 	The rules in the US states are deemed "CONSENT" laws, 
> not notice. There are one party and two party consent laws, 
> depending on which state you are in. In my 10 minutes of 
> looking around, I was unable to determine if notice is 
> required or not. 
> 	
> 	I do think our charter requires notice, although the 
> wording is a bit lacking in that it says "includes mechanisms 
> to alert users to the fact that a session they are 
> participating in is being recorded". Notice it says "users" 
> and not "all users". I think we had best treat this as all users.
> 	
> 	It does beg the question of whether an in band audio 
> statement that this call may be recorded is an adequate 
> mechanism. It is certainly what we have now. I would think we 
> want a signaling mechanism. An in band notice could also be used.
> 	
> 	Brian
> 	
> 	
> 	> The latter formulation seems better. There was 
> mention in the face-to-face of some US states that require 
> only one party to be notified, and this would seem to address 
> that point.
> 	> 
> 	> John
> 	> 
> 	>> From: Elwell, John 
> [mailto:[email-masked]] 
> 	>> Sent: 2010年11月22日 18:37
> (http://www.ietf.org/mail-archive/web/siprec/current/msg00878.
> html) 
> <http://www.ietf.org/mail-archive/web/siprec/current/msg00878.
> html%29> .

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Nov 2010 06:44:49 -0500

Trying to summarize the discussion so far, the current draft-req-04 has the following requirements:

   o REQ-024 The mechanism MUST provide a means of indicating to the
   participants involved in a CS that their session is being recorded.

   o REQ-072 It SHALL be possible to establish an RS without notifying
   the CS participants.

There appears to be general angst with regard to Req-72.

Deepanshu suggested changing Req-72 (I think?) to one of the following:
"It SHALL be possible to establish an RS notifying some of the CS
participants"
Or
"It SHALL NOT be possible to establish an RS without notifying any of the CS
participants"

John appears to favor the second one, but I don't think it's technically possible to fulfill such a requirement.

I suggest we just remove Req-72.  Req-24 only requires providing a means of indication - it does not mandate sending such an indication.  Therefore, Req-72 is implicit.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Nov 2010 07:02:03 -0500

> do seem to be adequate, in which case, if we leave these unchanged, we can address the solution issue in due course.

One open question is if you need a requirement for a signaling-plane indication of recording taking place, separate from in-audio.  The use-case someone mentioned to me for this is in some call centers and government places the phones have a little light/indicator which tells the user when they're being recorded by their RC/RS systems.  Of course since this type of status can change during the call, and may make more sense when tied into a mechanism to turn recording off/on from the phone, this type of thing may be out of scope for the current chartered work.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Mon, 29 Nov 2010 08:33:04 -0500

<as individual>
I want a signaling mechanism defined.   Use may be optional.

Brian

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 29 Nov 2010 14:53:02 +0100

And we already have a proposal in draft-johnston-siprec-cc-rec. The question is whether we need to bring this level or detail out in the requirements, or just assume it will be addressed in the solution.

John 

> Sent: 29 November 2010 13:33
> To: Hadriel Kaplan
> Cc: Elwell, John; Alissa Cooper; [email-masked]; Leon Portman
> Subject: Re: Is Req-24 notification enough? (was: Comments on 
> only the security part ofdraft-ietf-siprec-req-04)
> 
> <as individual>
> >> do seem to be adequate, in which case, if we leave these 
> unchanged, we can address the solution issue in due course.
> > 
> > One open question is if you need a requirement for a 
> signaling-plane indication of recording taking place, 
> separate from in-audio.  The use-case someone mentioned to me 
> for this is in some call centers and government places the 
> phones have a little light/indicator which tells the user 
> when they're being recorded by their RC/RS systems.  Of 
> course since this type of status can change during the call, 
> and may make more sense when tied into a mechanism to turn 
> recording off/on from the phone, this type of thing may be 
> out of scope for the current chartered work.
> > 
> > -hadriel
> > 
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 29 Nov 2010 14:58:02 +0100

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: 29 November 2010 11:45
> To: Elwell, John
> Cc: Alissa Cooper; Brian Rosen; [email-masked]; Leon Portman
> Subject: Notification that the session is being recorded
> (was: Comments on only the security part of draft-ietf-siprec-req-04)
>
>
> Trying to summarize the discussion so far, the current
> draft-req-04 has the following requirements:
>
> John appears to favor the second one, but I don't think it's
> technically possible to fulfill such a requirement.
[JRE] Yes, I preferred the second formulation, but I agree it probably still doesn't make much sense. The mechanism can say "MUST" send a notification in the protocol, and "MUST" render the contents of a received notification to the end user. However, an implementation that ignores those MUSTs will still be capable of interoperating - there is nothing we can do to make sure such notifications really get through to the user.

John (as individual)

>
> I suggest we just remove Req-72.  Req-24 only requires
> providing a means of indication - it does not mandate sending
> such an indication.  Therefore, Req-72 is implicit.
>
> -hadriel
>
>
> > We certainly seemed to be moving towards agreement in the
> meeting on having a MUST in the eventual solution, although
> the draft minutes do say discussion to continue on the list -
> there were people not present at the meeting who I knew had
> an opinion on the matter.
> >

---

From: Leon Portman <[email-masked]>
Date: Mon, 29 Nov 2010 17:09:40 +0200

+1

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, November 29, 2010 3:33 PM
To: Hadriel Kaplan
Cc: Leon Portman; [email-masked]
Subject: Re: [siprec] Is Req-24 notification enough? (was: Comments on only the security part ofdraft-ietf-siprec-req-04)

<as individual>

Brian

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 30 Nov 2010 12:12:52 +0530

I agree too.
An optional signaling mechanism can be defined to indicate the
participants involved that a session is recorded.
There may be other mechanisms that implementers may use [examples like
what Hadriel mentioned]

Ram 

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leon Portman
> Sent: Monday, November 29, 2010 8:40 PM
> To: Brian Rosen; Hadriel Kaplan
> Cc: [email-masked]
> Subject: Re: [siprec] Is Req-24 notification enough? (was: Comments
> ononly the security part ofdraft-ietf-siprec-req-04)
> 
> +1
> 
> Leon
> 
> Subject: Re: [siprec] Is Req-24 notification enough? (was: Comments on
> >> do seem to be adequate, in which case, if we leave these unchanged,
> we can address the solution issue in due course.
> >
> > One open question is if you need a requirement for a signaling-plane
> indication of recording taking place, separate from in-audio.  The
use-
> case someone mentioned to me for this is in some call centers and
> government places the phones have a little light/indicator which tells
> the user when they're being recorded by their RC/RS systems.  Of
course
> since this type of status can change during the call, and may make
more
> sense when tied into a mechanism to turn recording off/on from the
> phone, this type of thing may be out of scope for the current
chartered
> work.

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 30 Nov 2010 07:07:50 -0800

I first suggested to remove it and I continue to hold this position. The double-negative tone in the second sentence is confusing to me and we can imply this from REQ-024 anyways.

Henry

> Behalf Of Elwell, John
> Sent: Monday, November 29, 2010 8:58 AM
> To: Hadriel Kaplan
> Cc: [email-masked]; Leon Portman
> Subject: Re: [siprec] Notification that the session is being recorded
> [JRE] Yes, I preferred the second formulation, but I agree it probably
> still doesn't make much sense. The mechanism can say "MUST" send a
> notification in the protocol, and "MUST" render the contents of a
> received notification to the end user. However, an implementation that
> ignores those MUSTs will still be capable of interoperating - there is
> nothing we can do to make sure such notifications really get through to
> the user.
> 
> John (as individual)
> 
> 
> >

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.