Document Overview
The majority of Cisco IP phones support secure communication for both control and data channels. The security incorporated into Cisco IP phones includes the encryption and authentication of signaling communications between the Cisco IP phones and the Cisco Unified Communications Manager. Moreover, Cisco Unified Communications Manager supports encryption, authentication, and anti-replay protection of the voice packets exchanged between Cisco IP phones. It is crucial for network administrators to understand the advantages and disadvantages of secure Cisco IP phone communications. This document summarizes the basic security and encryption features that are supported by Cisco IP phones, Cisco Unified Communications Manager servers, and related Cisco voice products. Furthermore, this document is intended to provide best practices for enabling secure encryption frameworks. This document is not intended to provide detailed configuration or feature guides, rather it will present the information to communicate a general understanding of the available options. The intended audience of this document is network administrators, security and voice engineers, and those responsible for managing voice infrastructures. A cursory understanding of basic security, Public Key Infrastructure (PKI), and cryptography principles is required.
Introduction
VoIP is ubiquitous within enterprise environments. It is widely deployed in enterprises because it is flexible and cost effective. It is critical to secure the transmissions of analog voice that is digitized and transmitted in IP packets. Securing VoIP communication minimizes the risk of theft of private information by a hacker. The scenarios are varied but it is important, for security and compliance reasons, that corporations require secure voice communications utilizing their VoIP infrastructure.
There are several products and end-points involved in a Cisco VoIP deployment, including:
- Cisco IP phones: Endpoints that create and receive calls.
- Cisco Unified Communications Manager: Responsible for provisioning, administering, and monitoring Cisco IP phones.
- Cisco Unified Communications Manager Express: Installed on a Cisco router, this software can be leveraged for Cisco Unified Communications Manager functionality.
- Voice gateways (H.323) and Media Gateway Control Protocol (MGCP): Protocols that interconnect VoIP systems with the analog infrastructure. They are responsible for facilitating calls between IP and analog phones.
The security involved when deploying Cisco Unified Communications Manager Express is similar to a Cisco Unified Communications Manager deployment.
There are many technologies and products that comprise a VoIP system, but for the purpose of discussing security best practices, this document will focus on Cisco IP phones and Cisco Unified Communications Manager.
Figure 1: Typical VoIP deployment with Cisco Unified Communications Manager installed in the Headquarters and Cisco IP phones deployed externally.
Detailed in figure 1, voice and signaling needs to be secured. Transport security handles the coding, packing, and sending of the data.
Cisco Unified Communications Manager provides the following secure transport protocols for the signaling channels:
- Transport Layer Security (TLS): Provides secure and reliable data transfer between two systems or devices, by using secure ports and certificate exchange. Cisco Unified Communications Manager utilizes TLS to secure the control channel of Session Initiation Protocol (SIP) or Skinny Client Control Protocol (SCCP) endpoints to prevent access to the voice domain.
- Secure Socket Layer Virtual Private Network (SSL VPN): This client can be used in current model Cisco IP phones (7942, 7962, 7945, 7965, and 7975) to secure communications between the phones and devices that are located behind SSL VPN head-ends.
- IP Security (IPsec): This provides secure and reliable data transfer between Cisco Unified Communications Manager and voice gateways. This is the same technology that is used for VPNs which provides signaling authentication and encryption to MGCP and H.323 gateways.
To increase security, many devices support Secure Real-Time Transport Protocol (SRTP). SRTP authenticates and encrypts the media stream (voice packets) to ensure that the voice conversations, which originate or terminate on supported endpoints, are protected from eavesdroppers who may have gained access to the voice domain. Moreover, SRTP includes protection against replay attacks. The following sections will explain security best practices by detailing strong encryption and secure communications. The reader should note that Cisco will not provide an exhaustive description of the configuration options. The goal, by stressing security, is to offer a general understanding of the available options and provide administrators options for their infrastructure.
Transport Layer Security
Transport Layer Security (TLS) can be utilized to secure SIP and SCCP signaling. This is achieved by setting the Cisco Unified Communications Manager in mixed (secure) mode. In mixed mode, devices with secure/non-secure profiles and Real-Time Transport Protocol (RTP)/SRTP media are permitted to connect to the Cisco Unified Communications Manager. In order to use Cisco Unified Communications Manager in mixed mode, the Certificate Trust List (CTL) client and USB security tokens are required. The Cisco ASA Phone Proxy feature, later described in this document, can be leveraged to utilize TLS to secure communications between an external Cisco IP phone and the Cisco Unified Communications Manager. The Cisco Unified Communications Manager is required to be internally positioned relative to the Cisco ASA and other Cisco IP phones regardless whether they are located inside or outside the firewall.
Session Initiation Protocol-Transport Layer Security (SIP-TLS) and SCCP leverage TLS to establish an encrypted channel. The encrypted channel's purpose is to exchange call signaling messages and establish secure voice (SRTP) streams. Figure 2, shown below, illustrates a standard call set-up that utilizes SIP-TLS. When a Cisco IP phone requests a call, the phone creates an initial encrypted TLS channel with the Cisco Unified Communications Manager utilizing SIP messages to establish communications with the desired Cisco IP phone. SIP-TLS uses port 5061.
Figure 2: A secure call that is using SIP-TLS for signaling and SRTP for secure voice while utilizing Cisco Unified Communications Manager in Mixed (Secure) Mode.
TLS, which consists of the handshake and record protocols, is a secure transport mechanism for TCP-based communications. The process consists of the initial handshake, alert, and change cipher sub-protocols. The record protocol provides data encryption and integrity. Although a thorough review of TLS is outside the scope of this document, in order to understand Cisco IP phone certificate best practices, it is important to understand how a typical TLS transaction for SIP or SCCP is executed. Initially, the Cisco IP phone and Cisco Unified Communications Manager, with their trusted certificate stores, utilize a TLS handshake to mutually authenticate utilizing certificates which establishes a shared symmetric key. Signaling communications are encrypted using the symmetric key, while the algorithms are negotiated in TLS. For more information on SIP or SCCP TLS communication, please refer to the
Appendix.
SRTP utilizes symmetric key cryptography to provide encryption, integrity, authentication and anti-replay protection for voice streams (RTP). For Cisco IP phones, the SRTP keying information is negotiated over secure SIP, SCCP, or other signaling channels. For SIP to establish an SRTP connection, Session Description Protocol (SDP) Security Descriptions for Media Streams (SDES) is utilized by every Cisco IP phone to create SRTP keys through Cisco Unified Communications Manager. SCCP uses a similar process whereby Cisco Unified Communications Manager generates the required keys for SRTP between the Cisco IP phones. With the support of Cisco Unified Communications Manager, Cisco IP phones create symmetric keys that are able to secure the SRTP streams for the call.
Certificates
In the previous section, we described how certificates provide authentication and are utilized to establish symmetric keys to secure TLS data. This section will examine the different types of certificates and their uses.
Phone Authentication
When the Cisco IP phone delivers the client certificate to the Cisco Unified Communications Manager, it verifies that the Cisco IP phone possesses the private key for the certificate. Cisco Unified Communications Manager uses the CA certificates that are held in the trust store to ensure that the certificate presented by the Cisco IP phone is trustworthy. A detailed discussion of certificate authentication and Public Key Infrastructure (PKI) is beyond the scope of this document.
There are two types of certificates (along with their corresponding private keys) that are present on Cisco IP phones:
- Manufacturer Installed Certificate (MIC): Manufacturer Installed Certificates (MICs) are included on all 7941, 7961 and newer model Cisco IP phones. MICs are 2048-bit key certificates that are signed by the Cisco CA. When a MIC is present it is not necessary to install a Locally Significant Certificate (LSC). In order for the Cisco Unified Communications Manager to trust the MIC certificate, it utilizes the pre-installed CA certificates CAP-RTP-001, CAP-RTP-002, and Cisco_Manufacturing_CA in its certificate trust store.
- Locally Significant Certificate (LSC): A Locally Significant Certificate (LSC) must be installed on the Cisco IP phone utilizing USB tokens and the certificate trust list (CTL) client (illustrated below). The LSC possesses the public key for the Cisco IP phone, which is signed by the Cisco Unified Communications Manager Certificate Authority Proxy Function (CAPF) private key (illustrated below). This is the preferred method (as opposed to using MICs) because only Cisco IP phones that are manually provisioned by an administrator will be allowed to download and verify the CTL file (illustrated below). Older Cisco IP phones, such as the 7940 and 7960, do not contain MICs. Cisco IP phones require an LSC to operate in secure mode.
Figure 3: How MIC and LSC certificates are installed on a Cisco IP phone
Recommendations:
- Due to the increased security risk, Cisco recommends using MICs solely for LSC installation and not for continued use. Customers who configure Cisco IP phones to use MICs for TLS authentication or for any other purpose do so at their own risk. Cisco assumes no liability if MICs are compromised. For more information, please refer to the Cisco Unified Communications Manager Security Guide.
- The Next Generation Encryption Whitepaper recommends using a minimum 2048-bit key certificate.
Cisco Unified Communications Manager Authentication
When the phone receives the certificate from the server, it is required to verify if it should trust the Cisco Unified Communications Manager public key that is contained within the certificate in order to continue TLS negotiation. The Cisco IP phone authenticates server certificates based on the Cisco Certificate Trust List (CTL) file. The Cisco IP phone will download the CTL file via Trivial File Transfer Protocol (TFTP) during the initial boot and retain it through subsequent reboots. Once the download is complete, the Cisco IP phone will recognize all trusted certificate issuers. The CTL file is equivalent to the pre-configured CA certificate that is utilized by internet client browsers. As we will continue to explain, the CTL file is created with the CTL client and signed by the Cisco Site Administrator Security Token (SAST).
Provisioning Cisco IP phones with LSC Certificates
By default, LSC certificates are not installed on Cisco IP phones. Cisco IP phones that are required to use LSC certificates must be provisioned to allow TLS transactions before deployment in the field. LSC certificates can be provisioned to the Cisco IP phones through the Certificate Authority Proxy Function (CAPF) process. This process is completed using TLS and USB tokens coupled with the CTL client. Moreover, the Cisco ASA Phone Proxy feature can serve LSC certificates to the Cisco IP phones. Cisco IP phones will only work with the Cisco ASA Phone Proxy and will not establish secure connectivity with the Cisco Unified Communications Manager.
Using Cisco Unified Communications Manager (with USB Tokens)
Installing an LSC on a Cisco IP phone requires, at a minimum, two USB tokens and the CTL client. The CTL client is used to generate the necessary certificates on the Cisco Unified Communications Manager. Before utilizing the CTL client, the CTL provider and CAPF services must be enabled on the Cisco Unified Communications Manager cluster. These services enable the Cisco Unified Communications Manager to serve the CTL file request for certificates.
The CTL file should include the Cisco ASA, Cisco Unified Communications Manager and CAPF, which issues identity certificates to the endpoint devices. To clarify, the CTL file provides the Cisco IP phone with the necessary CA certificates, or any certificate, that should be trusted. When downloading a new CTL file, the Cisco IP phone verifies the new CTL signature using the certificates in its CTL file. If no CTL file is present, then the new CTL is not trusted by the Cisco IP phone.
The Certificate Authority Proxy Function (CAPF) processes the elements of the certificate generation procedure that are too processor-intensive for the Cisco IP phone. It interacts with the Cisco IP phone for key generation and certificate installation. The CAPF can be configured to generate certificate requests or local certificates. The CAPF is a process supported by devices that request LSC certificates from the Cisco Unified Communications Manager. The CAPF process utilizes TLS to download the LSC to the Cisco IP phone. To establish the CAPF TLS connection, the Cisco IP phone authenticates the CAPF process certificate using the CAPF CA certificate in the CTL file.
The CAPF process authenticates the Cisco IP phone using the following:
- MIC precedence over LSC
- Existing LSC precedence over MIC
- Authentication string (recommended one-time use)
- No client authentication (recommended only in secure environments)
These options are set by the Cisco Unified Communications Manager in the Cisco IP phone security profile. The option to select authentication methods can be utilized for Cisco IP phones that do not have a MIC or an existing LSC installed.
Cisco IP phones can request the LSC certificate once the CTL provider and CAPF services are enabled and the CTL client builds the CTL file on the Cisco Unified Communications Manager cluster. An LSC is installed on the Cisco IP phone upon completion of the CAPF configuration. Alternatively, the installation of an LSC can be initiated from the security configuration menu on the Cisco IP phone, as described in
Configuring Security on the Cisco Unified IP Phone.
As previously stated, the CTL client builds the signed CTL file on the Cisco Unified Communications Manager using USB tokens. The Cisco Site Administrator Security Token (CAST) is a portable hardware security module that contains a private key and an X.509v3 certificate that is signed by the Cisco CA. The CTL client is run on a PC utilizing the tokens that are connected to the USB port.
The CTL client executes the following tasks:
- The CTL Client sets the Cisco Unified Communications Manager cluster in mixed (secure) mode. The Cisco Unified Communications Manager cluster security parameter cannot be set to mixed mode through the enterprise parameters configuration window of Cisco Unified Communications Manager Administration. Configuring the Cisco CTL client is required to set the cluster security mode. For more information, please refer to theCisco CTL Client Configuration Settings section of the Cisco Unified Communications Manager Security Guide.
- The CTL client writes the CTL file to the Cisco Unified Communications Manager server(s).
- The CTL client writes the CAPF certificate file in Privacy Enhanced Email (PEM) format to all Cisco Unified Communications Manager nodes, excluding the first node, in the cluster. The CAPF certificate is used in a TLS connection between the Cisco IP phone and the Cisco Unified Communications Manager to download the LSC certificate.
- The CTL client writes the file to all configured TFTP servers.
- The CTL client writes the file to all configured Cisco ASA firewalls.
- The CTL client signs the CTL file with the private key (SAST) from the security token (USB token) when the CTL file was created.
Figure 4: CTL file and trusted certificate issuers
The reader should note that a minimum of two security tokens are required to work with the CTL client. The security tokens must originate from Cisco. The tokens are required to be installed in sequence through the USB port connected to the server or workstation. If the system lacks a USB port, you may substitute it with a USB PCI card. The Cisco Part number for the USB eToken is: KEY-CCM-ADMIN-K9=
For more information detailing the steps required to use the CTL client, please refer to the
CTL Client Configuration Checklist in the Cisco Unified Communications Manager Security Guide. To learn how to install the client on a PC, please refer to
Installing the Cisco CTL Client in the Cisco Unified Communications Manager Security Guide.
Recommendations:
If “No Client Authentication” is selected for client authentication in the CAPF, the Cisco IP phones are required to be authenticated locally to the Cisco Unified Communications Manager. The Cisco IP phones should not be provisioned over the internet. If “String Authentication” is selected, a one-time password is recommended.
USB tokens are important for security of the voice infrastructure; hence they should be kept in a secure place (for example, a safe) with a limited accessibility.
Subsequent to the provisioning of the Cisco IP phones with LSCs, Cisco recommends removing MIC root certificates from the Cisco Unified Communications Manager Trust Store to avoid future compatibility issues. Administrators should remove the following MIC trusted root certificates from the Cisco Unified Communications Manager Trust Store: CAP-RTP-001, CAP-RTP-002, Cisco_Manufacturing_CA and Cisco_Root_CA_2048. Before deleting them, a PEM format backup copy of these certificates should be exported from the Cisco Unified Communications Manager. In the event the certificates are required to be re-imported to provision Cisco IP phones utilizing MICs, a backup copy is readily available.
Caution: There are a number of Cisco IP phone models that do not have an LSC installed to create a TLS connection to the Cisco Unified Communications Manager. Those models will not successfully register.
A note concerning Cisco IP phone image and configuration security: Previously discussed in this document, we have demonstrated how TLS can secure signaling and voice communications. Moreover, Cisco Unified Communications Manager can secure the TFTP Cisco IP phone image and configuration downloads by signing and encrypting the configuration. Configuration encryption utilizes a symmetric key which is encrypted with the Cisco IP phones public key and appended to the encrypted configuration file. The Cisco IP phone applies the key in the CTL file to verify the signed image or configuration signature and applies its private key (MIC or LSC) to decrypt the symmetric key and the configuration.
A note concerning securing the SIP Trunk: Cisco Unified Communications Manager supports secure Session Initiation Protocol (SIP) communications with a SIP Trunk. This functionality sets up SIP-TLS communication between the Cisco Unified Communications Manager and the SIP Trunk. For more information, please refer to
Configuring the SIP Trunk Security Profile.
For devices that do not support TLS, SIP “Digest Authentication” can be used with Hashed Message Authentication Code (HMAC) to authenticate SIP using a key provided in the Cisco IP phone configuration. To prevent the key from theft, the downloaded TFTP configuration must be encrypted. (see “
A note concerning Cisco IP phone image and configuration security” described above) For more information, please refer to
Configuring Digest Authentication for the SIP Trunk.
A note concerning the Secure Remote Site Telephony (SRST) gateway: Included in the Cisco Unified Communications Manager security features, Secure Remote Site Telephony (SRST) operates on Cisco IOS and provides Cisco Unified Communications Manager call processing functions. A SRST enabled gateway provides limited call-processing tasks if the Cisco Unified Communications Manager cannot complete the call.
A SRST enabled gateway contains a self-signed certificate. After completing the requisite SRST configuration in Cisco Unified Communications Manager administration, it establishes a TLS connection to authenticate the certificate provider service in the SRST enabled gateway. Subsequently, Cisco Unified Communications Manager retrieves the certificate from the SRST enabled gateway and adds the certificate to its database.
Following a reset of the dependent devices in Cisco Unified Communications Manager administration, the TFTP server adds the SRST enabled gateway certificate to the Cisco IP phone cnf.xml file and sends the file to the Cisco IP phone. If required, a secure Cisco IP phone utilizes a TLS connection to interact with the SRST enabled gateway.
A note concerning Third-Party CA Certificates: Detailed in the
Cisco Unified Communications Manager Security Guide, Cisco Unified Communications Manager supports integration with third-party certificate authorities (CAs) by utilizing a PKCS#10 certificate signing request (CSR) mechanism. CSR requests are accessible from the Cisco Unified Communications Manager Operating System Certificate Manager menu. Customers who currently utilize third-party CAs should use the CSR mechanism to issue certificates for Cisco Unified Communications Manager, CAPF, IPsec, Tomcat and SRST enabled gateways. Cisco Unified Communications Manager does not provide Simple Certificate Enrollment Protocol (SCEP) support. An example of how to delete and regenerate security certificates is described in the following
whitepaper.
Subsequent to the CSR request, the signed certificate for Cisco Unified Communications Manager, CAPF and others, together with the CA root certificate, are uploaded to the Cisco Unified Communications Manager certification store. The Cisco Unified Communications Manager is able to provide certificates in the CTL file which provides secure Cisco IP phone communications for Cisco Unified Communications Manager TLS and CAPF TLS. Once a third-party a CA signed certificate is uploaded, the administrator must run the CTL client to update the CTL file. After running the CTL client, restarting the appropriate system services is required. For example, restart Cisco Unified Communications Manager and Cisco TFTP services to update the Cisco Unified Communications Manager certificate. Restart CAPF to update the CAPF certificate. Please refer to
Configuring the Cisco CTL Client for a detailed description concerning the update process.
Using Cisco ASA Phone Proxy (without USB tokens)
The Cisco Adaptive Security Appliance (Cisco ASA) Phone Proxy feature allows remote Cisco IP phones to establish secure communication channels directly with the Cisco ASA. These secure communications terminate directly on the firewall. The firewall “proxies” the voice communication, the signaling between the Cisco IP phones and the Cisco Unified Communications Manager, without requiring a separate device to encrypt the traffic to the Cisco Unified Communications Manager or moving the Cisco Unified Communications Manager to Mixed (secure) Mode. The Cisco ASA Phone Proxy is a Cisco licensed feature and was introduced in Cisco ASA version 8.0.
Figure 5 illustrates how Cisco IP phones establish a TLS signaling session to the Cisco ASA. Cisco IP phones pass unencrypted voice signaling to the Cisco Unified Communications Manager through the internal network. TLS communication setup is identical to the TLS negotiation between the Cisco IP phone and Cisco Unified Communications Manager described in the previous section. Subsequently, Cisco IP phones establish secure voice (SRTP) communication that is terminated on the Cisco ASA. Cisco IP phones will function with the Cisco ASA Phone Proxy and will not establish secure connectivity with the Cisco Unified Communications Manager.
Figure 5: Secure voice (SRTP) call set-up with Cisco ASA Phone Proxy
The Cisco ASA Phone Proxy can authenticate Cisco IP phones, using either MIC or LSC certificates, by importing root CA certificates into its trust store. In order for Cisco IP phones to successfully authenticate, the Cisco ASA affixes a certificate utilizing SAST keys in the CTL file to the Cisco IP phone. For more information regarding Cisco ASA Phone Proxy configurations, please refer to the
Cisco Support Community article. To configure a Cisco ASA Phone Proxy via the Cisco Adaptive Security Device Manager (ASDM), please refer to
Cisco ASA Phone Proxy sample configuration via ASDM.
The Cisco ASA Phone Proxy provisions Cisco IP phones with LSC certificates without requiring USB tokens. Phones that import LSC certificates will securely operate with a Cisco ASA Phone Proxy. In order for Cisco IP phones to download the LSC certificates, the Cisco ASA permits the CAPF TLS connection. It does not proxy the CAPF connection. The Cisco ASA requires the CAPF CA root certificate, contained in the CTL file, for the Cisco IP phone to establish a TLS connection with the CAPF process running on the Cisco Unified Communications Manager. Once completed, Cisco IP phones can download the LSC over the CAPF TLS connection. To clarify, the USB tokens are not necessary because the Cisco ASA is serving the CTL file and inserts the CAPF CA certificate, that the Cisco IP phone trusts, to establish the CAPF TLS connection.
SSL VPN client
Beginning with Cisco Unified Communications Manager 8.0 and Cisco Unified Communications Manager Express 8.6, Cisco IP phones located outside of the corporate network are able to register through an SSL VPN connection. The SSL VPN connection is established between a Cisco IP phone and a Virtual Private Network (VPN) head-end. The VPN head-end can be a Cisco Adaptive Secure Appliance (ASA) or Datagram Transport Layer Security (DTLS) enabled on a Cisco IOS SSL VPN router. The encrypted traffic consists of voice and signaling. PC traffic is not encrypted by the Cisco IP phone.
Cisco IP Phones models that support SSL VPN include 7942, 7962, 7945, 7965 and 7975. To support an SSL VPN connection, the Cisco IP phone version must be 9.0(2)SR1S or later. For a list of Cisco IP phones that support the SSL VPN client, go to “Cisco Unified Reporting”, select “Unified CM Phone Feature List” and choose “Virtual Private Network Client” from the pull-down menu. The Cisco Unified Reporting web application, which is accessible from the Cisco Unified Communications Manager console, generates reports for troubleshooting or inspecting cluster data.
Figure 6: SSL VPN from a Cisco IP phone to a VPN endpoint
To establish a VPN connection between a Cisco IP phone and a VPN gateway, the Cisco IP phone is required to be configured with specific VPN configuration parameters consisting of VPN gateway addresses, VPN head-end credentials, user or Cisco IP phone identification and the credential policy. The SSL CA certificates from either Cisco ASA or Cisco IOS are required to be imported into the Cisco Unified Communications Manager VPN gateway configuration. This requirement allows the Cisco IP phone to authenticate to the VPN head-end. The SSL configuration parameters stored on the Cisco IP phone (for example, VPN gateway addresses, and the credential policy) contain sensitive information and should be securely delivered utilizing a signed or encrypted configuration file. Alternatively, the Cisco IP phone can be provisioned internally before the phone is placed outside the corporate network.
Recommendation: If certificates are utilized for VPN authentication; a key size of at least 2048-bit should be used. For more VPN configuration best practices and recommended cryptographic algorithms please refer to the
Next Generation Encryption Whitepaper.
IPsec VPN
When a voice gateway (MGCP or H.323) is engaged in a secure call with an analog phone, SRTP can be used to encrypt the voice traffic. Assuming the endpoint is a Cisco IP phone, the SRTP keying credentials are negotiated through the signaling between the gateways and the Cisco Unified Communications Manager. If the signaling between the gateways and the Cisco Unified Communications Manager is not secure, an attacker could steal the SRTP keys and retrieve the voice conversation. As shown in Figure 7, in order to secure the signaling communications between voice gateways and the Cisco Unified Communications Manager, IPsec can be configured to secure the communication stream.
Figure 7: Secure call framework utilizing Cisco Unified Communications Manager or MGCP gateways
If IPsec is used, the authentication policy utilized for the Internet Key Exchange (IKE) negotiation can be either pre-shared keys or certificates. If certificates are used for IKE negotiation, the CA certificate is required to be installed on both devices, the voice gateway and Cisco Unified Communications Manager Trusted Certificate Store, in order for the devices to be able to successfully authenticate.
If FIPS 140-2 compliance mode is utilized in Cisco Unified Communications Manager, certificate authentication and secure algorithms will be enabled in the IPsec transformation sets.
For more information, please refer to the
IPsec Management section of the Cisco Unified Communications Manager OS Administration Guide and
Configuring a Secure MGCP Gateway.
Recommendation: If certificate authentication is selected in IKE, a key certificate size of 2048-bit is recommended. For more VPN configuration best practices and recommended cryptographic algorithms of the IPsec VPN configuration, please refer to
Next Generation Encryption Whitepaper.
Conclusion
In conclusion, securing Cisco IP phone communications is important for organizations in order protect trade secrets and to facilitate business and compliance requirements. This whitepaper describes several options for securing voice communications between Cisco IP phones. Voice is secured utilizing the SRTP protocol by exchanging keying material through signaling sessions. Signaling is secured using TLS or VPNs. Given the various methodologies for securing voice communication, certificates can play an important role in the authentication of voice endpoints. Moreover, administrators should utilize LSC certificates on Cisco IP phones whenever possible. USB security tokens, used for CTL installation on the Cisco Unified Communications Manager in secure mode, must be securely stored. The best practices and considerations described in this paper should be thoughtfully considered.
Appendix
Figure 8: Secure voice (SRTP) call set-up
After the client “hello”, which includes a random number1 and the cryptographic algorithms (Ciphersuites) supported by the Cisco IP phone are initiated, the Cisco Unified Communications Manager sends the certificate containing its public key, a random number2, the algorithm it chooses and requests a certificate from the Cisco IP phone.
The Cisco IP phone sends the certificate containing its public key and a CertificateVerify. The public key is encrypted with the server’s public key pre-master secret consisting of the version and a random number. The CertificateVerify contains the signature of previous handshake messages coupled with the Cisco IP phone’s private key. The CertificateVerify proves that the Cisco IP phone owns its private key. Next, the Cisco IP phone announces that it will begin sending encrypted data (ChangeCipherSpec) and transmits an encrypted VerifyData message with the master key. The master key is derived from a pseudo-random function (PRF) that utilizes the pre-master secret, master secret, random number1 and random number2. TheVerifyData is generated by the PRF with the master secret, “client finished” and hashes of previous handshake messages. At this point, the client has proven that it previously participated in the negotiation and has the master key for the session.
Subsequently, the Cisco Unified Communications Manager server sends a ChangeCipherSpec to notify the Cisco IP phone the process is complete. Next, it will proceed with encrypting the data by sending a VerifyData message. The VerifyData message is encrypted with the master key and is derived based on the process described in the previous paragraph. This process is required so the client and server can establish a master secret and encrypt, utilizing Ciphersuites symmetric key cryptography, SIP or SCCP communications.
Cisco IP phones utilize this process to register with Cisco Unified Communications Manager over TLS (steps 1 and 2 in Figure 8). Through a secure control channel within the Cisco Unified Communications Manager, Cisco IP phones can initiate a secure voice call using SRTP. SRTP is not supported unless TLS is used to secure SIP or SCCP.
The reader should note that the process described in the previous paragraph is not a sequence of handshake packets that will be identical in every SIP or SCCP TLS event. The packet exchanges could be divided into additional messages and the steps for TLS establishment could be different. Moreover, the algorithms used in the negotiation could change based on the negotiated Ciphersuites, but the concept behind the certificate and master key creation will be similar.
No comments:
Post a Comment