Cisco CallManager Security Guide, Release 5.0(1)
Security Overview
Downloads: This chapterpdf (PDF - 394.0KB) The complete bookPDF (PDF - 2.08MB) | Feedback

Security Overview

Table Of Contents

Security Overview

Authentication and Encryption Terminology

System Requirements

Features List

Security Icons

Interactions and Restrictions

Interactions

Restrictions

Authentication and Encryption

Barge and Encryption

Wideband Codecs and Encryption

Media Resources and Encryption

Device Support and Encryption

Phone Icons and Encryption

Cluster and Device Security Modes

Packet Capturing and Encryption

Best Practices

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

Configuring Media Encryption with Barge

Installation

TLS and IPSec

Certificate Types

Authentication, Integrity, and Authorization Overview

Image Authentication

Device Authentication

File Authentication

Signaling Authentication

Digest Authentication

Authorization

Encryption Overview

Signaling Encryption

Media Encryption

Configuration File Encryption

Configuration Checklist Overview

Where to Find More Information


Security Overview


Implementing security mechanisms in the Cisco CallManager system prevents identity theft of the phone/Cisco CallManager server, data tampering, and call-signaling/media-stream tampering. The Cisco IP telephony network:

Establishes and maintains authenticated communication streams.

Digitally signs files before transferring the file to the phone.

Encrypts media streams and call signaling between Cisco IP Phones.

This chapter provides information on the following topics:

Authentication and Encryption Terminology

System Requirements

Features List

Security Icons

Interactions and Restrictions

Installation

TLS and IPSec

Certificate Types

Authentication, Integrity, and Authorization 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

Access control list (ACL)

List that defines rights and permissions to access system functions and resources. See Method List.

Authentication

Process that verifies the identity of an entity.

Authorization

Specifies whether an authenticated user, service, or application has the necessary permissions to perform a requested action; in Cisco CallManager, security process that restricts SUBSCRIBE requests and certain trunk-side SIP requests to authorized users.

Authorization Header

A SIP user agent response to a challenge.

Certificate Authority (CA)

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

Certificate Authority Proxy Function (CAPF)

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

Certificate Trust List (CTL)

Used by phones, a file that automatically gets created after you install and configure the Cisco CTL client; 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; a list with CTL-signed certificates.

Challenge

In digest authentication, a request to a SIP user agent to authenticate its identity by providing a valid private key and other secured data.

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 before making a connection.

Digest Authentication

Used with SIP phones and trunks; process by which Cisco CallManager can challenge the identity of a SIP user agent.

Digest User

User name that is included in the authorization request that SIP phones or SIP trunks send; process to identify SIP source or application users.

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. Requires an encryption algorithm and encryption key.

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 tomcat 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.

IPSec

Provides secure H.225, H.245, and RAS signaling channels for end-to-end security.

Locally Significant Certificate (LSC)

A digital X.509v3 certificate that is installed on the phone or JTAPI/TAPI/CTI application; 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.

Message/Data Tampering

Event when an attacker attempts to alter messages in transit, including ending a call prematurely.

Method List

Tool to restrict certain categories of messages coming in on a SIP trunk during the authorization process; defines which SIP nonINVITE methods are allowed for a trunk-side application or device. Also Method ACL.

Secure Mode

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

Nonce

A unique, random number that the server generates for each digest authentication request.

Nonsecure Call

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

Replay Attack

Event when an attacker captures information that identifies a phone or proxy server and replays information pretending to be the actual device; for example, by impersonating the proxy server's private key.

System Administrator Security Token (SAST)

In CTI/JTAPI/TAPI applications, a token that is used to sign the CTL file for CTL download.

Simple Certificate Enrollment Protocol (SCEP)

An add-on that Microsoft Certificate Services Manager uses to generate certificates with CAPF function.

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 signaling messages that are sent between the device and the Cisco CallManager server.

SIP Realm

A string (name) that specifies protected space in digest authentication; identifies the line or trunk side user agent for the SIP request.

SSL

Part of TLS infrastructure for transport security.

Transport Layer Security (TLS)

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

Trust List

Certificate list without digital signatures.

Trust Store

Contains the list of trusted certificates and their public keys in Cisco CallManager; CA, CAPF, root, and peer certificates get put in the trust store.

X.509

Binary format for importing digital user and CA certificates.


System Requirements

The following system requirements exist for authentication or encryption:

Cisco CallManager 5.0(1) serves as the minimum requirement.

The Administrator password can be different on every server in the cluster.

The username and password used at the Cisco CTLclient (to log into the Cisco CallManager server) is the same as Cisco CallManager Administration username and password (the username and password used to log into the Cisco CallManager Administration).

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

Before you configure voice mail ports for security, verify that you installed a version of Cisco Unity that supports Cisco CallManager 5.0.

Features List

Cisco CallManager system uses a multilayered approach to call security, from the transport layer to the application layer.

Transport layer security includes TLS and IPSec for signaling authentication and encryption to control and prevent access to the voice domain. SRTP adds media authentication and encryption to secure privacy and confidentiality for voice conversation and other media. Media encryption keys derived by Cisco CallManager system securely get sent via encrypted signaling paths to Cisco IP Phones through TLS (or TCP for some phone models) and to gateways over IPSec-protected links.

Table 1-2 provides a summary of security features that Cisco CallManager can implement during a SIP or SCCP call, depending on the features supported and configured.

Table 1-2 Call Processing Security Features List

Security Feature
Line Side
Trunk Side

Transport/Connection/Integrity

Secure TLS port

IPSec associations

Secure TLS port (SIP trunk only)

Device Authentication

TLS certificate exchange w/CAPF

IPSec certificate exchange or pre-shared key

Digest Authentication

SIP phone users only

SIP trunk users or SIP trunk application users only

Signaling Authentication/Encryption

TLS Mode: authenticated or encrypted

IPSec [authentication header, encryption (ESP), or both]

TLS Mode: authenticated or encrypted mode (SIP trunk only)

Media Encryption

SRTP

SRTP

Authorization

Presence SUBSCRIBE requests

Presence SUBSCRIBE requests

Method list

Note: The features supported on a device vary by device type and protocol.


Security Icons

Phones that support security icons display the Cisco CallManager security level that is associated with a call.

The phone displays a shield icon for calls with a signaling security level of authenticated. A shield identifies a secured connection between Cisco IP devices.

The phone displays a lock icon for calls with encrypted media, meaning the media stream between the Cisco IP devices is encrypted.

Refer to "Phone Icons and Encryption" section, for restrictions that are associated with security icons.

Interactions and Restrictions

This section contains information on the following topics:

Interactions

Restrictions

Best Practices

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

Configuring Media Encryption with Barge

Interactions

This section describes how Cisco security features interact with Cisco CallManager applications.

To add presence group authorization for SIP phones and trunks, configure presence groups to restrict presence requests to authorized users.


Note Refer to the Cisco CallManager Features and Services Guide for more information about configuring presence groups.


To allow presence requests on SIP trunks, you must authorize Cisco CallManager to accept presence requests on the SIP trunk and, if required, configure end user clients in Cisco CallManager Administration to allow Cisco CallManager to accept and authenticate incoming presence requests from the remote device and application.

To use SIP-initiated transfer features and other advanced transfer-related features on SIP trunks, such as Web Transfer and Click to Dial, you must authorize Cisco CallManager to accept incoming Out of Dialog REFER requests.

To provide support for event reporting (such as MWI support) and to reduce per-call MTP allocations (from a voice messaging server for example), you must authorize Cisco CallManager to accept Unsolicited Notification SIP requests.

To allow Cisco CallManager to transfer an external call on a SIP trunk to an external device or party (in attended transfer, for example) you must authorize Cisco CallManager to accept SIP requests with replaces header in REFERS and INVITES.

For extension mobility, the SIP digest credentials change when a user logs in and out because different credentials are configured for different end users.

Cisco IPMA supports a secure connection to CTI (transport layer security connection); the administrator must configure a CAPF profile (one for each IPMA node).

