Subject: [siprec] Comments on only the security part of draft-ietf-siprec-req-04

From: Cullen Jennings <[email-masked]>
Date: Tue, 9 Nov 2010 23:24:24 -0700

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 

Req 32 - see 29. More interesting is the req about being able to use the same key

Req-33 - no idea what this mean in the security context 

Req 40 - This looks like a sentence like I would type. I have no idea what it means 

Req 41 - Yes, the first requirement I understand. So what do you use this Authentication for. I assumed it is used for Authorization. 

Req 50 - Don't get it. Seems related to 41 

Req 60 - see 29

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.

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.

---

From: Leon Portman <[email-masked]>
Date: Thu, 11 Nov 2010 04:22:26 +0200

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

[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.

[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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 11 Nov 2010 16:11:25 +0100

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Leon Portman
> Sent: 11 November 2010 02:22
> To: Cullen Jennings; [email-masked]
> Subject: Re: [siprec] Comments on only the security part of 
> draft-ietf-siprec-req-04
> 
> Cullen, Hi
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> 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
[JRE] This will be deleted - it is redundant.

> [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.
[JRE] I agree it is not intended as a security requirement. I think in practice the solution will handle this anyway, but at the time it was felt we should have a requirement - I don't think it does any harm. We don't want the RS establishment inadvertently terminating at a UA that is not an SRS and the UA trying to treat it as a normal call. Perhaps it will be obvious from the SDP, or perhaps we will have an option tag in a Require header field - that would be part of the solution in the support of this requirement.

> Req 32 - see 29. More interesting is the req about being able 
[JRE] Draft-04 does not have a requirement for being able to use the same key - that was in an earlier version.

> 
> [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.
> 
> [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
[JRE] This too is not a security requirement - it is in the wrong part. You need to be able to know that the session you are recording was a CS between Alice and Bob that started at 10.05 and finished at 10.27, for example.

> authentication on RS initiation"
[JRE] No, I think it should say "The mechanism SHALL provide means for an SRS to authenticate the SRC 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. 
[JRE] REQ-040 is about the SRC authenticating the SRS, to make sure it doesn't deliver recorded data to an unauthorised entity, somebody imposing as the genuine SRS. REQ-041 is about the SRS authenticating the SRC, to make sure it is receiving recordings from an entity authorised to send recordings. How authorisation is done is a matter for the SRS (REQ-040) or the SRC (REQ-041), but would presumably be on the basis of having authenticated the SRC and the SRS respectively.

> [LP] My understanding that we decided not to handle 
> authorization but only authentication (no fine authorization roles)
> Req 60 - 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.
[JRE] But I think we should delete REQ-073 - I think the different key management possibilities for media all deal with how protect the keys (e.g., by carrying over TLS in the case of SDES).

John (as individual)

---

From: Leon Portman <[email-masked]>
Date: Fri, 12 Nov 2010 03:09:50 +0200

I agree with John's comments and recommendations

Leon

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, November 11, 2010 5:11 PM
To: Leon Portman; Cullen Jennings; [email-masked]
Subject: RE: [siprec] Comments on only the security part of draft-ietf-siprec-req-04

John (as individual)

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 14 Nov 2010 15:11:10 -0500

With regards to the following requirement:
   o REQ-030 The mechanism MUST provide a means for the Recording
   Session identifier so that the Recording Session itself is labeled as
   a SIP session that is established for the purpose of recording.

Comments below...

> [JRE] I agree it is not intended as a security requirement. I think in practice the solution will handle this anyway, but at the time it was felt we should have a requirement - I don't think it doe…

1) obviously it's not a security requirement, so it should be moved

2) Cullen's right it's a solution not a requirement.  Instead I propose the following:
"Req-XXX The mechanism MUST provide a means for the Recording Session to identify itself as a Recording Session, including in the initial creation of the Recording Session."

3) With regards to a solution, I don't think an option-tag is right.  Afaik, so far in SIP we have stuck to the idea that a SIP session is a SIP session, regardless of whether it's for gaming, conferencing, or whatever.  There's nothing different about it with respect to SIP-layer processing rules.  Either the request-URI targets it at a resource that knows its purpose, or we use media feature-tags (rfc3840/5688).

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 14 Nov 2010 23:42:04 -0500

With regards to the following requirement:
o REQ-073 The mechanism SHALL provide means to ensure the
confidentiality of the encryption keys used in CS.

Comments below...

> [JRE] But I think we should delete REQ-073 - I think the different key management possibilities for media all deal with how protect the keys (e.g., by carrying over TLS in the case of SDES).

I also think you should delete it, since it is confusing and ambiguous.  One can read the requirement at least three different ways, and apparently even between the two of you you've read it in two different ways. :)

For example, you could read it as:
1) That the keys used for the CS are confidential, such that only the CS UAC and UAS can know them.  In other words, that the SRC would reject a request if the keys could be known to any middleman including the SRC (such as if it uses SDES keys).  I'm sure you don't mean this, but that's one way to read it.
2) That the keys used for the CS could be known to the SRC, but never shared with the SRS.  That's how Leon read it, I think.
3) That the keys used for the CS could be known to both the SRC and SRS, but that they be confidential between the SRC and SRS, which is I think how John read it.

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 Nov 2010 16:44:01 -0700

> "Req-XXX The mechanism MUST provide a means for the Recording Session to identify itself as a Recording Session, including in the initial creation of the Recording Session."

That turns it into a requirement thought I'm not sure it's a security requirement. I don't really understand why you this is needed. Wyy is this a requirement? (I've don't have any objection to it being a requirement, I just did not know why it is there)

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 Nov 2010 16:48:37 -0700

I know you have talked about this on the list before but I think you should consider having a requirement to allow some implementation to not have to re encrypt the data in the SRC. The people that are recording HD Telepresence Video sessions, are not going to be very keen on re encrypting everything. When I talk to them they tell me flat out they will not decrypt then re encrypt and they have a strong need for recording in scenarios Tele Presence in the usual financial industry use cases.

---

From: "Dave Smith" <[email-masked]>
Date: Thu, 18 Nov 2010 16:41:14 -0800

I would like to comment on this one.  
The only req't we have currently about this is the following:

   o REQ-032 If the Communication Session is encrypted, the Recording
Session MUST be able to use different keys.

I believe that the req't does not mandate/require that a deployment
performs re-encryption.  However, it essentially requires the protocol
to provide a mechanism to support re-encryption, in case it is desired.
And each implementation must decide if they want to use it, or not.  
I do not believe that a specific req't is needed to ensure that
re-encrytion is not required.  Your video use case could still be
deployed.  

However, to be more clear, I recommend to re-write REQ-032 in this way:
	REQ-032    The mechanism MUST support functionality such that if
the CS is encrypted, the RS may use different encryption keys.

Note that if the CS is not encrypted, the RS could be encrypted, or not.
It depends on the deployment.  
Remember that do have this related req't:

   o REQ-071 The mechanism SHALL ensure the confidentiality of the Media
sent from SRC to SRS.

The intent being, I believe, that encryption of RS is possible, but
optional.  RS encryption is NOT mandatory for a deployment.  
So REQ-071 would probably be better written this way:

	REQ-071 The mechanism MUST provide a means to support RS
confidentiality.  

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cullen Jennings
Sent: Thursday, November 18, 2010 3:49 PM
To: Elwell, John
Cc: [email-masked]; Leon Portman
Subject: Re: [siprec] Comments on only the security part
ofdraft-ietf-siprec-req-04

I know you have talked about this on the list before but I think you
should consider having a requirement to allow some implementation to not
have to re encrypt the data in the SRC. The people that are recording HD
Telepresence Video sessions, are not going to be very keen on re
encrypting everything. When I talk to them they tell me flat out they
will not decrypt then re encrypt and they have a strong need for
recording in scenarios Tele Presence in the usual financial industry use
cases. 

On Nov 11, 2010, at 8:11 AM, Elwell, John wrote:

