Subject: [siprec] Suggestions for text in the Architecture doc security section

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 2 Aug 2012 18:48:26 -0400

In today's siprec meeting we discussed security, mostly in the context of the protocol document.  Looking at the ARCHITECTURE document's security section, I find it way too weak.  I suggest we add:

1. Protection of the RS should be no worse than protection of the CS, and may need to be better 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.  Cryptosuites, and protocol mechanisms must be considered.  
2. It is essential that the SRC 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
3. 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.  It implies that the keying mechanism is the same on the CS as the RS.  That has implications on mandatory to implement keying mechanisms
4. When the media must be decrypted on the CS, and is re-encrypted on the RS, a new key must be used
5. The document doesn't discuss a retrieval mechanism for recorded media.  The security implications on retrieval are similar to those of recording, but because the retriever is another party to the recording session, item 2 is reversed - the client must be authenticated.  The crypto must be no less strong than that on the RS, and may need to be better.

Brian

---

From: Leon Portman <[email-masked]>
Date: Tue, 7 Aug 2012 11:51:31 +0300

Brian, Thank you 

I will update the architecture draft.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Friday, August 03, 2012 1:48 AM
To: [email-masked]
Subject: [siprec] Suggestions for text in the Architecture doc security section

1. Protection of the RS should be no worse than protection of the CS, and may need to be better 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.  Cryptosuites, and protocol mechanisms must be considered.  
2. It is essential that the SRC 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 3. 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.  It implies that the keying mechanism is the same on the CS as the RS.  That has implications on mandatory to implement keying mechanisms 4. When the media must be decrypted on the CS, and is re-encrypted on the RS, a new key must be used 5. The document doesn't discuss a retrieval mechanism for recorded media.  The security implications on retrieval are similar to those of recording, but because the retriever is another party to the recording session, item 2 is reversed - the client must be authenticated.  The crypto must be no less strong than that on the RS, and may need to be better.

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Aug 2012 09:08:48 -0400

In discussions, some folks felt we should be more explicit that the retrieval is out of scope.  Maybe reword 
> The document doesn't discuss a retrieval mechanism for recorded media.  The security implications on retrieval are similar to those of recording, but because the retriever is another party to the recording session, item 2 is reversed - the client must be authenticated.  The cry
> pto must be no less strong than that on the RS, and may need to be better.
to
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 reverse of item 2 above).  The crypto on the retrieval should be no less strong than used on the RS, and may need to be better.

On Aug 7, 2012, at 4:51 AM, Leon Portman wrote:

> 2. It is essential that the SRC 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 3. 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.  It implies that the keying mechanism is the same on the CS as the RS.  That has implications on mandatory to implement keying mechanisms 4. When the media must be decrypted on the CS, and is re-encrypted on the RS, a new key must be used 5. The document doesn't discuss a retrieval mechanism for recorded media.  The security implications on retrieval are similar to those of recording, but because the retriever is another party to the recording session, item 2 is reversed - the client must be authenticated.  The cry
> pto must be no less strong than that on the RS, and may need to be better.
> 
> Brian

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 8 Aug 2012 03:57:55 +0000

Hi Brian,

I am in favor of that working of the suggested text. Please see inline for additional comments.

> Sent: Tuesday, August 07, 2012 6:09 AM
> To: Leon Portman
> Cc: [email-masked]
> Subject: Re: [siprec] Suggestions for text in the Architecture doc security
> section
> 
> > The document doesn't discuss a retrieval mechanism for recorded media.
> The security implications on retrieval are similar to those of recording, but
> because the retriever is another party to the recording session, item 2 is
> reversed - the client must be authenticated.  The cry
> 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 reverse of
> item 2 above).  The crypto on the retrieval should be no less strong than
> used on the RS, and may need to be better.
> 
> 
> > In today's siprec meeting we discussed security, mostly in the context of
> the protocol document.  Looking at the ARCHITECTURE document's security
> section, I find it way too weak.  I suggest we add:
> >
> > 1. Protection of the RS should be no worse than protection of the CS, and
> may need to be better 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.
> Cryptosuites, and protocol mechanisms must be considered.
> > 2. It is essential that the SRC 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 3. 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.  It implies that the keying mechanism is the
> same on the CS as the RS.

