Cisco Unified CallManager Security Guide, Release 4.2(1)
Security Overview
Downloads: This chapterpdf (PDF - 334.0KB) The complete bookPDF (PDF - 1.85MB) | Feedback

Security Overview

Table Of Contents

Security Overview

Authentication and Encryption Terminology

System Requirements

Interactions and Restrictions

Installing Security

Adding a New Server to a Secure Cluster

Backing Up and Restoring Security

Restoring Data Only

Replacing an Existing or Failed Secure Publisher Database Server

Replacing an Existing/Failed Secure Subscriber Server

Restoring the Cisco CallManager Cluster That Uses Security

Certificate Types

Authentication and Integrity Overview

Encryption Overview

Configuration Checklist Overview

Where to Find More Information


Security Overview


Implementing authentication and encryption in the Cisco CallManager system prevents identity theft of the phone/Cisco CallManager server, data tampering, and call-signaling/media-stream tampering. To prevent these threats, the Cisco IP telephony network establishes and maintains authenticated communication streams, digitally signs files before the file is transferred to the phone, and encrypts media streams and call signaling between Cisco IP Phones.

This chapter provides information on the following topics:

Authentication and Encryption Terminology

System Requirements

Interactions and Restrictions

Best Practices

Resetting the Devices, Restarting Services, or Rebooting the Server/Cluster

Installing Security

Adding a New Server to a Secure Cluster

Backing Up and Restoring Security

Certificate Types

Authentication and Integrity Overview

Encryption Overview

Configuration Checklist Overview

Where to Find More Information

Authentication and Encryption Terminology

The definitions in Table 1-1 apply when you configure authentication and encryption for your Cisco IP telephony network:

Table 1-1 Terminology 

Term
Definition

Authentication

Process that verifies the identity of an entity.

Certificate Authority (CA)

Entity that issues certificates; may be a Cisco or third-party entity.

Certificate Authority Proxy Function (CAPF)

Process whereby supported devices can request locally significant certificates by using Cisco CallManager Administration.

Certificate Trust List (CTL)

List that Cisco IP Phones use; a file that you create after you install and configure the Cisco CTL client in the Cisco CallManager cluster; contains a predefined list of trusted items that the Cisco Site Administrator Security Token (security token) signs; provides authentication information to validate the certificates for servers and security tokens for Cisco IP Phones.

Cisco Site Administrator Security Token (security token; etoken)

A portable hardware security module that contains a private key and an X.509v3 certificate that the Cisco Certificate Authority signs; used for file authentication, it signs the CTL file and retrieves the private key of the certificate.

Device Authentication

Process that validates the identity of the device and ensures that the entity is what it claims to be.

Encryption

Process that ensures that only the intended recipient receives and reads the data; process that ensures the confidentiality of the information; process that translates data into ciphertext, which appears random and meaningless.

File Authentication

Process that validates digitally signed files that the phone downloads. The phone validates the signature to make sure that file tampering did not occur after the file creation.

Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS)

An IETF-defined protocol that ensures (at a minimum) the identity of the HTTPS server; by using encryption, ensures the confidentiality of the information that is exchanged between the IIS server and the browser client.

Image Authentication

Process that prevents tampering with the binary image prior to loading it on the phone; process whereby a phone validates the integrity and source of an image.

Integrity

Process that ensures that data tampering has not occurred between entities.

Locally Significant Certificate (LSC)

A digital X.509v3 certificate that is installed on the phone; issued by a third-party certificate authority or CAPF.

Manufacture-Installed Certificate (MIC)

A digital X.509v3 certificate that is signed by the Cisco Certificate Authority and installed in supported phones by Cisco manufacturing.

Man-in-the-Middle Attacks

Process that allows an attacker to observe and modify the information flow between Cisco CallManager and the phone.

Media Encryption

Process whereby the confidentiality of the media occurs by using cryptographic procedures. Media encryption uses Secure Real Time Protocol (SRTP) as defined in IETF RFC 3711.

Mixed Mode

Mode within a cluster that you configured for security; includes authenticated and nonauthenticated devices that connect to the Cisco CallManager.

Nonsecure Call

Call in which at least one device is not authenticated or encrypted.

Secure Call

Call in which all devices are authenticated, and the media stream is encrypted.

Signaling Authentication

Process that validates that no tampering occurred to signaling packets during transmission; uses the Transport Layer Security protocol.

Signaling Encryption

Process that uses cryptographic methods to protect the confidentiality of all SCCP signaling messages that are sent between the device and the Cisco CallManager server.

Secure Survivable Remote Site Telephony (SRST) References

Gateways, which authenticate to secure phones, that perform limited call-processing tasks if the Cisco CallManager cannot perform the tasks.

Transport Layer Security (TLS)

A security protocol that IETF defines and that provides integrity, authentication, and encryption and resides in the TCP layer in the IP communications stack.


System Requirements

The following system requirements exist for authentication or encryption:

Cisco CallManager 4.1(3) serves as the minimum requirement for each server in the cluster.

Cisco-provided operating system version 2000.2.6 (or later) serves as the minimum requirement for each server in the cluster. Verify that you have installed the latest operating system service release that goes with operating system 2000.2.6 (or later).

Before you install the Cisco CTL client, verify that the workstation or server runs Windows 2000 sp3a (or later).

Before you configure voice mail ports for security, verify that you installed Cisco Unity 4.0(5) or later.

The same Windows administrator username and password must exist on each server in the cluster.

Many requirements exist for the Certificate Authority Proxy Function. For Certificate Authority Proxy Function (CAPF) information, see the "CAPF System Interactions and Requirements" section.

Related Topics

Interactions and Restrictions

Installing Security

Configuration Checklist Overview

Troubleshooting

CAPF System Interactions and Requirements

Interactions and Restrictions

This section contains information on the following topics:

Restrictions

Best Practices

Resetting the Devices, Restarting Services, or Rebooting the Server/Cluster

Restrictions

Consider the following restrictions before you install and configure the authentication and encryption features:

Auto-registration does not work when you configure the cluster for mixed mode, which is required for device authentication.

You cannot implement signaling or media encryption if device authentication does not exist in the cluster; that is, if you do not install and configure the Cisco CTL client.

If you use a multicluster TFTP configuration, you must configure all Cisco CallManager clusters for the same security mode through the Cisco CTL client. You must install the Cisco CTL client in each cluster and choose the same clusterwide security mode during the configuration.


Caution Ensure that the TFTP path and alternate TFTP paths for building configuration files are unique; if the paths are not unique, a TFTP server may overwrite the CTL file that the other cluster creates.

Cisco does not support Network Address Translation (NAT) with Cisco CallManager if you configure the cluster for mixed mode; Application Layer Gateways (ALG) that allow VoIP to traverse firewalls and NAT do not work with signaling encryption.

You can enable UDP ALG in the firewall to allow media stream firewall traversal. Enabling the UDP ALG allows the media source on the trusted side of the firewall to open a bidirectional media flow through the firewall by sending the media packet through the firewall.


Tip Hardware DSP resources cannot initiate this type of connection, and, therefore, must exist outside of the firewall.


Signaling encryption does not support NAT traversal. Instead of using NAT, consider using LAN extension VPNs.

A Cisco IP Phone 7970 user cannot barge into an encrypted call if the Cisco IP Phone 7970 that is used to barge is not configured for encryption. When barge fails in this case, a busy tone plays on the phone where the user initiated the barge.

If the initiator phone is configured for encryption, the barge initiator can barge into an authenticated or nonsecure call from the encrypted phone. After the barge occurs, Cisco CallManager classifies the call as nonsecure.

If the initiator phone is configured for encryption, the barge initiator can barge into an encrypted call, and the phone indicates that the call state equals encrypted.

A user can barge into an authenticated call, even if the phone that is used to barge is nonsecure. The authentication icon continues to display on the authenticated devices in the call, even if the initiator phone does not support security.


Tip You can configure cbarge if you want barge functionality, but Cisco CallManager automatically classifies the call as nonsecure.


If you configure encryption for Cisco IP Phone models 7960 and 7940, those encrypted devices cannot accept a barge request when they are participating in an encrypted call. When the call is encrypted, the barge attempt fails. A tone plays on the phone to indicate that the barge failed.

A message displays in Cisco CallManager Administration when you attempt the following configuration:

In the Phone Configuration window, you choose Encrypted for the Device Security Mode (or System Default equals Encrypted), On for the Built In Bridge setting (or default setting equals On), and you click Insert or Update after you create this specific configuration.

In the Enterprise Parameter window, you update the Device Security Mode parameter.

In the Service Parameter window, you update the Built In Bridge Enable parameter.

The following information applies for Cisco IP Phone models 7960 or 7940 that are configured for encryption and associated with a wideband codec region. To establish an encrypted call, Cisco CallManager ignores the wideband codec and chooses another supported codec from the codec list that the phone presents. If the other devices in the call are not configured for encryption, Cisco CallManager may establish the authenticated/nonsecure call by using the wideband codec.

Cisco CallManager supports authenticated and encrypted calls between secure Cisco IP Phones and secure IOS gateways within a single cluster where no media resources are used. For example, Cisco CallManager 4.1(3) does not provide authentication, integrity, or encryption in the following cases:

