Subject: Re: [siprec] #35: Clarification of REQ-029 on security

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Oct 2010 15:36:54 +0200

The original text of this ticket states:
"We need to be more specific about what is subject to confidentiality and integrity (media, metadata, signalling), and what needs to be authenticated by what (SRS by SRC and/or vice versa)."

This relates to REQ-029 "The mechanism MUST support a means of providing security
   (confidentiality, integrity and authentication) for the SIPREC."

In addition, there may be further security requirements that are not captured by the existing text.

There has been no list discussion on this ticket, and discussion during Tuesday's call was inconclusive (see minutes:
http://www.ietf.org/mail-archive/web/siprec/current/msg00829.html).

I would like to invite contributions to make progress on this, which appears to be on the critical path for completing the requirements document. Any suggestions would be welcome, e.g.:
- specific requirement(s) text;
- things that should be considered;
- pointers to existing work that might be relevant (e.g., GEOPRIV);
- or even a separate I-D to help tease out the requirements.

I am looking for input from security experts, as well as from recording experts.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of siprec issue tracker
> Sent: 28 September 2010 08:49
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [siprec] #35: Clarification of REQ-029 on security
> 
> #35: Clarification of REQ-029 on security
> ------------------------------------------------+-------------
> --------------
>  Reporter:  john.elwell@...                       |       
> Owner:  krehor@...        
>      Type:  defect                              |      
> Status:  assigned        
>  Priority:  major                               |   
> Milestone:                  
> Component:  Requirements                        |     
> Version:                  
>  Severity:  Active WG Document                  |    
> Keywords:                  
> ------------------------------------------------+-------------
> --------------
> Changes (by krehor@...):
> 
>   * status:  new => assigned
> 
> 
> -- 
> Ticket URL: 
> <https://wiki.tools.ietf.org/wg/siprec/trac/ticket/35#comment:1>
> siprec <http://tools.ietf.org/siprec/>
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: Deepanshu <[email-masked]>
Date: Sat, 16 Oct 2010 15:01:22 +0800

Dear All,

I think we can start by defining the following groups:

X. SECURITY
0. A general requirement advocating the use of existing mechanism e,g TLS
and IPsec.
1. REQ-29 ...
2. REQ-31 ...
3. REQ-32 ...

X.1 AUTHENTICATION
1. The mechanism SHALL provide means for an SRS to SRC on RS initiation.
2. The mechanism SHALL provide means for an SRC to authenticate SRS on RS
initiation.
3. The mechanism SHALL allow only authorized SRC/SRS to initiate an RS.
4. The mechanism SHALL provide means for a user to manage authorization
rules which will allow an SRC/SRS to initiate a RS.

X.2 INTEGRITY
0. Data integrity of SIPREC messages MUST be ensured.
1. The mechanism SHALL provide means to ensure the integrity of Recorded
Media.
2. The Recorded Media SHALL provide enough information for future
search/retrieval and playback. The examples of such information are
identities of CS participants, start/end time of CS etc.

X.3 CONFIDENTIALITY
1. The mechanism SHALL provide means to establish an RS without notifying
the CS participants.
2. The mechanism SHALL provide means to ensure the confidentiality of the
encryption keys used in CS.

Please advice for any sort of additions, deletions, modifications or
clarifications.

Regards

Deepanshu Gautam
Tel: +86 25 56620008, Mob: +86 13585147627

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Elwell, John
Sent: 2010年10月14日 21:37
To: siprec issue tracker; [email-masked]
Cc: [email-masked]
Subject: Re: [siprec] #35: Clarification of REQ-029 on security

The original text of this ticket states:
"We need to be more specific about what is subject to confidentiality and
integrity (media, metadata, signalling), and what needs to be authenticated
by what (SRS by SRC and/or vice versa)."

This relates to REQ-029 "The mechanism MUST support a means of providing
security
   (confidentiality, integrity and authentication) for the SIPREC."

