Subject: Re: [siprec] Keying requirements

From: Leon Portman <[email-masked]>
Date: Wed, 13 Oct 2010 20:55:58 +0200

Yes, Dave, you are right. It is about key escrowing. May be we should not mention it at all? Anyway we will use standard key interchange mechanism. It will not have any impact on the protocol if original keys will be used or new ones. Or we should add it to security section as must (REQ-32 of course)?  But then it will really limit implementation options

Leon

----- Original Message -----
From: Dave Smith <[email-masked]>
To: Leon Portman; Henry Lum <[email-masked]>; Elwell, John <[email-masked]>; [email-masked] <[email-masked]>
Sent: Wed Oct 13 20:49:56 2010
Subject: RE: [siprec] Keying requirements

Thinking back nearly a year on this discussion, we were enlightened as
to why we needed REQ-032, and REQ-031 activity was forbidden in general
security practice.
Is that no longer the case?

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Leon Portman
Sent: Wednesday, October 13, 2010 10:52 AM
To: Henry Lum; Elwell, John; [email-masked]
Subject: Re: [siprec] Keying requirements

Actually, it is exactly the issue that I raised in another thread with
Cullen. The subject was "Keying of recording session", 
On September,30 

The main reason that we also have REQ-31, that for example SBCs
sometimes cannot decrypt and encrypt again with different set of keys
because they can only replicate RTP packets and not create a new ones

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henry Lum
Sent: Wednesday, October 13, 2010 7:02 PM
To: Elwell, John; [email-masked]
Subject: Re: [siprec] Keying requirements

Hi John,

I am a little confused about the requirement numbers; I think your
concern would be on REQ-031 and not REQ-032, right?

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: Wednesday, October 13, 2010 12:53 PM
> To: [email-masked]
> Subject: [siprec] Keying requirements
> 
> Req-03 states:
> "  o REQ-031 If the Communication Session is encrypted, the Recording
>    Session MUST be able to use the same keys.
> 
>    o REQ-032 If the Communication Session is encrypted, the Recording
>    Session MUST be able to use different keys."
> 
> REQ-031 makes sense. I have a concern with REQ-032.
> 
> We also have a requirement for pausing and resuming recording.
> Presumably it would be paused when information is exchanged on the
> communication session that for some reason must not be recorded.
> However, the SRS will have the key used by the CS during the time that
> recording is paused, so a rogue SRS (or somebody with access to the
key
> the SRS is using) could capture packets from the ongoing CS and
decrypt
> them. So REQ-032 would imply that, if we are to use the same key,
> either we would have to deny pause (e.g., in an environment where ALL
> CSs must be recorded) or we have to cause the CS to rekey at the time
> of pause and rekey again at the time of resume (which I think is an
> undesirable impact on the CS as a consequence of recording).
> 
> John (as individual)
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

------------------------------------------------------------------------
-------------------------------------------
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.
					
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

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