Subject: [siprec] Keying requirements

From: "Elwell, John" <[email-masked]>
Date: Wed, 13 Oct 2010 18:53:06 +0200

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)

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 13 Oct 2010 10:01:54 -0700

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

---

From: Leon Portman <[email-masked]>
Date: Wed, 13 Oct 2010 19:52:08 +0200

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,

Henry

key
decrypt

---

From: "Dave Smith" <[email-masked]>
Date: Wed, 13 Oct 2010 11:49:56 -0700

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,

Henry

key
decrypt
> undesirable impact on the CS as a consequence of recording).

------------------------------------------------------------------------
-------------------------------------------
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: Wed, 13 Oct 2010 21:39:59 +0200

Sorry, got the REQs the wrong way round. I have a problem with REQ-031.

John 

> From: Dave Smith [mailto:[email-masked]] 
> Sent: 13 October 2010 19:50
> To: Leon Portman; Henry Lum; Elwell, John; [email-masked]
> Subject: RE: [siprec] Keying requirements
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Leon Portman
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Henry Lum
> --------------------------------------------------------------
> -----------------------------------------------------
> 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: Wed, 13 Oct 2010 21:45:31 +0200

> because they can only replicate RTP packets and not create a new ones
[JRE] If SBCs cannot decrypt, this implies sending the SRTP packet unchanged to the SRS. This implies using the same SSRC value too. I am not sure whether there is anything wrong with that. My main concern, however, is what happens when recording is paused? How can the SBC force the CS endpoints to rekey?

John (as individual)

> ----------
> person, use it

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 13 Oct 2010 13:12:52 -0700

> [JRE] If SBCs cannot decrypt, this implies sending the SRTP packet
> unchanged to the SRS. This implies using the same SSRC value too. I am
> not sure whether there is anything wrong with that. My main concern,
> however, is what happens when recording is paused? How can the SBC
> force the CS endpoints to rekey?

[[hlum]] As a follow up to John's comment, assuming that rogue SRS is
not an issue and we reuse the same key for the RS. When a pause happens,
the SRS would have an out-of-date view of the packet index since the
actual CS is still generating encrypted packets. When you resume, the
replicated media on the RS may have rolled over the packet index and SRS
may get confused with the index. I think SRS can probably figure this
out since pause/resume is normally fairly short (normally lasting only a
sensitive field) but it's still a possibility that a long pause may
confuse the SRS. We may end up requiring the CS to rekey when a pause
happens which can be undesirable.

Henry

---

From: Leon Portman <[email-masked]>
Date: Wed, 13 Oct 2010 22:22:48 +0200

It is relatively easy to guess the index, we are doing it all the time with passive sniffing.

Leon

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Oct 2010 09:47:46 +0200

Leon,

Not sure what you mean here about guessing the index. I think the index is available from the received RTP packet, but the problem is the Roll Over Count (ROC). I don't think we can assume that pauses will be short (as Henry suggests), so there is the possibility that the ROC after resume will differ from the ROC prior to pause. If Security Descriptions is used for key management, there is no way of conveying the new ROC. Guessing is not very satisfactory, since it could have been incremented more than once during a long pause. With 10ms packet times and no gaps due to silence, the ROC will be incremented every 655 seconds, or 11 minutes, so long pauses would certainly be subject to roll-over. Moreover, you could start recording late during a CS, and again there is no way using Security Descriptions of signalling a non-zero ROC when establishing the RS.

Another issue is the so-called persistent recording, where the RS remains in existence for multiple CSs. I guess with this you would still need to do an offer-answer to establish the key (and implicitly set ROC to 0) each time a new CS starts. This would to a large extent defeat the object of persistent recording, which is supposed to eliminate delays in establishing the RS.

Another issue is how to communicate the SRTP master key used on the CS to the SRS. This seems to be fairly easy with Security Descriptions, but what about other mechanism standardized by the IETF? With DTLS-SRTP, I think we would need to establish a separate key for the RS, and then, if we want to use the same key as the CS, use the EKT extensions currently being developed in AVT. I think MIKEY in its various forms would also require EKT.

Use of the same key certainly has benefits in some contexts. I am thinking here of switched (as opposed to mixed) conferences, where media are forwarded to the different participants without decrypting, mixing and re-encrypting. Rekeying is used whenever somebody enters or leaves the conference, so that someone evicted from the conference, for example, cannot listen in to the ongoing conference. An SRS could be just one member of such a conference. However, I think this scenario should be left for a later phase, e.g., when EKT is finished.

