Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

CUCM supports PKI-based authentication and encryption features, as illustrated in
Figure 16-1.
Figure 16-1 PKI-Based CUCM Security Features
By using these features, you can secure the following communications:
• Signaling messages between Cisco IP Phones and CUCM or secure Survivable
Remote Site Telephony (SRST) gateways: Cisco Unified IP Phone 7906, 7911,
794[0125], 796[0125], and 797[015] models can be configured to use Transport Layer
Security (TLS) for authenticated and encrypted signaling when Skinny Client Control
Protocol (SCCP) is used. Cisco Unified IP Phone 7906,7911,794[125], 796[125], and
797[015] models can be configured to use TLS for authenticated and encrypted
signaling when session initiation protocol (SIP) is used. Secure SRST currently
supports only SCCP phones.
• Media exchange between IP Phones within a CUCM cluster or between CUCM
clusters that are interconnected with an intercluster trunk: Cisco Unified IP Phone
7906, 7911, 794[0125], 796[0125], and 797[015] models can be configured to use
Secure Real-Time Transport Protocol (SRTP) for authenticated and encrypted media
exchange if they support secure signaling. Secure media exchange is also possible
between IP Phones that use secure signaling when they are registered to a secure SRST
gateway during fallback. Secure media with SRTP prevents playback of captured audio
frames.
NOTE CUCM-to-CUCM intracluster and intercluster communication is not encrypted.
If two Cisco IP Phones are configured to use SRTP and are registered to different CUCM
servers within the cluster or to CUCM servers in different clusters, there is a security risk,
because the SRTP session keys need to be exchanged between the CUCM nodes (in
cleartext). Therefore, if the communication paths between CUCM nodes within a cluster
or the intercluster trunk between two clusters are not trusted, the recommendation is to
use IPsec between the CUCM nodes.
E n a b l i n g P K I - B a s e d S e c u r i t y F e a t u r e s i n C U C M 4 21
• Media exchange between Cisco IP Phones and MGCP or H.323 gateways: Cisco
Unified IP Phone 7906, 7911, 794[0125], 796[0125], and 797[015] models and Cisco
IOS MGCP gateways (running Cisco IOS Software Release 12.3(11)T2 or later) or
Cisco IOS H.323 gateways (running Cisco IOS Software Release 12.4(6)T or later) can
be configured to use SRTP for authenticated and encrypted media exchange if they
support secure signaling.
NOTE When SRTP with an MGCP or H.323 gateway is used, the SRTP session keys
are exchanged in cleartext between CUCM and the MGCP or H.323 gateway. Therefore,
if the communication path between CUCM and the MGCP or H.323 gateway is not
trusted, the recommendation is to use IPsec between CUCM and the MGCP or H.323
gateway.
• Signaling messages between CUCM and secure conference bridges: A secure
conference bridge can use SCCP over TLS.
• Media exchange between Cisco IP Phones and secure conference bridges: A
secure conference bridge can exchange audio with conference members by using
SRTP.
• Cisco IP Phone configuration file content: The CUCM TFTP server supports signed
and encrypted configuration files.
With the current release of CUCM, authenticated and encrypted calls are not possible in
any situation other than those listed here. This includes calls that are connected to media
resources other than secure conferences, including transcoders, Media Termination Points
(MTP), and Music On Hold (MOH).
NOTE Resource Reservation Protocol (RSVP) streams that use pass-through MTPs
(such as when RSVP agents for RSVP-based call admission control [CAC]) are used) do
support SRTP.
Configuration Procedure for PKI-Based CUCM Security Features
The following are the high-level configuration steps for enabling PKI-based security
features in CUCM:
Step 1 Enable security services: The Cisco Certificate Trust List (CTL)
Provider service and the Cisco Certificate Authority Proxy Function
(CAPF) service must be enabled if locally significant certificates (LSC)
are issued.
422 Chapter 16: Implementing Security in CUCM
Step 2 Use the Cisco CTL client to activate security options: The cluster must
be configured for mixed mode, and a signed CTL must be created.
Step 3 Configure devices for security: IP Phones must have certificates (either
manufacturing installed certificates [MIC] or LSCs), IP Phones must be
configured for a security mode (authenticated or encrypted), and the
CAPF parameters must be set for deployment of LSCs. If configuration
files should be encrypted for supported devices, the TFTP Encrypted
Configuration parameter has to be enabled in enterprise parameter
configuration.
Enabling Services Required for Security
Activate the required CUCM services for secure cluster operation from the CUCM
Serviceability Service Activation window, as shown in Figure 16-2.
Figure 16-2 Enabling Services Required for Security
Security Services
| Service Name Activation Status
|7 Cisco CTL Provider Activated
R Cisco Certificate Authority Proxy Function Activated
When security in a CUCM cluster is enabled, the following services must be activated:
• Cisco CTL Provider: This service has to be activated on all CUCM servers and Cisco
TFTP servers of the cluster.
• Cisco Certificate Authority Proxy Function: This service has to be activated on the
publisher server if LSCs are deployed.
Installing the Cisco CTL Client
The Cisco CTL client application is installed from the CUCM Administration Install
Plugins window, as shown in Figure 16-3.
During installation, a prompt for the destination folder appears. You can set any directory,
or you can accept the default.
The Cisco CTL client application can be installed on any PC running Microsoft Windows
2000 or later, as long as that PC has at least one Universal Serial Bus (USB) port.
E n a b l i n g P K I - B a s e d S e c u r i t y F e a t u r e s i n C U C M 4 23
Figure 16-3 Installing the Cisco CTL Client
The Smart Card service has to be activated on the PC. To activate the Smart Card
service under Microsoft Windows 2000, choose Start > Settings > Control Panel >
Administrative Tools > Services to launch the Microsoft services administration tool.
Then use the tool to verify the status of the Smart Card service. Set the startup type to
Automatic and the current Status to Running.
Cisco CTL Client Usage
The Cisco CTL client is needed in the following situations:
• For the initial activation of security in a cluster by setting the cluster security mode to
mixed mode
• For the deactivation or reactivation of security in a cluster
• After modifying CUCM or Cisco TFTP server configuration, which includes adding,
removing, renaming, or restoring a server or changing its IP address, hostname, or
certificate
• After adding or removing a security token
NOTE Reasons to remove a security token include loss or theft of the security token.
• After replacing or restoring a CUCM or Cisco TFTP server
424 Chapter 16: Implementing Security in CUCM
In all the situations listed, the Cisco CTL client creates a new CTL and signs it by using a
security token. The Cisco IP Phones load the new CTL and are then aware of the changes
to the IP telephony system. Any changes that are not reflected in the CTL cause the Cisco
IP Phones to treat the corresponding device as untrusted (for instance, if the IP address
of a server is changed but a new CTL that uses the Cisco CTL client application was
not created). From this perspective, the CTL can be seen as the certificate root store of a
browser (listing all trusted certificate-issuing entities). If any device that was previously
trusted is not trustworthy anymore (for instance, when a security token is lost), there is no
need for a certificate revocation list (CRL). Instead, the Cisco CTL client is used to update
the CRL by removing the untrusted entry (such as a lost security token) from the list.
Setting the Cluster Security Mode
When starting the Cisco CTL client for the first time, either the cluster security mode can
be set, or the CTL file is updated. A CUCM cluster supports two security mode options:
• Mixed mode: This mode allows secure calls between two security-enabled devices
and allows insecure calls between devices where at least one of the devices is not
security-enabled.
• Nonsecure mode: This is the default configuration, in which all calls are insecure.
Figure 16-4 shows how to use the CTL client to enable mixed mode in a CUCM cluster.
Figure 16-4 Setting the Cluster Security Mode
CAPF Configuration and LSC Enrollment 425
NOTE The third option, Update CTL File, lets you create a CTL before enabling
mixed mode in the cluster for preloading IP Phones with CTLs or lets you modify CTL
files, regardless of the cluster security mode.
If no CTL file has been created and the cluster is set to mixed mode, creating the CTL
file is an integrated part of the procedure to set the cluster security mode.
Updating the CTL
In addition to setting the cluster security mode, the Cisco CTL client is used to create or
update the CTL file, along with a physical security token, as shown in Figure 16-5.
Figure 16-5 Updating the CTL
This update is needed after you add or remove components, such as servers or security
tokens. After you change the list of CTL entries, the new CTL needs to be signed using a
security token, as shown in the figure.