Computer Telephony Integration (CTI) devices; some gateways; intercluster trunks; transcoders; media termination points

Calls that are made over two different clusters

Ad hoc or Meet Me conferences

Music on hold

Session Initiation Protocol (SIP) and H.323 devices

Some Cisco IP Phones models


Tip The encryption lock icon indicates that the media stream between the Cisco IP devices is encrypted.

The encryption lock icon may not display on the phone when you perform tasks such as conferencing, transferring, or putting a call on hold; the status changes from encrypted to nonsecure if the media streams that are associated with these tasks are not encrypted.



Tip Do not use Terminal Services to install the Cisco CTL client. Cisco installs Terminal Services, so Cisco Technical Assistance Center (TAC) can perform remote troubleshooting and configuration tasks.

Using CAPF may cause high CPU utilization. Generate certificates when minimal call processing occurs.


When the cluster security mode equals nonsecure, the device security mode is nonsecure in the phone configuration file, even though Cisco CallManager Administration may indicate that the device security mode is authenticated or encrypted. Under these circumstances, the phone attempts nonsecure connections with the SRST-enabled gateway and the Cisco CallManager servers in the cluster.

When the cluster security mode equals nonsecure, the security-related configuration in Cisco CallManager Administration is ignored; for example, the device security mode, the IS SRST Secure check box, and so on. The configuration is not deleted in Cisco CallManager Administration, but security is not provided.

The phone attempts a secure connection to the SRST-enabled gateway only when the cluster security mode equals Mixed Mode, the device security mode in the phone configuration file is set to authenticated or encrypted, the Is SRST Secure? check box is checked in the SRST Configuration window, and a valid SRST certificate and a valid SRST certificate exists in the phone configuration file.

Best Practices

Cisco strongly recommends the following best practices:

Always perform installation and configuration tasks in a secure lab environment before you deploy to a wide-scale network.

Cisco CallManager 4.1 automatically installs LDAPS (LDAP over SSL) for DC Directory. If you integrate your corporate directory, for example, Microsoft Active Directory or Netscape Server Directory, with Cisco CallManager, you can configure an option to support SSL. For information on how to perform this task, refer to the document, Installing Cisco Customer Directory Configuration Plugin for Cisco CallManager 4.0(1).

For a list of Cisco-provided applications that use LDAPS, refer to the Cisco CallManager System Guide.

Configure Cisco MultiLevel Administration, as described in the Cisco CallManager Administration Guide and Cisco CallManager System Guide.

Use the features that are described in this document in conjunction with the latest Cisco-provided operating system service releases and upgrades that are available on cisco.com.

Use the features that are described in this document in conjunction with the Cisco Security Agent that supports this release of Cisco CallManager.

Use the features that are described in this document with Cisco-approved, third-party security applications; for example, McAfee antivirus software.

To prevent toll fraud, configure conference enhancements that are described in the Cisco CallManager System Guide. Likewise, you can perform configuration tasks to restrict external transferring of calls. For information on how to perform this task, refer to the Cisco CallManager Features & Services Guide.

Configure SRST references and SRST-enabled gateways for security, as described in the "Configuring a Secure Survivable Remote Site Telephony (SRST) Reference" section and the Cisco IOS SRST Version 3.3 System Administrator Guide that supports this version of Cisco CallManager. You can obtain the SRST administration guide at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/voice/srst/srst33/srst33ad/index.htm

Configure Cisco Unity for security; configure voice mail ports for security in Cisco CallManager Administration.

Configure Cisco IOS MGCP gateways for encryption, as described in the "Configuring a Secure MGCP Gateway" section.

Configure IPSec in the network infrastructure, as described in the "Configuring a Secure MGCP Gateway" section.

Resetting the Devices, Restarting Services, or Rebooting the Server/Cluster

This section describes when you need to reset the devices, to restart services in Cisco CallManager Serviceability, or to reboot the server/cluster.

Consider the following guidelines:

Reset a single device (phones or voice mail ports) after you change the device security mode in Cisco CallManager Administration.

Reset the devices if you perform phone-hardening tasks.

Reset the devices after you change the clusterwide security mode from mixed to nonsecure mode (or vice versa).

Restart all devices after you configure the Cisco CTL client or update the CTL file.

Reset dependent devices after you configure secure SRST references.

Restart the Cisco CTL Provider service after you update ports for the TLS connection.

Restart the Cisco CallManager service after you change the clusterwide security mode from mixed to nonsecure mode (or vice versa).

Restart the Cisco Certificate Authority Proxy Function service after you update associated CAPF enterprise and service parameters.

Restart all Cisco CallManager and Cisco TFTP services in Cisco CallManager Serviceability after you configure the Cisco CTL client or update the CTL file. Perform this task on all servers that run these services.

