Application inspection allows a firewall to open pinholes and perform Network Address Translation (NAT) rewrite for Skinny Client Control Protocol (SCCP) and Session Initiation Protocol (SIP) signaling. However, when signaling encryption is enabled, the firewall can no longer parse the signaling information and the ability to open pinholes and rewrite IP addresses for NAT is lost.
The Transport Layer Security (TLS) Proxy function allows a Cisco® ASA appliance to decrypt and re-encrypt signaling traffic, which allows it to provide application inspection services within secured unified communications environments. The TLS Proxy is transparent to voice users.
This document starts by briefly explaining how TLS works. It then explains how TLS Proxy allows the Cisco ASA appliance to be inserted into a secure unified communications architecture. It then describes how to configure Cisco Unified Communications Manager and the Cisco ASA appliance to enable the TLS Proxy feature.
It is assumed that the reader has experience configuring cryptography on Cisco Unified Communications Manager.
TLS in a Unified Communications Environment
The TLS protocol allows applications to communicate across a network in a way that is designed to prevent eavesdropping, tampering, and message forgery. TLS uses cryptography to provide endpoint authentication and communications privacy over a network.
Typically, only the server is authenticated (i.e., its identity is ensured) while the client remains unauthenticated; this means that the end user (whether an individual or an application, such as a Web browser) can be sure about whom they are communicating with (i.e., a user connecting to online banking).
The next level of security is known as mutual authentication, in which both parties of the "conversation" are sure about whom they are communicating with. Mutual authentication requires public key infrastructure (PKI) deployment to clients.
The Cisco Unified Communications telephony environment uses mutual authentication, meaning that a phone only communicates with an authorized Cisco Unified Communications Manager server, and Cisco Unified Communications Manager servers only communicate with authorized phones.
The current appliance versions of Cisco Unified Communications Manager do not support Simple Certificate Enrollment Protocol (SCEP) or a third-party Certificate Authority. The Cisco Unified Communications Manager Certificate Authority Proxy Function (CAPF) client is used to manage the PKI. The CAPF tool is used to generate and sign locally significant certificates (LSCs) for the phones.
When a phone attempts to establish a TLS session with Cisco Unified Communications Manager, the server is able to check the identity of the phone by checking the phone certificate, and is able to trust this certificate because it is signed by CAPF. The phone validates the identity of Cisco Unified Communications Manager through a Certificate Trust List (CTL). This file is downloaded from the Trivial File Transfer Protocol (TFTP) server and contains the certificates of the trusted elements of the Cisco Unified Communications Manager cluster.
The important point to understand for TLS Proxy is that certificates are the means by which trust is established between the different devices. The important components of a digital certificate are the key pair (private and public) and the Certificate Authority.
In summary:
• How does a phone trust Cisco Unified Communications Manager?
A Certificate Trust List (CTL) is composed offline and stored on the phones.
The phones trust all of the entities on this list.
Cisco Unified Communications Manager's certificate (X.509v3) is contained within the CTL.
Cisco Unified Communications Manager's certificate is self-signed.
• How does Cisco Unified Communications Manager trust a phone?
The phone's certificate is signed by the CAPF service. The CAPF certificate is installed in the Cisco Unified Communications Manager certificate store.
When a phone registers, its certificate is stored in a dynamic trust list on Cisco Unified Communications Manager.
TLS Proxy Solution
When using TLS Proxy, the Cisco ASA appliance is inserted between the phones and Cisco Unified Communications Manager. The phones will now establish a TLS session with the ASA appliance. The appliance will, in turn, establish a proxy TLS connection with Cisco Unified Communications Manager on the phone's behalf. This function generates two TLS sessions (Figure 1).
Figure 1. TLS Sessions
For correct operation of the TLS Proxy feature, phones and Cisco Unified Communications Manager need to trust the Cisco ASA appliance, and the appliance needs to trust them.
Trusted Relationship between a Cisco Unified IP Phone and the Cisco ASA Adaptive Security Appliance
• The Cisco ASA appliance presents a certificate to the phone on behalf of Cisco Unified Communications Manager.
• The certificate is generated on the Cisco ASA appliance. This certificate can be self-signed like the original one from Cisco Unified Communications Manager, or signed by an external Certificate Authority.
• The certificate will be pushed to the phone in the CTL so the phone can trust the ASA appliance. The CTL client is used to add the ASA appliance's certificate to the trust list.
• The ASA administrator needs to create a trust point for the Certificate Authority that issued phone's certificate (CAPF).
Trusted Relationship Between Cisco Unified Communications Manager and the Cisco ASA Adaptive Security Appliance
• The Cisco ASA appliance presents a unique certificate to Cisco Unified Communications Manager on behalf of the phone. Phone certificates are dynamically created by the ASA appliance and are called local dynamic certificates (LDCs).
• In order to for Cisco Unified Communications Manager to trust the ASA appliance certificates, it needs to trust the Certificate Authority that signed them.
• The system administrator configures a Certificate Authority on the ASA appliance whose role will be to sign the LDCs. The Certificate Authority certificate is uploaded into Cisco Unified Communications Manager's certificate store, which allows the establishment of a trust relationship between Cisco Unified Communications Manager and the ASA appliance.
• The system administrator also creates a trust point on the ASA appliance so it trusts Cisco Unified Communications Manager. The trust points for both Cisco Unified Communications Manager and CAPF may be created manually or installed by the CTL provider on the ASA appliance (described in the next section).
TLS Proxy Lab Overview
The schematic of the lab used for the TLS Proxy is configured below. The ASA and Cisco Unified Communications Manager code releases used were Cisco ASA Software Release 8.0(2) and Cisco Unified Communications Manager 6.0, respectively.
Figure 2. TLS Proxy Lab Configuration
Two phone models were used in the lab: a Cisco Unified IP Phone 7970 with a manufacturing installed certificate and a Cisco Unified IP Phone 7940 with an LSC generated using the Cisco Unified Communications Manager CAPF tool.
TLS Proxy Configuration
Following are instructions on how to configure TLS Proxy from the Cisco ASA appliance command-line interface (CLI).
Step 1.Create RSA key pairs on the Cisco ASA appliance
This creates the cryptographic material to be used for generating certificates.
The first entry is used to create the CCM_proxy Certificate Authority trust point. Its certificate will be presented to the phone on behalf of Cisco Unified Communications Manager (Step 2).
The second entry is used to create the LDC_server Certificate Authority trust point and is used to sign the LDC certificates presented to Cisco Unified Communications Manager (Step 3).
The third entry is used to create all the LDCs (Step 5).
Step 2.Create the proxy certificate for the Cisco Unified Communications Manager cluster
hostname(config)# ! for self-signed CCM proxy certificate
The Certificate Authority trust point is used to present a certificate to the phone on behalf of Cisco Unified Communications Manager (configured in Step 5).
This is the proxy Cisco Unified Communications Manager certificate. It is self-signed (enrollment self).
The fully qualified domain name (FQDN) is not really used; it can be left as "none."
The subject name has to be configured but doesn't have any real significance. However, Cisco Unified IP Phones require certain fields from the X.509v3 certificate to be present to validate the certificate by consulting the CTL file. The subject name must be composed of the ordered concatenation of the CN, OU, and O fields. The CN field is mandatory; the others are optional.
The concatenated fields (when present) are separated by a semicolon, yielding one of the following forms:
CN=xxx;OU=yyy;O=zzz
CN=xxx;OU=yyy
CN=xxx;O=zzz
CN=xxx
This certificate is exported to the CTL. The relevant configuration parameters are specified within the ctl-provider subcommand (Step 4).
Step 3.Create an internal local Certificate Authority to sign the LDC for Cisco Unified IP Phones
hostname(config)# ! for the internal local LDC issuer
These commands create the Certificate Authority trust point that is used to sign the LDCs presented to Cisco Unified Communications Manager on behalf of each phone (Step 5).
Proxy-ldc-issuer defines the local Certificate Authority role for the trust point to issue dynamic certificates for TLS Proxy. This command can only be configured under a trust point with "enrollment self".
The FQDN is not really used; it can be left as "none."
The subject name has to be configured but doesn't have any real significance.
The certificate has to be imported manually to Cisco Unified Communications Manager to allow Cisco Unified Communications Manager to trust the LDCs presented by the Cisco ASA appliance (Step 7).
Step 4.Create a CTL provider instance in preparation for a connection from the CTL client
This configuration lets the ASA appliance accept a connection from the CTL client. For security reasons, the configuration defines which hosts are able to connect; in a production environment, numerous clients may be configured. In this lab environment, the CTL client was connected on the outside interface. In a production environment, we recommend connecting it from the inside interface for security reasons.
The username and password must match the Cisco Unified Communications Manager credentials.
The syntax specifies which certificate will be exported to the phones (created in Step 2) using the export certificate command. When the CTL client connects, it will retrieve the certificate and add it to the list of servers in the CTL.
The "CTL install" command tells the ASA appliance to parse the CTL file provided by the CTL client and install trust points. The trust points installed are those for the Cisco Unified Communications Manager server and CAPF. Any trust points installed by this command will have names prefixed with "_internal_CTL_<ctl_name>". This is an optional command and is enabled by default. If this command is disabled, each Cisco Unified Communications Manager server's and CAPF's certificate must be manually imported and installed using the crypto ca trustpoint and crypto ca authenticate commands.
By default, the connection will be made on port 2444; however, it can be changed with the service port <listening_port> command. This port number must match the one configured on Cisco Unified Communications Manager (defined under Enterprise Parameters on the Unified Communications Manager administration page).
Step 5.Create a TLS Proxy instance
hostname(config)# tls-proxy my_proxy
hostname(config-tlsp)# server trust-point ccm_proxy
The server trust point specifies the proxy trustpoint certificate that is presented to the phones during the TLS handshake (created in Step 2). This is the certificate that was added to the CTL in Step 4.
Client ldc issuer defines the Certificate Authority that issues the dynamic certificates to Cisco Unified Communications Manager on behalf of the phones. This is the certificate created in Step 3.
Client ldc keypair specifies which key pair to use to create the LDCs. It should be noted that the same pair is used for all the LDCs. This key pair was created in Step 1.
Client cipher-suite defines the cipher suite that is announced during the TLS handshake. These are used to replace the original ciphers in the phone's Hello message to Cisco Unified Communications Manager. This allows the system administrator to configure asymmetric encryption. For example, if the link between the ASA appliance and Cisco Unified Communications Manager was over a trusted network, a weaker cipher could be used between the ASA appliance and Cisco Unified Communications Manager to reduce the overhead on Cisco Unified Communications Manager. However, a NULL cipher is not currently supported with the version tested.
The LDCs are created dynamically.
Step 6.Enable TLS Proxy in SCCP or SIP inspection
hostname(config)# class-map sec_skinny
hostname(config-cmap)# match port tcp eq 2443
This syntax defines which specific type of traffic the Cisco ASA appliance will inspect for a specific class. In this case, the system matches all the TCP traffic for port 2443 (secure SCCP signaling).
hostname(config)# policy-map type inspect skinny skinny_inspect
Entering the above creates a new inspection map for SCCP. This allows the administrator to tune the default inspection "rules" he/she may want to enforce, such as RTP conformance, signaling timeout, media timeout, registration, or filtering the message ID. The lab used default parameters.
With these commands, the system adds a new class sec_skinny to the policy global_policy. It specifies that that the inspection map skinny_inspect created during the previous step is used for the new class. The optional tls-proxy attribute enables the TLS Proxy feature and identifies which TLS Proxy instance to use (in this case, my_proxy created in Step 5).
hostname(config)# service-policy global_policy global
This configures the global_policy to be used by the Cisco ASA appliance.
Step 7.Export the local Certificate Authority certificate (ldc_server) and install it as a trusted certificate on the Cisco Unified Communications Manager server
To allow Cisco Unified Communications Manager to trust the proxy phone certificates created dynamically by the ASA appliance, the certificate of the Certificate Authority created on the ASA appliance needs to be imported into Cisco Unified Communications Manager. Use the following command to display the certificate on the screen:
hostname(config)# crypto ca export ldc_server identity-certificate (replace ldc_server by the name that was used in Step 2)
Copy the output, including the "Begin Certificate" and "End Certificate" lines, to a text file.
Step 1 Under CUCM OS administration page, Navigate to Security>Certificate Management>
Step 2 Select Upload Certificate
Step 3 Select CallManager-trust under Certificate name
Step 4 Click Browse and navigate to the ASA certificate
Step 5 To upload the certificate, click Upload
Step 8.Configure the CTL client
Run the CTL client on one of the machines that was defined on the Cisco ASA appliance in Step 4. If the CTL client is not on this machine, it can be downloaded from Cisco Unified Communications Manager under the CUCM administration page by selecting Application/plugins. Click Find, then Download. Alternatively, go directly to:
https://x.x.x.x:8443/plugins/CiscoCTLClient.exe
(where x.x.x.x is the IP address of Cisco Unified Communications Manager)
One of the USB security tokens used to initially configure the CTL client will be required to update it.
In the following diagram, the CTL client contains the two security tokens that were used to turn on Cisco Unified Communications Manager security, the certificate for CAPF, and the certificate for Cisco Unified Communications Manager and TFTP.
Select Add Firewall.
Provide the IP address or the name of the Cisco ASA appliance. Ensure the host used to run the CTL client is able to resolve the name of Cisco Unified Communications Manager and that the IP address is reachable. It should be the IP address of the interface that was used while configuring the CTL provider in Step 4. The login and the password must be the same as the one configured on the ASA appliance in Step 4.
As can be seen in the following screenshot, the Cisco ASA appliance is added as a Cisco Unified Communications Manager. This is because the ASA appliance is acting as a proxy Cisco Unified Communications Manager for the phones.
The CTL will also be downloaded to the ASA appliance so it can be parsed to configure the CAPF and Cisco Unified Communications Manager as Certificate Authority trust points. This is shown in the following screenshot:
