Table Of Contents
Security Overview
Authentication and Encryption Terminology
System Requirements
Interactions and Restrictions
Interaction Between Cisco CallManager and the Cisco IP Phone
Restrictions
Best Practices
Resetting the Devices, Restarting Cisco CallManager Service, or Rebooting the Server/Cluster
Authentication and Encryption Installation
Configuration Checklist
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 alleviate these threats, the Cisco IP telephony network establishes and maintains authenticated communication streams between the phone and the server, 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
•
Authentication and Encryption Installation
•
Configuration Checklist
•
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.
|
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.
|
Image Authentication
|
Process that prevents tampering with the binary image prior to loading it on the phone.
|
Device Authentication
|
Process that validates the identity of the device and ensures that the entity is who it claims to be.
|
Signaling Authentication
|
Process that validates that no tampering has occurred to signaling packets during transmission; uses the Transport Layer Security protocol.
|
Certificate Trust List (CTL)
|
Lists that all security-related operations require; a file that is created when you install and configure the Cisco CTL client in the Cisco CallManager cluster; contains a predefined list of trusted items that the Site Administrator Security Token (security token) signs.
|
Mixed Mode
|
Within a cluster that you configured for security, includes devices that are configured for authentication/encryption and phones that are configured as non-secure.
|
Site Administrator Security Token (security token; etoken)
|
A hardware device that you insert in a USB port and that contains a certificate that the Cisco Certificate Authority issued; used for file authentication, it signs the CTL file and retrieves the private key of the certificate.
|
Transport Layer Security (TLS)
|
Protocol that provides integrity, authentication, and encryption through the use of a configured port.
|
Secure Call
|
Call in which all devices are authenticated and the media stream is encrypted.
|
Nonsecure Call
|
Call in which at least one device is not authenticated or encrypted.
|
Integrity
|
Process that ensures that data tampering has not occurred between entities.
|
Encryption
|
Process that ensures that only the intended recipient receives and reads the data; process that translates data into ciphertext, which appears random and meaningless.
|
Signaling Encryption
|
Process that ensures that all SCCP signaling messages that are sent between the device and the Cisco CallManager server are encrypted.
|
Media Encryption
|
Process that ensures that the media streams between supported devices are encrypted.
|
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.
|
Locally Significant Certificate
|
Certificates that are installed on the phone by using CAPF functionality; issued by a certificate authority server or CAPF.
|
Man-in-the-Middle Attacks
|
Process that allows an attacker to observe and modify the information flow between Cisco CallManager and the phone.
|
System Requirements
The following system requirements exist for authentication or encryption:
•
Cisco CallManager 4.0(1) serves as the minimum requirement for each server in the cluster.
•
Operating system 2000.2.5 (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.5 (or later).
•
Before you install the Cisco CTL client, verify that the workstation or server runs Windows 2000 sp3a (or later).
•
The same Windows administrator username and password must exist on each server in the cluster.
Related Topics
•
Interactions and Restrictions
•
Authentication and Encryption Installation
•
Authentication, Integrity, and Encryption
•
Certificate Authority Proxy Function
•
Configuration Checklist
•
Troubleshooting
Interactions and Restrictions
This section contains information on the following topics:
•
Interaction Between Cisco CallManager and the Cisco IP Phone
•
Restrictions
•
Best Practices
•
Resetting the Devices, Restarting Cisco CallManager Service, or Rebooting the Server/Cluster
Interaction Between Cisco CallManager and the Cisco IP Phone
When you install Cisco CallManager 4.0(1) or later, the Cisco CallManager cluster boots up in nonsecure mode; when the phones boot up after the Cisco CallManager installation, all devices register as nonsecure with Cisco CallManager.
The Cisco CallManager installation creates a self-signed certificate on corresponding Cisco CallManager and TFTP servers. After you configure the cluster for authentication, Cisco CallManager uses this self-signed certificate to authenticate with supported Cisco IP Phones.
Note
The features in this document support a limited list of Cisco IP Phone models. For the latest list of supported phones, refer to the phone administration documentation that supports Cisco CallManager 4.0(1).
Cisco CallManager supports authentication, integrity, and encryption for some Cisco IP Phone to Cisco IP Phone calls within a single cluster where no media services are used. Table 1-2 provides a list of supported features on various Cisco IP Phones.
Table 1-2 Features for Cisco IP Phones
Cisco IP Phone Model
|
Supported Feature
|
Cisco IP Phone model 7970
|
Image authentication, file authentication, device authentication, signaling encryption, media encryption, factory reset, and phone hardening, such as web server disabling
|
Cisco IP Phone models 7960 and 7940
|
Image authentication, file authentication, device authentication, customer-site certificate installations, factory resets, and phone hardening, such as web server disabling
|
Cisco IP Phone models 7912, 7910, 7905G, and 7902
|
Image authentication
|
Tip
For information on unsupported scenarios, see the "Restrictions" section.
Note
Calls can only register as secure if you configured the Cisco CallManager cluster for mixed mode and the device(s) support authentication or encryption.
Before you implement all authentication and encryption features across a widespread network, Cisco strongly recommends that you implement them in a secure lab environment and verify that the features behave as expected.
Cisco CallManager maintains the authentication and encryption status at the device level, in this case, with the Cisco IP Phone. If all phones that are involved in the call register as secure, the call status registers as secure. If one of the phones registers as nonsecure, the call registers as nonsecure, even if the phone of the caller or recipient registers as secure.
When a call is held, forwarded, or transferred, the call status may be temporarily nonsecure or unknown until the call between the parties is established.
Cisco CallManager retains the authentication and encryption status of the device when a user uses Cisco CallManager Extension Mobility. Cisco CallManager also retains the authentication and encryption status of the device when shared lines are configured.
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.
•
Application Layer Gateways (ALG) that allow Voice over IP to traverse firewalls and Network Address Translation (NAT) do not work with signaling encryption. For Cisco IOS firewalls, use the UDP ALG. For NAT, route private addresses internally or use route maps; use IPSec and V3PNs for remote locations.
•
Cisco CallManager supports authentication, integrity, and encryption for Cisco IP Phone to Cisco IP Phone calls within a single cluster where no media services are used. For example, Cisco CallManager 4.0(1) does not provide authentication, integrity, or encryption in the following cases:
–
Computer Telephony Integration (CTI) devices; gateways; intercluster trunks; transcoders; media termination points
–
Calls that are made over two different clusters
–
Ad hoc or MeetMe conferences
–
Music on Hold
–
Session Initiation Protocol (SIP), Media Gateway Control Protocol (MGCP), and H.323 devices
–
Survivable Remote Site Telephony (SRST)
–
Some Cisco IP Phones models
Tip
If the call is authenticated or encrypted, the Cisco IP Phone model 7970 displays an icon that indicates the call state.
For a list of supported phones, see Table 1-2, the phone administration documentation that supports this version of Cisco CallManager, or the firmware release notes that support the phone model.
Caution 
Do not use Terminal Services to install the Cisco CTL client or CAPF utility. Cisco installs Terminal Services, so Cisco Technical Assistance Center (TAC) can perform remote troubleshooting and configuration tasks.
Do not use Virtual Network Computing (VNC) to install or configure the Cisco CTL client. If you want to do so, you can use VNC to install the CAPF utility. Using the CAPF utility via VNC may cause high CPU utilization, so do not use VNC when you use the CAPF utility to generate certificates.
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.
•
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, MacAfee antivirus software
•
Use Windows native mode IPSEC for authenticated and encrypted signaling to gateways and other application servers; for example, Cisco Unity, or Cisco IP Contact Center (IPCC), or other Cisco CallManager servers.
Note
This document does not describe Windows IPSEC configuration. For information on IPSEC configuration, refer to the Security Application Notes.
Resetting the Devices, Restarting Cisco CallManager Service, or Rebooting the Server/Cluster
This section describes when you need to reset the devices, restart the Cisco CallManager service in Cisco CallManager Serviceability, or when to reboot the server/cluster.
Consider the following guidelines:
•
Reset a single device 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.
•
Restart the Cisco CallManager service after you change the clusterwide security mode from mixed to nonsecure mode (or vice versa).
•
Reboot all Cisco CallManager and Cisco TFTP servers after you configure the Cisco CTL client or update the CTL file.
•
Reboot the server where you installed the Cisco CTL client if you set the Smart Card service to Started and Automatic.
To restart the Cisco CallManager service, refer to the Cisco CallManager Serviceability Administration Guide.
To reset a single device after updating the configuration, see the "Configuring the Devices for Authentication or Encryption" 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
•
Authentication, Integrity, and Encryption
•
Certificate Authority Proxy Function
•
Configuration Checklist
•
Troubleshooting
Authentication and Encryption Installation
To obtain authentication support, you install a plugin, 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 4.0(1).
Caution 
Cisco recommends that you install and configure the Certificate Authority Proxy Function (CAPF) utility on the publisher database server. If you install and configure it on another server in the cluster, be aware that the utility may adversely affect Cisco CallManager performance. Use the utility during a scheduled maintenance window.
To use the CAPF utility, you must have administrative privileges on the server.
Related Topics
•
Authentication, Integrity, and Encryption
•
Certificate Authority Proxy Function
Configuration Checklist
To implement the features for Cisco CallManager and the Cisco IP Phone, perform the tasks that are described in Table 1-3.
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 the phone model
•
Cisco IP Telephony Solution Reference Network Design Guide
•
Security application notes for 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.0 that is installed in the cluster
•
Readme documentation for Cisco-provided operating system upgrades and service releases that post to cisco.com