Add these issues to the one I already mentioned about having to rekey the CS after RS pause/resume, and I think we end up with a number of constraints or additional requirements associated with REQ-031 (use of same keys). We can try to add these into the requirements document or, for the sake of limiting the scope to something easily achievable, it would be preferable to drop REQ-031 from the initial deliverables.

John

> From: Leon Portman [mailto:[email-masked]] 
> Sent: 13 October 2010 21:23
> To: Henry Lum
> Cc: Elwell, John; Dave Smith; Leon Portman; <[email-masked]>

---

From: Leon Portman <[email-masked]>
Date: Thu, 14 Oct 2010 17:34:51 +0200

John, 

Yes, I meant ROC and not index. My point was that ROC can be guessed by brute force just by trying.
Regarding DTLS_SRTP, we had some discussion about it as well. The main problem here actually that it is take too long to establish the session because of two phases of the key interchange.

I agree that we should remove REQ-31. Hadriel was the main drive for this requirement. I put him on this email to respond.

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Thursday, October 14, 2010 9:48 AM
To: Leon Portman; Henry Lum
Cc: Dave Smith; <[email-masked]>; Leon Portman
Subject: Re: [siprec] Keying requirements

Leon,

John

---

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

Removed REQ-031 but kept REQ-032 in draft-ietf-siprec-req-04 as per
discussion on mailing list and for tracker ticket #47.

Ken

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Leon Portman
> Sent: Thursday, October 14, 2010 8:35 AM
> To: Elwell, John; Leon Portman; Henry Lum; HadrielKaplan
> Cc: Dave Smith; <[email-masked]>
> Yes, I meant ROC and not index. My point was that ROC can be guessed
by brute
> force just by trying.
> Regarding DTLS_SRTP, we had some discussion about it as well. The main
problem
> here actually that it is take too long to establish the session
because of two
> phases of the key interchange.
> 
> I agree that we should remove REQ-31. Hadriel was the main drive for
this
> requirement. I put him on this email to respond.
> 
> Regards
> 
> Leon
> 
Behalf Of
> Elwell, John
> Not sure what you mean here about guessing the index. I think the
index is
> available from the received RTP packet, but the problem is the Roll
Over Count
> (ROC). I don't think we can assume that pauses will be short (as Henry
> suggests), so there is the possibility that the ROC after resume will
differ
> from the ROC prior to pause. If Security Descriptions is used for key
> management, there is no way of conveying the new ROC. Guessing is not
very
> satisfactory, since it could have been incremented more than once
during a
> long pause. With 10ms packet times and no gaps due to silence, the ROC
will be
> incremented every 655 seconds, or 11 minutes, so long pauses would
certainly
> be subject to roll-over. Moreover, you could start recording late
during a CS,
> and again there is no way using Security Descriptions of signalling a
non-zero
> ROC when establishing the RS.
> 
> Another issue is the so-called persistent recording, where the RS
remains in
> existence for multiple CSs. I guess with this you would still need to
do an
> offer-answer to establish the key (and implicitly set ROC to 0) each
time a
> new CS starts. This would to a large extent defeat the object of
persistent
> recording, which is supposed to eliminate delays in establishing the
RS.
> 
> Another issue is how to communicate the SRTP master key used on the CS
to the
> SRS. This seems to be fairly easy with Security Descriptions, but what
about
> other mechanism standardized by the IETF? With DTLS-SRTP, I think we
would
> need to establish a separate key for the RS, and then, if we want to
use the
> same key as the CS, use the EKT extensions currently being developed
in AVT. I
> think MIKEY in its various forms would also require EKT.
> 
> Use of the same key certainly has benefits in some contexts. I am
thinking
> here of switched (as opposed to mixed) conferences, where media are
forwarded
> to the different participants without decrypting, mixing and
re-encrypting.
> Rekeying is used whenever somebody enters or leaves the conference, so
that
> someone evicted from the conference, for example, cannot listen in to
the
> ongoing conference. An SRS could be just one member of such a
conference.
> However, I think this scenario should be left for a later phase, e.g.,
when
> EKT is finished.
> 
> Add these issues to the one I already mentioned about having to rekey
the CS
> after RS pause/resume, and I think we end up with a number of
constraints or
> additional requirements associated with REQ-031 (use of same keys). We
can try
> to add these into the requirements document or, for the sake of
limiting the
> scope to something easily achievable, it would be preferable to drop
REQ-031
> from the initial deliverables.
> 
> John
> 
> > >>> Actually, it is exactly the issue that I raised in another
thread
> > >> with