Default Security Overview
The Default Security features provides a basic level of security for supported Cisco Unified IP Phone without any extra configuration requirement.
This feature provides the following default security for supported IP Phones:
-
Default Authentication of TFTP
-
Optional Encryption
-
Certificate Verifications
Default Security uses the following components to provide basic security in non secure environments:
-
Identity Trust List (ITL)—this file is created only after TFTP service is activated at cluster installation and is used by Cisco Unified IP Phone to establish trust.
-
Trust Verification Service—This service runs on all Unified Communications Manager nodes and authenticates certificates for Cisco Unified IP Phone. The TVS certificate, along with a few other key certificates, is bundled in the ITL file.
Initial Trust List
The Initial Trust List (ITL) file is used for the initial security, so that the endpoints can trust Unified Communications Manager. ITL does not need any security features to be enabled explicitly. The ITL file is automatically created when the TFTP service is activated and the cluster is installed. The Unified Communications Manager's TFTP server’s private key is used to sign the ITL file.
When the Unified Communications Manager cluster or server is in non-secure mode, the ITL file is downloaded on every supported Cisco Unified IP Phone. You can view the contents of an ITL file using the CLI command admin:show itl.
Cisco Unified IP Phone need the ITL file to perform the following tasks:
-
Communicate securely to CAPF, a prerequisite to support the configuration file encryption.
-
Authenticate the configuration file signature
-
Authenticate application servers, such as EM services, directory, and MIDlet during HTTPS establishment using TVS.
If the Cisco IP Phone does not have an existing CTL file, it trusts the first ITL file automatically. The TVS must be able to return the certificate corresponding to the signer.
If the Cisco IP Phone has an existing CTL file, it uses the CTL file to authenticate the ITL file signature.
Note |
The SHA-1or MD5 algorithm value changes only when there is a change in the Initial Trust List (ITL) file value. You can use the checksum value of the ITL files to identify the difference between the ITL file of Cisco IP Phone and Unified Communications Manager cluster. The checksum value of the ITL file changes only when you modify the ITL file. |
The Initial Trust List (ITL) file has the same format as the CTL file. However, it is a smaller and leaner version.
The following attributes apply to the ITL file:
-
The system builds the ITL file automatically when the TFTP service is activated and you install the cluster. The ITL file is updated automatically if the content is modified.
-
The ITL file does not require eTokens. It uses a soft eToken (the private key associated with TFTP server's CallManager certificate).
-
The Cisco Unified IP Phone download the ITL file during a reset, restart, or after downloading the CTL file.
The ITL file contains the following certificates:
-
ITLRecovery Certificate—This certificate signs the ITL File.
-
The CallManager certificate of the TFTP server—This certificate allows you to authenticate the ITL file signature and the phone configuration file signature.
-
All the TVS certificates available on the cluster—These certificates allow the phone to communicate to TVS securely and to request certificates authentication.
-
The CAPF certificate—These certificates support configuration file encryption. The CAPF certificate isn't required in the ITL File (TVS can authenticate it), however, it simplifies the connection to CAPF.
The ITL file contains a record for each certificate. Each record contains:
-
A certificate
-
Pre-extracted certificate fields for easy lookup by the Cisco IP Phone
-
Certificate role (TFTP, CUCM, TFTP+CCM, CAPF, TVS, SAST)
The TFTP server's CallManager certificate is present in two ITL records with two different roles:
-
TFTP or the TFTP and CCM role—To authenticate configuration file signature.
-
SAST role—To authenticate the ITL file signature.
Certificate Management Changes for ITLRecovery Certificate
-
The validity of ITLRecovery has been extended from 5 years to 20 years to ensure that the ITLRecovery certificate remains same for a longer period.
Note
The validity of ITLRecovery certificates continues to be 5 years if you upgrade Unified Communications Manager. While upgrading Unified Communications Manager, the certificates get copied to the later release. However, when you regenerate an ITLRecovery certificate or when you do a fresh install of Unified Communications Manager, the validity of ITLRecovery gets extended to 20 years.
-
Before you regenerate an ITLRecovery certificate, a warning message appears on both the CLI and the GUI. This warning message displays that if you use a tokenless CTL and if you regenerate the CallManager certificate, ensure that the CTL file has the updated CallManager certificate and that certificate is updated to endpoints.
Interactions and Restrictions
If a Unified Communications Manager cluster has more than 39 certificates, then the ITL file size on Cisco IP Phone exceeds 64 kilobytes. Increase in the ITL file size affects the ITL to load properly on the phone causing the phone registration to fail with Unified Communications Manager.
Trust Verification Service
There are large number of phones in a network and Cisco Unified IP Phone have limited memory. Hence, Unified Communications Manager acts as a remote trust store through TVS and so that a certificate trust store doesn’t have to be placed on each phone. The Cisco Unified IP Phones contact TVS server for verification, because it cannot verify a signature or certificate through CTL or ITL files. Thus, having a central trust store is easier to manage than having the trust store on all the Cisco Unified IP Phones.
TVS enables Cisco Unified IP Phone to authenticate application servers, such as EM services, directory, and MIDlet, during HTTPS establishment.
TVS provides the following features:
-
Scalability—Cisco Unified IP Phone resources are not impacted by the number of certificates to trust.
-
Flexibility—Addition or removal of trust certificates are automatically reflected in the system.
-
Security by Default—Non-media and signaling security features are part of the default installation and don't require user intervention.
Note |
When you enable secure signaling and media, create a CTL file and then set the cluster to mixed mode. To create a CTL file and set the cluster to mixed mode, use the CLI command utils ctl set-cluster mixed-mode. |
The following are the basic concepts that describe TVS:
-
TVS runs on the Unified Communications Manager server and authenticates certificates on behalf of the Cisco IP Phone.
-
Cisco Unified IP Phone only needs to trust TVS, instead of downloading all the trusted certificates.
-
The ITL file is generated automatically without user intervention. The ITL file is downloaded by Cisco Unified IP Phone and trust flows from there.
Authentication, Integrity, and Authorization
Integrity and authentication protect against the following threats:
-
TFTP file manipulation (integrity)
-
Modification of call-processing signaling between the phone and Unified Communications Manager (authentication)
-
Man-in-the-middle attacks (authentication), as defined in Acronyms section.
-
Phone and server identity theft (authentication)
-
Replay attack (digest authentication)
Authorization specifies what an authenticated user, service, or application can do. You can implement multiple authentication and authorization methods in a single session.
Image Authentication
This process prevents tampering with the binary image, the firmware load, prior to loading it on the phone. Tampering with the image causes the phone to fail the authentication process and reject the image. Image authentication occurs through signed binary files that automatically install when you install Unified Communications Manager. Likewise, firmware updates that you download from the web also provide signed binary images.
Device Authentication
This process validates the identity of the communicating device and ensures that the entity is who it claims to be.
Device authentication occurs between the Unified Communications Manager server and supported Cisco Unified IP Phones, SIP trunks, or JTAPI/TAPI/CTI applications (when supported). An authenticated connection occurs between these entities only when each entity accepts the certificate of the other entity. Mutual authentication describes this process of mutual certificate exchange.
Device authentication relies on the creation of the CiscoCTL file (for authenticating Unified Communications Manager server node and applications), and the Certificate Authority Proxy Function (for authenticating phones and JTAPI/TAPI/CTI applications).
Tip |
A SIP user agent that connects via a SIP trunk authenticates to Unified Communications Manager if the CallManager trust store contains the SIP user agent certificate and if the SIP user agent contains the Unified Communications Manager certificate in its trust store. For information on updating the CallManager trust store, refer to the Administration Guide for Cisco Unified Communications Manager that supports this Unified Communications Manager release. |
File Authentication
This process validates digitally signed files that the phone downloads; for example, the configuration, ring list, locale, and CTL files. The phone validates the signature to verify that file tampering did not occur after the file creation. For a list of devices that are supported, see "Phone Model Support".
If you configure the cluster for mixed mode, the TFTP server signs static files, such as ring list, localized, default.cnf.xml, and ring list wav files, in.sgn format. The TFTP server signs files in <device name>.cnf.xml format every time that the TFTP server verifies that a data change occurred for the file.
The TFTP server writes the signed files to disk if caching is disabled. If the TFTP server verifies that a saved file has changed, the TFTP server re-signs the file. The new file on the disk overwrites the saved file that gets deleted. Before the phone can download the new file, the administrator must restart affected devices in Unified Communications Manager.
After the phone receives the files from the TFTP server, the phone verifies the integrity of the files by validating the signature on the file. For the phone to establish an authenticated connection, ensure that the following criteria are met:
-
A certificate must exist in the phone.
-
The CTL file must exist on the phone, and the Unified Communications Manager entry and certificate must exist in the file.
-
You configured the device for authentication or encryption.
Signaling Authentication
This process, also known as signaling integrity, uses the TLS protocol to validate that no tampering occurred to signaling packets during transmission.
Signaling authentication relies on the creation of the Certificate Trust List (CTL)file.
Digest Authentication
This process for SIP trunks and phones allows Unified Communications Manager to challenge the identity of a device that is connecting to Unified Communications Manager. When challenged, the device presents its digest credentials, similar to a username and password, to Unified Communications Manager for verification. If the credentials that are presented match those that are configured in the database for that device, digest authentication succeeds, and Unified Communications Manager processes the SIP request.
Note |
Be aware that the cluster security mode has no effect on digest authentication. |
Note |
If you enable digest authentication for a device, the device requires a unique digest user ID and password to register. |
You configure SIP digest credentials in the Unified Communications Manager database for a phone user or application user.
-
For applications, you specify digest credentials in the Application User Configuration window.
-
For phones that are running SIP, you specify the digest authentication credentials in the End User window. To associate the credentials with the phone after you configure the user, you choose a Digest User, the end user, in the Phone Configuration window. After you reset the phone, the credentials exist in the phone configuration file that the TFTPserver offers to the phone. See topics related to encrypted phone configuration file setup to ensure digest credentials do not get sent in the clear in TFTP downloads.
-
For challenges received on SIP trunks, you configure a SIP realm, which specifies the realm username (device or application user) and digest credentials.
When you enable digest authentication for an external phone or trunk that is running SIP and configure digest credentials, Unified Communications Manager calculates a credentials checksum that includes a hash of the username, password, and the realm. The system uses a nonce value, which is a random number, to calculate the MD5 hash. Unified Communications Manager encrypts the values and stores the username and the checksum in the database.
To initiate a challenge, Unified Communications Manager uses a SIP 401 (Unauthorized) message, which includes the nonce and the realm in the header. You configure the nonce validity time in the SIP device security profile for the phone or trunk. The nonce validity time specifies the number of minutes that a nonce value stays valid. When the time interval expires, Unified Communications Manager rejects the external device and generates a new number.
Note |
Unified Communications Manager acts as a user agent server (UAS) for SIP calls that are originated by line-side phones or devices that are reached through the SIP trunk, as a user agent client (UAC) for SIP calls that it originates to the SIP trunk, or a back-to-back user agent (B2BUA) for line-to-line or trunk-to-trunk connections. In most environments, Unified Communications Manager acts primarily as B2BUA connecting SCCP and SIP endpoints. (A SIP user agent represents a device or application that originates a SIP message.) |
Tip |
Digest authentication does not provide integrity or confidentiality. To ensure integrity and confidentiality for the device, configure the TLS protocol for the device, if the device supports TLS. If the device supports encryption, configure the device security mode as encrypted. If the device supports encrypted phone configuration files, configure encryption for the files. |
Digest Authentication for Phones
When you enable digest authentication for a phone, Unified Communications Manager challenges all requests for phones that are running SIP except keepalive messages. Unified Communications Manager does not respond to challenges from line-side phones.
After receiving a response, Unified Communications Manager validates the checksum for the username that is stored in the database against the credentials in the response header.
Phones that are running SIP exist in the Unified Communications Manager realm, which is defined in Unified Communications Manager Administration at installation. You configure the SIP Realm for challenges to phones with the service parameter SIP Station Realm. Each digest user can have one set of digest credentials per realm.
Tip |
If you enable digest authentication for an end user but do not configure the digest credentials, the phone will fail registration. If the cluster mode is nonsecure and you enable digest authentication and configure digest credentials, the digest credentials get sent to the phone, and Unified Communications Manager still initiates challenges. |
Digest Authentication for Trunks
When you enable digest authentication for a trunk, Unified Communications Manager challenges SIP trunk requests from SIP devices and applications that connect through a SIP trunk. The system uses the Cluster ID enterprise parameter in the challenge message. SIP user agents that connect through the SIP trunk respond with the unique digest credentials that you configured for the device or application in Unified Communications Manager.
When Unified Communications Manager initiates a SIP trunk request, a SIP user agent that connects through the SIP trunk can challenge the identity of Unified Communications Manager. For these incoming challenges, you configure a SIP Realm to provide the requested credentials for the user. When Unified Communications Manager receives a SIP 401(Unauthorized) or SIP 407 (Proxy Authentication Required) message, Unified Communications Manager looks up the encrypted password for the realm that connects though the trunk and for the username that the challenge message specifies. Unified Communications Manager decrypts the password, calculates the digest, and presents it in the response message.
Tip |
The realm represents the domain that connects through the SIP trunk, such as xyz.com, which helps to identify the source of the request. |
To configure the SIP Realm, see topics related to digest authentication for SIP trunks. You must configure a SIP Realm and username and password in Unified Communications Manager for each SIP trunk user agent that can challenge Unified Communications Manager. Each user agent can have one set of digest credentials per realm.
Authorization
Unified Communications Manager uses the authorization process to restrict certain categories of messages from phones that are running SIP, from SIP trunks, and from SIP application requests on SIP trunks.
-
For SIP INVITE messages and in-dialog messages, and for phones that are running SIP, Unified Communications Manager provides authorization through calling search spaces and partitions.
-
For SIP SUBSCRIBE requests from phones, Unified Communications Manager provides authorization for user access to presence groups.
-
For SIP trunks, Unified Communications Manager provides authorization of presence subscriptions and certain non-INVITE SIP messages; for example, out-of-dial REFER, unsolicited notification, and any SIP request with the replaces header. You specify authorization in the SIP Trunk Security Profile Configuration window when you check the allowed SIP requests in the window.
To enable authorization for SIP trunk applications, check the Enable Application Level Authorization and the Digest Authentication check box in the SIP Trunk Security Profile window; then, check the allowed SIP request check boxes in the Application User Configuration window.
If you enable both SIP trunk authorization and application level authorization, authorization occurs for the SIP trunk first and then for the SIP application user. For the trunk, Unified Communications Manager downloads the trunk Access Control List (ACL) information and caches it. The ACL information gets applied to the incoming SIP request. If the ACL does not allow the SIP request, the call fails with a 403 Forbidden message.
If the ACL allows the SIP request, Unified Communications Manager checks whether digest authentication is enabled in the SIP Trunk Security Profile. If digest authentication is not enabled and application-level authorization is not enabled, Unified Communications Manager processes the request. If digest authentication is enabled, Unified Communications Manager verifies that the authentication header exists in the incoming request and then uses digest authentication to identify the source application. If the header does not exist, Unified Communications Manager challenges the device with a 401 message.
Before an application-level ACL gets applied, Unified Communications Manager authenticates the SIP trunk user agent through digest authentication. Therefore, you must enable digest authentication in the SIP Trunk Security Profile before application-level authorization can occur.
NMAP Scan Operation
You can run a Network Mapper (NMAP) scan program on any Windows or Linux platform to perform vulnerability scans. NMAP represents a free and open source utility for network exploration or security auditing.
Note |
NMAP DP scan can take up to 18 hours to complete. |
Syntax
nmap -n -vv -sU -p <port_range> <ccm_ip_address>
where:
-n: No DNS resolution. Tells NMAP to never do reverse DNS resolution on the active IP addresses that it finds. Because DNS can be slow even with the NMAP built-in parallel stub resolver, this option can slash scanning times.
-v: Increases the verbosity level, which causes NMAP to print more information about the scan in progress. The system shows open ports as they are found and provides completion time estimates when NMAP estimates that a scan will take more than a few minutes. Use this option twice or more for even greater verbosity.
-sU: Specifies a UDP port scan.
-p: Specifies which ports to scan and overrides the default. Be aware that individual port numbers are acceptable, as are ranges that are separated by a hyphen (for example 1-1023).
ccm_ip_address: IP address of Cisco Unified Communications Manager
Autoregistration
The system supports autoregistration in both mixed mode and nonsecure mode. The default configuration file will also be signed. Cisco IP Phones that do not support Security by Default will be served a nonsigned default configuration file.
Migrate IP Phones Between Clusters with Cisco Unified Communications Manager and ITL Files
Unified Communications Manager 8.0(1) and later introduced the new Security By Default feature and the use of Initial Trust List (ITL) files. With this new feature, you must be careful when moving phones between different Unified CM clusters and ensure that you follow the proper steps for migration.
Caution |
Failure to follow the proper steps may lead to a situation where thousands of phones must manually have their ITL files deleted. |
Cisco IP Phones that support the new ITL file must download this special file from their Unified CM TFTP server. Once an ITL file is installed on a phone, all future configuration files and ITL file updates must be signed by one of the following items:
-
The TFTP server certificate that is currently installed on the phone or
-
A TFTP certificate that can be validated TVS services on one of the clusters. You can find the certificates of TVS services within the cluster listed in the ITL file.
With this new security functionality in mind, three problems can occur when moving a phone from one cluster to another cluster:
-
The ITL file of the new cluster is not signed by the current ITL file signer, so the phone cannot accept the new ITL file or configuration files.
-
The TVS servers listed in the existing ITL of the phone may not be reachable when the phones are moved to the new cluster.
-
Even if the TVS servers are reachable for certificate verification, the old cluster servers may not have the new server certificates.
If one or more of these three problems are encountered, one possible solution is to delete the ITL file manually from all phones being moved between clusters. However, this is not a desirable solution since it requires massive effort as the number of phones increases.
The most preferred option is to make use of the Cisco Unified CM Enterprise Parameter Prepare Cluster for Rollback to pre-8.0. Once this parameter is set to True, the phones download a special ITL file that contains empty TVS and TFTP certificate sections.
When a phone has an empty ITL file, the phone accepts any unsigned configuration file (for migrations to Unified CM pre-8.x clusters), and also accepts any new ITL file (for migrations to different Unified CM 8.x clusters).
The empty ITL file can be verified on the phone by checking
. Empty entries appear where the old TVS and TFTP servers used to be.The phones must have access to the old Unified CM servers only as long as it takes them to download the new empty ITL files.
If you plan to keep the old cluster online, disable the Prepare Cluster for Rollback to pre-8.0 Enterprise Parameter to restore Security By Default.