Introduction

It’s with great enthusiasm I’m coming to you today to talk about Communications Manager encryption! Collaboration and encryption are two of my favorite subjects so bringing them together is exciting. For many years engineers have steered clear of enabling encryption on Communications Manager, but I think it’s time it becomes the default. The position I’m taking isn’t a favored one and I’m hoping the rest of this post may change your mind. Let’s face it — It’s 2016 and security is and has become a really big deal. Ask any CIO or CSO and they’ll tell you encrypted telecommunications inside or outside of their business is important. The ugly truth (and the reason I’m writing this) is that most Communications Manager systems are running completely in the clear.

The Ugly

I’m not going to get into the details of all surface attack areas in the Cisco CUCM solution. The basics are very well understood that the signaling and media is in the clear. It’s easy to access conversations using a simple packet capture in Wireshark and Vomit. Since nearly all Cisco infrastructure devices support some type of packet capture it is a trivial task to record any phone conversation of your choice. If you want to look at some details of VoIP penetration testing I suggest taking a look at Viproy. You’ll find a wealth of information already generated by people who do this for a living. For example – the Tapberry Pi IP Phone is a fairly intrusive device, but would you ever suspect a tampered IP phone?

Now I’m not going to come out saying that enabling CUCM mixed-mode is the end all solution to this problem. It’s merely there to build a foundation on which all other endpoints, trunks, and associated services can be encrypted. Will mixed-mode prevent all of the surface attack areas that’s a part of penetration testing? Nope, not even close. You have to look and think about security within the solution as a concept, not a feature. When you’re bolting on new services like Expressway, Conductor, or Contact Center is it your mode of operation to ignore SSL/TLS, set all SIP to TCP 5060, and just “make it work”? That’s the mode of operation I’d like to see changed among collaboration engineers. Failing back to un-encrypted means something is wrong and I don’t think it’s OK as a long term mode of operation.

The more this is implemented the more it’ll become a standard.

The Good

The primary fear that’s been instilled in collaboration engineers is the thought of a lost security token. Most of us have been there doing an upgrade or certificate management and completely forgot to check if it’s mixed mode. I have news for you – that isn’t the products fault, but it was really bad prior to 10.x. I believe it’s just a lingering fear from everything prior to 10.x that makes us glaze over mixed-mode. When it does go wrong it goes wrong very dramatically. If the phone trusting keychain breaks you’ll have an operational CUCM with zero phones. Understanding the recovery keys that are now in place is fundamental to restoring operations.

Communications Manager 10.x has helped alleviate the concerns when it comes to losing a security token. It’s now a simple operation to enable services, run the commands, and mixed-mode is operational. The focus here is enabling CTL (Certificate Trust Lists) on Communications Manager to show there isn’t anything to worry about. Were also talking about using the embedded “utils ctl” operations and not using hardware eTokens. It’s also good to note that phones no longer talk to the call manager service for certificate operations so it’s an “out-of-band” certificate management.

How does Communications Manager prevent security token loss? The tokenless CTL approach has been enhanced by including an additional SAST (Site Administrator Security Token) in the CTL file for recovery operations. It just so happens that this additional SAST is the ITLRecovery certificate. The benefit should be clear if you’re familiar with ITL operations. The ITLRecovery certificate does not change during hostname or certificate operations, and there is a procedure for manually backing up this key. So you can take this secondary token offline independent of the disaster recovery system. It’s a virtual to physical operation so you can burn the key to CD or save it in a key vault.

Just to reiterate – performing the CTL operation using the command line the CTL file gets signed by the Callmanager.pem private key and includes the ITLRecovery certificate as a second SAST. This should remove your fears of lost security tokens using this new tokenless CTL method. The ITLRecovery key has very clear guidance how to backup this key and I’ll demonstrate it below.

The Activation

I’m going to run through a few things to check before getting to mixed-mode activation. The activation of CTL is based on the assumption all secure by default TVS and ITL operations are working normally. If you want to check all ITL operations this link will walk you through a detailed process. Unified Communications Manager ITL Enhancements in Version 10.0(1)

Certificate management is super important and the last thing you want to happen is a certificate expiring without warning. My prerequisite to any and all certificate operations is to ensure that the certificate monitor is in operation. (I’m making the assumption your CUCM can send e-mails. It better.) My recommendation is to configure certificate monitor to start notifications 90 days before expiration. The default 29 days is to short especially three years later when installers are gone and you’re scrambling to figure out what to do.

I want this thing to annoy all the right people every 7 days. Make it noisy.

Example:

Now that we have that out of the way it’s important to now check the validity of all current CUCM certificates. Enabling mixed-mode turns on CTL operations and inside that CTL file is the Callmanager.pem. I generally have a rule of thumb that if I’m on a cluster and Callmanager.pem has less than a year to go just spend the extra cycle and reissue it.

So let’s take a look at my lab callmanager.pem and see if it needs any action. If the validity period is less than a year go ahead and reissue Callmanager.pem ensuring its SHA256 and X509v3 compliant. This is an entirely different process so I’m counting on everything is good with Callmanager.pem and ITL operations.

admin: show cert list own

CallManager/CallManager.pem: Certificate Signed by warcop-server1-ca

admin:show cert own CallManager/CallManager.pem

Validity From: Tue Jul 22 16:45:34 EDT 2014

To:   Thu Jul 21 16:45:34 EDT 2019

Great! My lab is still good for a few more years. Let’s backup the ITLRecovery key and you’ll enter your SFTP details to the file.

admin:file get tftp ITLRecovery.p12

Please wait while the system is gathering files info …done.
Sub-directories were not traversed.
Number of files affected: 1
Total size in Bytes: 1717
Total size in Kbytes: 1.6767578
Would you like to proceed [y/n]? y
SFTP server IP: 172.31.255.99
SFTP server port [22]:
User ID: cisco
Password: *****
Download directory: /

Go ahead and save this file to a key vault or burn to CD as this is your primary recovery token for both ITL operations and CTL operations.

Time to activate some services.

Activate the Cisco CTL Provider service on each Cisco Unified Communications Manager server in the cluster.

Activate the Cisco Certificate Authority Proxy service only on the first node in the cluster.

Make sure to activate the CAPF services and CTL provider service before performing any CTL operations. This ensures you do not have to update the CTL again after CAPF is enabled.

Do you have a CTL file already? It’s possible that long ago the cluster was running mixed mode and was changed back to non-secure mode. If this was the case the CTL file left on the TFTP servers may be old and needs deleting. You can check for a ctl file with “show ctl”.

admin:show ctl

Length of CTL file: 0
CTL File not found. Please run CTLClient plugin or run the CLI – utils ctl.. to generate the CTL file.
Error parsing the CTL File.

So we’ve determined that we do not have a CTL file and the “show ctl” command above hints us how to generate it. If you do have a CTL file first make sure you’re completely positive you’ll never need the old one and run “file delete tftp CTLFile.tlv”

The following are the only options for “utils ctl” operations.

• utils ctl set-cluster mixed-mode
  • Updates the CTL file and sets the cluster to mixed mode.

• utils ctl set-cluster non-secure-mode
  • Updates the CTL file and sets the cluster to non-secure mode.

• utils ctl update CTLFile
  • Updates the CTL file on each node in the cluster.

At this point the last remaining set is to activate CTL operation. You’ll need to be prepared to reboot the cluster and all phones will begin downloading the CTL file.

admin:utils ctl set-cluster mixed-mode

This operation will set the cluster to Mixed mode. Do you want to continue? (y/n): Y
Moving Cluster to Mixed Mode
Cluster set to Mixed Mode
Please Restart the TFTP and Cisco CallManager services on all nodes in the cluster that run these services

Now you can verify that the CTL file has been generated and exists in the TFTP directory.

admin:show ctl

The checksum value of the CTL file:
a0352774cac687c17a253497dd521b89(MD5)
133f24b90202b3b744b754f9b9aceb6007d82223(SHA1)
Length of CTL file: 7200
The CTL File was last modified on Tue Mar 15 21:51:16 EDT 2016

(take a look at the end of this post for a full CTL file output example)

The CTL file is going to contain four records and two of which are the SAST tokens with the first record showing the Callmanager.pem signing record and the last showing the ITLRecovery record. At this point you have a valid CTL and you’re ready to reboot the cluster. The command indicates that you only need to restart services, but I favor rebooting the cluster to get everything off to a fresh start.

So this what should display after reboot when you check the Cluster Security Mode Enterprise Parameter. (Ignore LBM Security Mode – it’s just in the screenshot)

