Editor's note: Thanks to Diya Mathew for providing this month's Chalk Talk article. This article appeared in the August 2013 issue of the Cisco TS Newsletter. Are you subscribed?
Introduction
Many administrators choose to implement CME with security. This document describes how to configure Secure CME to operate with secure signaling and media as well as how to troubleshoot any issues along the way by analyzing debugs.
First and foremost, it is important to note that in a secure environment, devices can communicate with each other only if they have the other party’s certificate. Here are a few relevant terms you’ll come across often:
- TLS/SSL - Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security over the Internet.
In OSI model equivalences, TLS/SSL is initialized at layer 5 (the Session layer) then works at layer 6 (the Presentation layer). In both models, TLS and SSL work on behalf of the underlying transport layer, whose segments carry encrypted data.
- PKI – Public Key Infrastructure is a form of message encryption using two keys (small files); one is public and used by the sender to encrypt the message, the other is private and used by the recipient to decrypt it. Each device in the network has a pair of unique keys.
- Simple Certificate Enrollment Protocol (SCEP) - Cisco IOS Software uses SCEP to communicate with a PKI. It offers a mechanism to support the secure transportation of key information and certificates between the different components of a PKI.
- “Enrolling in a Certificate Authority” - Enrollment is the process of obtaining a certificate. It occurs between the end host desiring the certificate and the authority in the PKI that is responsible for providing certificates. The end hosts that will participate in a PKI must obtain a certificate, which they will present to the parties with whom they communicate when they need a secured communications channel. For eg, the CME will request a certificate from a CA. When phones register to it, they will have a copy of the CME’s digital signature. Figure 1 shows a generic example:
Figure 1
- End host generates a private-public key pair.
- End host generates a certificate request, which it forwards to the CA.
- Human intervention is required to approve the enrollment request, which is received by CA.
- After the CA operator approves the request, the CA or RA signs the certificate request with its private key and returns the completed certificate to the end host.
- End host writes certificate into a non-volatile storage area: PC hard disk or NVRAM on Cisco routers.
Overview of Secure CME
CME phone authentication uses the PKI capabilities in Cisco IOS software for certificate-based authentication of IP phones. Every device participating in a secure communication is enrolled in the PKI using a process in which the device generates an RSA key pair and has its identity validated by a trusted entity (also known as a certification authority [CA] or trustpoint).
After each entity enrolls in a PKI, every peer (end host) is granted a digital certificate that has been issued by a CA. When peers must negotiate a secure communication session, they exchange digital certificates.
Specifications
- When using ISR routers, keep in mind to use only 1 of the following IOS images:
- universal
- advipservicesk9
- adventerprisek9
- With ISR G2 routers, both the UC (uck9) and the Security (securityk9) feature licenses must be installed.
- Time on the router must be accurate before building CA and trustpoints.
- HTTP server must be running on the router.
Limitations
- Secure three-way software conferencing is not supported
- Calls to Cisco Unity Express are not secure.
- Music on Hold (MOH) is not secure.
- Video calls are not secure.
- Modem relay and T.3 fax relay calls are not secure.
- Conversion between inband tone and RFC 2833 DTMF is not supported.
- Secure CME does not support SIP trunks; only H.323 trunks are supported.
Phone Authentication Process
Figure 2 depicts all the components that can be enabled in a single CME router (or external router) to setup a secure network:
Figure 2
CA is the trusted entity that signs certificates. The CA issues certificates to CME, SAST, CAPF, and TFTP functions. If the CA is a third-party CA or if the Cisco IOS CA is on a Cisco IOS router external to the CME, you must configure an RA on CME router to issue certificates to phones.
The next step is to create a Certificate Trust List (CTL) file, which is a list of known, trusted certificates and tokens. After you configure the CTL client, it creates the CTL file (CTLfile.tlv) and makes it available in the TFTP directory. The CTL file is signed using the SAST certificate's corresponding private key. Configure a CTL provider on every other CME router in the network which is not running CTL client.
The telephony service module signs phone configuration files and saves it in SEP<mac-address>.cnf.xml.sgn format. When an IP phone boots up, it requests the CTL file (CTLfile.tlv) from the TFTP server and downloads its digitally signed configuration file.
The CAPF is like a proxy server for the phones which are unable to directly communicate with the CA. The CAPF server signs LSCs on behalf of CA. The IP phone checks the signed config file for CAPF status and authenticates with any of the 4 options:
<capfAuthMode>X</capfAuthMode>
1 – Auth string
2 – Null string
3 – Locally Significant Cert
4 – Manufacturing Inserted Cert
If a certificate operation is needed, the phone initiates a TLS session with the CAPF server on TCP port 3804 and begins the CAPF dialogue. The certificate operation can be an upgrade, delete, or fetch operation.
Finally the phone initiates a TLS connection with the secure CME on TCP port 2443 if the device security mode settings in the .cnf.xml.sgn file are set to authenticated or encrypted.