In addition, there may be further security requirements that are not
captured by the existing text.

There has been no list discussion on this ticket, and discussion during
Tuesday's call was inconclusive (see minutes:
http://www.ietf.org/mail-archive/web/siprec/current/msg00829.html).

I would like to invite contributions to make progress on this, which appears
to be on the critical path for completing the requirements document. Any
suggestions would be welcome, e.g.:
- specific requirement(s) text;
- things that should be considered;
- pointers to existing work that might be relevant (e.g., GEOPRIV);
- or even a separate I-D to help tease out the requirements.

I am looking for input from security experts, as well as from recording
experts.

John

---

From: Deepanshu <[email-masked]>
Date: Sat, 16 Oct 2010 18:08:48 +0800

Correction below

>1. The mechanism SHALL provide means for an SRS to **authenticate** SRC on
>RS initiation.

Regards

Deepanshu Gautam
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Deepanshu
Sent: 2010年10月16日 15:01
To: 'Elwell, John'; 'siprec issue tracker'; [email-masked]
Cc: [email-masked]
Subject: Re: [siprec] #35: Clarification of REQ-029 on security

Dear All,

X. SECURITY

X.1 AUTHENTICATION

X.2 INTEGRITY

X.3 CONFIDENTIALITY

Regards

Deepanshu Gautam

-----Original Message-----

John

---

From: Leon Portman <[email-masked]>
Date: Sun, 17 Oct 2010 10:54:46 +0200

Additional items, may be some of them are out of scope of the protocol but obviously not of the entire solution:

PRIVACY
1. The mechanism SHALL provide means for participants to control which metadata is reported to SRS
2. The mechanism SHALL provide means to control retention of recorded media

AUTHENTICATION
1. The mechanism SHALL provide means for authentication of CS participants

AUTHORIZATION
1. The mechanism SHALL provide means for authorization of the access to recorded media and metadata

INTEGRITY
1. The mechanism SHALL provide means to ensure the integrity of recorded Metadata.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Deepanshu
Sent: Saturday, October 16, 2010 12:09 PM
To: 'Deepanshu'; 'Elwell, John'; 'siprec issue tracker'; [email-masked]
Cc: [email-masked]
Subject: Re: [siprec] #35: Clarification of REQ-029 on security

Correction below

Regards

Deepanshu Gautam
-----Original Message-----

Dear All,

X. SECURITY

X.1 AUTHENTICATION

X.2 INTEGRITY

X.3 CONFIDENTIALITY

Regards

Deepanshu Gautam

-----Original Message-----

John

---

From: Deepanshu <[email-masked]>
Date: Mon, 18 Oct 2010 09:48:06 +0800

Thanks Leon,

Why do you think that CS participants need to be authenticated? Aren’t they
already at the time of CS establishment?

Regards

Deepanshu Gautam
-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 2010年10月17日 16:55
To: Deepanshu; 'Elwell, John'; 'siprec issue tracker'; [email-masked]
Cc: [email-masked]
Subject: RE: [siprec] #35: Clarification of REQ-029 on security

Additional items, may be some of them are out of scope of the protocol but
obviously not of the entire solution:

PRIVACY
1. The mechanism SHALL provide means for participants to control which
metadata is reported to SRS
2. The mechanism SHALL provide means to control retention of recorded media

AUTHENTICATION

AUTHORIZATION
1. The mechanism SHALL provide means for authorization of the access to
recorded media and metadata

INTEGRITY
1. The mechanism SHALL provide means to ensure the integrity of recorded
Metadata.

Leon

-----Original Message-----

Correction below

Regards

Deepanshu Gautam
-----Original Message-----

Dear All,

X. SECURITY

X.1 AUTHENTICATION

X.2 INTEGRITY

X.3 CONFIDENTIALITY

Regards

Deepanshu Gautam

-----Original Message-----

John

---

From: "Dave Smith" <[email-masked]>
Date: Sun, 17 Oct 2010 20:59:50 -0700