Congratulations! You’ve put down the foundation to enable encryption across a variety of devices, trunks, and services.

With version 11 it’s important to note that the ITLRecovery key validity period has been extended from 5 years to 20 years. If you perform an upgrade to version 11 this key is not automatically extended because that would break things. Once you’re on version 11 you should go through the ITLRecovery key re-issuance procedure. Once the new key is generated it will be 20 years and then you should perform “utils ctl update CTLfile”.

Hint: Version 11 also introduced something different when you regenerate a Callmanager, ECDSA, or Tomcat certificate. Now that HTTPS configuration downloads are available the TFTP service need be deactivated and reactivated. A service restart isn’t enough to have TFTP pull that new certificate and have the service on port 6972 running with the latest signature.

From an operations standpoint when do I need to run “utils ctl update CTLfile”? Any time you’re performing cluster changing operations such as adding or removing nodes, after restoring cluster nodes, changing IPs or hostnames, and especially anytime you upload or change certificates on the system. I’ve just worked it into my routine to keep the CTL file updated during all certificate operations.

I hope I’ve dispelled some myths about tokenless CTL and you’ll take a second look at enabling mixed-mode. It’s highly unlikely security engineers are going to become familiar with all CUCM security operations so I believe it’s the responsibility of the collaboration engineer to step up. We’re talking a basic understanding of PKI and nothing more than a few keys within the system.

Please feel free to hit me up on Twitter @Warcop if you see something that needs further clarification. Also, feel free to disagree with me!

Important References:

Security Guide for Cisco Unified Communications Manager , Release 11.0(1)

Unified Communications Manager ITL Enhancements in Version 10.0(1)

IP Phone Security and CTL (Certificate Trust List)

Viproy VoIP Penetration Testing and Exploitation Kit

vomit – voice over misconfigured[1] internet telephones

Full CTL File:

admin:show ctl
The checksum value of the CTL file:
f52754c4c647ae3a4f25c4bd24726213(MD5)
296d6a7990cc80ad9bcfa1d747e0a18e34a18df4(SHA1)

Length of CTL file: 7200
The CTL File was last modified on Sat Feb 20 20:08:59 EST 2016

Parse CTL File
—————-

Version:        1.2
HeaderLength:   420 (BYTES)

BYTEPOS TAG             LENGTH  VALUE
——- —             ——  —–
3       SIGNERID        2       105
4       SIGNERNAME      56      CN=cucm1.warcop.net;OU=IT;O=Warcop;L=Atlanta;ST=GA;C=US
5       SERIALNUMBER    19      76:00:00:00:07:F2:F3:96:30:3A:DA:D8:27:00:00:00:00:00:07
6       CANAME          21      CN=warcop-server1-ca
7       SIGNATUREINFO   2       15
8       DIGESTALGORTITHM        1
9       SIGNATUREALGOINFO       2       8
10      SIGNATUREALGORTITHM     1
11      SIGNATUREMODULUS        1
12      SIGNATURE       256
9e  8b  d8  25  78  8f  5d  c0
49  7e  f3  ac  4f  9b  ae  4f
b5  98  98  d  c1  86  30  32
6c  65  78  9b  3a  88  c9  5f
63  5  a2  a6  2d  b9  de  f1
5e  8a  8e  29  cd  84  48  a6
a9  71  86  40  39  20  b2  21
d0  5d  35  e4  9c  69  3b  56
15  c4  cd  f7  93  3c  3  87
eb  56  ba  e1  93  4  14  b3
15  83  69  23  ba  73  e5  20
95  fd  7  21  a4  53  8e  a6
10  3a  3c  e8  85  f0  fc  ee
62  c3  8a  a8  c1  df  e  45
f1  4  8f  1d  ae  46  39  91
d9  2d  c5  6a  8f  5d  3d  e8
54  65  cf  cd  56  d7  16  89
d6  d3  d3  74  91  3d  5c  2a
92  23  3e  d0  a6  40  d2  eb
0  5b  f8  c5  9  e4  aa  3d
39  39  9d  14  6c  7  d7  20
cb  d8  74  64  53  17  2d  3d
ad  8b  e3  c8  fd  b3  63  70
50  a4  15  69  97  c5  e4  a0
f3  bf  78  7c  91  30  fc  41
3e  2e  dd  be  4c  50  3b  60
72  4a  de  76  ee  99  ff  b1
ae  69  c3  b  21  13  f7  b6
94  2  88  fa  d2  e  3b  58
8d  d2  71  f3  d3  93  78  9
9b  98  fe  a2  f5  b9  80  8e
42  44  1b  b  54  88  ea  49
14      FILENAME        12
15      TIMESTAMP       4