Restart the Cisco CallManager service on each server in the cluster after you install the Cisco Unity certificate on each server in the cluster.

Reboot the server where you installed the Cisco CTL client if you set the Smart Card service to Started and Automatic.

To restart a service, refer to the Cisco CallManager Serviceability Administration Guide.

To reset a single device after updating the configuration, see the "Configuring the Device Security Mode for a Single Device" section.

To reset all devices in the cluster, perform the following procedure:

Procedure


Step 1 In Cisco CallManager Administration, choose System > Cisco CallManager.

Step 2 In the pane on the left side of the window, choose a server.

Step 3 Click Reset Devices.

Step 4 Perform Step 2 and Step 3 for each server in the cluster.


Related Topics

System Requirements

Configuring the Cisco CTL Client

Using the Certificate Authority Proxy Function

Configuration Checklist Overview

Troubleshooting

Installing Security

To obtain authentication support, you install a plug-in, the Cisco CTL client, from Cisco CallManager Administration. You must install the Cisco CTL client on a single Windows 2000 server or workstation that has a USB port. If you choose to do so, you can install the client on a Cisco CallManager server that has a USB port. To install the Cisco CTL client, you must obtain at least two security tokens.

Media and signaling encryption automatically install when you install Cisco CallManager.

Cisco CallManager automatically installs Secure Sockets Layer (SSL) for Cisco CallManager virtual directories.

Cisco Certificate Authority Proxy Function (CAPF) installs automatically as a part of Cisco CallManager Administration.

Related Topics

Configuring the Cisco CTL Client

Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS)

Adding a New Server to a Secure Cluster

After you perform the installation procedures that are described in the Cisco CallManager installation guide, run the CTL client to update the CTL file; make sure that you click the Update CTL file radio button and sign the file with a token that exists in the file and that the phone trusts. If you add several servers at the same time, run the CTL client after you install Cisco CallManager on all new servers. Finally, if you want to do so, run BARS to back up the latest version of the CTL file.


Tip Ensure that the Cisco CTL Provider service is activated and running in Cisco CallManager Serviceability. If the service is not running, the CTL operations fail.


Related Topic

Cisco CallManager installation guide

Configuring the Cisco CTL Client

Cisco IP Telephony Backup and Restore (BARS) Administration Guide

Backing Up and Restoring Security

This section contains information on the following topics:

Restoring Data Only

Replacing an Existing or Failed Secure Publisher Database Server

Replacing an Existing/Failed Secure Subscriber Server

Restoring the Cisco CallManager Cluster That Uses Security

If you configure security in your cluster, the following information applies for backups and restorations:

Use the latest version of the Cisco IP Telephony Backup and Restore System (BARS) utility to back up data.

BARS backs up the CTL file and security-related configuration that exists in the database.

Unless stated in this security document, all guidelines in the Cisco IP Telephony Backup and Restore System (BARS) Administration Guide apply.

For a list of Cisco CallManager data that gets backed up and restored, refer to the Cisco IP Telephony Backup and Restore System (BARS) Administration Guide.


Tip All CTL operations depend on the Cisco CTL Provider service in Cisco CallManager Serviceability. Ensure that the service is activated and running when you use the CTL client.


Restoring Data Only

If you implemented security, you must update the CTL file after you restore the data; sign the CTL file with a token that exists in the file and that the phone trusts.

For data restorations, you do not need to re-create the Cisco CallManager self-signed certificate/keys or the CAPF certificate/keys. If you copied the Cisco Unity certificate to all servers in the cluster prior to the data restoration, you do not need to copy the certificate again.

Related Topics

Updating the CTL File

Cisco IP Telephony Backup and Restore System (BARS) Administration Guide

Replacing an Existing or Failed Secure Publisher Database Server

When you replace an existing/failed publisher database server, the Cisco CallManager installation automatically installs the Cisco CallManager self-signed certificate/keys and the CAPF certificate/keys on the server.

If you need to replace or rebuild an existing/failed publisher database server and you configured security prior to the replacement/rebuild, perform the following procedure:

Procedure


Step 1 Obtain at least one token that exists in the current CTL file and that the phone trusts. You must use the token in Step 9.

Step 2 Use the latest version of BARS to back up the Cisco CallManager data on the existing publisher database server.

Step 3 On the new or rebuilt server, perform the following operating system tasks:

a. Use the Cisco-provided disks to install the Windows 2000 operating system.

b. Upgrade the operating system to match the version that currently runs in the cluster.

c. Apply operating system service releases to match the version that runs in the cluster.

Step 4 On the new or rebuilt server, perform the following Cisco CallManager installation tasks:

a. Use Cisco-provided disks to install Cisco CallManager.

b. Upgrade Cisco CallManager to match the version that runs in the cluster.

c. Apply Cisco CallManager service releases and engineering specials to match the version that runs in the cluster.

Step 5 On the new or rebuilt server, install the version of BARS that created the backup file in Step 2.

Step 6 Use BARS to restore the data on the new or rebuilt publisher database server.

Step 7 Verify that the restored data exists on the publisher database server.

Step 8 If the CTL client exists on a subscriber server or a PC/workstation, go to Step 9. If the CTL client existed on the failed publisher database server, go to Cisco CallManager Administration and install the CTL client.


Tip Because the CTL file gets restored, do not choose the Mixed Mode or Non-secure cluster security option after you launch and run the CTL client.


Step 9 Run the CTL client to update the CTL file; make sure that you click the Update CTL file radio button and sign the file with a token that exists in the file and that the phone trusts.

Step 10 Restart the Cisco TFTP and Cisco CallManager services.

Step 11 Reset all devices.


Related Topics

Cisco IP Telephony Backup and Restore System (BARS) Administration Guide

Configuring the Cisco CTL Client

Resetting the Devices, Restarting Services, or Rebooting the Server/Cluster

Installing the Operating System on the Cisco IP Telephony Applications Server

Cisco CallManager installation and upgrade documents

Cisco CallManager Serviceability Administration Guide

Replacing an Existing/Failed Secure Subscriber Server

If you are replacing an existing/failed secure subscriber server and you configured security prior to the replacement/rebuild, perform the following tasks:

Procedure


Step 1 Obtain at least one token that exists in the current CTL file and that the phone trusts. You must use the token in Step 5.

Step 2 On the new or rebuilt subscriber server, perform the following operating system tasks:

a. Use the Cisco-provided disks to install the Windows 2000 operating system.

b. Upgrade the operating system to match the version that currently runs in the cluster.

c. Apply operating system service releases to match the version that currently runs in the cluster.

Step 3 On the new or rebuilt subscriber server, perform the following Cisco CallManager installation tasks:

a. Use Cisco-provided disks to install Cisco CallManager.

b. Upgrade Cisco CallManager to match the version that runs in the cluster.

c. Apply Cisco CallManager service releases and engineering specials to match the version that runs in the cluster.

Step 4 If the CTL client exists on the publisher database server or a PC/workstation, go to Step 5. If the CTL client existed on the failed subscriber server, browse to Cisco CallManager Administration and install the CTL client.


Tip Because the CTL file gets restored, do not choose the Mixed Mode or Non-secure cluster security option after you launch and run the CTL client.


Step 5 Run the CTL client to update the CTL file; click the Update CTL File radio button and sign the file with a token that existed in the file and is trusted by the phones.

Step 6 Restart the Cisco CallManager service.

Step 7 Reset all devices.


Related Topics

Cisco IP Telephony Backup and Restore System (BARS) Administration Guide

Configuring the Cisco CTL Client

Resetting the Devices, Restarting Services, or Rebooting the Server/Cluster

Installing the Operating System on the Cisco IP Telephony Applications Server

Cisco CallManager installation and upgrade documents

Cisco CallManager Serviceability Administration Guide

Restoring the Cisco CallManager Cluster That Uses Security

The Cisco IP Telephony Backup and Restore System (BARS) Administration Guide describes how to restore the entire Cisco CallManager cluster in the unlikely event that every server in the cluster crashes. Before you restore a secure cluster, ensure that your situation meets all of the following criteria:

Every server in the cluster crashed.

You configured security prior to the restoration.

The phones and the backup file contain a valid CTL file.

If your situation meets the preceding criteria, perform the following tasks:

1. Obtain at least two tokens that exist in the current CTL file and that the phone trusts.

2. Restore the entire cluster, as described in the BARS documentation. Start with the publisher database server. After you complete the restoration on the publisher database server, restore the subscriber servers one at a time.

3. If the CTL client existed on a failed server in the cluster, reinstall the CTL client on the new or rebuilt server.

4. Run the CTL client. Click the Update CTL file radio button and make sure that you sign the file with a token that exists in the CTL file and that the phone trusts.


Tip Because the CTL file gets restored, do not choose the Mixed Mode or Non-secure cluster security option after you launch and run the CTL client.


5. Restart the Cisco TFTP and Cisco CallManager services.

6. Reset all devices.

Related Topics

Cisco IP Telephony Backup and Restore System (BARS) Administration Guide

Configuring the Cisco CTL Client

Resetting the Devices, Restarting Services, or Rebooting the Server/Cluster

Certificate Types