I would recommend to add the following explicitly:  

X.3 CONFIDENTIALITY
3.  The mechanism MUST support optional functionality to secure transmissions between SRC and SRS (e.g., via SRTP).

A few other inputs/questions below.   

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Deepanshu
Sent: Saturday, October 16, 2010 3:09 AM
To: 'Deepanshu'; 'Elwell, John'; 'siprec issue tracker'; [email-masked]
Cc: [email-masked]
Subject: Re: [siprec] #35: Clarification of REQ-029 on security

Correction below

Regards

Deepanshu Gautam
-----Original Message-----

Dear All,

X. SECURITY
0. A general requirement advocating the use of existing mechanism e,g TLS
and IPsec.  [DS]  Not sure why we need this; couldn't recommendations like TLS, SRTP be added to actual req'ts where applicable?
1. REQ-29 ...[DS]  It makes sense that this could be removed and replaced by the new req'ts.  
2. REQ-31 ...[DS]  The decision was for this to be removed (actually deferred, per earlier discussions) 
3. REQ-32 ...

X.1 AUTHENTICATION
1. The mechanism SHALL provide means for an SRS to authenticate SRC on RS initiation.
2. The mechanism SHALL provide means for an SRC to authenticate SRS on RS initiation.
 
[DS]  A question - could we merge 1 and 2 above to become the following:  The mechanism MUST support authentication between SRC and SRS on RS initiation.  ?

X.2 INTEGRITY

X.3 CONFIDENTIALITY

Regards

Deepanshu Gautam

-----Original Message-----

John

-------------------------------------------------------------------------------------------------------------------
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: Deepanshu <[email-masked]>
Date: Mon, 18 Oct 2010 12:32:24 +0800

Thanks Dave,

Inline with [DG].....

Deepanshu Gautam

-----Original Message-----
From: Dave Smith [mailto:[email-masked]] 
Sent: 2010年10月18日 12:00
To: Deepanshu; Elwell, John; siprec issue tracker; [email-masked]
Cc: [email-masked]
Subject: RE: [siprec] #35: Clarification of REQ-029 on security

X.3 CONFIDENTIALITY
3.  The mechanism MUST support optional functionality to secure
transmissions between SRC and SRS (e.g., via SRTP).

Regards,
Dave

-----Original Message-----

Correction below

Regards

Deepanshu Gautam
-----Original Message-----

Dear All,

X. SECURITY
0. A general requirement advocating the use of existing mechanism e,g TLS
and IPsec.  [DS]  Not sure why we need this; couldn't recommendations like
TLS, SRTP be added to actual req'ts where applicable?
[DG] Yes, it can be done.
1. REQ-29 ...[DS]  It makes sense that this could be removed and replaced by
the new req'ts.  
2. REQ-31 ...[DS]  The decision was for this to be removed (actually
deferred, per earlier discussions) 
[DG] *If* it was agreed to delete this, so be it.
3. REQ-32 ...

X.1 AUTHENTICATION
1. The mechanism SHALL provide means for an SRS to authenticate SRC on RS
initiation.
2. The mechanism SHALL provide means for an SRC to authenticate SRS on RS
initiation.
 
[DS]  A question - could we merge 1 and 2 above to become the following:
The mechanism MUST support authentication between SRC and SRS on RS
initiation.  ?
[DG] The concerns in the related ticket was to mention "who is
authenticating who" that why I made two separate requirements an di do
believe they are better to be two then one.

X.2 INTEGRITY

X.3 CONFIDENTIALITY

Regards

Deepanshu Gautam

-----Original Message-----

John

----------------------------------------------------------------------------
---------------------------------------
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: Mon, 18 Oct 2010 09:35:45 +0200

> From: Deepanshu [mailto:[email-masked]] 
> Sent: 16 October 2010 11:09
> To: 'Deepanshu'; Elwell, John; 'siprec issue tracker'; 
> [email-masked]
> Cc: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> Deepanshu
> Sent: 2010年10月16日 15:01
[JRE] I am not sure this should be within scope. I assume by "user" you means an authorised manager (as opposed to a user participating in CSs that might be subject to recording).

