Subject: [siprec] Updated architecture draft

From: Leon Portman <[email-masked]>
Date: Wed, 5 Sep 2012 19:27:09 +0300

Hello

Please see attached updated architecture draft with revised security section and fixes from IETF 84 meetings.

The new section is as follows. Please comment and i will submit:

5.  Security considerations

   The Recording Session is fundamentally a standard SIP dialog and
   media session and therefore makes use of existing SIP security
   mechanisms for securing the Recording Session and Recording Metadata.

   The intended use of this architecture is only for the case where the
   users are aware that they are being recorded, and the architecture
   provides the means for the Session Recording Client to notify users
   that they are being recorded.

   This architectural solution is not intended to support lawful
   intercept which in contrast requires that users are not informed.

   It is the responsibility of the Session Recording Server to protect
   the Replicated Media and Recording Metadata once it has been received
   and archived.

   Protection of the RS should be not weaker than protection of the CS,
   and may need to be stronger because the media is retransmitted
   (allowing more possibility for interception), stored (allowing
   malicious attack on the storage system) and retrievable (through the
   recorder's authorized retrieval interface).  This applies to both the
   signaling and media paths.

   It is essential that the SRC will authenticate the SRS because the
   client must be certain that it is recording on the right recording
   system.  It is less important that the SRS authenticate the SRC, but
   implementations must have the ability to perform mutual
   authentication.

   In some environments, it is desirable to not decrypt and re-encrypt
   the media.  This means the same key is used on the CS and RS.  This
   only works when the media is encrypted, not the transport.  That has
   implications on mandatory to implement keying mechanisms.  When the
   media must be decrypted on the CS, and is re-encrypted on the RS, a
   new key must be used.

   The retrieval mechanism for media recorded by this protocol is out of
   scope.  Implementations of retrieval mechanisms should consider the
   security implications carefully as the retriever is not usually a
   party to the call that was recorded.  Retrievers should be
   authenticated carefully.  The crypto suites on the retrieval should
   be no less strong than used on the RS, and may need to be stronger.

Leon

---

From: Leon Portman <[email-masked]>
Date: Thu, 6 Sep 2012 15:59:36 +0300

There was problem with attachment. Some have it got embedded at the top of the document.
Please see below for updated security section.

Leon

On Sep 5, 2012, at 7:27 PM, Leon Portman <[email-masked]> wrote:

> Hello<draft-ietf-siprec-architecture-06.txt>
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 7 Sep 2012 06:30:23 +0000

Hi Leon,

Please see inline for my comments. Most of the text look good. A few minor
nits below

> On 05/09/12 9:57 PM, "Leon Portman" <[email-masked]> wrote:

>   signaling and media paths.

Is it required to have text on storage/retrieval here ? Since we have
mentioned storage and retrieval is out of scope I feel its better not have
much text around the same.

>   only works when the media is encrypted, not the transport.

<snip>
>That has
</snip>
Is this statement needed in this document ? We seem to talk about specific
use-case here(decryption and re-encryption). Would it better to move this
to protocol  document ?

>   be no less strong than used on the RS, and may need to be stronger.

Again this paragraph talks mostly about retrieval and storage which is
outside the scope of SIPREC work. It would be better to remove them.

Regards,
Ram

>
>
>
>Leon
>
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec
>
>
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 7 Sep 2012 10:48:07 +0000

Hi Leon,

I added some comments to Ram's below.

Also during IETF84 we agreed one of the bullets in the SRS initiated flow to "Identify the session that is to be recorded.  The actual mechanism of the identification can be dependent on SRC policy or be defined by future SIPREC extensions".

Have you made other changes other than the security considerations section?

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ram Mohan R (rmohanr)
> Sent: 07 September 2012 07:30
> To: Leon Portman; [email-masked]
> Cc: Brian Rosen
> Subject: Re: [siprec] Updated architecture draft
> 
> Hi Leon,
> 

[AndyH] - I would add that mechanism for protecting the storage and retrieval from the SRS is out of scope of this work.

> much text around the same.

[AndyH] I agree with Ram and don't think protection of the RS has any impact on vulnerabilities due to the storing or retrieving of media from the RS. Therefore I think we can do without the text "stored (allowing malicious attack on the storage system) and retrievable (through the recorder's authorized retrieval interface)".

> use-case here(decryption and re-encryption). Would it better to move

[AndyH] Could we do without the statement "That has implications on mandatory to implement keying mechanisms"? I don't see why we need it. But I think we need to keep the second sentence regarding using a new key if re-encrypting.

> outside the scope of SIPREC work. It would be better to remove them.

[AndyH] Brian requested this paragraph just as guidance for implementers of and RS and because he thought the IESG would ask for this so I am happy to keep it.

---

From: Leon Portman <[email-masked]>
Date: Fri, 7 Sep 2012 14:56:23 +0300

Andy, Ram and Partha, 

Thank you very much for the comments.
The updated text is as follows:

"5.  Security considerations

   It is the responsibility of the Session Recording Server to protect
   the Replicated Media and Recording Metadata once it has been received
   and archived.  The mechanism for protecting the storage and retrieval
   from the SRS is out of scope of this work.

   Protection of the RS should be not weaker than protection of the CS,
   and may need to be stronger because the media is retransmitted
   (allowing more possibility for interception).  This applies to both
   the signaling and media paths.

   In some environments, it is desirable to not decrypt and re-encrypt
   the media.  This means the same key is used on the CS and RS.  This
   only works when the media is encrypted, not the transport.  When the
   media must be decrypted on the CS, and is re-encrypted on the RS, a
   new key must be used.

   be no less strong than used on the RS, and may need to be stronger."

I have also updated SRS-initiated flow section - based on Paul comment, adding plurality to session.

Regards

Leon

On Sep 7, 2012, at 1:48 PM, "Hutton, Andrew" <[email-masked]> wrote:

> mechanism for protecting the storage and retrieval from the SRS is out of scope of this work

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 7 Sep 2012 21:40:28 +0530

Leon,

The security consideration text looks good.

Thanks

Partha

From: Leon Portman [mailto:[email-masked]] 
Sent: Friday, September 07, 2012 5:26 PM
To: Andrew Hutton; Ram Mohan R (rmohanr); Parthasarathi R
Cc: [email-masked]; Brian Rosen
Subject: Re: [siprec] Updated architecture draft

Andy, Ram and Partha, 

   authentication.

   new key must be used.

I have also updated SRS-initiated flow section - based on Paul comment,
adding plurality to session.

Regards

Leon

On Sep 7, 2012, at 1:48 PM, "Hutton, Andrew"
<[email-masked]> wrote:

mechanism for protecting the storage and retrieval from the SRS is out of
scope of this work

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 7 Sep 2012 16:37:46 +0000

> On 07/09/12 4:18 PM, "Hutton, Andrew"

>>of
>[AndyH] Brian requested this paragraph just as guidance for implementers
>of and RS and because he thought the IESG would ask for this so I am
>happy to keep it

Ok Fine. We can leave this text here for now.

Thanks,
Ram

>.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 7 Sep 2012 17:17:27 +0000

This text looks good for me.

Thanks,
Ram

> On 07/09/12 5:26 PM, "Leon Portman" <[email-masked]> wrote:

>Andy, Ram and Partha,
>
>Thank you very much for the comments.The updated text is as follows:
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 13 Sep 2012 00:40:50 +0000

Hi Leon,

Overall the changes look very good. My only concern is in regard to the following paragraph.

More specifically, the sentence, " This only works when the media is encrypted, not the transport", does not work well for me. Can you explain the intent a bit more? It is not that I disagree, but rather that I do not understand what it is saying.

Thanks,
Charles

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Leon Portman
> Sent: Friday, September 07, 2012 4:56 AM

---

From: Dave Higton <[email-masked]>
Date: Thu, 13 Sep 2012 08:45:01 +0100

... and anyway, media are plural!

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: 13 September 2012 01:41
To: Leon Portman; Andrew Hutton; Ram Mohan R (rmohanr); Parthasarathi R
Cc: [email-masked]; Brian Rosen
Subject: Re: [siprec] Updated architecture draft

Hi Leon,

Thanks,
Charles

> Behalf Of Leon Portman

---

From: Leon Portman <[email-masked]>
Date: Thu, 13 Sep 2012 10:59:21 +0300

Thanks for the catch.

Regarding transport vs media level encryption, I think the point was to note that if transport level encryption is used (like TLS) for the media, you need to decrypt the traffic.

Leon

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 14 Sep 2012 16:11:34 +0000

Hi Leon,

I do not think what you describe as transport level encryption of the media is something we have defined or recommended within the context of SIPREC, so I think addressing it in the architecture draft is not worthwhile. I suggest the following replacement text.