Cisco uses the following certificates types in phones and servers:

Manufacture-installed certificate (MIC)—Cisco manufacturing automatically installs this certificate in supported phone models. With certain phone models, one MIC and one locally significant certificate can exist in the same phone, in which case, the LSC takes precedence over the MIC for authentication to the Cisco CallManager after you configure the device security mode for authentication or encryption.

You cannot overwrite or delete the manufacture-installed certificate.

Locally significant certificate (LSC)—This certificate type installs on supported phones after you perform the necessary tasks that are associated with the Cisco Certificate Authority Proxy Function (CAPF). With certain phone models, one LSC and one MIC can exist in the same phone, in which case, the LSC takes precedence over the MIC for authentication to the Cisco CallManager after you configure the device security mode for authentication or encryption.

CAPF certificate—This certificate gets copied to all servers in the cluster after you complete the Cisco CTL client configuration. This certificate installs in C:\Program Files\Cisco\Certificates on each server in the cluster.

HTTPS certificate—When installed on the IIS web site that hosts the Cisco CallManager SSL-enabled virtual directories, this server authentication certificate, httpscert.cer, provides authentication between the IIS server and the browser client. This certificate installs in C:\Program Files\Cisco\Certificates.

Self-signed Cisco CallManager certificate—This certificate, ccmserver.cer, automatically installs when you install Cisco CallManager 4.1.

The Cisco CallManager self-signed certificates provide server identification, including the Cisco CallManager server name and the Global Unique Identifier (GUID). On each server in the cluster, Cisco CallManager stores the certificates, which exist in DER format, in C:\Program Files\Cisco\Certificates. Administrators have read-only access to the certificates.

SRST certificate in the SRST-enabled gateway—This certificate gets added to the Cisco CallManager database after you configure the SRST reference for security and reset the phones. The phone obtains this certificate through the configuration file. This certificate does not exist in the Cisco CTL file. For more information on the SRST certificate in the gateway, refer to the Cisco SRST documentation that supports the gateway.

Cisco Unity server certificate—Cisco Unity uses this certificate, which exists in PEM format, to sign the Cisco Unity SCCP device certificates. The Cisco Unity Telephony Integration Manager manages this certificate. You must manually copy the Cisco Unity server certificate to C:\Program Files\Cisco\Certificates on each server in the cluster.

Cisco Unity SCCP device certificates—Cisco Unity SCCP devices use this signed certificate, which exist in PEM format, to establish a TLS connection with the Cisco CallManager.

Related Topics

Interactions and Restrictions

Installing Security

Authentication and Integrity Overview

Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS)

Configuring the Cisco CTL Client

Using the Certificate Authority Proxy Function

Configuring a Secure Survivable Remote Site Telephony (SRST) Reference

Authentication and Integrity Overview

Integrity and authentication protect against the following threats:

TFTP file manipulation (integrity)

Modification of call-processing signaling between the phone and Cisco CallManager (authentication)

Man-in-the-middle attacks (authentication), as defined in Table 1-1

Device and server identity theft (authentication)

Image Authentication

This process prevents tampering with the binary image, that is, the firmware load, prior to loading it on the phone. Tampering with the image causes the phone to fail the authentication process and reject the image. Image authentication occurs through signed binary files that are automatically installed when you install Cisco CallManager. Likewise, firmware updates that you download from the web also provide signed binary images.

For a list of devices that are supported, see the "Phone Configuration Overview for Security" section.

Device Authentication

This process validates the identity of the device and ensures that the entity is who it claims to be.

Device authentication occurs between the Cisco CallManager server and supported device when each entity accepts the certificate of the other entity; only then does a secure connection between the entities occur. Device authentication relies on the creation of the Cisco CTL file, as described in "Configuring the Cisco CTL Client" section.

File Authentication

This process validates digitally signed files that the phone downloads; for example, the configuration, ring list, locale, and CTL files. The phone validates the signature to verify that file tampering did not occur after the file creation; for a list of devices that are supported, see the "Phone Configuration Overview for Security" section.

The TFTP server does not sign any files if you configure the cluster for nonsecure mode. If you configure the cluster for mixed mode, the TFTP server signs static files, such as ring list, localized, default .cnf.xml, and ring list wav, files in .sgn format. The TFTP server signs files in <device name>.cnf.xml format every time that the TFTP server verifies that a data change occurred for the file.

The TFTP server writes the signed files to disk if caching is disabled. If the TFTP server verifies that a saved file has changed, the TFTP server re-signs the file. The new file on the disk overwrites the saved file that gets deleted. Before the phone can download the new file, the administrator must restart affected devices in Cisco CallManager Administration.

After the phone receives the files from the TFTP server, the phone verifies the integrity of the files by validating the signature on the file. For the phone to establish a TLS connection, ensure that the following criteria are met:

A certificate must exist in the phone.

The CTL file must exist on the phone, and the Cisco CallManager entry and certificate must exist in the file.

You configured the device for authentication or encryption.


Note File authentication relies on the creation of the Certificate Trust List (CTL) file, which is described in the "Configuring the Cisco CTL Client" section.


Signaling Authentication

This process, also known as signaling integrity, uses the TLS protocol to validate that no tampering has occurred to signaling packets during transmission.

Signaling authentication relies on the creation of the Certificate Trust List (CTL) file, which is described in the "Configuring the Cisco CTL Client" section.

Related Topics

System Requirements

Interactions and Restrictions

Configuring the Cisco CTL Client

Using the Certificate Authority Proxy Function

Configuring the Device Security Mode

Troubleshooting

Encryption Overview


Tip Encryption installs automatically when you install Cisco CallManager 4.1 on each server in the cluster.

The files from the security package install in C:\Program Files\Cisco\bin.


Cisco CallManager supports the following types of encryption:

Signaling Encryption

Media Encryption

Signaling Encryption

Signaling encryption ensures that all SCCP signaling messages that are sent between the device and the Cisco CallManager server are encrypted.

Signaling encryption ensures that the information that pertains to the parties, DTMF digits that are entered by the parties, call status, media encryption keys, and so on, are protected against unintended or unauthorized access.

Cisco does not support Network Address Translation (NAT) with Cisco CallManager if you configure the cluster for mixed mode; Application Layer Gateways (ALG) that allow VOIP to traverse firewalls and NAT do not work with signaling encryption.

You can enable UDP ALG in the firewall to allow media stream firewall traversal. Enabling the UDP ALG allows the media source on the trusted side of the firewall to open a bidirectional media flow through the firewall by sending the media packet through the firewall.


Tip Hardware DSP resources cannot initiate this type of connection, and therefore, must exist outside of the firewall.


Signaling encryption does not support NAT traversal. Instead of using NAT, consider using LAN extension VPNs.

Media Encryption

Media encryption, which uses SRTP, ensures that only the intended recipient can interpret the media streams between supported devices. Support includes audio streams only. Media encryption includes creating a media master key pair for the devices, delivering the keys to the devices, and securing the delivery of the keys while the keys are in transport.

Authentication and signaling encryption serve as the minimum requirements for media encryption; that is, if the devices do not support signaling encryption and authentication, media encryption cannot occur.

The following example demonstrates media encryption.

1. Device A and Device B, which support media encryption and authentication, register with Cisco CallManager.

2. When Device A places a call to Device B, Cisco CallManager requests two sets of media session master values from the key manager function.

3. Both devices receive the two sets, one set for the media stream, Device A—Device B, and the other set for the media stream,
Device B—Device A.

4. Using the first set of master values, Device A derives the keys that encrypt and authenticate the media stream, Device A—Device B.

5. Using the second set of master values, Device A derives the keys that authenticate and decrypt the media stream, Device B—Device A.

6. Device B uses these sets in the inverse operational sequence.

7. After the devices receive the keys, the devices perform the required key derivation, and SRTP packet processing occurs.


Tip For a list of supported items, see the "Interactions and Restrictions" section.


Related Topics

System Requirements

Interactions and Restrictions

Configuring the Device Security Mode

Troubleshooting

Configuration Checklist Overview

Table 1-2 describes tasks that you must perform to implement authentication and encryption. Additionally, chapters may contain a checklist for the tasks that you must perform for the specified security feature.

Table 1-2 Configuration Checklist for Authentication and Encryption 

Configuration Steps
Related Procedures and Topics

Step 1 

On each server in the cluster, activate the Cisco CTL Provider service in Cisco CallManager Serviceability.

Tip If you activated this service prior to a Cisco CallManager upgrade, you do not need to activate the service again. The service automatically activates after the upgrade.

Activating the Cisco CTL Provider Service

Step 2 

On the publisher database server, activate the Cisco Certificate Authority Proxy service in Cisco CallManager Serviceability to install, upgrade, troubleshoot, or delete locally significant certificates.

Timesaver Performing this task before you install and configure the Cisco CTL client ensures that you do not have to update the CTL file to use CAPF.

Activating the Certificate Authority Proxy Function Service

Step 3 

If you do not want to use the default settings, configure ports for the TLS connection.

Tip If you configured these settings prior to a Cisco CallManager upgrade, the settings migrate automatically during the upgrade.

Configuring Ports for the TLS Connection

Step 4 

Obtain at least two security tokens and the passwords, hostnames/IP addresses, and port numbers for the servers that you will configure for the Cisco CTL client.

