08-14-2013 11:59 AM - edited 03-12-2019 10:04 AM
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?
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:
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.
Figure 1
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.
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: