The Feature Information for Secure SIP Call Signaling and SRTP Media with Cisco SRST table lists the release history for this feature.

Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.

Use a Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com isn’t required.

Note

The Feature Information for Secure SIP Call Signaling and SRTP Media with Cisco SRST table lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.

General

• Secure Cisco Unified IP phones supported in secure SCCP and SIP SRST must have the Certification Authority (CA) or third-party certificates installed, and encryption enabled. For more information on CA server authentication, see Autoenrolling and Authenticating the Secure Cisco Unified SRST Router to the CA Server.

• The SRST router must have a certificate; a certificate can be generated by a third party or by the Cisco IOS certificate authority (CA). The Cisco IOS CA can run on the same gateway as Cisco Unified SRST. Over the TLS channel (port 2445), automated certificate exchange happens between the Unified SRST router and the Cisco Unified Communications Manager. However, the phone certificate exchange to Unified SRST through Unified Communications Manager has to be downloaded manually on the Unified SRST router.

• Certificate trust lists (CTLs) on Cisco Unified Communications Manager must be enabled.

• It is mandatory to configure the command supplementary-service media-renegotiate under voice service voip configuration mode to enable the supplementary features supported on Unified Secure SRST.

Public Key Infrastructure on Secure SRST

• Set the clock, either manually or by using Network Time Protocol (NTP). Setting the clock ensures synchronicity with Cisco Unified Communications Manager.

• Enable the IP HTTP server (Cisco IOS processor) with the ip http server command, if not already enabled. For more information on public key infrastructure (PKI) deployment, see the Cisco IOS Certificate Server feature.

• If the certificate server is part of your startup configuration, you may see the following messages during the boot procedure:

% Failed to find Certificate Server's trustpoint at startup % Failed to find Certificate Server's cert.

These messages are informational messages and indicate a temporary inability to configure the certificate server because the startup configuration has not been fully parsed yet. The messages are useful for debugging, in case the startup configuration is corrupted.

You can verify the status of the certificate server after the boot procedure using the show crypto pki server command.

Supported Cisco Unified IP Phones, Platforms, and Memory Requirements

• For a list of supported Cisco Unified IP Phones, routers, network modules, and codecs for secure SRST, see the Cisco Unified Survivable Remote Site Telephony Compatibility Information feature.

• For the most up-to-date information about the maximum number of Cisco Unified IP Phones, the maximum number of directory numbers (DNs) or virtual voice ports, and memory requirements, see the Cisco Unified SRST 12.3 Supported Firmware, Platforms, Memory, and Voice Products feature.

General

• Cryptographic software features (“k9”) are under export controls. This product contains cryptographic features and is subject to United States and local country laws governing import, export, transfer, and use. Delivery of Cisco cryptographic products does not imply third-party authority to import, export, distribute or use encryption. Importers, exporters, distributors and, users are responsible for compliance with U.S. and local country laws. By using this product you agree to comply with applicable laws and regulations. If you are unable to comply with U.S. and local laws, return this product immediately

  A summary of U.S. laws governing Cisco cryptographic products may be found at the following URL: http://www.cisco.com/wwl/export/crypto/tool/

  If you require further assistance, please contact us by sending email to export@cisco.com.

• When a Secure Real-Time Transport Protocol (SRTP) encrypted call is made between Cisco Unified IP Phone endpoints or from a Cisco Unified IP Phone to a gateway endpoint, a lock icon is displayed on the IP phones. The lock indicates security only for the IP leg of the call. Security of the PSTN leg is not implied.

SCCP SRST

• Secure SCCP SRST is supported only within the scope of a single router.

• Cisco 4000 Series Integrated Services Routers support Secure SCCP SRST only on Unified SRST 12.3 and later releases. For Secure SCCP support on Unified SRST 12.3 Release:

  • Secure Cisco Jabber is not supported.

  • SRTP passthrough is not supported.

  • SDP Passthrough is not supported.

  • Video Calling is not supported.

  • Transcoding is not supported.

  • Hardware Conferencing is not supported (Only Software Conferencing is supported).

  • Secure Multicast MOH is not supported (Multicast MOH stays active, but non-secure).

  • Live MOH is not supported.

  • Secure H.323 is not supported.

  • Hot Standby Routing Protocol (HSRP) is not supported.

  • T.38 Fax Relay and Modem Relay is not supported for Unified Secure SRST.

• For call support on Voice Gateway introduced as part of Unified SRST 12.3 Release:

  • Speed Dial is not supported.

  • For a pure SCCP shared line, Hold and Remote Resume is not supported from an analog phone.

  • Full Blind Transfer mode (Configured with the CLI command transfer-system full-blind) is not supported.

  • Consider a call between two Analog Voice Gateways (VG A and VG B) registered on Unified Secure SRST as SCCP endpoints. If a call is already put on hold from the VG B endpoint (could be an SCCP phone too), then VG A (has to be an Analog Voice Gateway) cannot put the same call on hold (double hold). For more information, see CSCvi15203.

  • For three-way software conference related behavior and limitations, see Three-way Software Conferencing for Secure SCCP, Unified SRST Release 12.3.

SIP SRST

• Cisco 4000 Series Integrated Services Router supports Secure SIP SRST only on Unified SRST 12.1 and later releases.

• SRTP passthrough is not supported.

• SDP Passthrough is not supported.

• Video Calling is not supported.

• Transcoding is not supported.

• Hardware Conferencing is not supported (Only BIB Conferencing is supported).

• It is mandatory to configure security-policy secure under voice register global configuration mode. Non-Secure endpoints cannot register when security-policy secure is configured. As such, mixed deployments of secure and non-secure endpoints is not possible.

Secure Cisco Unified IP phones that are located at remote sites and that are attached to gateway routers can communicate securely with Cisco Unified Communications Manager using the WAN. But if the WAN link or Cisco Unified Communications Manager goes down, all communication through the remote phones becomes non-secure. To overcome this situation, gateway routers can now function in secure SRST mode, which activates when the WAN link or Cisco Unified Communications Manager goes down. When the WAN link or Cisco Unified Communications Manager is restored, Cisco Unified Communications Manager resumes secure call-handling capabilities.

Secure SRST provides new Cisco Unified SRST security features such as authentication, integrity, and media encryption. Authentication provides assurance to one party that another party is whom it claims to be. Integrity provides assurance that the given data has not been altered between the entities. Encryption implies confidentiality; that is, that no one can read the data except the intended recipient. These security features allow privacy for Cisco Unified SRST voice calls and protect against voice security violations and identity theft.

SRST security is achieved when:

• End devices are authenticated using certificates.

• Signaling is authenticated and encrypted using Transport Layer Security (TLS) for TCP.

• A secure media path is encrypted using Secure Real-Time Transport Protocol (SRTP).

• Certificates are generated and distributed by a CA.

As a part of the Secure SIP SRST feature on Unified SRST Release 12.1, support is provided for calls with Transport Layer Security protocols (TLS) versions up to 1.2. Also, supports TLS 1.2 exclusivity as part of Unified SRST Release 12.1.

Starting from Cisco Unified SRST 14.4 Release (Cisco IOS XE 17.14.1a), SRST security feature supports TLS version 1.3 and associated ciphers.

Note	It's recommended to use TLS version 1.2 or 1.3 wherever possible to ensure security or compliance.

SIP SRST supports the following three functionalities:

• The TLS exclusivity functionality enables only the configured version of TLS (1.0 or 1.1 or 1.2 or 1.3).

• The default form supports all the TLS versions 1.3, 1.2, and 1.1. However, to configure TLS version 1.0, you must explicitly specify the TLS version.

• In sip-ua configuration mode, SIP SRST supports minimum TLS version functionality. You can configure the minimum TLS version only with TLS version 1.2, which supports both TLS versions 1.2 and 1.3 cipher negotiations with the peers.

  Note	For the functionality configurations, see Signaling Security on Unified SRST - TLS.

For the list of supported TLS cipher suites, see TLS Cipher Suites.

Note

The Cisco IP Phone 7800 Series and Cisco IP Phone 8800 Series is supported on the Unified Secure SIP SRST Release 12.1 configured on a Cisco 4000 Integrated Services Router. For Secure SIP SRST to be supported on Cisco 4000 Series Integrated Services Router, you need to enable the following technology package licenses on the router: security uck9 For Unified SRST 12.2 and previous releases, only SIP phones are supported on the Cisco 4000 Integrated Services Router for Secure SIP SRST. Unified SRST 12.3 and later releases supports a mixed deployment of SIP and SCCP phones on the Cisco 4000 Integrated Services Router.

As a part of the Secure SCCP SRST feature on Unified SRST Release 12.3, support is provided for calls with the Transport Layer Security protocols (TLS) versions up to 1.2. Also, TLS 1.2 exclusivity is supported as part of Unified SRST Release 12.3. For more information on the TLS protocol support introduced for Secure SCCP in Unified SRST Release 12.3, see SRST Routers and the TLS Protocol.

Starting from Cisco Unified SRST 14.4 Release (Cisco IOS XE 17.14.1a), the secure SRST security feature is enhanced to support TLS version 1.3 and associated ciphers. SCCP SRST supports TLS exclusivity and default form functionalities:

Note	It's recommended to use TLS version 1.2 or 1.3 wherever possible to ensure security or compliance.

SCCP SRST supports the following three functionalities:

• The TLS exclusive functionality enables only the configured version of TLS (1.0 or 1.1 or 1.2 or 1.3).

• The default form supports all the TLS versions 1.3, 1.2, and 1.1. However, to configure TLS version 1.0, you must explicitly specify the TLS version.

• Secure SCCP SRST supports SHA2 ciphers with TLS versions 1.2 and 1.3.

  Note	For the functionality configurations, see Signaling Security on Unified SRST - TLS.

For the list of supported TLS cipher suites, see TLS Cipher Suites.

• Cisco Unified SRST versions before 12.3(14)T are not capable of supporting secure connections or have security enabled. If an SRST router is not capable of SRST as a fallback mode—that is, it is not capable of completing a TLS handshake with Cisco Unified Communications Manager—its certificate is not added to the configuration file of the Cisco IP phone. The absence of a Cisco Unified SRST router certificate causes the Cisco Unified IP phone to use nonsecure (clear-text) communication when in Cisco Unified SRST fallback mode. The capability to detect and fallback in clear-text mode is built into Cisco Unified IP phone firmware. See Media and Signaling Authentication and Encryption Feature for Cisco IOS MGCP Gateways for more information on clear-text mode.

Transport Layer Security (TLS) provides secure TCP channels between Cisco Unified IP phones, secure Cisco Unified SRST Routers, and Cisco Unified Communications Manager. The TLS process begins with the Cisco Unified IP Phone establishing a TLS connection when registering with a Cisco Unified Communications Manager. Assuming that a Cisco Unified Communications Manager is configured to fall back to Cisco Unified SRST, the TLS connection between the Cisco Unified IP Phones and the secure Cisco Unified SRST Router is also established. If the WAN link or Cisco Unified Communications Manager fails, call control reverts to the Cisco Unified SRST router.

Unified Secure SIP and SCCP SRST Earlier Release Versions

From Unified Secure SIP SRST Release 12.1, support is introduced for SIP-to-SIP calls with Transport Layer Security up to TLS version 1.2. For configuring TLS 1.2 exclusivity functionality, you need to configure the command transport tcp tls v1.2 under sip-ua configuration mode. When you configure TLS 1.2 exclusivity on the Secure SIP SRST, any registration attempt by phones using lower versions of TLS (1.0, 1.1) are rejected.

Before Unified SCCP SRST Release 12.3, support is available only for TLS 1.0 version. From Unified Secure SCCP SRST Release 12.3 and later releases, support is introduced for Transport Layer Security up to TLS version 1.2. To configure a specific TLS version or TLS 1.2 exclusivity for Unified Secure SCCP SRST, you need to configure transport-tcp-tls under call-manager-fallback . When transport-tcp-tls is configured without specifying a version, it enables the default behavior of the CLI command. In the default form, all the TLS versions (except TLS 1.0) are supported for this CLI command.

For TLS 1.0 support on Cisco IOS XE Fuji Release 16.9.1 for SCCP endpoints, you need to specifically configure:

• transport-tcp-tls v1.0 in call-manager-fallback configuration mode.

For TLS 1.0 support on Cisco IOS XE Fuji Release 16.9.1 for SIP and mixed deployment scenarios, you need to specifically configure:

• transport-tcp-tls v1.0 in sip-ua configuration mode.

From Cisco IOS XE Fuji Release 16.9.1, the security certificate exchange between Unified Secure SRST Release 12.3 and Unified Communications Manager doesn't support TLS version 1.0.

For Secure SIP and Secure SCCP endpoints that don't support TLS version 1.2, you need to configure TLS 1.0 for the endpoints to register to Unified Secure SRST 12.3 (Cisco IOS XE Fuji Release 16.9.1). This also means that endpoints which support 1.2 should also use the 1.0 suites.

Note	Unified Communications Manager Release 11.5.1SU3 is the minimum version required to support security certificate exchange with Unified Secure SRST Release 12.3 (Cisco IOS XE Fuji Release 16.9.1).

Note

SCCP phones and the Analog Voice Gateways VG202, VG204, and VG224 support only TLS version 1.0. For Unified Secure SRST 12.3 Release and later, supports TLS versions 1.1 and 1.2 for Cisco Analog Voice Gateways VG202XM, VG204XM, VG310, and VG320. For Unified Secure SCCP SRST Release 12.3 and later releases, Analog Voice Gateways can register their SCCP endpoints with TLS versions up to 1.2 (TLS 1.0, 1.1, and 1.2). The VG2xx and VG3xx Analog Voice Gateway series are End-of-Life or End-of-Support.

enable
 configure terminal
 stcapp security tls-version v1.3
exit

--
VG(config)#stcapp security tls-version ?
  v1.0 Enable TLS Version 1.0
  v1.1 Enable TLS Version 1.1
  v1.2 Enable TLS Version 1.2
  v1.3 Enable TLS Version 1.3

Rate limit log for SIP : 

%SIP-5-TLS_CONNECTION: TLS insecure handshake detected: version TLSv1.2 with cipher AES256-SHA for SIP connection. 
Please upgrade to TLS 1.2 or above with strong ciphers.
%SIP-5-TLS_CONNECTION: TLS insecure connection summary for last 1 hour: SIP connections: 1. 
Please upgrade to TLS 1.2 or above with strong ciphers for enhanced security.
 
 Rate limit log for SCCP : 
 
 %SIP-5-TLS_CONNECTION: TLS insecure handshake detected: version TLSv1.1 with cipher AES128-SHA for SCCP connection. 
 Please upgrade to TLS 1.2 or above with strong ciphers.
 %SIP-5-TLS_CONNECTION: TLS insecure connection summary for last 1 hour: SCCP connections: 1.  
 Please upgrade to TLS 1.2 or above with strong ciphers for enhanced security.

Device(config)# voice service voip
Device(conf-voi-serv)#sip-ua
Device(config-sip-ua)# transport tcp tls ?
v1.0 Enable TLS Version 1.0
v1.1 Enable TLS Version 1.1
v1.2 Enable TLS Version 1.2
v1.3 Enable TLS Version 1.3
<cr>              <cr>

Device(config)# voice service voip
Device(conf-voi-serv)#sip-ua
Device(config-sip-ua)# transport tcp tls
Device(config-sip-ua)# transport tcp tls v1.2 ?
minimum Enable TLS versions 1.2 and 1.3
<cr>              <cr>

Router(config-sip-ua)#transport tcp tls v1.0
 SECURITY WARNING - Module: SIPUA, Command: transport tcp tls v1.0 , Reason: Weak tls version, 
Remediation: Use stronger tls version to enhance security

Router(config)#call-manager-fallback
Router(config-cm-fallback)#transport-tcp-tls ?
v1.0 Enable TLS Version 1.0
v1.1 Enable TLS Version 1.1
v1.2 Enable TLS Version 1.2
v1.3 Enable TLS Version 1.3

Router(config)#call-manager-fallback
Router(config-cm-fallback)#transport-tcp-tls v1.3 ?
sha2 Allow SHA2 ciphers only

Router(config-cm-fallback)# transport-tcp-tls v1.1                 
 SECURITY WARNING - Module: CALLMANAGER, Command: transport-tcp-tls v1.1, Reason: Weak tls version, 
Remediation: Use stronger tls version to enhance security

Router(config-cm-fallback)# do sh run | sec call-manager-fallback  
call-manager-fallback
 transport-tcp-tls v1.1
 max-conferences 8 gain -6
 transfer-system full-consult
 ip source-address 10.10.10.239 port 2000
 max-ephones 30
 max-dn 30

From Unified Secure SRST 12.6 onwards, the TLS cipher support offered on Secure SRST is modified to enhance security.

Starting from Unified Secure SRST 14.4, TLS version 1.3 is supported in addition to 1.2, 1.1, 1.0 and all the associated cipher suites.

Unified Secure SIP SRST enables routers to provide secure call-handling for Unified IP phones during an outage. The support is for endpoints that lose connection to the remote primary, secondary, or tertiary Unified CM installations during a WAN outage. If SIP OAuth is configured, SIP clients can securely register to the SRST during WAN link failures. The SRST can provide secure call control for the following SIP clients:

• Cisco Jabber Client

• Cisco Webex Client

• Cisco IP Phone 78xx Series

• Cisco IP Phone 88xx Series

Dynamic, token-based authentication provides improved security for devices registering to Unified CM.

When registering to the SRST during an outage, UCM issues an authentication token that the client uses. A challenge is issued when a new registration request doesn't include a token. The SRST attempts to validate the token using keys previously received securely from UCM. If the validation is successful, the SRST allows the client to register and place calls locally. Clients presenting a token that can't be validated by the SRST aren't allowed to register.

Note	Supports TLS version 1.3 to fetch SIP OAuth keys from the CUCM. The http client secure-ciphersuite command configuration supports TLS version 1.3 ciphers. For configuration details, see http client secure-ciphersuite .

Note	Stores the key pairs in persistent memory, ensuring that clients can register if the SRST router reloads during a service outage.

To configure SIP OAuth for the Unified Secure SIP SRST, perform the following:

1. Configure a TLS listen port without client validation for use by SIP OAuth clients.

   Note	The TLS listen port is open in addition to the default secure port that uses mTLS.

   voice service voip
     sip
       listen-port secure no-client-validation ?
         <1024-49151>   Port number
   

2. Perform call service stop before configuring the listen port and no call service stop after configuring the listen port.

3. Configure access to the UCM key server with appropriate authentication details. Stores clear text passwords using type 6 encryption.

   voice register global
   	sip-oauth                SIP OAuth parameters for Unified SRST 
   	    key-server key-server ipv4:10.5.10.50:8443 username administrator password 0 abcd12345
   

4. Configure device pools for compatible clients to use SIP OAuth. Enables SIP OAuth for compatible clients using the voice register pool configuration.

   voice register pool <tag>
           sip-oauth
   

From SRST 14.2 onwards, the ciphers that secure SIP SRST offers only ciphers that meet your compliance requirements. Similarly, configure secure SCCP SRST to allow SHA2 TLS1.2 ciphers.

From SRST 14.4 onwards, Secure SCCP SRST also supports SHA2 ciphers with TLS v1.3.

SCCP Client Registration

When SCCP SRST is configured with SHA2 ciphers, SCCP clients must use one of the following SHA2 cipher suites to establish a TLS connection:

• TLS 1.2 SHA2:

  • ECDHE_RSA_AES_256_GCM_SHA256

  • ECDHE_RSA_AES_256_GCM_SHA384

  • DHE_RSA_AES128_GCM_SHA256

  • DHE_RSA_AES256_GCM_SHA384

  • ECDHE_ECDSA_AES128_GCM_SHA256

  • ECDHE_ECDSA_AES256_GCM_SHA384

• TLS 1.3 and TLS1.3 SHA2:

  • AES128_GCM_SHA256

  • AES256_GCM_SHA384

  • CHACHA20_POLY1305_SHA256

Media packets are encrypted and sent using the AEAD_AES_256_GCM SRTP cipher suite.

Note	When Secure SCCP SRST is configured to require SHA2 ciphers, only clients using SCCP protocol version 23 or higher are allowed to register. If SHA2 isn't configured as a requirement for Secure SCCP SRST, then clients using SCCP protocol version 23 or lesser may be used.

SIP Client Registration

Secure SIP SRST may be configured to allow SIP clients to establish a TLS connection using single or multiple preferred cipher suites.

For example:

Device(config)#voice class tls-cipher 333

Device(config-class)#cipher 1 ?
AES128_GCM_SHA256              supported in TLS 1.3
AES256_GCM_SHA384              supported in TLS 1.3
CHACHA20_POLY1305_SHA256       supported in TLS 1.3
DHE_RSA_AES128_GCM_SHA256      supported in TLS 1.2
DHE_RSA_AES256_GCM_SHA384      supported in TLS 1.2
DHE_RSA_WITH_AES_128_CBC_SHA   supported in TLS 1.2 & below
DHE_RSA_WITH_AES_256_CBC_SHA   supported in TLS 1.2 & below
ECDHE_ECDSA_AES128_GCM_SHA256  supported in TLS 1.2
ECDHE_ECDSA_AES256_GCM_SHA384  supported in TLS 1.2
ECDHE_RSA_AES128_GCM_SHA256    supported in TLS 1.2
ECDHE_RSA_AES256_GCM_SHA384    supported in TLS 1.2
RSA_WITH_AES_128_CBC_SHA       supported in TLS 1.2 & below
RSA_WITH_AES_256_CBC_SHA       supported in TLS 1.2 & below

Device(config-class)#cipher 1 DHE_RSA_AES128_GCM_SHA256
Device(config-class)#end

Note	Configure SRST TLS cipher policy before a SIP client is allowed to connect and register.

After the successful signaling, media packets are encrypted based on the srtp-crypto configuration. Configure an SRTP cipher list first using the voice class srtp-crypto <tag> command. Associate the SRTP cipher list with the voice register pool.

Device(config)#voice class srtp-crypto 22
Device(config-class)#?
VOICECLASS configuration commands:
crypto      Configure preferred SRTP cipher-suite
exit        Exit from voice class configuration mode
help        Description of the interactive help system
no          Negate a command or set its defaults

Device(config-class)#crypto ?
<1-4>       Set the preference order for the cipher-suite (1 = Highest)

Device(config-class)#crypto 1 ?
 AEAD_AES_128_GCM         Allow secure calls with SRTP AEAD_AES_128_GCM cipher-suite
 AEAD_AES_256_GCM         Allow secure calls with SRTP AEAD_AES_256_GCM cipher-suite
 AES_CM_128_HMAC_SHA1_32  Allow secure calls with SRTP AES_CM_128_HMAC_SHA1_32 cipher-suite
 AES_CM_128_HMAC_SHA1_80  Allow secure calls with SRTP AES_CM_128_HMAC_SHA1_80 cipher-suite

Device(config-class)#crypto 1 AEAD_AES_256_GCM
Device(config-class)#do show run | sec srtp-cry
 voice class srtp-crypto 22
 crypto 1 AEAD_AES_256_GCM

Device(config)# voice register pool 17
Device(config-register-pool)# id network 10.1.10.217 mask 255.255.255.255
Device(config-register-pool)# dtmf-relay rtp-nte
Device(config-register-pool)# codec g711ulaw

Show run output for pool:
=============================================
Device#show running-config | sec voice register pool 17
 voice register pool 17
 id network 10.1.10.217 mask 255.255.255.255
 dtmf-relay rtp-nte
 voice-class srtp-crypto 22
 codec g711ulaw
Device#show run

Configure srtp-crytpto 23 command, which is present, you get the following error:

Device(config-register-pool)#voice-class srtp-crypto 23
ERROR: There is no voice-class srtp-crypto 23

Configure srtp-crytpto 22 command, which is present, you get the following output:

Device(config-register-pool)#voice-class srtp-crypto 22
Device(config-register-pool)#

Note	SRTP crypto policy must be configured before it can be used in a voice register pool configuration.

Media encryption, which uses Secure Real-Time Protocol (SRTP), ensures that only the intended recipient can interpret the media streams between supported devices. Support includes audio streams only.

If the devices support SRTP, the system uses a SRTP connection. If at least one device does not support SRTP, the system uses an RTP connection. SRTP-to-RTP fallback may occur for transfers from a secure device to a non-secure device for music-on-hold (MOH), and so on.

Note

Secure SRST handles media encryption keys differently for different devices and protocols. All phones that are running SCCP get their media encryption keys from SRST, which secures the media encryption key downloads to phones with TLS encrypted signaling channels. Phones that are running SIP generate and store their own media encryption keys. Media encryption keys that are derived by SRST securely get sent through encrypted signaling paths to gateways over IPSec-protected links for H.323.

Warning

Before you configure SRTP or signaling encryption for gateways and trunks, Cisco strongly recommends that you configure IPSec because Cisco H.323 gateways, and H.323/H.245/H.225 trunks rely on IPSec configuration to ensure that security-related information does not get sent in the clear. Cisco Unified SRST does not verify that you configured IPSec correctly. If you do not configure IPSec correctly, security-related information may get exposed.

The following figure shows the interworking of the credentials server on the SRST router, Cisco Unified Communications Manager, and the Cisco Unified IP Phone. The following table describes the establishment of secure SRST to the Cisco Unified IP Phone.

The following figure illustrates the process of secure SRST authentication and encryption, and the following table describes the process.

Note	The media is encrypted automatically after the phone and router certificates are exchanged and the TLS connection is established with the SRST router.

The following configuration sections ensure that the secure Cisco Unified SRST Router and the Cisco Unified IP Phones can request mutual authentication during the TLS handshake. The TLS handshake occurs when the phone registers with the Cisco Unified SRST Router, either before or after the WAN link fails.

This section contains the following procedures:

For Unified SRST 14.4 and later releases, when a handshake between CUCM and SIP SRST (CAPF) fails due to TLS version mismatch, then it generates a syslog message in the following format:

Dec 13 06:15:54.587: %EPHONE_CRED-2-CTL_TLS_HANDSHAKE_FAILED: Reason: unsupported protocol, 
Socket ID: 1, local address : 10.1.20.11:2445 and  remote address : 10.5.10.50:56372

When a handshake between Voice Gateway and SCCP SRST fails due to TLS version mismatch, then it generates a syslog message in the following format:

Dec 13 15:31:52.949: %SKINNYSECURESERVICE-3-TLS_HANDSHAKE_FAILED:  
Reason: unsupported protocol, SocketID: 0, local address : 10.1.20.11:2443 and  remote address : 10.1.20.179:12239

When a handshake between CUCM and SIP SRST fails due to cipher mismatch while fetching the sip-oauth keys, then it generates a syslog message in the following format:

Dec 13 06:42:59.612: %HTTPC-6-TLS_HANDSHAKE_FAILED:  Reason: sslv3 alert handshake failure, Connection ID: 0, remote address : [2001:10:5:10::50]:8443

Rate limit log for SIP : 

%SIP-5-TLS_CONNECTION: TLS insecure handshake detected: version TLSv1.2 with cipher AES256-SHA for SIP connection. 
Please upgrade to TLS 1.2 or above with strong ciphers.
%SIP-5-TLS_CONNECTION: TLS insecure connection summary for last 1 hour: SIP connections: 1. 
Please upgrade to TLS 1.2 or above with strong ciphers for enhanced security.
 
 Rate limit log for SCCP : 
 
 %SIP-5-TLS_CONNECTION: TLS insecure handshake detected: version TLSv1.1 with cipher AES128-SHA for SCCP connection. 
 Please upgrade to TLS 1.2 or above with strong ciphers.
 %SIP-5-TLS_CONNECTION: TLS insecure connection summary for last 1 hour: SCCP connections: 1.  
 Please upgrade to TLS 1.2 or above with strong ciphers for enhanced security.

The following commands are introduced or modified in the feature or features documented in this section. For information about these commands, see the Cisco IOS Voice Command Reference at http://www.cisco.com/en/US/docs/ios/voice/command/reference/vr_book.html. For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or Cisco IOS Command List, All Releases at http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html.

• security-policy

• show voice register global

• show voice register all

• transport-tcp-tls