Thanks for your feedback.

Security features protect against threats, including threats to the identity of the phone and to data. These features establish and maintain authenticated communication streams between the phone and the Cisco Unified Communications Manager server, and ensure that the phone uses only digitally signed files.

Cisco Unified Communications Manager Release 8.5(1) and later includes Security by default, which provides the following security features for Cisco IP Phones without running the CTL client:

• Signing of the phone configuration files

• Phone configuration file encryption

• HTTPS with Tomcat and other web services

Implementing security in the Cisco Unified Communications Manager system prevents identity theft of the phone and Cisco Unified Communications Manager server, prevents data tampering, and prevents call signaling and media stream tampering.

To alleviate these threats, the Cisco IP telephony network establishes and maintains secure (encrypted) communication streams between a phone and the server, digitally signs files before they are transferred to a phone, and encrypts media streams and call signaling between Cisco IP Phones.

A Locally Significant Certificate (LSC) installs on phones after you perform the necessary tasks that are associated with the Certificate Authority Proxy Function (CAPF). You can use Cisco Unified Communications Manager Administration to configure an LSC, as described in the Cisco Unified Communications Manager Security Guide. Alternatively, you can initiate the installation of an LSC from the Security menu on the phone. This menu also lets you update or remove an LSC.

The phones use the phone security profile, which defines whether the device is nonsecure or secure. For information about applying the security profile to the phone, see the documentation for your particular Cisco Unified Communications Manager release.

If you configure security-related settings in Cisco Unified Communications Manager Administration, the phone configuration file contains sensitive information. To ensure the privacy of a configuration file, you must configure it for encryption. For detailed information, see the documentation for your particular Cisco Unified Communications Manager release.

The following table provides an overview of the security features that the phones support. For more information, see the documentation for your particular Cisco Unified Communications Manager release.

The following table contains the Trust List update alarm messages and meaning. For more information, see the Cisco Unified Communications Manager documentation.

When security is implemented for a phone, you can identify secure phone calls by icons on the phone screen. You can also determine whether the connected phone is secure and protected if a security tone plays at the beginning of the call.

In a secure call, all call signaling and media streams are encrypted. A secure call offers a high level of security, providing integrity and privacy to the call. When a call in progress is encrypted, you can see the secure icon on the line.

In Cisco Unified Communications Manager, phones configured as secure (encrypted and trusted) can be assigned a protected status. Once protected, these devices can be configured to play a security tone at the beginning of each call.

• Protected Device:

  To change the status of a secure phone to protected:

  1. In Cisco Unified Communications Manager Administration, select Device > Phone.
  2. Locate the phone that you will set up.
  3. In the Phone Configuration window, select the Protected Device check box.
  4. Click Save.

• Play Secure Indication Tone:

  To enable the protected phone to play a secure or nonsecure indication tone:

  1. In Cisco Unified Communications Manager Administration, select System > Service Parameters.
  2. Select the server and then the Cisco CallManager service.
  3. In the Clusterwide Parameters (Feature - Secure Tone) area, set the Play Tone to Indicate Secure/Non-Secure Call Status setting to True.
  4. Click Save.

Because all WLAN devices that are within range can receive all other WLAN traffic, securing voice communications is critical in WLANs. To ensure that intruders don’t manipulate nor intercept voice traffic, the Cisco SAFE Security architecture supports the phone. For more information about security in networks, see http://www.cisco.com/en/US/netsol/ns744/networking_solutions_program_home.html.

The Cisco Wireless IP telephony solution provides wireless network security that prevents unauthorized sign-ins and compromised communications by using the following authentication methods that the phone supports.

• Open Authentication: Any wireless device can request authentication in an open system. The AP that receives the request may grant authentication to any requestor or only to requestors that are found on a list of users. Communication between the wireless device and Access Point (AP) could be nonencrypted.

• Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling (EAP-FAST) Authentication: This client-server security architecture encrypts EAP transactions within a Transport Level Security (TLS) tunnel between the AP and the RADIUS server, such as Identity Services Engine (ISE).

  The TLS tunnel uses Protected Access Credentials (PACs) for authentication between the client (phone) and the RADIUS server. The server sends an Authority ID (AID) to the client (phone), which in turn selects the appropriate PAC. The client (phone) returns a PAC-Opaque to the RADIUS server. The server decrypts the PAC with the primary key. Both endpoints now contain the PAC key and a TLS tunnel is created. EAP-FAST supports automatic PAC provisioning, but you must enable it on the RADIUS server.

  In ISE, by default, the PAC expires in one week. If the phone has an expired PAC, authentication with the RADIUS server takes longer while the phone gets a new PAC. To avoid PAC provisioning delays, set the PAC expiration period to 90 days or longer on the ISE or RADIUS server.

• Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) Authentication: EAP-TLS requires a client certificate for authentication and network access. For wireless EAP-TLS, the client certificate can be MIC, LSC, or user-installed certificate.

• Protected Extensible Authentication Protocol (PEAP): Cisco proprietary password-based mutual authentication scheme between the client (phone) and a RADIUS server. The phone can use PEAP for authentication with the wireless network. Both PEAP-MSCHAPV2 and PEAP-GTC authentication methods are supported.

• Pre-Shared Key (PSK): The phone supports ASCII and hexadecimal (HEX) formats. You must use these formats when setting up a WPA2/SAE Pre-shared key.

  ASCII: An ASCII-character string with 8 to 63 characters in length (0-9, lowercase a-z, uppercase A-Z, and special characters). For example, GREG123567@9ZX&W.

  HEX: A HEX-character string with 64 hex digits in length (0-9, a-f or A-F).

The following authentication schemes use the RADIUS server to manage authentication keys:

• WPA2/WPA3: Uses RADIUS server information to generate unique keys for authentication. Because these keys are generated at the centralized RADIUS server, WPA2/WPA3 provides more security than WPA preshared keys that are stored on the AP and phone.

• Fast Secure Roaming: Uses RADIUS server and a wireless domain server (WDS) information to manage and authenticate keys. The WDS creates a cache of security credentials for FT-enabled client devices for fast and secure reauthentication.

With WPA2/WPA3, encryption keys aren’t entered on the phone, but are automatically derived between the AP and phone. But the EAP username and password that are used for authentication must be entered on each phone.

To help protect voice traffic over the wireless link, the phone supports AES-based encryption for WPA2/WPA3 authentication. AES is a symmetric block cipher standardized by NIST. AES uses a fixed 128-bit block size and supports key sizes of 128 bits, 192 bits, and 256 bits. In Wi-Fi networks, AES is used by cipher suites such as CCMP or GCMP, while authentication is provided separately by PSK, SAE, or 802.1X/EAP, depending on the configured WLAN security mode. The supported cipher suite and key size depend on the phone model and WLAN configuration.

When the phone uses AES encryption, both the signaling SIP packets and voice Real-Time Transport Protocol (RTP) packets are encrypted between the AP and the phone.

Authentication and encryption schemes are set up within the wireless LAN. VLANs are configured in the network and on the APs and specify different combinations of authentication and encryption. An SSID associates with a VLAN and the particular authentication and encryption scheme. For wireless client devices to authenticate successfully, you must configure the same SSIDs with their authentication and encryption schemes on the APs and on the phone.

Some authentication schemes require specific types of encryption.

The authentication and encryption schemes in the following table shows the network configuration options for Cisco Wireless Phone 9821 that corresponds to AP configuration.

Cisco Wireless Phone 9821 supports 802.1X authentication for wired networks. This is typically used during automatic provisioning when the phone is connected to the desktop charger via a supported USB-to-Ethernet adapter.

Support for 802.1X authentication on wired networks requires several components as follows:

• Cisco IP Phone: The phone initiates the request to access the network. Cisco IP Phones contain an 802.1X supplicant. This supplicant allows network administrators to control the connectivity of IP phones to the LAN switch ports. The current release of the phone 802.1X supplicant uses the EAP-FAST and EAP-TLS options for network authentication.

• Authentication server: The authentication server and the switch must both be configured with a RADIUS shared secret.

• Switch: The switch must support 802.1X, so it can act as the authenticator and relay the EAP messages between the phone and the authentication server. After the exchange completes, the switch grants or denies the phone access to the network.

Cisco IP Phones and Cisco Catalyst switches traditionally use Cisco Discovery Protocol (CDP) to identify each other and determine parameters such as VLAN allocation and inline power requirements.

You must perform the following actions to configure 802.1X.

• Configure CDP/LLDP voice VLAN bypass.

• Configure the authentication server and the switch before you enable 802.1X authentication for wired networks on the phone.

• Configure Voice VLAN: Because the 802.1X standard doesn't account for VLANs, you should configure this setting based on the switch support.

  • Enabled: If you’re using a switch that supports multidomain authentication, you can configure it to use the voice VLAN.
  • Disabled: If the switch doesn’t support multidomain authentication, disable the Voice VLAN and consider assigning the port to the native VLAN.

• Cisco Wireless Phone 9821 has a different prefix in the PID from that for the other Cisco phones. To enable your phone to pass 802.1X authentication, set the Radius·User-Name parameter to include your Cisco Wireless Phone 9821.

  For example, the PID of Cisco Wireless Phone 9821 is WP-9821. You can set Radius·User-Name to Start with WP or Contains WP in both of the following sections:

  • Policy > Conditions > Library Conditions

  • Policy > Policy Sets > Authorization Policy > Authorization Rule 1