> [JRE] I agree it is not intended as a security requirement. I think in
practice the solution will handle this anyway, but at the time it was
felt we should have a requirement - I don't think it does any harm. We
don't want the RS establishment inadvertently terminating at a UA that
is not an SRS and the UA trying to treat it as a normal call. Perhaps it
will be obvious from the SDP, or perhaps we will have an option tag in a
Require header field - that would be part of the solution in the support
of this requirement.
> [JRE] Draft-04 does not have a requirement for being able to use the
same key - that was in an earlier version.
> [JRE] This too is not a security requirement - it is in the wrong
part. You need to be able to know that the session you are recording was
a CS between Alice and Bob that started at 10.05 and finished at 10.27,
for example.
> [JRE] REQ-040 is about the SRC authenticating the SRS, to make sure it
doesn't deliver recorded data to an unauthorised entity, somebody
imposing as the genuine SRS. REQ-041 is about the SRS authenticating the
SRC, to make sure it is receiving recordings from an entity authorised
to send recordings. How authorisation is done is a matter for the SRS
(REQ-040) or the SRC (REQ-041), but would presumably be on the basis of
having authenticated the SRC and the SRS respectively.
> [JRE] But I think we should delete REQ-073 - I think the different key
management possibilities for media all deal with how protect the keys
(e.g., by carrying over TLS in the case of SDES).

-------------------------------------------------------------------------------------------------------------------
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.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Nov 2010 07:17:17 -0700

Thanks for the answers. One point inline ....

> 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Nov 2010 09:57:00 -0500

I too have wondered about the need for this requirement.

I can see the following situations when it might be helpful:

- The RS is established by the SRS toward the SRC. The SRC might not 
realize the purpose of the invite. But this is currently out of scope, 
and when it is in scope I suspect there will be more to it than just 
saying "I'm an SRS" - there will need be more info on what is expected 
to be recorded.

- There has been some talk (mostly by Brian) of REFERing an SRS to a 
conference focus as a way of recording a conference. In some ways this 
is similar to the prior point. But the relationship is different, 
because it was proposed that an SRC would do the REFERing and the focus 
would not be considered an SRC. Again this is currently out of scope and 
probably has more complexity.

Other than those cases I think there is just the "normal" case of the 
SRC using an INVITE to establish an RS with the SRS. Presumably they 
both know the purpose, so the indication seems redundant.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Nov 2010 17:54:05 +0100

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 18 November 2010 23:44
> To: Hadriel Kaplan
> Cc: Elwell, John; Leon Portman; [email-masked]
> Subject: Re: REQ-30 (was: Comments on only the security part 
> of draft-ietf-siprec-req-04)
> 
> 
> >> [JRE] I agree it is not intended as a security 
> requirement. I think in practice the solution will handle 
> this anyway, but at the time it was felt we should have a 
> requirement - I don't think it does any harm. We don't want 
> the RS establishment inadvertently terminating at a UA that 
> is not an SRS and the UA trying to treat it as a normal call. 
> Perhaps it will be obvious from the SDP, or perhaps we will 
> have an option tag in a Require header field - that would be 
> part of the solution in the support of this requirement.
> > 
> > "Req-XXX The mechanism MUST provide a means for the 
> Recording Session to identify itself as a Recording Session, 
> including in the initial creation of the Recording Session."
> 
> That turns it into a requirement thought I'm not sure it's a 
> security requirement. I don't really understand why you this 
> is needed. Wyy is this a requirement? (I've don't have any 
> objection to it being a requirement, I just did not know why 
> it is there)
[JRE] I have already said it is not a security requirement. I can live with or without this requirement (because I think think we will ensure the solution does the right thing anyway).

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Nov 2010 18:03:30 +0100

> Sent: 19 November 2010 14:17
> To: Leon Portman
> Cc: [email-masked]
> 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. 
[JRE] Perhaps I shouldn't have mentioned option tags, it was only an example. I was thinking in terms of an option tag in Require if there happens to be some special behaviour we require of the SRS. I was certainly not wanting to use option tags for routing. But don't dwell on that - I don't think anyone intended mentioning option tags in the requirements.

John (as individual)