In some environments, it is desirable to not decrypt and re-encrypt the media.  This means the same media encryption key is negotiated and used within the CS and RS.  If for any reason the media is decrypted on the CS, and is re-encrypted on the RS, a new key must be used.

Cheers,
Charles

> Sent: Thursday, September 13, 2012 12:59 AM
> To: Dave Higton; Charles Eckel (eckelcu)
> Cc: Andrew Hutton; Ram Mohan R (rmohanr); Parthasarathi R;
> [email-masked]; Brian Rosen
> Regarding transport vs media level encryption, I think the point was to note
> that if transport level encryption is used (like TLS) for the media, you need
> to decrypt the traffic.
> 
> Leon
> 
> Behalf Of Charles Eckel (eckelcu)
> > More specifically, the sentence, " This only works when the media is
> encrypted, not the transport", does not work well for me. Can you explain
> the intent a bit more? It is not that I disagree, but rather that I do not
> understand what it is saying.
> >
> > Thanks,
> > Charles
> >

---

From: Leon Portman <[email-masked]>
Date: Fri, 14 Sep 2012 19:39:54 +0300

Charles,  thanks

Looking good for me

Leon
On Sep 14, 2012 7:11 PM, "Charles Eckel (eckelcu)" <[email-masked]>
wrote:

> Hi Leon,
>
> I do not think what you describe as transport level encryption of the
> media is something we have defined or recommended within the context of
> SIPREC, so I think addressing it in the architecture draft is not
> worthwhile. I suggest the following replacement text.
>
> In some environments, it is desirable to not decrypt and re-encrypt the
> media.  This means the same media encryption key is negotiated and used
> within the CS and RS.  If for any reason the media is decrypted on the CS,
> and is re-encrypted on the RS, a new key must be used.
>
> Cheers,
> Charles
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 17 Sep 2012 12:25:16 +0000

The text suggested by Charles below looks good to me.

Regards
Andy

From: Leon Portman [mailto:[email-masked]]
Sent: 14 September 2012 17:40
To: Charles Eckel (eckelcu)
Cc: Dave Higton; [email-masked]; Parthasarathi R; Brian Rosen; Ram Mohan R (rmohanr); Hutton, Andrew
Subject: RE: [siprec] Updated architecture draft

Charles,  thanks

Looking good for me

Leon
On Sep 14, 2012 7:11 PM, "Charles Eckel (eckelcu)" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Leon,

Cheers,
Charles

> From: Leon Portman [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: Thursday, September 13, 2012<tel:2012> 12:59 AM
> [email-masked]<mailto:[email-masked]>; Brian Rosen
> On Sep 13, 2012<tel:2012>, at 10:45 AM, Dave Higton <[email-masked]<mailto:[email-masked]>>
> wrote:
>
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> > Sent: 13 September 2012<tel:2012> 01:41
> > Cc: [email-masked]<mailto:[email-masked]>; Brian Rosen
> >> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> >> Behalf Of Leon Portman
> >> Sent: Friday, September 07, 2012<tel:2012> 4:56 AM
> >> Cc: [email-masked]<mailto:[email-masked]>; Brian Rosen
> >> On Sep 7, 2012<tel:2012>, at 1:48 PM, "Hutton, Andrew" <andrew.hutton@siemens-
<mailto:andrew.hutton@siemens-%0b>> >> enterprise.com<http://enterprise.com>> wrote:
> > [email-masked]<mailto:[email-masked]>

---

From: Dave Higton <[email-masked]>
Date: Mon, 17 Sep 2012 14:24:52 +0100

One little detail: media are plural, so one sentence needs two changes:

"If for any reason the media are decrypted on the CS, and are re-encrypted on the RS, a new key must be used."

Dave

From: Hutton, Andrew [mailto:[email-masked]]
Sent: 17 September 2012 13:25
To: Leon Portman; Charles Eckel (eckelcu)
Cc: Dave Higton; [email-masked]; Parthasarathi R; Brian Rosen; Ram Mohan R (rmohanr)
Subject: RE: [siprec] Updated architecture draft

Regards
Andy

From: Leon Portman [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: 14 September 2012 17:40
To: Charles Eckel (eckelcu)
Cc: Dave Higton; [email-masked]<mailto:[email-masked]>; Parthasarathi R; Brian Rosen; Ram Mohan R (rmohanr); Hutton, Andrew
Subject: RE: [siprec] Updated architecture draft

Charles,  thanks

Looking good for me

Leon

Cheers,
Charles