cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Chalk Talk: Understanding and Setting Up Secure CME

1198
Views
9
Helpful
0
Comments
Enthusiast

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:

Picture1.jpg

Figure 1

  1. End host generates a private-public key pair.
  2. End host generates a certificate request, which it forwards to the CA.
  3. Human intervention is required to approve the enrollment request, which is received by CA.
  4. 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.
  5. 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:

Picture2.jpg

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.

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards
This widget could not be displayed.