> identities of CS participants, start/end time of CS etc.
[JRE] This is basically the metadata, which I believe is covered by other requirements.

> 1. The mechanism SHALL provide means to establish an RS 
[JRE] I don't think we want such a requirement. It can b e considered to be in violation of privacy requirements, and in some jurisdictions it would be illegal. Having said that, the notification need not necessarily be at the time recording starts. For example, playing an announcement at the start of a call saying that calls may be recorded will be sufficient in some jurisdictions.

> encryption keys used in CS.
[JRE] I don't see the relevance of this. The CS will negotiate keys in a confidential manner independently of SIPREC, and there should be no need for disclosure of those keys to the SRS. What is more important is to preserve the confidentiality of the keys used in the RS (which, in the case of shared keys, if we allow this - see separate email thread - would also be the keys used in the CS). But I don't think confidentiality of keys used in the RS needs bringing out as a separate requirement. In order to meet a requirement that recorded data and metadata be confidentiality protected, it is clearly necessary to ensure that the keys are not disclosed.

John (as individual)

> [mailto:[email-masked]] On Behalf Of
> Elwell, John
> Sent: 2010年10月14日 21:37

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Oct 2010 09:37:25 +0200

> Sent: 17 October 2010 09:55
> To: Deepanshu; Elwell, John; 'siprec issue tracker'; [email-masked]
> Cc: [email-masked]
> Additional items, may be some of them are out of scope of the 
> protocol but obviously not of the entire solution:
> 
> PRIVACY
> 1. The mechanism SHALL provide means for participants to 
> control which metadata is reported to SRS
[JRE] I think we need some sort of justification / example for this requirement. If a participant can suppress some of the metadata, it potential could make the recording useless.

> 2. The mechanism SHALL provide means to control retention of 
[JRE] It is probably reasonable for some metadata, at the time of the recording, to indicate preference/requirement concerning retention. Subsequent to completion of the recording, any further control of the stored recording is outside the scope of SIPREC, I believe. So if we need such a requirement (i.e., if can't just be listed as an item of metadata), we would need to word it more precisely.

> 1. The mechanism SHALL provide means for authentication of CS 
[JRE] I disagree. Authentication of CS participants is something that can be done during CS establishment, independently of SIPREC. Although there is some dissatisfaction with current SIP mechanisms addressing this problem space, SIPREC should not go down that rat hole.

> access to recorded media and metadata
[JRE] It depends what is meant by this. Providing as part of metadata at the time of recording some sort of privacy rules, indicating who might be authorised to replay the recording, might be within scope. The mechanism for authorising somebody requesting playback of a recording I think is out of scope.

John (as individual)

> [mailto:[email-masked]] On Behalf Of Deepanshu

---

From: Deepanshu <[email-masked]>
Date: Mon, 18 Oct 2010 16:09:37 +0800

Thanks John

Inline with [DG]..

Regards

Deepanshu Gautam

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 2010年10月18日 15:36
To: Deepanshu; 'siprec issue tracker'; [email-masked]
Cc: [email-masked]
Subject: RE: [siprec] #35: Clarification of REQ-029 on security

> rules which will allow an SRC/SRS to initiate a RS.
[JRE] I am not sure this should be within scope. I assume by "user" you
means an authorised manager (as opposed to a user participating in CSs that
might be subject to recording).

> identities of CS participants, start/end time of CS etc.
[JRE] This is basically the metadata, which I believe is covered by other
requirements.
[DG] Yes it is, but the requirement here is to ensure the integrity of
Metadata.

> 1. The mechanism SHALL provide means to establish an RS 
[JRE] I don't think we want such a requirement. It can b e considered to be
in violation of privacy requirements, and in some jurisdictions it would be
illegal. Having said that, the notification need not necessarily be at the
time recording starts. For example, playing an announcement at the start of
a call saying that calls may be recorded will be sufficient in some
jurisdictions.
[DG] As for requirement it doesn't says that this has to be done, so it is
not a violation. It says: it SHALL be possible. In other words our solution
MUST not preclude it. There *is* a requirement to establish an RS without
notifying CS participants (e.g agent performance monitoring system) and it
is NOT illegal. The mechanism MUST allow this; if it is illegal in some
jurisdictions then it should not be implemented. If someone does, they are
on their own.
I can further suggest the following re-wording
"It SHALL be possible to establish an RS without notifying the CS
participants"

> encryption keys used in CS.
[JRE] I don't see the relevance of this. The CS will negotiate keys in a
confidential manner independently of SIPREC, and there should be no need for
disclosure of those keys to the SRS. What is more important is to preserve
the confidentiality of the keys used in the RS (which, in the case of shared
keys, if we allow this - see separate email thread - would also be the keys
used in the CS). But I don't think confidentiality of keys used in the RS
needs bringing out as a separate requirement. In order to meet a requirement
that recorded data and metadata be confidentiality protected, it is clearly
necessary to ensure that the keys are not disclosed.
[DG] Okay then lets have a requirement on recorded data and metadata be
conf. protected. Do we already have one? If not, what about the following
"The mechanism SHALL ensure the confidentiality of the Recorded Media and
Metadata"

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Oct 2010 10:24:19 +0200

> Sent: 18 October 2010 09:10
> To: Elwell, John; 'siprec issue tracker'; [email-masked]
> Cc: [email-masked]
[JRE] I agree that data integrity should apply to both data and metadata.

> "It SHALL be possible to establish an RS without notifying the CS
[JRE] We have to be careful of the following, from the charter:
"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."
So I would be very wary about doing anything that explicitly supports cases of recording without notifying participants.

John

---

From: Deepanshu <[email-masked]>
Date: Mon, 18 Oct 2010 17:12:04 +0800

Deepanshu Gautam

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 2010年10月18日 16:24
To: Deepanshu; 'siprec issue tracker'; [email-masked]
Cc: [email-masked]
Subject: RE: [siprec] #35: Clarification of REQ-029 on security

[JRE] We have to be careful of the following, from the charter:
"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."
So I would be very wary about doing anything that explicitly supports cases
of recording without notifying participants.
[DG] Is it really a wiretapping (as defined in 2804) we are talking here? In
all our use cases (including conference) the entity (SRC) who will be
replicating media *will actually be* the receiver of the original media.
Isn't? And 2804 exclude this to be called as wiretapping. So we don't have
to worry about it. We are not doing wiretapping.

John

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 18 Oct 2010 17:49:42 +0530

Hi Deepanshu,
Please see inline <Ram>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Deepanshu
Sent: Monday, October 18, 2010 1:40 PM
To: 'Elwell, John'; 'siprec issue tracker'; Ken Rehor (krehor)
Cc: [email-masked]
Subject: Re: [siprec] #35: Clarification of REQ-029 on security

Thanks John

Inline with [DG]..

Regards

Deepanshu Gautam

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 2010年10月18日 15:36
To: Deepanshu; 'siprec issue tracker'; [email-masked]
Cc: [email-masked]
Subject: RE: [siprec] #35: Clarification of REQ-029 on security

<Ram> I am not sure if the wording is correct. I agree we need to ensure the INTEGRITY and CONFIDENTIALITY of the Recorded Media and Metadata that is sent from SRC to SRS. once the information is received at SRS, it is up to SRS on how he stores and ensures the confidentiality of the stored data/metadata. 
Probably we can re-word as "The mechanism SHALL ensure the INTEGRITY and CONFIDENTIALITY of the Metadata and Media sent from SRC to SRS" ?

Thanks,
Ram

John (as individual)

---

From: Deepanshu <[email-masked]>
Date: Tue, 19 Oct 2010 10:17:06 +0800

Thanks Ram,

I'm fine with your proposal

Regards

Deepanshu Gautam
-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 2010年10月18日 20:20
To: Deepanshu; Elwell, John; siprec issue tracker; Ken Rehor (krehor)
Cc: [email-masked]
Subject: RE: [siprec] #35: Clarification of REQ-029 on security

Hi Deepanshu,
Please see inline <Ram>

-----Original Message-----

Thanks John

Inline with [DG]..

Regards

Deepanshu Gautam

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 2010年10月18日 15:36
To: Deepanshu; 'siprec issue tracker'; [email-masked]
Cc: [email-masked]
Subject: RE: [siprec] #35: Clarification of REQ-029 on security

[JRE] I don't see the relevance of this. The CS will negotiate keys in a
confidential manner independently of SIPREC, and there should be no need for
disclosure of those keys to the SRS. What is more important is to preserve
the confidentiality of the keys used in the RS (which, in the case of shared
keys, if we allow this - see separate email thread - would also be the keys
used in the CS). But I don't think confidentiality of keys used in the RS
needs bringing out as a separate requirement. In order to meet a requirement
that recorded data and metadata be confidentiality protected, it is clearly
necessary to ensure that the keys are not disclosed.
[DG] Okay then lets have a requirement on recorded data and metadata be
conf. protected. Do we already have one? If not, what about the following
"The mechanism SHALL ensure the confidentiality of the Recorded Media and
Metadata"
<Ram> I am not sure if the wording is correct. I agree we need to ensure the
INTEGRITY and CONFIDENTIALITY of the Recorded Media and Metadata that is
sent from SRC to SRS. once the information is received at SRS, it is up to
SRS on how he stores and ensures the confidentiality of the stored
data/metadata. 
Probably we can re-word as "The mechanism SHALL ensure the INTEGRITY and
CONFIDENTIALITY of the Metadata and Media sent from SRC to SRS" ?

Thanks,
Ram

John (as individual)

---

From: "Dave Smith" <[email-masked]>
Date: Mon, 18 Oct 2010 22:20:34 -0700

My inputs provided below (see  [DS]  ).

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Deepanshu
Sent: Monday, October 18, 2010 7:17 PM
To: 'Ram Mohan R (rmohanr)'; 'Elwell, John'; 'siprec issue tracker'; 'Ken Rehor (krehor)'
Cc: [email-masked]
Subject: Re: [siprec] #35: Clarification of REQ-029 on security

Thanks Ram,

Regards

Deepanshu Gautam
-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 2010年10月18日 20:20
To: Deepanshu; Elwell, John; siprec issue tracker; Ken Rehor (krehor)
Cc: [email-masked]
Subject: RE: [siprec] #35: Clarification of REQ-029 on security

Hi Deepanshu,
Please see inline <Ram>

-----Original Message-----

Thanks John

Inline with [DG]..

Regards

Deepanshu Gautam

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 2010年10月18日 15:36
To: Deepanshu; 'siprec issue tracker'; [email-masked]
Cc: [email-masked]
Subject: RE: [siprec] #35: Clarification of REQ-029 on security

> 3. The mechanism SHALL allow only authorized SRC/SRS to 
[DS] This is not Authentication, it is Authorization. Recommend separate section for it.  
 
[JRE] I am not sure this should be within scope. I assume by "user" you
means an authorised manager (as opposed to a user participating in CSs that
might be subject to recording).
[DS]  I believe #4 here is not required (probably it is part of the solution).  

[JRE] This is basically the metadata, which I believe is covered by other
requirements.
[DG] Yes it is, but the requirement here is to ensure the integrity of
Metadata.
[DS]  For consistency, I recommend to change #0 to "The mechanism Must provide a means to ensure the integrity of transmitted messages."
If you think #2 is important then I recommend to reword to : "The mechanism Must provide a means to ensure the integrity of metadata."  However, I am not so sure that this is in scope - once the metadata is received by the SRS what happens next is out of scope.   
 
[DS] I agree with this in principle, but I believe that this would naturally be available in the solution and that it would not be necessary to explicitly request it in the req'ts.  

[DS]  FYI - my input sent on another thread was to consider the following wording:  
Also, we need to decide if we want to have different sections for Confidentiality and Integrity, or not.  I think they are different things, so possibly we should provide them separately, but I am curious if the solutions for them are the same.  

Thanks,
Ram

John (as individual)

---

From: Deepanshu <[email-masked]>
Date: Tue, 19 Oct 2010 15:48:16 +0800

Inline with [**DG2**]

Deepanshu Gautam

-----Original Message-----
From: Dave Smith [mailto:[email-masked]] 
Sent: 2010年10月19日 13:21
To: Deepanshu; Ram Mohan R (rmohanr); Elwell, John; siprec issue tracker;
Ken Rehor (krehor)
Cc: [email-masked]

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Deepanshu
Sent: Monday, October 18, 2010 7:17 PM
To: 'Ram Mohan R (rmohanr)'; 'Elwell, John'; 'siprec issue tracker'; 'Ken
Rehor (krehor)'
Cc: [email-masked]
Subject: Re: [siprec] #35: Clarification of REQ-029 on security

Thanks Ram,

Regards

Deepanshu Gautam
-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 2010年10月18日 20:20
To: Deepanshu; Elwell, John; siprec issue tracker; Ken Rehor (krehor)
Cc: [email-masked]
Subject: RE: [siprec] #35: Clarification of REQ-029 on security

Hi Deepanshu,
Please see inline <Ram>

-----Original Message-----

Thanks John

Inline with [DG]..

Regards

Deepanshu Gautam

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 2010年10月18日 15:36
To: Deepanshu; 'siprec issue tracker'; [email-masked]
Cc: [email-masked]
Subject: RE: [siprec] #35: Clarification of REQ-029 on security

> 3. The mechanism SHALL allow only authorized SRC/SRS to 
[DS] This is not Authentication, it is Authorization. Recommend separate
section for it.  
[**DG2**] OK
 
[JRE] I am not sure this should be within scope. I assume by "user" you
means an authorised manager (as opposed to a user participating in CSs that
might be subject to recording).
[DS]  I believe #4 here is not required (probably it is part of the
solution).  
[**DG2**] I fine to give it up if everyone else like it to be.