I do not believe this is true. For example, if EKT is used in the RS, it could be interworked with SDES in the CS. In such a case, the key could be the same despite the keying mechanism being different, with the SRC providing the interworking between the keying mechanisms.
For this reason, we may want to recommend support for EKT by the SRC and SRS. This recommendation would be added to the protocol draft.

Cheers,
Charles

> That has implications on mandatory to implement
> keying mechanisms 4. When the media must be decrypted on the CS, and is
> re-encrypted on the RS, a new key must be used 5. The document doesn't
> discuss a retrieval mechanism for recorded media.  The security implications
> on retrieval are similar to those of recording, but because the retriever is
> another party to the recording session, item 2 is reversed - the client must
> be authenticated.  The c
>  ry

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 8 Aug 2012 12:49:38 +0000

Hi,

I am also in favor of the latest suggested text from Brian which makes it clear that the retrieval of recordings is not within scope of SIPREC.

I don't understand the argument that we should recommend EKT on the RS and really hope we can avoid such a statement. I think the conclusion from our session at IETF84 was that we should carefully craft the security section of the architecture and protocol specs to avoid making specific recommendations regarding the keying mechanism however we would for example need to make some statements such as stating that TLS must be used for SIP if SDES is deployed.

Regards
Andy (As an individual).

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Charles Eckel (eckelcu)
> Sent: 08 August 2012 04:58
> To: Rosen, Brian; Leon Portman
> Cc: [email-masked]
> Subject: Re: [siprec] Suggestions for text in the Architecture doc
> security section
> 
> Hi Brian,
> 
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Rosen, Brian
> > In discussions, some folks felt we should be more explicit that the
> retrieval
> > is out of scope.  Maybe reword
> > > Subject: [siprec] Suggestions for text in the Architecture doc
> security
> > section
> > >
> I do not believe this is true. For example, if EKT is used in the RS,
> it could be interworked with SDES in the CS. In such a case, the key
> could be the same despite the keying mechanism being different, with
> the SRC providing the interworking between the keying mechanisms.
> For this reason, we may want to recommend support for EKT by the SRC
> and SRS. This recommendation would be added to the protocol draft.
> 
> Cheers,
> Charles
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 8 Aug 2012 15:29:57 +0000

A comment on my own comment below.

Regards
Andy

> Behalf Of Hutton, Andrew
> Sent: 08 August 2012 13:50
> To: Charles Eckel (eckelcu); Rosen, Brian; Leon Portman;
> [email-masked]
> I am also in favor of the latest suggested text from Brian which makes
> it clear that the retrieval of recordings is not within scope of
> SIPREC.
> 
> I don't understand the argument that we should recommend EKT on the RS
> and really hope we can avoid such a statement. I think the conclusion
> from our session at IETF84 was that we should carefully craft the
> security section of the architecture and protocol specs to avoid making
> specific recommendations regarding the keying mechanism however we
> would for example need to make some statements such as stating that TLS
> must be used for SIP if SDES is deployed.

[AndyH] - Having just been through the notes and the meetecho video then I have to say we did not conclude that we should avoid specific recommendations the only conclusion was that we need to do so work on crafting the security considerations in both the protocol and architecture spec and that more discussion is needed on the list.

> > I am in favor of that working of the suggested text. Please see
> inline
> > for additional comments.
> >
> > > because the retriever is another party to the recording session,
> item
> > 2 is
> > > > pto must be no less strong than that on the RS, and may need to
> be
> > better.
> > > to
> > > The retrieval mechanism for media recorded by this protocol is out
> of
> > scope.
> > > implications carefully as the retriever is not usually a party to
> the
> > call that
> > > item 2 above).  The crypto on the retrieval should be no less
> strong
> > than
> > > Behalf Of Rosen, Brian
> > > be certain that it is recording on the right recording system.  It
> is
> > less
> > > it is desirable to not decrypt and re-encrypt the media.  This
> means
> > the
> > > keying mechanisms 4. When the media must be decrypted on the CS,
> and
> > is
> > > > pto must be no less strong than that on the RS, and may need to
> be
> > better.
> > > >
> > > > Brian

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 8 Aug 2012 15:57:45 +0000

Hi Andy,

Let me try to clarify. The part of the suggested text that I see as problematic is the following:

" 3. 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.  It implies that the keying mechanism is the same on the CS as the RS.  That has implications on mandatory to implement keying mechanisms."

The point I was trying to make was that using the same key in the CS as in the RS does NOT imply that the keying mechanism is the same on the CS as the RS. An example of such as case is a SRC using SDES in the CS and EKT in the RS. 
With that in mind, I think it would be useful to add a description of this to the security section of the protocol draft along, possibly with a recommendation for EKT support by at least the SRC and potentially for recording aware UAs and the SRS as well. In this case,  support for media encryption using SRTP with SDES may be required for recording-aware UAs, the SRC and the SRS, and DTLS/SRTP with EKT may be recommended. Any such requirements/recommendation would be in the protocol draft, not the architecture. Interworking with RTCWEB is one case in which support for EKT in the SRC would be useful. Interworking with a SIPREC aware conference server that supports EKT is another.

Cheers,
Charles

> From: Hutton, Andrew [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2012 5:50 AM
> To: Charles Eckel (eckelcu); Rosen, Brian; Leon Portman; [email-masked]
> Subject: RE: [siprec] Suggestions for text in the Architecture doc security
> section
> 
> Hi,
> 
> I am also in favor of the latest suggested text from Brian which makes it
> clear that the retrieval of recordings is not within scope of SIPREC.
> 
> and really hope we can avoid such a statement. I think the conclusion from
> our session at IETF84 was that we should carefully craft the security section
> of the architecture and protocol specs to avoid making specific
> recommendations regarding the keying mechanism however we would for
> example need to make some statements such as stating that TLS must be
> used for SIP if SDES is deployed.
> 
> Regards
> Andy (As an individual).
> 
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Aug 2012 09:26:41 -0700

I don't think we need to *recommend* that the SRC/SRC implement EKT.
It should be sufficient to point out what becomes possible if it is 
implemented.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 8 Aug 2012 19:14:26 +0000

I agree with Paul and see no reason why we should "recommend" that any component in the SIPREC architecture support EKT. If we have to mention EKT, and I am not convinced we do, then it should be sufficient to describe the implications.

Regards
Andy (As an Individual)

On 8 Aug 2012, at 17:26, "Paul Kyzivat" <[email-masked]> wrote:

> It should be sufficient to point out what becomes possible if it is implemented.
> 
>    Thanks,
>    Paul
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 8 Aug 2012 20:48:05 +0000

I believe this works for me as well. Let me summarize to make sure we are all in agreement.
1) remove "It implies that the keying mechanism is the same on the CS as the RS." from proposed addition to architecture document.
2) mention in security section of protocol draft that EKT may optionally be used to interwork with SDES without requiring media decrypt/encrypt by SRC.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hutton, Andrew
> Sent: Wednesday, August 08, 2012 12:14 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> I agree with Paul and see no reason why we should "recommend" that any
> component in the SIPREC architecture support EKT. If we have to mention
> EKT, and I am not convinced we do, then it should be sufficient to describe
> the implications.
> 
> Regards
> Andy (As an Individual)
> 
> 
> 
> 
> >> " 3. 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.  It implies that the
> keying mechanism is the same on the CS as the RS.  That has implications on
> mandatory to implement keying mechanisms."
> >>
> >> The point I was trying to make was that using the same key in the CS as in
> the RS does NOT imply that the keying mechanism is the same on the CS as
> the RS. An example of such as case is a SRC using SDES in the CS and EKT in
> the RS.
> >> With that in mind, I think it would be useful to add a description of this to
> the security section of the protocol draft along, possibly with a
> recommendation for EKT support by at least the SRC and potentially for
> recording aware UAs and the SRS as well. In this case,  support for media
> encryption using SRTP with SDES may be required for recording-aware UAs,
> the SRC and the SRS, and DTLS/SRTP with EKT may be recommended. Any
> such requirements/recommendation would be in the protocol draft, not the
> architecture. Interworking with RTCWEB is one case in which support for EKT
> in the SRC would be useful. Interworking with a SIPREC aware conference
> server that supports EKT is another.
> >>
> >> Cheers,
> >> Charles
> >>
> from

---

From: Leon Portman <[email-masked]>
Date: Wed, 8 Aug 2012 23:51:20 +0300

I am ok

Leon

---

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Aug 2012 16:56:19 -0400

WFM

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 9 Aug 2012 09:03:48 +0000

Would this mean a dependency on the draft-ietf-avtcore-srtp-ekt-00?

If so I would like to try to avoid that.

Regards
Andy

> From: Brian Rosen [mailto:[email-masked]]
> Sent: 08 August 2012 21:56
> To: Charles Eckel
> Cc: Hutton, Andrew; Paul Kyzivat; [email-masked]
> > 1) remove "It implies that the keying mechanism is the same on the CS
> as the RS." from proposed addition to architecture document.
> > 2) mention in security section of protocol draft that EKT may
> optionally be used to interwork with SDES without requiring media
> decrypt/encrypt by SRC.
> >
> > Cheers,
> > Charles
> >
> >>>> Let me try to clarify. The part of the suggested text that I see
> as
> >> problematic is the following:
> >>>>
> >>>>> I don't understand the argument that we should recommend EKT on
> the
> >> RS
> >>>>> our session at IETF84 was that we should carefully craft the
> security
> >> section
> >>>>> example need to make some statements such as stating that TLS
> must
> >> be
> >>>>>>>> The document doesn't discuss a retrieval mechanism for
> recorded
> >>>>>> media.
> >>>>>>> because the retriever is another party to the recording
> session, item
> >>>>>> 2 is
> >>>>>>>> pto must be no less strong than that on the RS, and may need
> to be
> >>>>>> better.
> >>>>>>> to
> >>>>>>> The retrieval mechanism for media recorded by this protocol is
> out of
> >>>>>> scope.
> >>>>>>> implications carefully as the retriever is not usually a party
> to the
> >>>>>> call that
> >>>>>>> was recorded.  Retrievers should be authenticated carefully
> (the
> >>>>>> reverse of
> >>>>>>>> 1. Protection of the RS should be no worse than protection of
> the
> >>>>>> CS, and
> >>>>>>> may need to be better 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
> >>>>>>>> 2. It is essential that the SRC 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
> >>>>>>> encrypted, not the transport.  It implies that the keying
> mechanism
> >>>>>> is the
> >>>>>>> another party to the recording session, item 2 is reversed -
> the
> >>>>>> client must
> >>>>>>> be authenticated.  The c
> >>>>>>> ry
> >>>>>>>> pto must be no less strong than that on the RS, and may need
> to be
> >>>>>> better.
> >>>>>>>>
> >>>>>>>> Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Aug 2012 07:04:33 -0700

> If so I would like to try to avoid that.

IMO what we write should be done in such a way that we don't get 
normative dependency. IIUC we should be safe as long as we only have an 
informative reference. So as long as we only describe the implications 
of EKT, without requiring anything, we should be ok.

	Thanks,
	Paul

>> On Aug 8, 2012, at 4:48 PM, Charles Eckel (eckelcu)<[email-masked]>
>> wrote:
>>
>>>> On 8 Aug 2012, at 17:26, "Paul Kyzivat"<[email-masked]>
>> wrote:
>>>>