CTL Record #:1
—-
BYTEPOS TAG             LENGTH  VALUE
——- —             ——  —–
1       RECORDLENGTH    2       2260
2       DNSNAME         6       cucm1
3       SUBJECTNAME     56      CN=cucm1.warcop.net;OU=IT;O=Warcop;L=Atlanta;ST=GA;C=US
4       FUNCTION        2       System Administrator Security Token
5       ISSUERNAME      21      CN=warcop-server1-ca
6       SERIALNUMBER    19      76:00:00:00:07:F2:F3:96:30:3A:DA:D8:27:00:00:00:00:00:07
7       PUBLICKEY       270
8       SIGNATURE       256
9       CERTIFICATE     1594    0D D1 77 CB E1 C4 64 B3 CB 6E F0 24 69 DE C8 7B DF 47 63 67 (SHA1 Hash HEX)
10      IPADDRESS       4
This etoken was used to sign the CTL file.

CTL Record #:2
—-
BYTEPOS TAG             LENGTH  VALUE
——- —             ——  —–
1       RECORDLENGTH    2       2260
2       DNSNAME         6       cucm1
3       SUBJECTNAME     56      CN=cucm1.warcop.net;OU=IT;O=Warcop;L=Atlanta;ST=GA;C=US
4       FUNCTION        2       CCM+TFTP
5       ISSUERNAME      21      CN=warcop-server1-ca
6       SERIALNUMBER    19      76:00:00:00:07:F2:F3:96:30:3A:DA:D8:27:00:00:00:00:00:07
7       PUBLICKEY       270
8       SIGNATURE       256
9       CERTIFICATE     1594    0D D1 77 CB E1 C4 64 B3 CB 6E F0 24 69 DE C8 7B DF 47 63 67 (SHA1 Hash HEX)
10      IPADDRESS       4

CTL Record #:3
—-
BYTEPOS TAG             LENGTH  VALUE
——- —             ——  —–
1       RECORDLENGTH    2       1100
2       DNSNAME         6       cucm1
3       SUBJECTNAME     53      CN=CAPF-3ca8c4ee;OU=IT;O=Warcop;L=Atlanta;ST=GA;C=US
4       FUNCTION        2       CAPF
5       ISSUERNAME      53      CN=CAPF-3ca8c4ee;OU=IT;O=Warcop;L=Atlanta;ST=GA;C=US
6       SERIALNUMBER    16      4C:F5:F5:88:A1:DB:CB:58:BC:2A:8C:4F:6C:6B:3C:8E
7       PUBLICKEY       140
8       SIGNATURE       128
9       CERTIFICATE     666     D2 BF B8 54 05 0D 62 30 F6 BA 12 98 E0 37 7C 08 E5 CB 64 70 (SHA1 Hash HEX)
10      IPADDRESS       4

CTL Record #:4
—-
BYTEPOS TAG             LENGTH  VALUE
——- —             ——  —–
1       RECORDLENGTH    2       1160
2       DNSNAME         6       cucm1
3       SUBJECTNAME     68      CN=ITLRECOVERY_cucm1.warcop.net;OU=IT;O=Warcop;L=Atlanta;ST=GA;C=US
4       FUNCTION        2       System Administrator Security Token
5       ISSUERNAME      68      CN=ITLRECOVERY_cucm1.warcop.net;OU=IT;O=Warcop;L=Atlanta;ST=GA;C=US
6       SERIALNUMBER    16      69:62:6A:28:E3:76:37:C7:23:75:C2:D9:80:3C:D7:82
7       PUBLICKEY       140
8       SIGNATURE       128
9       CERTIFICATE     696     43 BA 4D 06 24 8D 5A FA 5D FB 6C 28 7A 7F 50 33 BB 72 D8 D2 (SHA1 Hash HEX)
10      IPADDRESS       4
This etoken was not used to sign the CTL file.

The CTL file was verified successfully.