> > [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.
> > 
> > [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?
> > Req 41 - Yes, the first requirement I understand. So what 
> do you use this Authentication for. I assumed it is used for 
> Authorization. 
> > 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.

---

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

I think your proposed formulations are good.

John (as individual) 

> From: Dave Smith [mailto:[email-masked]] 
> Sent: 19 November 2010 00:41
> To: Cullen Jennings; Elwell, John
> Subject: RE: [siprec] Comments on only the security part 
> Perhaps it
> > [JRE] No, I think it should say "The mechanism SHALL 
> provide means for
> an SRS to authenticate the SRC on RS
> >   initiation"
> > 
> >> 
> --------------------------------------------------------------
> -----------------------------------------------------
> 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.
> 					
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Nov 2010 18:25:04 +0100

Cullen,

Yes, I can see your point. Dave Smith has already proposed some rewording that would allow implementations not to re-encrypt, but I wonder whether we need to go further. I was certainly instrumental in removing a requirement we had at one time that said that the mechanism must also allow reuse of the same key, and this is because of impact on the CS having to rekey whenever recording is turned off. But I guess this is no different from a switched video conference where the bridge does not decrypt and re-encrypt, but the whole conference has to rekey whenever a party leaves. So I think I am coming round to the opinion that using the same keys might be reasonable in some circumstances.

Perhaps we need to approach the requirements in a different way. I guess one requirement is along the lines of the mechanism must not allow the SRS access to keys used when the CS is not being recorded. Do we also need a requirement about being possible to avoid decryption and re-encryption at an SRC, or can this be left for the solution?

If I recall the details of SRTP correctly, I think the encryption depends on the SSRC value. So this implies using the same SSRC values on the RS that are used on the CS. So for a 2-party call, say, if the two directions happen to use the same SSRC value, we would have two streams in the same direction on the RS using that same SSRC value. Don't know whether this is a problem or not.

John (as individual)

> Sent: 18 November 2010 23:49
> To: Elwell, John
> Cc: Leon Portman; [email-masked]
> I know you have talked about this on the list before but I 
> think you should consider having a requirement to allow some 
> implementation to not have to re encrypt the data in the SRC. 
> The people that are recording HD Telepresence Video sessions, 
> are not going to be very keen on re encrypting everything. 
> When I talk to them they tell me flat out they will not 
> decrypt then re encrypt and they have a strong need for 
> recording in scenarios Tele Presence in the usual financial 
> industry use cases. 
> 
> 
> > [JRE] I agree it is not intended as a security requirement. 
> I think in practice the solution will handle this anyway, but 
> at the time it was felt we should have a requirement - I 
> don't think it does any harm. We don't want the RS 
> establishment inadvertently terminating at a UA that is not 
> an SRS and the UA trying to treat it as a normal call. 
> > [JRE] Draft-04 does not have a requirement for being able 
> to use the same key - that was in an earlier version.
> > 
> >> 
> > [JRE] This too is not a security requirement - it is in the 
> wrong part. You need to be able to know that the session you 
> are recording was a CS between Alice and Bob that started at 
> 10.05 and finished at 10.27, for example.
> > 
> >> 
> provide means for an SRS to authenticate the SRC on RS
> >   initiation"
> > 
> >> 
> > [JRE] REQ-040 is about the SRC authenticating the SRS, to 
> make sure it doesn't deliver recorded data to an unauthorised 
> entity, somebody imposing as the genuine SRS. REQ-041 is 
> about the SRS authenticating the SRC, to make sure it is 
> receiving recordings from an entity authorised to send 
> recordings. How authorisation is done is a matter for the SRS 
> (REQ-040) or the SRC (REQ-041), but would presumably be on 
> the basis of having authenticated the SRC and the SRS respectively.
> > 
> >> 
> > [JRE] But I think we should delete REQ-073 - I think the 
> different key management possibilities for media all deal 
> with how protect the keys (e.g., by carrying over TLS in the 
> case of SDES).
> > 
> > John (as individual)
> > 
> >>

---

From: Deepanshu <[email-masked]>
Date: Mon, 22 Nov 2010 09:41:44 +0800

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

Of Cullen Jennings
> 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
> [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. 

> [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.
> [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 41 - Yes, the first requirement I understand. So what do you use this
Authentication for. I assumed it is used for Authorization. 
> [LP] My understanding that we decided not to handle authorization but only
authentication (no fine authorization roles)
> 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.

---

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

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

> [mailto:[email-masked]] On Behalf Of Deepanshu
> Sent: 22 November 2010 01:42
> To: 'Cullen Jennings'; 'Leon Portman'
> Cc: [email-masked]
> was convinced 
> (http://www.ietf.org/mail-archive/web/siprec/current/msg00976.
> short I think
> relevant BCPs - you
> > Req 30 - I have no idea why you need this - sounds like a 
> solution not a
> requirement 
> > 
> list. The main
> CS. But it can
> > Req 32 - see 29. More interesting is the req about being 
> able to use the
> same key
> > 
> best practice.
> don't know who is
> direct relation
> > Req 40 - This looks like a sentence like I would type. I 
> have no idea what
> it means 
> > [LP]
> > "The mechanism SHALL provide means for an SRS to SRC 
> authentication on RS
> initiation"
> > 
> do you use this
> > [LP] yes, we don't need Req 40. 40 and 41 are the same, how 
> I understand
> them
> > 
> authorization but only
> seem to reflect
> indication). If

---

From: Deepanshu <[email-masked]>
Date: Mon, 22 Nov 2010 19:18:28 +0800

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

-----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

Deepanshu,

John

---

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

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

> From: Deepanshu [mailto:[email-masked]] 
> Sent: 22 November 2010 11:18
> To: Elwell, John; 'Cullen Jennings'; 'Leon Portman'
> Cc: [email-masked]
> for? If the

---

From: "De Villiers de Wet" <[email-masked]>
Date: Mon, 22 Nov 2010 16:02:17 +0200

John

I disagree:  if parties are not NOTIFIED real-time via some mechanism specified in SIPREC, it does not follow that the sending party and none of the recipient parties therefore do not KNOW about the delivery to the third party (i.e. the recording system and its owners/custodians/users).  The sender or recipient(s) could know in some other way about "the delivery to a third party, i.e. the SRS or its owners/custodians/users).

For example, if employees in a Call Center are informed via their terms & conditions of employment (someone has mentioned this before I think), they have been informed, condition 2 of wiretapping is violated, and a recording system that does not notify any of the participants in real-time of the recording activity is therefore not doing wiretapping.

De Villiers

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 22 November 2010 12: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,

John

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 Nov 2010 09:29:39 -0700

As FYI ... I believe your charter requires notification of all participants and I will be objecting to anything that is not that unless you re-charter to do wiretap.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Nov 2010 11:51:20 -0500

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

---

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

De Villiers,

I am not sure what you are disagreeing with, because I was only asking a question.

Anyway, I agree with what you are saying - parties need to be notified somehow, but that could be by in-band means or by external means, such as contract.

John 

> From: De Villiers de Wet [mailto:[email-masked]] 
> Sent: 22 November 2010 14:02
> To: Elwell, John
> Cc: [email-masked]; Deepanshu; Cullen Jennings; Leon Portman
> I disagree:  if parties are not NOTIFIED real-time via some 
> mechanism specified in SIPREC, it does not follow that the 
> sending party and none of the recipient parties therefore do 
> not KNOW about the delivery to the third party (i.e. the 
> recording system and its owners/custodians/users).  The 
> sender or recipient(s) could know in some other way about 
> "the delivery to a third party, i.e. the SRS or its 
> owners/custodians/users).
> 
> For example, if employees in a Call Center are informed via 
> their terms & conditions of employment (someone has mentioned 
> this before I think), they have been informed, condition 2 of 
> wiretapping is violated, and a recording system that does not 
> notify any of the participants in real-time of the recording 
> activity is therefore not doing wiretapping.
> 
> De Villiers
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Nov 2010 05:50:52 -0500

John,
where is this "condition 2" from?  I checked the requirements draft and I cannot find this text, nor can I find it in earlier emails.

-hadriel

---

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

This was in section 3 of RFC 2804. It seems the earlier part of the thread was snipped.

John 

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 29 November 2010 10:51
> To: Elwell, John
> Cc: Deepanshu; Cullen Jennings; Leon Portman; [email-masked]
> where is this "condition 2" from?  I checked the requirements 
> draft and I cannot find this text, nor can I find it in 
> earlier emails.
> 
> -hadriel
> 
>

---

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

> As FYI ... I believe your charter requires notification of all participants and I will be objecting to anything that is not that unless you re-charter to do wiretap. 

I've re-read the charter and I don't see it saying that.  It says the following regarding this topic:

  The working group will make sure that any protocol specified addresses these
  concerns and includes mechanisms to alert users to the fact that a
  session they are participating in is being recorded.

  The working group must take care that the session recording requirements
  and protocol does not conflict with the IETF statement on wiretapping
  contained in RFC 2804.

In particular, neither the charter nor RFC 2804 require notifying ALL participants.  Furthermore, the charter requires the protocol to include mechanisms to alert users - not that an implementation actually has to use such a mechanism.

In other words, the charter does not "require notification of all participants" - it only requires the *ability* to notify *one or more* participants.

-hadriel