Cisco CUCM Security
References
IP Telephony for 802.1X Design Guide
Understanding NAC, 802.1X and MAB
Configuring 802.1X on Cat Swicthes https://www.cisco.com/c/dam/global/en_hk/assets/pdfs/collabortaion_technologies_enterprise_vocie_security.pdf
Configure Automatic Certificate Enrollment and Renewal Via CAPF Online CA
- Copy “computer” template - needs to have 'Digital signature' and 'key encipherment' key usage or Device secure registration will fail
- Change validly period to 5 years and renewal to 6 weeks
Notes
Locally Significant Certificates (LSC)—A certificate that installs on supported phones after you perform the necessary configuration tasks that are associated with the Cisco Certificate Authority Proxy Function (CAPF). The LSC secures the connection between Unified Communications Manager and the phone after you configure the device security mode for authentication or encryption.
Online CA—Use this option to have an external online CA signed LSC for phones. The CAPF service connects automatically to the external CA. When a CSR is submitted, the CA signs and returns the CA-signed LSC automatically.
Many Cisco IP phone versions support 802.1X. They can use either pre-provisioned manufacturing installed certificates (MIC) or customer-controlled locally significant certificates (LSCs) for 802.1X authentication
Touchless phone configuration and certificate enrollment—Starting in Version 7.1.2, the Cisco Unified Communication Manager (Unified CM) can centrally enable phones for 802.1X via a downloaded configuration file. In addition, Unified CM provides a Certificate Authority Proxy Function (CAPF) that enables phones to enroll locally-signed LSCs to use for authentication. Because these functions are performed over the network, there is no need to physically touch the phones.
Cisco Discovery Protocol Enhancement for Second Port Disconnect The best solution for the lack of direct link state awareness is to address the root cause. The switch does not know the link state of the data port of the phone (the second port), but the phone does. Therefore, if the phone can communicate link state to the switch, the switch can immediately clear the session. This is exactly what the CDP Enhancement for Second Port Disconnect, also known as host movement detection, does. Cisco IP phones can send a CDP message to the switch indicating that the link state for the port of the data device is down, allowing the switch to immediately clear the session of the data device, as shown in Figure 8.
Cisco IP Phones support two types of X.509 certificates: the Manufacturing Installed Certificate (MIC) and the Locally Significant Certificate (LSC). Customers typically leverage MICs and LSCs to secure the signaling and voice path used for IP telephony, but the same certificates can be used for 802.1X.
MAB ⇒ MAC Authentication Bypass
For scalability and ease of deployment, phones should be enabled for 802.1X via the network. Starting with Unified CM 7.1.2, it is possible to enable 802.1X on phones by enabling 802.1X in the phone configuration file or via the Bulk Administration Tool on the Unified CM. The next time the phone resets and downloads its configuration file, 802.1X is enabled for all supported EAP methods.
Obviously, enabling 802.1X on phones via the network requires that the phones have network access. This means that you should enable the phones for 802.1X before you enable identity-based access control on the switches.
Bring up new phones in a physically secure staging area where the access ports are not enabled for 802.1X. This allows the phones to access the network and download the needed configuration files.
Manually enable 802.1X on each phone using the keypad. Although not practical for initial deployments of large numbers of phones, it may work for small numbers of phones. GOR - Not sure above would work - as the phone would not have the cert yet - so staging area is likely needed
Monitor Mode IP telephony is fully supported in monitor mode.
The primary goal of monitor mode is to enable authentication without imposing any form of access control. This approach allows network administrators to see who is on the network and prepare for access control in a later phase without affecting end users in any way.
To get the most value out of monitor mode, configure your phones and backend databases to the fullest extent possible. Enable 802.1X on the phones that support it, and create the most up-to-date MAC database possible. Although authorization, such as VLAN assignment and ACL assignment, is typically not done in monitor mode, enable authorization on the switch and create an authorization policy on the AAA server that sends the device-traffic-class=voice VSA for phones. This way, known phones are correctly identified and assigned to the voice domain, allowing you to discover phones that cannot authenticate and phones that can authenticate but are not properly authorized into the voice domain. Because you are in monitor mode, you can identify and fix authentication and authorization problems without affecting the operation of the phone.
When enabling monitor mode in an IP telephony environment, the host mode should be set to multiauth host mode. This prevents security violations even if the ACS server does not return the device-traffic-class=voice VSA for the phone.
Cisco IP Phones that do not Support 802.1X
| Cisco IP Phone Model | Support For 802.1X |
|---|---|
| 7902 | No |
| 7905 | No |
| 7910 | No |
| 7912 | No |
| 7920 | No |
| 7935 | No |
| 7936 | No |
| 7940 | No |
| 7960 | No |
MDA Overview
When a phone first plugs into a switchport, the link-up event triggers the start of the 802.1X state machine on the port. To get network access, the phone must now authenticate. Phones can authenticate using either 802.1X or MAB. As part of a successful authentication, the AAA server must inform the switch that the authenticated device is a phone.
If the phone unplugs from the switch, link state goes down and the switch clears all sessions on the port. Any phone or device that later connects to that same port is forced to authenticate to gain access.
Regardless of whether the phone is authenticated via 802.1X or MAB, the most important message from the MDA perspective is the final RADIUS Access-Accept from the ACS. The Access-Accept message contains a special Cisco vendor-specific attribute (VSA) that includes the string device-traffic-class = voice. This VSA tells the switch that the device that just authenticated is a phone and should be allowed access to the voice VLAN.
At a high level, MDA behaves the same way no matter what kind of IP phone is connected to the port. However, there are some functional differences between phones that require special consideration. Of particular importance is how the phone learns the voice VLAN. Cisco IP phones and some third-party phones learn the voice VLAN via CDP or Link Layer Discovery Protocol (LLDP). Other third-party phones rely on different mechanisms such as Dynamic Host Configuration Protocol (DHCP) or Trivial FTP (TFTP). MDA is flexible enough to handle both kinds of phones.
The Cisco IP phone and the switch start exchanging CDP messages. The first CDP frame received from the Cisco IP phone allows the switch to realize that a Cisco IP phone is actually connected to the port so that the right information, such as power level, voice VLAN ID (VVID), and so on) can then be delivered to the phone. CDP messages originated by the Cisco IP phone are always untagged, even when the Cisco IP phone learns the configured VVID. For non-Cisco phones that support LLDP for voice VLAN learning, the process is the same.
Best Practice Recommendation—Enable Control Plane Policing (CoPP). Because LLDP and CDP are allowed before authentication, CoPP can be used to rate-limit these types of traffic, thus preventing them from being used as a denial-of-service (DoS) attack vector. Consider enabling CoPP if your platform supports it.
Traffic Allowed Prior to Authentication: By default, 802.1X ensures that all traffic is dropped except for traffic needed for authentication. However, when MDA is enabled, the switch makes a few exceptions to this rule. Most notably, both CDP and LLDP are allowed before authentication. This allows phones to send and receive information regarding power requirements and the voice VLAN. Note that the processing of CDP does not mean that the phone is able to use CDP or LLDP to bypass authentication for general network access. Although phones may learn the voice VLAN via CDP or LLDP before authentication, the switch drops all other traffic, whether tagged with the voice VLAN or not, if the phone has not authenticated.
Asynchronously from the CDP exchange, the process of authentication begins and the switch generates a RADIUS-Request sent to the backend authentication server.
After the Cisco IP phone is successfully authenticated via 802.1X or MAB, the AAA server sends a RADIUS-Accept message to the switch with the device-traffic-class=voice VSA. After this attribute is received, the switch authorizes the MAC address of the phone and allows it access to the voice VLAN. The switch also temporarily allows the MAC address of the phone on the data VLAN in case the phone has not yet learned the VVID.
Cisco IP phone tags all its traffic leveraging the VVID information learned via the CDP exchange discussed in Step 1. This traffic is allowed through the switch port as a result of authenticating the MAC address of the Cisco IP phone in the voice domain. After the switch receives tagged traffic from the phone, indicating that the phone has learned the VVID, the switch no longer allows the MAC address of the phone on the data VLAN.
Acronyms
802.1x
IEEE 802.1X, an IEEE Standard for Port-Based Network Access Control (PNAC), provides protected authentication for secure network access. it uses an authentication server called a RADIUS Server. It checks a user’s credentials to see if they are an active member of the organization and, depending on the network policies, grants users varying levels of access to the network. This allows unique credentials or certificates to be used per user, eliminating the reliance on a single network password that can be easily stolen.
CAPF
The Cisco Certificate Authority Proxy Function (CAPF) is a Cisco proprietary service that issues Locally Significant Certificates (LSCs) and authenticates Cisco endpoints. The CAPF service runs on Unified Communications Manager and performs the following tasks:
- Issues LSCs to supported Cisco Unified IP Phones.
- Authenticates phones when mixed mode is enabled.
- Upgrades existing LSCs for phones.
- Retrieves phone certificates for viewing and troubleshooting.
CDP Enhancement for Second Port Disconnect
Cisco Discovery Protocol (CDP) Enhancement for Second Port Disconnect—Allows a Cisco IP phone to send a CDP message to the switch when a host unplugs from behind the phone. The switch is then able to clear any authenticated session for the indirectly connected host, exactly the same as if the host had been directly connected and the switch had detected a link down event.
EAP
The standard authentication protocol used on encrypted networks is Extensible Authentication Protocol (EAP), which provides a secure method to send identifying information over-the-air for network authentication. 802.1X is the standard that is used for passing EAP over wired and wireless Local Area Networks (LAN). It provides an encrypted EAP tunnel that prevents outside users from intercepting information.
The EAP protocol can be configured for credential (EAP-TTLS/PAP and PEAP-MSCHAPv2) and digital certificate (EAP-TLS) authentication and is a highly secure method for protecting the authentication process.
LSC
Locally Significant Certificates (LSC)—A certificate that installs on supported phones after you perform the necessary configuration tasks that are associated with the Cisco Certificate Authority Proxy Function (CAPF). The LSC secures the connection between Unified Communications Manager and the phone after you configure the device security mode for authentication or encryption.
MAB
MAC Authentication Bypass
MDA
Multi-Domain Authentication allows an IP Phone and a PC to authenticate on the same switch port while it places them on appropriate Voice and Data VLANs.
MIC
Manufacture Installed Certificates (MIC)—Cisco Manufacturing installs MICs automatically in supported phone models. Manufacturer-installed certificates authenticate to Cisco Certificate Authority Proxy Function (CAPF) for LSC installation. You cannot overwrite or delete manufacture-installed certificate.
Proxy EAPoL-Logoff—If
Proxy EAPoL-Logoff—If the phone or switch cannot support CDP Enhancement for Second Port Disconnect, a Cisco IP phone can send a proxy EAPoL-Logoff message to the switch when an 802.1X-authenticated device unplugs from behind the phone. This allows the switch to cleanly terminate the authenticated session in the absence of direct knowledge of the link state of the port to which the device was connected. However, unlike CDP Enhancement for Second Port Disconnect, this feature works only for 802.1X-authenticated devices; not MAB or WebAuth.
Implementation Summary
Cisco IP Phones support two types of X.509 certificates: the Manufacturing Installed Certificate (MIC) and the Locally Significant Certificate (LSC). A phone that presents a valid MIC can be assumed to be a valid Cisco phone. However, the MIC by itself cannot be used to determine whether this phone is a corporate asset or a rogue Cisco phone. For that, you need an LSC. Unlike the MIC, the LSC is signed by the CAPF of the Unified CM, which is the central call control and configuration engine for Cisco IP Telephony.
Unified CM can sign LSCs using the following types of CAPF:
Self-signed CAPF—Acts as a standalone CA, signing the LSCs with its own self-signed certificate. CA-signed CAPF—Signed by an external CA. A CA-signed CAPF signs the LSCs with the externally signed certificate in a subordinate manner.
Self-signed CAPF CAs have a lifetime of five years. Cisco ACS does not allow network access to the phones if the LSCs have expired. The lifetime of the CA-signed CAPF is determined by the CA when it issues the certificate to Unified CM. Whatever lifetime you choose, be sure to renew the CAPF certificate and reissue the LSCs before expiration.
In an 802.1X authentication, the AAA server is responsible for validating the certificate provided by the phone. To do this, the AAA server must have a copy of the root CA certificate that signed the certificate of the phone. The root certificates for both LSCs and MICs can be exported from the Unified CM Operating System Administration interface and imported into your AAA server.
There is currently no mechanism within Unified CM for revoking MICs and LSCs. If the certificate of a phone becomes invalid or a phone is stolen, that phone must be removed from, or renamed in, Unified CM to prevent it from gaining access to the call control resources in Unified CM. Although the phone is not able to register or make calls, the lack of an explicit certificate revocation mechanism means that the phone is still able to authenticate using 802.1X, because its certificate is still valid as far as the AAA server can determine. To keep the phone with a revoked certificate from gaining network access via 802.1X, use an exception policy in ACS 5 to specifically disallow that phone when it attempts to authenticate.
Guest VLAN
If an 802.1X authentication times out while waiting for an EAPOL message exchange and MAB (if configured) fails, the switch can be configured to assign the client to a guest VLAN that provides limited services. However, when MDA is deployed, the Guest VLAN is supported only for devices in the data domain. Phones that inadvertently get assigned to the Guest VLAN because of a failed MAB authentication do not function properly because they do not have access to the voice VLAN, and may cause a security violation if there is already an authenticated device in the data domain.
Implementation Steps
- Get list of all Cisco endpoints configured on CUCM
- Highlight if any of the devices do NOT support 802.1X
- Enable the phones for 802.1X before you enable identity-based access control on the switches.
- For any new phones once 802.1X has been enabled - a staging area must be used to allow the phone be configrued and download its Certificate in advance of been shipped to site - and connected to a 802.1X enabled port
CAPF Online CA Mode
If you chose the CAPF online CA mode where the LSC endpoint certificates are signed by an external CA, perform the following the steps:
- Import the CA certificate (or trust chain) to the Unified CM CAPF-trust.
- Import the CA server IIS certificate or its CA certificate (or trust chain) to the Unified CM tomcat-trust, if not already done.
- If some phones or TelePresence endpoints are configured in encrypted mode, import the CA certificate (or trust chain) to the Unified CM CallManager-trust, if not already done.
- Configure the CAPF service parameters on the Unified CM publisher. Use the following settings:
- Field
- Setting
- Certificate Issuer to Endpoint
- Online CA
- Online CA Hostname
- Common Name (CN) in the certificate used by Microsoft IIS service. Typically, this is an FQDN.
- Online CA Port - Typically 443
- Online CA Template
- Name of the certificate template defined in the Microsoft CA
- Online CA Type
- Microsoft CA
- Online CA Username - Username of a user that has the right permissions to issue a certificate using the certificate template specified above
- Online CA Password - Password of a user that has the right permissions to issue a certificate using the certificate template specified above
- Activate the Cisco Certificate Enrollment Service on the Unified CM publisher, if not already done.
- Restart the CAPF service.
Migrating phone from one cluster to another
If a secure phone gets moved to another cluster, the Unified Communications Manager will not trust the LSC certificate that the phone sends because it was issued by another CAPF, whose certificate is not in the CTL file.
To enable the secure phone to register, delete the existing CTL file. You can then use the Install/Upgrade option to install a new LSC certificate with the new CAPF and reset the phone for the new CTL file (or use the MIC). Use the Delete option in the CAPF section on the Phone Configuration window to delete the existing LSC before you move the phones.
I believe above is relevant only if using secure mode / ip phone using TLS with CUCM Cluster (which is not relevant for 802.1X).
SHA256
Beginning from Unified Communications Manager Release 11.5(1) SU1, all the LSC certificates issued by CAPF service are signed with SHA-256 algorithm. Therefore, IP Phones 7900/8900/9900 series models supports SHA-256 signed LSC certificates and external SHA2 identity certificates (Tomcat, CallManager, CAPF, TVS and so on). For any other cryptographic operation that require validation of signature, only SHA-1 is supported.
Note If you use phone models, which are in End of Software Maintenance or End of Life, we strongly recommend using the Unified Communications Manager before 11.5(1) SU1 release.
Above is confusing!!!
Troubleshooting
file view activelog cm/trace/capf/sdi/CiscoRA.log file list activelog cm/trace/capf/sdi/* file tail activelog cm/trace/capf/sdi/capf000000XX.txt