Unlike classic enterprise PKI deployments, the PKI topology in Cisco IP telephony is not a single PKI system. Instead of having a single Certificate Authority (CA) that issues all certificates, there are several instances issuing certificates:
Self-Signed Certificates PKI Topology
Figure 26-3 illustrates several IP telephony services with self-signed certificates. This design requires each server (or server component) have its own self-signed certificate. In the example shown, the Cisco CallManager, TFTP, and CAPF servers all have created their own self-signed certificates. Each one of them act as their own PKI root (they establish their own authority).
Figure 26-3. Self-Signed Certificate PKI Topology
Manufacturing Installed Certificates PKI Topology
Currently, the Cisco 7911, 7941, 7961, 7970, and 7971 IP Phones have a certificate installed by Cisco in nonvolatile memory. This allows the IP phone to be capable of communicating securely with the CallManager out of the box. Cisco highly recommends that you replace these MICs with your own certificate as soon as possible. Figure 26-4 illustrates the keys used when an IP phone comes with an MIC preinstalled.
Figure 26-4. MIC PKI Topology
The IP phone with the MIC has its own public and private key pair and a Cisco manufacturing CA certificate installed. The certificate of the IP phone is signed by the Cisco manufacturing CA, which makes the Cisco manufacturing CA the PKI root for all MICs.
Locally Significant Certificates PKI Topology
LSCs are certificates that you install to the IP phone. These can be installed from the CAPF CallManager function or from another CA. When deploying the LSCs to the IP phones, you have a major choice to make:
Of course, the factor that this decision hinges on is risk. By automatically deploying LSCs to the IP phones, you assume that all the phones that are currently plugged into the network are "friendly." The CallManager will automatically deploy LSCs to all phones. If a hacker has a phone plugged into the network, it will also get an LSC and become a trusted device. The alternate, manual method creates a huge amount of administrative overhead because you must visit each device and manually enter a sequence of digits provided by the CAPF. However, by following this method, you ensure that each IP phone be physically verified before it is considered a trusted device.
As shown in Figure 26-5, the CAPF can either generate LSCs itself, or it can act as a proxy between the IP phone and some other CA.
Figure 26-5. LSC PKI Topology
Independent, Separated PKI Topology
As illustrated in Figure 26-6, your IP telephony network might have several, coexisting PKI topologies. There is no single root; instead, there are multiple independent PKI topologies. So far, there is no trust relationship among these different PKIs. A trusted introducer is needed, bringing all the different PKI topologies together under one trusted source. The Certificate Trust List (CTL) client provides that function.
Figure 26-6. Multiple PKI Topologies
The Cisco CTL client itself has a certificate issued by the Cisco manufacturing CA. The goal of the Cisco CTL client is to obtain the certificates of all entities that issue certificates (self-signed certificates only or certificates for other devices). Then, the Cisco CTL client signs the list of these certificates, the CTL, using its private key. The public and private keys of the Cisco CTL client are stored on a smart token called a security token, which is just a USB key plugged into the PC running the CTL client.
Now there is a single, trusted introducer in the system again: The Cisco CTL client "introduces" trusted devices, not by signing their certificates, but by signing a list of trusted certificates signed by several PKI roots, as shown in Figure 26-7. The CTL can be compared to the root certificate store of Microsoft Internet Explorer. Both are a list of trusted certificate-issuing entities.
Figure 26-7. CTL Client Creating a List of Trusted Certificates
The CTL usually includes these certificates:
As shown in Figure 26-8, When an IP phone boots, the CTL is downloaded from the TFTP server to the IP phone. It contains all certificates of the entities that issued self-signed certificates. By having this list, the IP phone knows which PKI roots to trust and can trust all certificates that have been issued by any PKI root contained in the CTL.
Figure 26-8. Obtaining the CTL
CTL Client Application
The Cisco CTL client software, available as a plug-in application on Cisco CallManager Administration, is used to create or update the CTL. When the list is accurate, the Cisco CTL client will ensure that the CTL is signed by the keys of the Cisco CTL client. These keys are stored on an external Universal Serial Bus (USB) device, which is called the security token. When the CTL needs to be signed, the Cisco CTL client passes the CTL to the security token, and the security token signs it and then returns the signed CTL to the Cisco CTL client application. The Cisco CTL client itself does not have access to the private key stored on the security token. Therefore, it is not the CTL client application that actually signs the CTL; the CTL client only interacts with the security token requesting the security token to create the signature. The public key of a security token is signed by the Cisco manufacturing CA during production, and the appropriate certificate is also stored on the security token itself.
The CTL file needs to be updated after configuration changes, such as changing or adding IP telephony servers or security tokens to the system.
The CTL also acts as an authorization list because it specifies which certificates belong to which IP telephony function. A TFTP server, for instance, is not allowed to sign a CTL, only IP phone configuration files. The CAPF, as another example, is allowed to sign the LSCs of other IP phones only but not the CTL or any TFTP files.
CTL Verification on the IP Phone
Every time that an IP phone receives a new CTL, the new CTL is verified. It is accepted by the IP phone only if it was signed by the Cisco CTL client using one of the administrator tokens. The phone can verify the signature using the public key (the certificate) of the Cisco CTL client (in fact, the certificate of the appropriate administrator token), which must be included in the currently installed ("old") CTL.
This certificate of the administrator token is signed by the Cisco manufacturing CA. This signature is also validated by using the certificate of the Cisco manufacturing CA, which also must be included in the currently installed CTL. This concept works well as long as the phone already has a CTL.
Initial Deployment Issue
For the first download of a CTL to an IP phone, there is an issue: How does an IP phone know which administrator tokens are trusted without already having a CTL? This problem occurs only at initial deployment, when the phone does not yet have a local CTL. In this case, any administrator token could pretend to be a valid token for the IP telephony system in question. An attacker could either replace the CTL file on the TFTP server with a falsified file or change the CTL file in the path between the IP phone and the TFTP server.
The problem can be solved by downloading the initial CTL over a trusted network to ensure that no falsified initial CTL is loaded to the phone. When the phone has a valid CTL, it will trust new CTLs only if they are signed using a security token that is already known to the IP phone. If the CTL file in the IP phone is erased, the same problem occurs. Again, you must ensure that the next CTL download is done over a trusted network path because the IP phone will blindly accept any CTL.
After the IP phone is deployed, it is usually difficult to trust the network path between the phone and Cisco CallManager. Therefore, a user should not be able to erase the initially installed CTL. There are two ways to remove a CTL from an IP phone: a factory reset or the IP phone Settings menu. A factory reset is not simple, but using the Settings menu is rather easy. To prevent users from using the Settings menu to remove the CTL, you should disable settings access at the phone. When using authentication strings as the authentication method during CAPF phone certificate operations, you have to enable settings access during the enrollment. After successful enrollment, you should then disable settings access again.
PKI Enrollment in Cisco IP Telephony
Part I: Cisco CallManager Fundamentals
Introduction to Cisco Unified Communications and Cisco Unified CallManager
Cisco Unified CallManager Clustering and Deployment Options
Cisco Unified CallManager Installation and Upgrades
Part II: IPT Devices and Users
Cisco IP Phones and Other User Devices
Configuring Cisco Unified CallManager to Support IP Phones
Cisco IP Telephony Users
Cisco Bulk Administration Tool
Part III: IPT Network Integration and Route Plan
Cisco Catalyst Switches
Configuring Cisco Gateways and Trunks
Cisco Unified CallManager Route Plan Basics
Cisco Unified CallManager Advanced Route Plans
Configuring Hunt Groups and Call Coverage
Implementing Telephony Call Restrictions and Control
Implementing Multiple-Site Deployments
Part IV: VoIP Features
Configuring User Features, Part 1
Configuring User Features, Part 2
Configuring Cisco Unified CallManager Attendant Console
Configuring Cisco IP Manager Assistant
Part V: IPT Security
Securing the Windows Operating System
Securing Cisco Unified CallManager Administration
Preventing Toll Fraud
Hardening the IP Phone
Understanding Cryptographic Fundamentals
Understanding the Public Key Infrastructure
Understanding Cisco IP Telephony Authentication and Encryption Fundamentals
Configuring Cisco IP Telephony Authentication and Encryption
Part VI: IP Video
Introducing IP Video Telephony
Configuring Cisco VT Advantage
Part VII: IPT Management
Introducing Database Tools and Cisco Unified CallManager Serviceability
Configuring Alarms and Traces
Using Additional Management and Monitoring Tools
Part VIII: Appendix
Appendix A. Answers to Review Questions