When multiple instance of a CTI/JTAPI/TAPI application are running, CTI TLS support requires administrators to configure a unique instanceID (IID) for every application instance to secure signaling and media communication streams between CTI Manager and JTAPI/TSP/CTI applications.

When the device security mode equals authenticated or encrypted, the Cisco Unity-CM TSP connects to Cisco CallManager through the Cisco CallManager TLS port. When the security mode equals nonsecure, the Cisco Unity TSP connects to Cisco CallManager through the Cisco CallManager port.

Restrictions

The following sections describe restrictions that apply to Cisco security features:

Authentication and Encryption

Barge and Encryption

Wideband Codecs and Encryption

Media Resources and Encryption

Device Support and Encryption

Phone Icons and Encryption

Cluster and Device Security Modes

Packet Capturing and Encryption

Authentication and Encryption

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

Auto-registration does not work when you configure the cluster for secure 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 enable the CTL Provider service or install and configure the Cisco CTL client.

Cisco does not support Network Address Translation (NAT) with Cisco CallManager if you configure the cluster for secure mode.

You can enable UDP in the firewall to allow media stream firewall traversal. Enabling UDP 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.

SRTP encrypts voice packets only.

Barge and Encryption

The following restrictions apply to barge and encryption:

A Cisco IP Phone model 7960 (SCCP) and 7970 user cannot barge into an encrypted call if the Cisco IP Phone model 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 apply a security profile that supports encryption, you choose On for the Built In Bridge setting (or default setting equals On), and you click Save after you create this specific configuration.

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

Wideband Codecs and Encryption

The following information applies for Cisco IP Phone models 7960 or 7940 that are configured for encryption and associated with a wideband codec region. This only applies to Cisco IP Phone models 7960 or 7940 that are configured for TLS/SRTP.

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.

Media Resources and Encryption

Cisco CallManager supports authenticated and encrypted calls between secure Cisco IP Phones (SCCP or SIP), secure CTI devices/route points, secure Cisco MGCP IOS gateways, secure SIP trunks, secure H.323 gateways, and secure H.323/H.245/H.225 trunks where no media resources are used. For example, Cisco CallManager 5.0 does not provide media encryption in the following cases:

Calls that involve transcoders or media termination points

Ad hoc or Meet Me conferences

Calls that involve music on hold

Device Support and Encryption

Some phones, such as Cisco IP Phone model 7912, do not support encrypted calls. Some phones support encryption but do not validate certificate signatures. Refer to the Cisco IP Phone administration and user documentation that supports your phone model and this version of Cisco CallManager for more information.

SIP trunks do not support SRTP encryption; Cisco CallManager supports RTP encryption on SIP trunks and secures calls with TLS.


Note Cisco CallManager supports SRTP primarily for IOS gateways and Cisco CallManager H.323 trunks on gatekeeper-controlled and non-gatekeeper-controlled trunks. If SRTP cannot be engaged for a call, Cisco CallManager engages RTP.


Not all phones support encrypted configuration files. Some phones support encrypted configuration files but do not validate file signatures. All phones that support encrypted configuration files require new firmware (except for Cisco IP Phone models 7905 and 7912) that is compatible with this release to receive full encrypted configuration files. Cisco IP Phone models 7905 and7912 use existing security mechanisms and do not require new firmware for this feature.

Refer to "Supported Phone Models" section on page 7-3, for phone support of encrypted configuration files.

Phone Icons and Encryption

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.

Cisco CallManager does not display the lock icon for calls that originate at or terminate to SIP trunk-side connections. Cisco CallManager does not display the shield icon for calls that are transiting H.323 trunks.

Cluster and Device Security Modes

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 gets ignored; for example, the device security mode, the SRST Allowed check box, and so on. The configuration does not get 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 secure, the device security mode in the phone configuration file is set to authenticated or encrypted, the SRST Allowed? check box is checked in the Trunk Configuration window, and a valid SRST certificate exists in the phone configuration file.

Packet Capturing and Encryption

When SRTP encryption is implemented, third-party sniffing tools do not work. Authorized administrators with appropriate authentication can initiate packet capturing in Cisco CallManager Administration with a configuration change in Cisco CallManager Administration (for devices that support packet capturing).

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 IPSec for gateways and other application servers at remote locations; for example, Cisco Unity, or Cisco IP Contact Center (IPCC), or other Cisco CallManager servers.


Caution Failure to use IPSec in these instances results in session encryption keys getting transmitted in the clear.

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.

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

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

Consider the following guidelines:

Reset a single device after you apply a different security profile in Cisco CallManager Administration.

Reset the devices if you perform phone-hardening tasks.

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

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

Reset the devices after you update CAPF enterprise parameters.

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 secure to nonsecure mode (or vice versa).

Restart the Cisco Certificate Authority Proxy Function service after you update associated CAPF 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 all Cisco CallManager and Cisco TFTP services after you start or stop the CTL Provider service.

Reset dependent devices after you configure secure SRST references.

If you set the Smart Card service to Started and Automatic, reboot the server where you installed the Cisco CTL client.

Restart the Cisco IP Manager Assistant (IPMA) service, Cisco WebDialer Web Service, and the Cisco Extended Functions service after you configure the security-related service parameters that are associated with the Application User CAPF Profile.

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 "Applying a SCCP or SIP Phone Security Profile" section on page 5-8.

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

Procedure


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

The Find/List window displays.

Step 2 Click Find.

A list of configured Cisco CallManager servers displays.

Step 3 Choose the Cisco CallManager on which you want to reset devices.

Step 4 Click Reset.

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


Configuring Media Encryption with Barge

Use the following information with the "Barge and Encryption" section.

When you attempt to configure barge for Cisco IP Phone models 7960 and 7940 that are configured for encryption, the following message displays:

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.

The message displays when you perform the following tasks in Cisco CallManager Administration:

In the Phone Configuration window, you choose Encrypted for the Device Security Mode (or System Default equals Encrypted), and 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.


Tip For changes to take effect, you must reset the dependent Cisco IP devices.


Installation

To obtain authentication support, you install a plug-in, the Cisco CTL client, from Cisco CallManager Administration. To install the Cisco CTL client, you must obtain at least two security tokens.

Media and signaling encryption capabilities 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.

TLS and IPSec

Transport security handles the coding, packing, and sending of data. Cisco CallManager provides the following secure transport protocols:

Transport Layer Security (TLS) provides secure and reliable data transfer between two systems or devices, using secure ports and certificate exchange. TLS secures and controls connections between Cisco CallManager-controlled systems, devices, and processes to prevent access to the voice domain. Cisco CallManager uses TLS to secure SCCP calls to SCCP phones and SIP calls to SIP phones or trunks.

IP Security (IPSec) provides secure and reliable data transfer between Cisco CallManager and gateways. IPSec implements signaling authentication and encryption to Cisco IOS MGCP and H.323 gateways. IPSec uses real-time protocol (RTP) for message authentication and to transport the actual date stream in a connection.

Secure RTP (SRTP) can be added to TLS and IPSec transport services for the next level of security on devices that support SRTP. SRTP authenticates and encrypts the media stream (voice packets) to ensure that voice conversations originating at or terminating to Cisco IP Phones and either TDM or analog voice gateway ports are protected from eavesdroppers who may have gained access to the voice domain. SRTP adds protection against replay attacks.

Certificate Types

Certificates secure client and server identities. Cisco uses the following certificate types in phones:

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.

The Certificate Management Tool does not manage these certificates that are stored in the phone.

Cisco uses the following self-signed (own) certificate types in Cisco CallManager servers:

HTTPS certificate (tomcat_cert)—This self-signed root certificate gets generated during the Cisco CallManager installation for the HTTPS server.

Cisco CallManager node certificate (ccmnode_cert)—This self-signed root certificate automatically installs when you install Cisco CallManager 5.0(1) for the Cisco CallManager server. Cisco CallManager certificates provide server identification, including the Cisco CallManager server name and the Global Unique Identifier (GUID).

CAPF certificate (CAPF_cert)—The system copies this root certificate to all servers in the cluster after you complete the Cisco CTL client configuration.

IPSec certificate (ipsec_cert)—This self-signed root certificate gets generated during Cisco CallManager installation for IPSec connections with MGCP and H.323 gateways.

SRST-enabled gateway certificate—When you configure a secure SRST reference in Cisco CallManager Administration, Cisco CallManager retrieves the SRST-enabled gateway certificate from the gateway and stores it in the Cisco CallManager database. After you reset the devices, the certificate gets added to the phone configuration file. Because the certificate is stored in the database, this certificate does not get integrated into the certificate management tool.

After root certificates are installed, certificates get added to the root trust stores to secure connections between users and hosts, integrate application devices, and so on. For security reasons, trusted certificate files typically get stored as an 8-digit number (such as f7a74b2c.0), which represents a c_rehash of the certificate name.

Cisco CallManager imports the following certificate types to the Cisco CallManager trust store:

Cisco Unity server certificate—Cisco Unity uses this self-signed root certificate to sign the Cisco Unity SCCP device certificates. The Cisco Unity Telephony Integration Manager manages this certificate.

Cisco Unity SCCP device certificates—Cisco Unity SCCP devices use this signed certificate to establish a TLS connection with the Cisco CallManager. Every Unity device (or port) gets issued a certificate that is rooted at the Unity root certificate. The Unity certificate name is a hash of the certificate's subject name, which is based on the Unity machine name.

SIP Proxy server certificate—A SIP user agent that connects via a SIP trunk authenticates to Cisco CallManager if the Cisco CallManager trust store contains the SIP user agent certificate and if the SIP user agent contains the Cisco CallManager certificate in its trust store.

Administrators have read-only access to certificates. Administrators can view the fingerprint of server certificates, regenerate self-signed certificates, and delete trust certificates at the Cisco IPT Platform GUI.

Administrators can also regenerate and view self-signed certificates at the command line interface (CLI).


Note Cisco CallManager supports only PEM (.pem) and DER (.der) formatted certificates.


For information on updating the Cisco CallManager trust store, generating Certificate Signing Requests (CSRs), and managing certificates, refer to the Cisco IP Telephony Platform Administration Guide.

Authentication, Integrity, and Authorization 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

Phone and server identity theft (authentication)

Replay attack (digest authentication)

Authorization specifies what an authenticated user, service, or application can do. You can implement multiple authentication and authorization methods in a single session.

See the following sections for information on authentication, integrity, and authorization:

Image Authentication

Device Authentication

File Authentication

Signaling Authentication

Digest Authentication

Authorization

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.

Device Authentication

This process validates the identity of the device and ensures that the entity is who it claims to be. For a list of devices that are supported, see the "Supported Phone Models" section.

Device authentication occurs between the Cisco CallManager server and supported Cisco IP Phones, SIP trunks, or JTAPI/TAPI/CTI applications (when supported). An authenticated connection occurs between these entities only when each entity accepts the certificate of the other entity. This process of mutual certificate exchange is called mutual authentication.

Device authentication relies on the creation of the Cisco CTL file (for authenticating Cisco CallManager server node and applications), as described in "Configuring the Cisco CTL Client" section, and the Certificate Authority Proxy Function (for authenticating phones and JTAPI/TAPI/CTI applications), as described in "Using the Certificate Authority Proxy Function" section.


Tip A SIP user agent that connects via a SIP trunk authenticates to Cisco CallManager if the Cisco CallManager trust store contains the SIP user agent certificate and if the SIP user agent contains the Cisco CallManager certificate in its trust store. For information on updating the Cisco CallManager trust store, refer to the Cisco IP Telephony Platform Administration Guide.


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 "Supported Phone Models" section.

The TFTP server does not sign any files if you configure the cluster for nonsecure mode. If you configure the cluster for secure 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 an authenticated 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 the "Configuring the Cisco CTL Client" section describes.


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 the "Configuring the Cisco CTL Client" section describes.

Digest Authentication

This process for SIP trunks and phones allows Cisco CallManager to challenge the identity of a SIP user agent (UA) when the UA sends a request to Cisco CallManager. (A SIP user agent represents a device or application that originates a SIP message.)

Cisco CallManager acts as a user agent server (UAS) for SIP calls originated by line-side phones or devices reached through the SIP trunk, as a user agent client (UAC) for SIP calls that it originates to the SIP trunk, or a back-to-back user agent (B2BUA) for line-to-line or trunk-to-trunk connections. In most environments, Cisco CallManager acts primarily as B2BUA connecting SCCP and SIP endpoints.

Cisco CallManager can challenge SIP phones or SIP devices connecting through a SIP trunk (as a UAS) and can respond to challenges received on its SIP trunk interface (as a UAC). When digest authentication is enabled for a phone, Cisco CallManager challenges all SIP phone requests except keepalive messages.


Note Cisco CallManager does not respond to challenges from line-side phones.


Cisco CallManager defines a SIP call as having two or more separate call legs. For a standard, two-party call between two SIP devices, two separate call legs exist: one leg between the originating SIP UA and Cisco CallManager (the originating call leg) and the other leg between Cisco CallManager and destination SIP UA (the terminating call leg). Each call leg represents a separate dialog. Because digest authentication is a point-to-point process, digest authentication on each call leg stays independent of the other call legs. SRTP capabilities can change for each call leg, depending on the capabilities negotiated between the user agents.


Tip Digest authentication does not provide integrity or confidentiality. To ensure integrity and confidentiality for the device, configure the TLS protocol for the device, if the device supports TLS. If the device supports encryption, configure the device security mode as encrypted. If the device supports encrypted phone configuration files, configure encryption for the files.


Cisco CallManager server uses a SIP 401 (Unauthorized) message to initiate a challenge, which includes the nonce and the realm in the header. (The nonce specifies a random number that gets used to calculate the MD5 hash.) When a SIP user agent challenges the identity of Cisco CallManager, Cisco CallManager responds to SIP 401 and SIP 407 (Proxy Authentication Required) messages.

After you enable digest authentication for a SIP phone or trunk and configure digest credentials, Cisco CallManager calculates a credentials checksum that includes a hash of the username, password, and the realm. Cisco CallManager encrypts the values and stores the username and the checksum in the database. Each digest user can have one set of digest credentials per realm.


Tip SIP phones can only exist in the Cisco CallManager realm. For SIP trunks, the realm represents the domain that connects through the SIP trunk, such as xyz.com, which helps to identify the source of the request.


When Cisco CallManager challenges a user agent, Cisco CallManager indicates the realm and nonce value for which the user agent must present its credentials. After receiving a response, Cisco CallManager validates the checksum for the username that is stored in the database against the credentials received in the response header from the UA. If the credentials match, digest authentication succeeded, and Cisco CallManager processes the SIP request.

When responding to a challenge from a user agent that is connected through the SIP trunk, Cisco CallManager responds with the Cisco CallManager username and password that are configured for the realm, that is specified in the challenge message header. When Cisco CallManager gets challenged, the Cisco CallManager looks up the username and encrypted password based on the realm that the challenge message specifies. Cisco CallManager decrypts the password, calculates the digest, and presents it in the response message

Administrators configure SIP digest credentials for a phone user or application user. For applications, you specify digest credentials in the Applications User Configuration window in Cisco CallManager Administration. For SIP phones, you specify the digest authentication credentials, which are then applied to a phone, in the End User window in Cisco CallManager Administration.

To associate the credentials with the phone after you configure the user, you choose a Digest User, an end user, in the Phone Configuration window. After you reset the phone, the credentials exist in the phone configuration file that the TFTP server offers to the phone.

If you enable digest authentication for an end user but do not configure the digest credentials, the phone will fail registration. If the cluster mode is nonsecure and you enable digest authentication and configure digest credentials, the digest credentials get sent to the phone and Cisco CallManager still initiates challenges.