[JRE] This is basically the metadata, which I believe is covered by other
requirements.
[DG] Yes it is, but the requirement here is to ensure the integrity of
Metadata.
[DS]  For consistency, I recommend to change #0 to "The mechanism Must
provide a means to ensure the integrity of transmitted messages."
[**DG2**] OK
If you think #2 is important then I recommend to reword to : "The mechanism
Must provide a means to ensure the integrity of metadata."  However, I am
not so sure that this is in scope - once the metadata is received by the SRS
what happens next is out of scope.   
[**DG2**] I think we can use what Ram suggested i.e "The mechanism SHALL
ensure the INTEGRITY and CONFIDENTIALITY of the Metadata and Media sent from
SRC to SRS"
 
[JRE] I don't think we want such a requirement. It can b e considered to be
in violation of privacy requirements, and in some jurisdictions it would be
illegal. Having said that, the notification need not necessarily be at the
time recording starts. For example, playing an announcement at the start of
a call saying that calls may be recorded will be sufficient in some
jurisdictions.
[DG] As for requirement it doesn't says that this has to be done, so it is
not a violation. It says: it SHALL be possible. In other words our solution
MUST not preclude it. There *is* a requirement to establish an RS without
notifying CS participants (e.g agent performance monitoring system) and it
is NOT illegal. The mechanism MUST allow this; if it is illegal in some
jurisdictions then it should not be implemented. If someone does, they are
on their own.
I can further suggest the following re-wording
"It SHALL be possible to establish an RS without notifying the CS
participants"
[DS] I agree with this in principle, but I believe that this would naturally
be available in the solution and that it would not be necessary to
explicitly request it in the req'ts.
[**DG2**] I think if we agree on the concept itself then its better to call
it out as a requirement to avoid doing something (as a part of solution)
which will preclude it i.e having SRC always including 'recorded' feature
tag in the RS initiation requests.

