Subject: [siprec] Proposed text for security section in siprec-protocol

From: "Henry Lum" <[email-masked]>
Date: Thu, 27 Sep 2012 14:41:58 -0700

It's my first attempt to begin writing the security section for the
protocol draft. I try to capture all the important points raised in the
previous meeting to ensure we have enough coverage for the security
concerns.

Regards,
Henry

12.  Security Considerations

   The recording session is fundamentally a standard SIP dialog
   [RFC3261], therefore, the recording session can reuse any of the
   existing SIP security mechanism available for securing the recorded
   media as well as metadata.  The user cases and requirements document
   [RFC6341] outlines the general security considerations, and the
   following describe specific security recommendations.

   The SRC and SRS MUST support SIPS and TLS as per RFC3261.  The
   Recording Session SHOULD be at least as secure as the Communication
   Session, meaning using at least the same strength of cipher suite as
   the CS if the CS is secured.  For example, if the CS uses SIPS for
   signalling and RTP/SAVP for media, then the RS does not downgrade the
   level of security in the RS to SIP or plain RTP since doing so will
   mean an automatic security downgrade for the CS.  In deployments
   where the SRC and the SRS are in the same administrative domain and
   the same physical switch that prevents outside user access, some SRC
   may choose lower the level of security when establishing the
   recording session.  While physically securing the SRC and SRS may
   prevent an outside attacker from accessing important call recordings,
   this still does not prevent from an inside attacker from accessing
   the internal network to gain access to the call recordings.

12.1.  Authentication and Authorization

   The recording session reuses the SIP mechanism to challenge requests
   that is based on HTTP authentication.  The mechanism relies on 401
   and 407 SIP responses as well as other SIP header fields for carrying
   challenges and credentials.

   The SRS may have its own set of recording policies to authorize
   recording requests from the SRC.  The use of recording policies is
   outside the scope of the Session Recording Protocol.

   The SRC and SRS MUST support mutual authentication for establishing
   the recording session.  In deployments where the SRC and the SRS are
   in the same administrative domain, the deployment may choose not to
   authenticate each other or only to have SRC authenticate the SRS as
   there is an inherent trust relation between the SRC and the SRS when
   they are hosted in the same administrative domain.  In deployments
   where the SRS can be hosted on a different administrative domain,
   then it is important to perform mutual authentication to ensure the
   authenticity of both the SRC and the SRS before transmitting any
   recorded media.  The risk of not authenticating the SRS is that the
   recording may be sent to a compromised SRS and that sensitive call
   recording will be obtained by an attacker.  On the other hand, the
   risk of not authenticating the SRC is that an SRS will be willingly
   accept any call recording from an unknown SRC and allow potential
   forgery of call recordings.

12.2.  RTP handling

   In many scenarios it will be critical that the media transported
   between the SRC and SRS to be protected.  Media encryption is an
   important element in the overall SIPREC solution; therefore SRC and
   SRS MUST support RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124].  RTP/
   SAVP and RTP/SAVPF provide media encryption, integrity protection,
   replay protection, and a limited form of source authentication.  They
   do not contain or require a specific keying mechanism.

   When RTP/SAVP or RTP/SAVPF is used, RS can choose to use the same or
   different security keys than the ones used in the CS.  Some SRCs are
   designed to simply replicate RTP packets from the CS media stream to
   the SRS, and the SRC will be reusing the same keys as the CS.  In
   this case, the SRC MUST secure the SDES in the RS with at least the
   same level of security as the CS.  The risk of lowering the level of
   security in the RS for this case is that it will effectively become a
   downgrade attack on the CS since the same key is used for both CS and
   RS.

   For SRCs that perform transcoding or mixing of media before sending
   to the SRS, the SRC MUST negotiate a different security key than the
   one being used in the CS, to ensure that the security in the CS is
   not compromised by the SRC when reusing the same security key.

12.3.  Metadata

   Metadata contains sensitive information such as the address of record
   of the participants and other extension data placed by the SRC.  It
   is essential to protect the content of the metadata in the RS.  Since
   metadata is a content type transmitted in SIP signalling, metadata
   can be protected by SIPS/TLS.  If the RS is not secured for any
   reason, the metadata content can also be secured by using S/MIME.

12.4.  Storage and playback

   While storage and playback of the call recording is beyond the scope
   of this document, it is worthwhile to mention here that it is also
   important for the recording storage and playback to provide a level
   of security that is comparable to the communication session.  It
   would defeat the purpose of securing both the communication session
   and the recording session mentioned in the previous sections if the
   recording can be easily played back with a simple unsecured HTTP
   interface without any form of authentication or authorization.

---

From: "Jain, Rajnish" <[email-masked]>
Date: Fri, 28 Sep 2012 01:31:03 +0000

Hi Henry,

Pls. see a few comments in-line [rj]:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry Lum
Sent: Thursday, September 27, 2012 5:42 PM
To: [email-masked]
Subject: [siprec] Proposed text for security section in siprec-protocol

It's my first attempt to begin writing the security section for the protocol draft. I try to capture all the important points raised in the previous meeting to ensure we have enough coverage for the security concerns.

Regards,
Henry

   The recording session is fundamentally a standard SIP dialog
   [RFC3261], therefore, the recording session can reuse any of the
   existing SIP security mechanism available for securing the recorded
   media as well as metadata.  

[rj] The existing SIP security mechanisms will also allow secure RS SIP signaling (such as over TLS or IPSec). 
Substitute: ... available for securing _session signaling_, recorded media as well as metadata.

The user cases and requirements document
   [RFC6341] outlines the general security considerations, and the
   following describe specific security recommendations.

[rj] _use cases_

   The SRC and SRS MUST support SIPS and TLS as per RFC3261.  

[rj] RFC 3261 does not require TLS support in all SIP entities. Quote from RFC 3261:

------------
26.3.1 Requirements for Implementers of SIP

   Proxy servers, redirect servers, and registrars MUST implement TLS,
   and MUST support both mutual and one-way authentication.  It is
   strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also
   be capable of acting as a TLS server.
------------

   The Recording Session SHOULD be at least as secure as the Communication

[rj] Since the paragraph above suggests that only server-side authentication might be sufficient if SRC and SRS are in the same administrative domain, shouldn't the first statement in the paragraph (a normative statement) loosen the MUST strength. 

12.2.  RTP handling

12.3.  Metadata

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