Administrators configure the SIP realm for challenges to the phone and for challenges that are received through the SIP trunk.The SIP Realm GUI provides the trunk-side credentials for UAC mode. You configure the SIP realm for phones with the service parameter SIP Station Realm. You must configure a SIP realm and username and password in Cisco CallManager Administration for each SIP trunk user agent that can challenge Cisco CallManager.

Administrators configure the minutes that the nonce value stays valid for the external device before getting rejected and a new number gets generated by Cisco CallManager.

Authorization

Cisco CallManager uses the authorization process to restrict certain categories of messages from SIP phones, from SIP trunks, and from SIP application requests on SIP trunks.

For SIP INVITE messages and in-dialog messages, and for SIP phones, Cisco CallManager provides authorization through calling search spaces and partitions.

For SIP SUBSCRIBE requests from phones, Cisco CallManager provides authorization for user access to presence groups.

For SIP trunks, Cisco CallManager provides authorization of presence subscriptions and certain non-INVITE SIP messages; for example, out-of-dial REFER, unsolicited notification, and any SIP request with the replaces header. You specify authorization in the SIP Trunk Security Profile window when you check the related check boxes in the window.

Authorization occurs for the SIP trunk first (as configured in the SIP Trunk Security Profile) and then for the SIP application user agent on the SIP trunk (as configured in the Application User Configuration), when application-level authorization is configured. For the trunk, Cisco CallManager downloads the trunk ACL information and caches it. The ACL information gets applied to the incoming SIP request. If the ACL does not allow the SIP request, the call fails with a 403 Forbidden message.

If the ACL allows the SIP request, Cisco CallManager checks whether digest authentication is enabled in the SIP Trunk Security Profile. If digest authentication is not enabled and application-level authorization is not enabled, Cisco CallManager processes the request. If digest authentication is enabled, Cisco CallManager verifies that the authentication header exists in the incoming request and then uses digest authentication to identify the source application. If the header does not exist, Cisco CallManager challenges the device with a 401 message.

To enable SIP application authorization on the SIP trunk, you must check the Enable Application Level Authorization check box in the SIP Trunk Security Profile window. Before an application-level ACL gets applied, Cisco CallManager authenticates the SIP trunk user agent through digest authentication. Therefore, you must enable digest authentication in the SIP Trunk Security Profile for application-level authorization to occur.

Encryption Overview


Tip Encryption installs automatically when you install Cisco CallManager 5.0(1) on each server in the cluster.


Cisco CallManager supports the following types of encryption:

Signaling Encryption

Media Encryption

Configuration File Encryption

Signaling Encryption

Signaling encryption ensures that all SIP and 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 secure mode; NAT does 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 the firewall.


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

SIP trunks support signaling encryption but do not support media encryption.

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.

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

For most security-supported devices, 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. Cisco IOS gateways and trunks support media encryption without authentication. For Cisco IOS gateways and trunks, you must configure IPSec when you enable the SRTP capability (media encryption).


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


Secure SIP trunks can support secure calls over TLS; be aware, though, that the trunk supports signaling encryption but does not support media encryption (SRTP). Because the trunk does not support media encryption, the shield icon may display on the phones during the call; that is, if all devices in the call support authentication or signaling encryption.

The following example demonstrates media encryption for SCCP and MGCP calls.

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.


Note SIP phones and H.323 trunks/gateways generate their own cryptographic parameters and send them to Cisco CallManager.


Configuration File Encryption

Cisco CallManager pushes digest credentials and other secured data to the phone as part of the configuration file download for phones that support encrypted configuration files (see "Supported Phone Models" section on page 7-3). Only the device configuration file is encrypted for download. Cisco CallManager encodes and store encryption keys in the database.

To enable encrypted configuration files, set the TFTP Encrypted Configuration enterprise parameter to True.The TFTP server encrypts and decrypts configuration files by using symmetric key and public key encryption. See Chapter 7, "Understanding Encryption of the Phone Configuration File", for more information.

When the TFTP Encrypted Configuration enterprise parameter is set to False, Cisco CallManager displays a warning message that digest credentials will be sent in the clear when digest authentication gets enabled in the SIP phone or trunk security profile.

Configuration Checklist Overview

Table 1-3 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-3 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 first node, 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 port 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 Cisco CallManager 4.0. To update the Cisco CTL file after an upgrade to Cisco CallManager 5.0(1), you must install the plug-in that is available in Cisco CallManager Administration 5.0(1).

System Requirements

Installation

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 5.0(1), you must install and configure the 5.0(1) version of the Cisco CTL client.

Configuring the Cisco CTL Client

Step 7 

Configure the phone security profiles. Perform the following tasks when you configure the profiles:

Configure the device security mode (for SCCP and SIP phones).

The device security mode 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 choose a security profile for encryption in the Phone Configuration window.

Configure CAPF settings (for some SCCP and SIP phones).

Additional CAPF settings display in the Phone Configuration window.

If you plan to use digest authentication for SIP phones, check the Enable Digest Authentication check box.

Configuring a Phone Security Profile, page 5-1

Step 8 

Apply the phone security profiles to the phones.

Applying a SCCP or SIP Phone Security Profile, page 5-8

Step 9 

Configure CAPF to issue certificates to the phones.

If you performed certificate operations before the upgrade to Cisco CallManager 5.0(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 5.0.


Caution The CAPF data on the Cisco CallManager 4.0 subscriber server does not migrate to the Cisco CallManager 5.0(1) database, and a loss of data occurs if you do not copy the data to the 5.0(1) 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 5.0(1) must reissue the certificates, which are no longer valid.

System Requirements

CAPF Configuration Checklist

Step 10 

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

System Requirements

Entering the Authentication String on the Phone

Step 11 

Configure digest authentication for SIP phones.

Configuring Digest Authentication for the SIP Phone, page 8-1

Step 12 

Configure encryption for phone configuration files.

Configuring Encrypted Phone Configuration Files, page 7-1

Step 13 

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.

Phone Hardening, page 9-1

Step 14 

Configure voice mail ports for security.

Configuring Voice Messaging Ports for Security, page 10-1

Cisco CallManager 5.0 Integration Guide for Cisco Unity 4.x

Step 15 

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, page 12-1

Step 16 

Configure IPSec.

Configuring Encryption for Gateways and Trunks, page 13-1

Considerations for Configuring IPSec in the Network Infrastructure, page 13-5

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

Cisco IP Telephony Platform Administration Guide

Step 17 

Configure the SIP trunk security profile.

If you plan to use digest authentication, check the Enable Digest Authentication check box in the profile.

For trunk-level authorization, check the authorization check boxes for the allowed SIP requests.

If you want application-level authorization to occur after trunk-level authorization, check the Enable Application Level Authorization check box.

You cannot check application-level authorization unless digest authentication is checked.

Authorization

Configuring the SIP Trunk Security Profile, page 14-2

Configuring Digest Authentication Enterprise Parameters, page 15-2

Step 18 

Apply the SIP trunk security profile to the trunk.

Applying a SIP Trunk Security Profile, page 14-6

Step 19 

Configure digest authentication for the trunk.

Configuring Digest Authentication for the SIP Trunk, page 15-1

Step 20 

If you checked the Enable Application Level Authorization check box in the SIP trunk security profile, configure the allowed SIP requests by checking the authorization check boxes in the Application User Configuration window.

Cisco CallManager Administration Guide

Step 21 

Reset all phones in the cluster.

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

Step 22 

Reboot all servers in the cluster.

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

Where to Find More Information

Related Cisco Documentation

Refer to the following documents for further information about related Cisco IP telephony applications and products:

Cisco IP Phone Administration Guide for Cisco CallManager

Cisco IP Telephony Platform Administration Guide

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

Cisco CallManager 5.0 Integration Guide for Cisco Unity 4.x

Cisco Survivable Remote Site Telephony (SRST) administration documentation that supports the SRST-enabled gateway

Cisco IP Telephony Disaster Recovery Framework Administration Guide

Cisco CallManager Bulk Administration Guide

The firmware release notes that support your phone model