[JRE] I don't see the relevance of this. The CS will negotiate keys in a
confidential manner independently of SIPREC, and there should be no need for
disclosure of those keys to the SRS. What is more important is to preserve
the confidentiality of the keys used in the RS (which, in the case of shared
keys, if we allow this - see separate email thread - would also be the keys
used in the CS). But I don't think confidentiality of keys used in the RS
needs bringing out as a separate requirement. In order to meet a requirement
that recorded data and metadata be confidentiality protected, it is clearly
necessary to ensure that the keys are not disclosed.
[DG] Okay then lets have a requirement on recorded data and metadata be
conf. protected. Do we already have one? If not, what about the following
"The mechanism SHALL ensure the confidentiality of the Recorded Media and
Metadata"
<Ram> I am not sure if the wording is correct. I agree we need to ensure the
INTEGRITY and CONFIDENTIALITY of the Recorded Media and Metadata that is
sent from SRC to SRS. once the information is received at SRS, it is up to
SRS on how he stores and ensures the confidentiality of the stored
data/metadata. 
Probably we can re-word as "The mechanism SHALL ensure the INTEGRITY and
CONFIDENTIALITY of the Metadata and Media sent from SRC to SRS" ?
[DS]  FYI - my input sent on another thread was to consider the following
wording:  
X.3 CONFIDENTIALITY
3.  The mechanism MUST support optional functionality to secure
transmissions between SRC and SRS (e.g., via SRTP).  
Also, we need to decide if we want to have different sections for
Confidentiality and Integrity, or not.  I think they are different things,
so possibly we should provide them separately, but I am curious if the
solutions for them are the same.  
[**DG2**] I think its ok to have integrity and confidentiality separately
even if the solution is same. A solution can take care of several
requirements :-)

Thanks,
Ram

John (as individual)

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Thu, 28 Oct 2010 01:28:25 -0700

Based on discussion on the mailing list, in draft-ietf-siprec-req-04 I've made the following changes:

Added new requirements sections SECURITY, AUTHENTICATION, AUTHORIZATION, INTEGRITY, and CONFIDENTIALITY, and moved and added new relevant requirements to those sections.

Corrections will be made in the forthcoming draft-ietf-siprec-req-05 to address additional comments.

Ken

> Sent: Tuesday, October 19, 2010 12:48 AM
> To: 'Dave Smith'; Ram Mohan R (rmohanr); 'Elwell, John'; 'siprec issue
> tracker'; Ken Rehor (krehor)
> Cc: [email-masked]

---

From: "siprec issue tracker" <[email-masked]>
Date: Thu, 28 Oct 2010 08:30:31 -0000

Comment(by krehor@…):

 Based on discussion on the mailing list, in draft-ietf-siprec-req-04 I've
 made the following changes:

 Added new requirements sections SECURITY, AUTHENTICATION, AUTHORIZATION,
 INTEGRITY, and CONFIDENTIALITY, and moved and added new relevant
 requirements to those sections.

 Corrections will be made in the forthcoming draft-ietf-siprec-req-05 to
 address additional comments.

 Ken

-- 
------------------------------------------------+---------------------------
 Reporter:  john.elwell@…                       |       Owner:  krehor@…        
     Type:  defect                              |      Status:  assigned        
 Priority:  major                               |   Milestone:                  
Component:  Requirements                        |     Version:                  
 Severity:  Active WG Document                  |    Keywords:                  
------------------------------------------------+---------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/35#comment:2>
siprec <http://tools.ietf.org/siprec/>