Configuring the Cisco CTL Client

Step 5 

Install the Cisco CTL client.

Tip You cannot use the Cisco CTL client that was available with a previous release of Cisco CallManager. To update the Cisco CTL file after an upgrade to Cisco CallManager 4.1(3), you must install the plug-in that is available in Cisco CallManager Administration 4.1(3). If you do not need to make changes to the file, you do not need to install the 4.1(3) client version.

System Requirements

Installing Security

Installing the Cisco CTL Client

Step 6 

Configure the Cisco CTL client.

Tip If you created the Cisco CTL file prior to a Cisco CallManager upgrade, the Cisco CTL file migrates automatically during the upgrade. To update the Cisco CTL file after an upgrade to Cisco CallManager 4.1(3), you must install and configure the 4.1(3) version of the Cisco CTL client.

Configuring the Cisco CTL Client

Step 7 

Configure CAPF to issue certificates.

If you performed this task for Cisco CallManager 4.1(2), you do not need to perform the task again.

If you performed certificate operations before the upgrade to Cisco CallManager 4.1 and CAPF ran on a subscriber server, you must copy the CAPF data to the 4.0 publisher database server before you upgrade the cluster to Cisco CallManager 4.1. The CAPF data on the Cisco CallManager 4.0 subscriber server does not migrate to the Cisco CallManager 4.1 database, and a loss of data occurs if you do not copy the data to the 4.1 publisher database. If a loss of data occurs, the locally significant certificates that you issued with CAPF utility 1.0(1) remain in the phones, but CAPF 4.1(3) must reissue the certificate, which is not valid.

System Requirements

CAPF Configuration Checklist

Migrating Existing CAPF Data

Copying CAPF 1.0(1) Data from a 4.0 Subscriber Server to the 4.0 Publisher Database Server

Step 8 

Verify that the locally significant certificates installed on supported Cisco IP Phones.

System Requirements

Entering the Authentication String on the Phone

Verifying That a Locally Significant Certificate Exists on the Phone

Step 9 

Configure supported phones for authentication or encryption.

Tip The device configuration migrates automatically during the Cisco CallManager upgrade. If you want to configure encryption for devices that only supported authentication in Cisco CallManager 4.0, you must update the Device Security Mode in the Phone Configuration window in Cisco CallManager Administration.

Configuring the Device Security Mode

Step 10 

Perform phone-hardening tasks.

Tip If you configured phone-hardening settings prior to a Cisco CallManager upgrade, the device configuration settings migrate automatically during the upgrade.

Performing Phone-Hardening Tasks

Step 11 

Configure voice mail ports for security.

Configuring Voice Mail Ports for Security

Cisco CallManager 4.1 Integration Guide for Cisco Unity 4.0

Step 12 

Configure security settings for SRST references.

Tip If you configured secure SRST references in a previous Cisco CallManager release, the configuration automatically migrates during the Cisco CallManager upgrade.

Configuring a Secure Survivable Remote Site Telephony (SRST) Reference

Step 13 

Configure IPSec in the network infrastructure; configure Cisco IOS MGCP gateways for security.

Configuring a Secure MGCP Gateway

IPSec Considerations and Recommendations

Media and Signaling Authentication and Encryption Feature for Cisco IOS MGCP Gateways

Step 14 

Reset all phones in the cluster.

Resetting the Devices, Restarting Services, or Rebooting the Server/Cluster

Step 15 

Reboot all servers in the cluster.

Resetting the Devices, Restarting Services, or Rebooting the Server/Cluster

Where to Find More Information

Related Cisco Documentation

Cisco IP Phone Administration Guide for Cisco CallManager, Cisco IP Phone Models 7960G and 7940G

Cisco IP Phone Administration Guide for Cisco CallManager, Cisco IP Phone Model 7970G

Cisco IP Phone Administrator Guide for Cisco CallManager Models 7902G, 7905G, and 7912G

The firmware release notes that support your phone model

Cisco IP Telephony Solution Reference Network Design Guide

Security application notes for topics, such as toll fraud, operating system hardening, TCP/UDP ports, and so on

Cisco Security Agent documentation that is compatible with the version of Cisco CallManager 4.1 that is installed in the cluster

Readme documentation for Cisco-provided operating system upgrades and service releases that post to cisco.com

Cisco CallManager Administration documentation for multilevel administration access, toll fraud prevention, and SSL usage for directory applications

Media and Signaling Authentication and Encryption Feature for Cisco IOS MGCP Gateways

Cisco CallManager 4.1 Integration Guide for Cisco Unity 4.0

Cisco IOS SRST Version 3.3 System Administrator Guide