Cisco IP Phone Security

Domain and Internet Setting

Configure Restricted Access Domains

You can configure the phone to register, provision, firmware upgrade, and send reports using only the specified servers. Any registration, provisioning, upgrade, and report that don't use the specified servers can't be performed on the phone. If you specify the servers to use, ensure that the servers you enter in the following fields are included in the list:

  • Profile Rule, Profile Rule B, Profile Rule C, and Profile Rule D on the Provisioning tab

  • Upgrade Rule and Cisco Headset Upgrade Rule on the Provisioning tab

  • Report Rule on the Provisioning tab

  • Custom CA Rule on the Provisioning tab

  • Proxy and Outbound Proxy on the Ext (n) tab

Before you begin

Access the Phone Web Interface.

Procedure

Step 1

Select Voice > System.

Step 2

In the System Configuration section, locate the Restricted Access Domains field and enter fully qualified domain names (FQDNs) for each server. Separate FQDNs with commas.

Example:

voiceip.com, voiceip1.com

You can configure this parameter in the phone configuration XML file (cfg.xml) by entering a string in this format: 

<Restricted_Access_Domains ua="na">voiceip.com, voiceip1.com</Restricted_Access_Domains>

Step 3

Click Submit All Changes.

Configure the DHCP Options

You can set the order in which your phone uses the DHCP options. For help with DHCP Options, see DHCP Option Support.

Before you begin

Access the Phone Web Interface.

Procedure

Step 1

Select Voice > Provisioning.

Step 2

In the Configuration Profile section, set the DHCP Option To Use and DHCPv6 Option To Use parameters as described in the Parameters for DHCP Options Configuration table.

Step 3

Click Submit All Changes.

Parameters for DHCP Options Configuration

The following table defines the function and usage of parameters for DHCP Options Configuration in the Configuration Profile section under the Voice>Provisioning tab in the phone web interface. It also defines the syntax of the string that is added in the phone configuration file with XML(cfg.xml) code to configure a parameter.

Table 1. Parameters for DHCP Options Configuration

Parameter

Description

DHCP Option To Use

DHCP options, delimited by commas, used to retrieve firmware and profiles.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format:

    <DHCP_Option_To_Use ua="na">66,160,159,150,60,43,125</DHCP_Option_To_Use>

  • In the phone web page, enter the DHCP options separated by commas.

    Example: 66,160,159,150,60,43,125

Default: 66,160,159,150,60,43,125

DHCPv6 Option To Use

DHCPv6 options, delimited by commas, used to retrieve firmware and profiles.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format:

    <DHCPv6_Option_To_Use ua="na">17,160,159</DHCPv6_Option_To_Use>

  • In the phone web page, enter the DHCP options separated by commas.

    Example: 17,160,159

Default: 17,160,159

DHCP Option Support

The following table lists the DHCP options that are supported on the multiplatform phones.

Network Standard

Description

DHCP option 1

Subnet mask

DHCP option 2

Time offset

DHCP option 3

Router

DHCP option 6

Domain name server

DHCP option 15

Domain name

DHCP option 41

IP address lease time

DHCP option 42

NTP server

DHCP option 43

Vendor-specific information

Can be used for TR.69 Auto Configurations Server (ACS) discovery.

DHCP option 56

NTP server

NTP server configuration with IPv6

DHCP option 60

Vendor class identifier

DHCP option 66

TFTP server name

DHCP option 125

Vendor-identifying vendor-specific information

Can be used for TR.69 Auto Configurations Server (ACS) discovery.

DHCP option 150

TFTP server

DHCP option 159

Provisioning server IP

DHCP option 160

Provisioning URL

Configure the Challenge for SIP INVITE Messages

You can set up the phone to challenge the SIP INVITE (initial) message in a session. The challenge restricts the SIP servers that are permitted to interact with devices on a service provider network. This practice prevents malicious attacks against the phone. When you enable this feature, authorization is required for initial incoming INVITE requests from the SIP proxy.

You can also configure the parameters in the phone configuration file with XML(cfg.xml) code.

Before you begin

Access the Phone Web Interface.

Procedure

Step 1

Select Voice > Ext(n), where n is an extension number.

Step 2

In the SIP Settings section, select Yes from the Auth INVITE list to enable this feature or select No to disable it.

You can configure this parameter in the phone configuration XML file (cfg.xml) by entering a string in this format: 
<Auth_INVITE_1>Yes</Auth_INVITE_1_>

Default: No.

Step 3

Click Submit All Changes.

Support for RFC-8760

You can replace RFC-3261 and can add support of additional authentication digest algorithms that are specified by RFC-8760. RFC-8760 specifies digest algorithms, such as SHA256, SHA-512/256, and MD5. With RFC-8760, phone sends SIP REGISTER or INVITE or SUBSCRIBE requests without authorization header field. SIP server responses 401/407 status code with www-authenticate or proxy-authenticate header field. A SIP server responds with multiple www-authenticate headers. If multiple headers are sent, each must have a different algorithm, with the most preferred one first. Support for RFC-8760 has advantages over RFC-3261 and are described in the following table for different scenarios.

Steps

SIP Request Direction

RFC-3261

RFC-8760

Step 1

Phone to SIP server

Phone sends SIP requests without authorization.

Phone sends SIP requests without authorization.

Step 2

SIP server to Phone

SIP Server responses 401 status with one www-authenticate with MD5 algorithm.

SIP server responses 401 status with one or multiple www-authenticates with different algorithms, such as SHA-256, SHA-512-256, and MD5.

Step 3

Phone to SIP server

Phone retries to send request and add an authorization header with MD5 algorithm.

Phone retries to send request and add an authorization with top most header field(SHA-256).

Step 4

SIP server to Phone

SIP server validates the authorization.

SIP server validates the authorization.

Enable Auth INVITE and Auth Resync Reboot

You can enable the phone authorization with RFC 8760.

Before you begin

Procedure

Step 1

Select Voice > Ext (n) where n is an extension number.

Step 2

In the SIP Settings section, select Yes from the Auth Support RFC8760 list.

When you select Yes, the phone authorization supports RFC 8760. You can disable it when you select No.

You can configure this parameter in the phone configuration XML file (cfg.xml) by entering a string in this format:

<Auth_Support_RFC8760>Yes</Auth_Support_RFC8760/>

Default: No

Step 3

Click Submit All Changes .

Support for Additional Digest Algorithms for Hoteling Authentication

Phone now support RFC 8760 for hoteling authentication. To support this feature, SHA-256, SHA-512, and SHA-256 digest algorithms are added to the phone. Before, phone was supporting only MD5 algorithm.

Control the TLS Minimum Value

You can control the minimum TLS value of the phone with the TLS parameters. When configured, the minimum TLS version will be used for negotiation between the TLS client and TLS server.

You can set the minimum version of TLS for client and server respectively, such as 1.0, 1.1, or 1.2.

Before you begin

Procedure

Step 1

Select Voice > System

Step 2

In the Security Settings section, select a TLS version from the TLS Client Min Version list.

  • TLS 1.0: The TLS client supports the versions of TLS from 1.0 to 1.2.

    If the TLS version in server is lower than 1.0, the connection can't be established.

  • TLS 1.1: The TLS client supports TLS 1.1 and 1.2.

    If the TLS version in server is lower than 1.1, the connection can't be established.

  • TLS 1.2 (default): The TLS client supports TLS 1.2 only.

    If the TLS version in server is lower than 1.2, the connection can't be established.

The following table shows the brief view TLS client minimum value result.

TLS Client min version

Server TLS version

Results

TLS 1.0

TLS 1.0

TLS 1.0

TLS 1.1

TLS 1.1

TLS 1.2

TLS 1.2

TLS 1.1

TLS 1.0

Protocol alert

TLS 1.1

TLS 1.1

TLS 1.2

TLS 1.2

TLS 1.2

TLS 1.0

Protocol alert

TLS 1.1

Protocol alert

TLS 1.2

TLS 1.2

You can configure this parameter in the phone configuration XML file (cfg.xml) by entering a string in this format:

<TLS_Client_Min_Version ua="na">TLS 1.2</TLS_Client_Min_Version>

Default Value: TLS 1.2

Note

 

This feature has been applied to most of the TLS clients initiated by phone, such as SIP over TLS, XMPP, E911 Geolocation, and Wifi.

Step 3

Select a TLS version from the TLS Server Min Version list. Users need to use an HTTPS client that support TLS to connect with the phone.

  • TLS 1.1: The TLS server supports TLS 1.1 and 1.2.

    If the TLS version in client is lower than 1.1, the connection can't be established.

  • TLS 1.2 (default): The TLS server supports TLS 1.2 only.

    If the TLS version in client is lower than 1.2, the connection can't be established.

The following table shows the brief view TLS server minimum value result.

TLS Server min version

Client TLS version

Results

TLS 1.1

TLS 1.0

Protocol alert

TLS 1.1

TLS 1.1

TLS 1.2

TLS 1.2

TLS 1.2

TLS 1.0

Protocol alert

TLS 1.1

Protocol alert

TLS 1.2

TLS 1.2

You can configure this parameter in the phone configuration XML file (cfg.xml) by entering a string in this format:

<TLS_Server_Min_Version ua="na">TLS 1.2</TLS_Server_Min_Version>

Default Value: TLS 1.2

Step 4

Click Submit All Changes.

Enable the Control of Webex Metrics Service

With Metrics Enable, enable the phone control of all metric services.

Before you begin

Procedure

Step 1

Select Voice > Phone

Step 2

In the Webex section, select Yes from the Metrics Enable list.

When you select Yes, the phone controls the sending of all metrics messages. You can disable it when you select No.

You can configure this parameter in the phone configuration XML file (cfg.xml) by entering a string in this format:

<Webex_Metrics_Enable ua="na">Yes</Webex_Metrics_Enable>

Default: No

Step 3

Click Submit All Changes.

Enable the Control of PRT Upload at Crash Service

You can indicate whether to automatically upload the PRT package to the server when the phone crashes.

Before you begin

Procedure

Step 1

Select Voice > Provisioning

Step 2

In the Problem Report Tool section, select Yes from the PRT Upload at Crash list.

When you select Yes, the phone controls the automatic upload of the process crash. You can disable it when you select No.

You can configure this parameter in the phone configuration XML file (cfg.xml) by entering a string in this format:

<PRT_Upload_at_Crash ua="na">Yes</PRT_Upload_at_Crash>

Default: No

Step 3

Click Submit All Changes.

Transport Layer Security

Transport Layer Security (TLS) is a standard protocol for securing and authenticating communications over the Internet. SIP over TLS encrypts the SIP signaling messages between the service provider SIP proxy and the end user.

The Cisco IP Phone uses UDP as the standard for SIP transport, but the phone also supports SIP over TLS for added security.

The following table describes the two TLS layers.

Table 2. TLS Layers

Protocol Name

Description

TLS Record Protocol

Layered on a reliable transport protocol, such as SIP or TCH, this layer ensures that the connection is private through use of symmetric data encryption and it ensures that the connection is reliable.

TLS Handshake Protocol

Authenticates the server and client, and negotiates the encryption algorithm and cryptographic keys before the application protocol transmits or receives data.

Encrypt Signaling with SIP Over TLS

You can configure added security when you encrypt signaling messages with SIP over TLS.

Before you begin

Access the Phone Web Interface. See Transport Layer Security

Procedure

Step 1

Select Voice > Ext(n), where n is an extension number.

Step 2

In the SIP Settings section, select TLS from the SIP Transport list.

You can configure this parameter in the phone configuration XML file (cfg.xml) by entering a string in this format: 
<SIP_Transport_1_ ua="na">TLS</SIP_Transport_1_>
.

Options available:

  • UDP

  • TCP

  • TLS

  • Auto

Default: UDP.

Step 3

Click Submit All Changes.

Configure LDAP over TLS

You can configure LDAP over TLS (LDAPS) to enable secure data transmission between the server and a specific phone.


Attention

Cisco recommends leaving the authentication method to the default value of None. Next to the server field is an authentication field that uses the values None, Simple, or DIGEST-MD5. There is no TLS value for authentication. The software determines the authentication method from the LDAPS protocol in the server string.

You can also configure the parameters in the phone configuration file with XML(cfg.xml) code.

Before you begin

Access the phone administration web page. See Access the Phone Web Interface.

Procedure

Step 1

Select Voice > Phone.

Step 2

In the LDAP section, enter a server address in the Server field.

You can also configure this parameter in the phone configuration XML file (cfg.xml) by entering a string in this format:

<LDAP_Server ua="na">ldaps://10.45.76.79</LDAP_Server>

For example, enter ldaps://<ldaps_server>[:port].

where:

  • ldaps://= The start of the server address string.

  • ldaps_server = IP address or domain name

  • port = Port number. Default: 636

Step 3

Click Submit All Changes.

Configure StartTLS

You can enable Start Transport Layer Security (StartTLS) for the communications between the phone and the LDAP server. It uses the same network port (default 389) for both secure and insecure communications. If the LDAP server supports StartTLS, TLS encrypts the communications. Otherwise, the communications are in plaintext.

Before you begin

Procedure

Step 1

Select Voice > Phone.

Step 2

In the LDAP section, enter a server address in the Server field.

For example, enter ldap://<ldap_server>[:port].

Where:

  • ldap:// = The start of the server address string, scheme of the URL

  • ldap_server = IP address or domain name

  • port = Port number

You can also configure this parameter in the phone configuration XML file (cfg.xml) by entering a string in this format:

<LDAP_Server ua="na">ldap://<ldap_server>[:port]</LDAP_Server>

Step 3

Set the StartTLS Enable field to Yes.

You can also configure this parameter in the phone configuration XML file (cfg.xml) by entering a string in this format:

<LDAP_StartTLS_Enable ua="na">Yes</LDAP_StartTLS_Enable>

Step 4

Click Submit All Changes.

HTTPS Provisioning

The phone supports HTTPS for provisioning for increased security in managing remotely deployed units. Each phone carries a unique SLL Client Certificate (and associated private key), in addition to a Sipura CA server root certificate. The latter allows the phone to recognize authorized provisioning servers, and reject non-authorized servers. On the other hand, the client certificate allows the provisioning server to identify the individual device that issues the request.

For a service provider to manage deployment by using HTTPS, a server certificate must be generated for each provisioning server to which a phone resyncs by using HTTPS. The server certificate must be signed by the Cisco Server CA Root Key, whose certificate is carried by all deployed units. To obtain a signed server certificate, the service provider must forward a certificate signing request to Cisco, which signs and returns the server certificate for installation on the provisioning server.

The provisioning server certificate must contain the Common Name (CN) field, and the FQDN of the host running the server in the subject. It might optionally contain information following the host FQDN, separated by a slash (/) character. The following examples are of CN entries that are accepted as valid by the phone: 


CN=sprov.callme.com
CN=pv.telco.net/mailto:admin@telco.net
CN=prof.voice.com/info@voice.com

In addition to verifying the server certificate, the phone tests the server IP address against a DNS lookup of the server name that is specified in the server certificate.

Get a Signed Server Certificate

The OpenSSL utility can generate a certificate signing request. The following example shows the openssl command that produces a 1024-bit RSA public/private key pair and a certificate signing request: 


openssl req –new –out provserver.csr

This command generates the server private key in privkey.pem and a corresponding certificate signing request in provserver.csr. The service provider keeps the privkey.pem secret and submits provserver.csr to Cisco for signing. Upon receiving the provserver.csr file, Cisco generates provserver.crt, the signed server certificate.

Procedure

Step 1

Navigate to https://software.cisco.com/software/cda/home and log in with your CCO credentials.

Note

 

When a phone connects to a network for the first time or after a factory reset, and there are no DHCP options set up, it contacts a device activation server for zero touch provisioning. New phones use "activate.cisco.com" instead of "webapps.cisco.com" for provisioning. Phones with firmware release earlier than 11.2(1) continues to use "webapps.cisco.com". We recommend that you allow both the domain names through your firewall.

Step 2

Select Certificate Management.

On the Sign CSR tab, the CSR of the previous step is uploaded for signing.

Step 3

From the Select Product drop-down list box, select SPA1xx firmware 1.3.3 and newer/SPA232D firmware 1.3.3 and newer/SPA5xx firmware 7.5.6 and newer/CP-78xx-3PCC/CP-88xx-3PCC.

Note

 

This product includes the Cisco IP Phone 6800 Series Multiplatform Phones.

Step 4

In the CSR File field, click Browse and select the CSR for signing.

Step 5

Select the encryption method:

  • MD5
  • SHA1
  • SHA256

Cisco recommends that you select SHA256 encryption.

Step 6

From the Sign in Duration drop-down list box, select the applicable duration (for example, 1 year).

Step 7

Click Sign Certificate Request.

Step 8

Select one of the following options to receive the signed certificate:

  • Enter Recipient’s Email Address—If you wish to receive the certificate via email, enter your email address in this field.
  • Download—If you wish to download the signed certificate, select this option.

Step 9

Click Submit.

The signed server certificate is either emailed to the email address previously provided or downloaded.

Multiplatform Phone CA Client Root Certificate

Cisco also provides a Multiplatform Phone Client Root Certificate to the service provider. This root certificate certifies the authenticity of the client certificate that each phone carries. The Multiplatform Phones also support third-party signed certificates such as those provided by Verisign, Cybertrust, and so on.

The unique client certificate that each device offers during an HTTPS session carries identifying information that is embedded in its subject field. This information can be made available by the HTTPS server to a CGI script invoked to handle secure requests. In particular, the certificate subject indicates the unit product name (OU element), MAC address (S element), and serial number (L element).

The following example from the Cisco IP Phone 7841 Multiplatform Phones client certificate subject field shows these elements:

OU=CP-7841-3PCC, L=88012BA01234, S=000e08abcdef
The following example from the Cisco IP Conference Phone 7832 Multiplatform Phones client certificate subject field shows these elements:

OU=CP-7832-3PCC, L=88012BA01234, S=000e08abcdef
The following example from the Cisco IP Phone 8841 Multiplatform Phones client certificate subject field shows these elements:

OU=CP-8841-3PCC, L=88012BA01234, S=000e08abcdef
The following example from the Cisco IP Phone 6841 Multiplatform Phones client certificate subject field shows these elements:

OU=CP-6841-3PCC, L=88012BA01234, S=000e08abcdef

To determine if a phone carries an individualized certificate, use the $CCERT provisioning macro variable. The variable value expands to either Installed or Not Installed, according to the presence or absence of a unique client certificate. In the case of a generic certificate, it is possible to obtain the serial number of the unit from the HTTP request header in the User-Agent field.

HTTPS servers can be configured to request SSL certificates from connecting clients. If enabled, the server can use the Multiplatform Phone Client Root Certificate that Cisco supplies to verify the client certificate. The server can then provide the certificate information to a CGI for further processing.

The location for certificate storage may vary. For example, in an Apache installation, the file paths for storage of the provisioning server-signed certificate, its associated private key, and the Multiplatform Phone CA client root certificate are as follows: 


# Server Certificate:
SSLCertificateFile /etc/httpd/conf/provserver.crt

# Server Private Key:
SSLCertificateKeyFile /etc/httpd/conf/provserver.key

# Certificate Authority (CA):
SSLCACertificateFile /etc/httpd/conf/spacroot.crt

For specific information, refer to the documentation for an HTTPS server.

The Cisco Client Certificate Root Authority signs each unique certificate. The corresponding root certificate is made available to service providers for client authentication purposes.

Redundant Provisioning Servers

The provisioning server can be specified as an IP address or as a Fully Qualified Domain Name (FQDN). The use of an FQDN facilitates the deployment of redundant provisioning servers. When the provisioning server is identified through an FQDN, the phone attempts to resolve the FQDN to an IP address through DNS. Only DNS A-records are supported for provisioning; DNS SRV address resolution is not available for provisioning. The phone continues to process A-records until a server responds. If no server that is associated with the A-records responds, the phone logs an error to the syslog server.

Syslog Server

If a syslog server is configured on the phone through use of the <Syslog Server> parameters, the resync and upgrade operations send messages to the syslog server. A message can be generated at the start of a remote file request (configuration profile or firmware load), and at the conclusion of the operation (indicating either success or failure).

The logged messages are configured in the following parameters and macro expanded into the actual syslog messages:

  • Log_Request_Msg

  • Log_Success_Msg

  • Log_Failure_Msg

Enable the Firewall

We have improved phone security by hardening the operating system. Hardening ensures that the phone has a firewall to protect it from malicious incoming traffic. The firewall tracks the ports for incoming and outgoing data. It detects incoming traffic from unexpected sources and blocks the access. Your firewall allows all outgoing traffic.

The firewall may dynamically unblock normally blocked ports. The outgoing TCP connection or UDP flow unblocks the port for return and continued traffic. The port is kept unblocked while flow is alive. The port reverts to blocked state when flow terminates or ages out.

The legacy setting, IPv6 Multicast Ping Voice > System > IPv6 Settings > Broadcast Echo continues to work independently of the new firewall settings.

Firewall configuration changes generally don't result in a phone restart. Phone soft restarts generally don't affect firewall operation.

The firewall is enabled by default. If it is disabled, you can enable it from the phone web page.

Before you begin

Access the Phone Web Interface

Procedure

Step 1

Select Voice > System > Security Settings.

Step 2

In the Firewall drop down list, select Enabled.

You can also configure this parameter in the configuration file (cfg.xml) by entering a string in this format:
<Firewall ua="na">Enabled</Firewall>

The allowed values are Disabled|Enabled. The default value is Enabled.

Step 3

Click Submit All Changes.

This enables the firewall with its default open UDP and TCP ports.

Step 4

Select Disabled to disable the firewall if you wish your network to return to its prior behavior.

The following table describes the default open UDP ports.

Table 3. Firewall Default Open UDP Ports

Default Open UDP Port

Description

DHCP/DHCPv6

DHCP client Port 68

DHCPv6 client Port 546

SIP/UDP

Configure the Port in Voice > Ext<n> > SIP Settings > SIP Port (example: 5060), when Line Enable is set to Yes, and SIP Transport is set to UDP or Auto.

RTP/RTCP

UDP port range from RTP Port Min to RTP Port Max+1

PFS (Peer Firmware Sharing)

Port 4051, when Upgrade Enable and Peer Firmware Sharing are set to Yes.

TFTP clients

Ports 53240-53245. You need this port range if the remote server uses a port other than the standard TFTP port 69. You may turn it off if the server uses standard port 69. See Configure Your Firewall with Additional Options.

TR-069

UDP/STUN port 7999, when Enable TR-069 is set to Yes.

The following table describes the default open TCP ports.

Table 4. Firewall Default Open TCP Ports

Default Open TCP Port

Description

Web server

Port configured via Web Server Port (default 80), when Enable Web Server is set to Yes.

PFS (Peer Firmware Sharing)

Ports 4051 and 6970, when both Upgrade Enable and Peer Firmware Sharing are set to Yes.

TR-069

HTTP/SOAP port in TR-069 Connection Request URL, when Enable TR-069 is set to Yes.

The port is chosen randomly from the range 8000-9999.

Configure Your Firewall with Additional Options

You can configure additional options in the Firewall Options field. Type the keyword for each option in the field, and separate the keywords by commas (,). Some keywords have values. Separate the values by colons (:).

Before you begin

Access the Phone Web Interface

Procedure

Step 1

Go to Voice > System > Security Settings.

Step 2

Select Enabled for the Firewall field.

Step 3

In the Firewall Options field, enter the keywords. The list of ports applies to both IPv4 and IPv6 protocols.

When you enter the keywords,

  • separate the keywords with commas (,).

  • separate keywords values with colons (:).

Table 5. Firewall Optional Settings

Firewall Options Keywords

Description

Field is empty.

The firewall runs with default open ports.

NO_ICMP_PING

The firewall blocks incoming ICMP/ICMPv6 Echo requests (Ping).

This option may break some types of traceroute requests to the phone. Windows tracert is one example.

Example Firewall Options entry with a combination of options:

NO_ICMP_PING,TCP:12000,UDP:8000:8010

The firewall runs with default settings and the following additional options:

  • Drops incoming ICMP/ICMPv6 Echo (Ping) requests.

  • Opens TCP port 12000 (IPv4 and IPv6) for incoming connections.

  • Opens UDP port range 8000-8010 (IPv4 and IPv6) for incoming requests.

NO_ICMP_UNREACHABLE

The phone doesn't send ICMP/ICMPv6 Destination Unreachable for UDP ports.

Note

 

The exception is to always send Destination Unreachable for ports in the RTP port range.

This option may break some types of traceroute requests to the device. For example, Linux traceroute may break.

NO_CISCO_TFTP

  • The phone doesn't open TFTP-client port-range (UDP 53240:53245).

  • Requests to non-standard (non 69) TFTP server ports fail.

  • Requests to standard TFTP server port 69 work.

The following keywords and options apply when the phone runs custom apps that handle incoming requests.

UDP:<xxx>

Opens UDP port <xxx>.

UDP:<xxx:yyy>

Opens UDP port-range, <xxx to yyy>, inclusive.

You can have up to 5 UDP port options (single ports and port ranges). For example, you can have 3 UDP:<xxx> and 2 UDP:<xxx:yyy>.

TCP:<xxx>

Opens TCP port <xxx>.

TCP:<xxx:yyy>

Opens TCP port-range <xxx to yyy>, inclusive.

You can have up to 5 TCP port options (single ports and port ranges). For example, you can have 4 TCP:<xxx> and one TCP:<xxx:yyy>.

You can also configure this parameter in the configuration file (cfg.xml) by entering a string in this format: 
<Firewall_Config ua="na">NO_ICMP_PING</Firewall_Config>

Step 4

Click Submit All Changes.

Configure the Cipher List

You can specify the cipher suites that the phone TLS applications use. The specified cipher list applies to all the applications that use the TLS protocol. The TLS applications on your phone include:

  • Customer CA Provisioning

  • E911 Geolocation

  • Firmware/Cisco Headset Upgrade

  • LDAPS

  • LDAP (StartTLS)

  • Picture Download

  • Logo Download

  • Dictionary Download

  • Provisioning

  • Report Upload

  • PRT Upload

  • SIP over TLS

  • TR-069

  • WebSocket API

  • XML Services

  • XSI Services

You can also specify the cipher suites with the TR-069 parameter (Device.X_CISCO_SecuritySettings.TLSCipherList) or with the the configuration file (cfg.xml). Enter a string in the configuration file in this format: 
<TLS_Cipher_List ua="na">RSA:!aNULL:!eNULL</TLS_Cipher_List>

Before you begin

Access the phone administration web page, see Access the Phone Web Interface.

Procedure

Step 1

Select Voice > System.

Step 2

In the Security Settings section, enter the cipher suite or the combination of cipher suites in the TLS Cipher List field.

Example: 

RSA:!aNULL:!eNULL
supports those cipher suites using RSA authentication, but excludes those cipher suites offering no encryption and authentication.

Note

 

A valid cipher list must follow the format defined at https://www.openssl.org/docs/man1.1.1/man1/ciphers.html. Your phone doesn't support all the cipher strings listed on the OpenSSL web page. For the supported strings, see Supported Cipher Strings.

If the value in the TLS Cipher List field is blank or invalid, the cipher suites used vary with applications. See the following list for the suites that the applications use when this field is with a blank or an invalid value.

  • Web Server (HTTPS) applications use the following cipher suites:

    • ECDHE-RSA-AES256-GCM-SHA384

    • ECDHE-RSA-AES128-GCM-SHA256

    • AES256-SHA

    • AES128-SHA

    • DES-CBC3-SHA

  • XMPP uses the cipher list HIGH:MEDIUM:AES:@STRENGTH.

  • SIP, TR-069, and other applications using the curl library use the DEFAULT cipher string. The DEFAULT cipher string contains the following cipher suites that the phone support: 

    DEFAULT Cipher Suites (28 suites):
        ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        ECDHE_RSA_WITH_AES_256_GCM_SHA384
        DHE_RSA_WITH_AES_256_GCM_SHA384
        ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
        ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
        DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
        ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        ECDHE_RSA_WITH_AES_128_GCM_SHA256
        DHE_RSA_WITH_AES_128_GCM_SHA256
        ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
        ECDHE_RSA_WITH_AES_256_CBC_SHA384
        DHE_RSA_WITH_AES_256_CBC_SHA256
        ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
        ECDHE_RSA_WITH_AES_128_CBC_SHA256
        DHE_RSA_WITH_AES_128_CBC_SHA256
        ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        ECDHE_RSA_WITH_AES_256_CBC_SHA
        DHE_RSA_WITH_AES_256_CBC_SHA
        ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        ECDHE_RSA_WITH_AES_128_CBC_SHA
        DHE_RSA_WITH_AES_128_CBC_SHA
        RSA_WITH_AES_256_GCM_SHA384
        RSA_WITH_AES_128_GCM_SHA256
        RSA_WITH_AES_256_CBC_SHA256
        RSA_WITH_AES_128_CBC_SHA256
        RSA_WITH_AES_256_CBC_SHA
        RSA_WITH_AES_128_CBC_SHA
        EMPTY_RENEGOTIATION_INFO_SCSV

Step 3

Click Submit All Changes.

Supported Cipher Strings

The supported cipher strings listed following is based on the OpenSSL 1.1.1d standards.

Table 6. Supported Cipher Strings (OpenSSL 1.1.1d)

Strings

Strings

Strings

DEFAULT

kECDHE, kEECDH

CAMELLIA128, CAMELLIA256, CAMELLIA

COMPLEMENTOFDEFAULT

ECDHE, EECDH

CHACHA20

ALL

ECDH

SEED

COMPLEMENTOFALL

AECDH

MD5

HIGH

aRSA

SHA1, SHA

MEDIUM

aDSS, DSS

SHA256, SHA384

eNULL, NULL

aECDSA, ECDSA

SUITEB128, SUITEB128ONLY, SUITEB192

aNULL

TLSv1.2, TLSv1, SSLv3

kRSA, RSA

AES128, AES256, AES

kDHE, kEDH, DH

AESGCM

DHE, EDH

AESCCM, AESCCM8

ADH

ARIA128, ARIA256, ARIA

Enable Hostname Verification for SIP over TLS

You can enable increased phone security on a phone line if you use TLS. The phone line can verify the hostname to determine if the connection is secure.

Over a TLS connection, the phone can verify the hostname to check the server identity. The phone can check both the Subject Alternative Name (SAN) and the Subject Common Name (CN). If the hostname on the valid certificate matches the hostname that is used to communicate with the server, the TLS connection establishes. Otherwise, the TLS connection fails.

The phone always verifies the hostname for the following applications:

  • LDAPS

  • LDAP (StartTLS)

  • XMPP

  • Image upgrade over HTTPS

  • XSI over HTTPS

  • File download over HTTPS

  • TR-069

When a phone line transports SIP messages over TLS, you can configure the line to enable or bypass the hostname verification with the TLS Name Validate field on the Ext(n) tab.

Before you begin

Procedure

Step 1

Go to Voice > Ext(n).

Step 2

In the Proxy and Registration section, set the TLS Name Validate field to Yes to enable the hostname verification, or No to bypass the hostname verification.

You can also configure this parameter in the configuration file (cfg.xml) by entering a string in this format:
<TLS_Name_Validate_1_ ua="na">Yes</TLS_Name_Validate_1_>

The allowed values are Yes or No. The default setting is Yes.

Step 3

Click Submit All Changes.

Enable Client-Initiated Mode for Media Plane Security Negotiations

To protect media sessions, you can configure the phone to initiate media plane security negotiations with the server. The security mechanism follows the standards stated in RFC 3329 and its extension draft Security Mechanism Names for Media (See https://tools.ietf.org/html/draft-dawes-sipcore-mediasec-parameter-08#ref-2). The transport of negotiations between the phone and the server can use SIP protocol over UDP, TCP, and TLS. You can limit that media plane security negotiation is applied only when the signaling transport protocol is TLS.

You can also configure the parameters in the configuration file (cfg.xml). To configure each parameter, see the syntax of the string in Parameters for Media Plane Security Negotiation.

Before you begin

Access the phone administration web page. See Access the Phone Web Interface.

Procedure

Step 1

Select Voice > Ext (n).

Step 2

In the SIP Settings section, set the MediaSec Request and MediaSec Over TLS Only field as defined in Parameters for Media Plane Security Negotiation

Step 3

Click Submit All Changes.

Parameters for Media Plane Security Negotiation

The following table defines the function and usage of the parameters for media plane security negotiation in the SIP Settings section under the Voice> Ext (n) tab in the phone web interface. It also defines the syntax of the string that is added in the phone configuration file (cfg.xml) with XML code to configure a parameter.

Table 7. Parameters for Media Plane Security Negotiation

Parameter

Description

MediaSec Request

Specifies whether the phone initiates media plane security negotiations with the server.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format: 
    <MediaSec_Request_1_ ua="na">Yes</MediaSec_Request_1_>

  • In the phone web interface, set this field to Yes or No as needed.

Allowed values: Yes|No

  • Yes—Client-initiated Mode. The phone initiates media plane security negotiations.

  • No—Server-initiated Mode. The server initiates media plane security negotiations. The phone doesn't initiate negotiations, but can handle negotiation requests from the server to establish secure calls.

Default: No

MediaSec Over TLS Only

Specifies the signaling transport protocol over which media plane security negotiation is applied.

Before setting this field to Yes, ensure that the signaling transport protocol is TLS.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format: 
    <MediaSec_Over_TLS_Only_1_ ua="na">No</MediaSec_Over_TLS_Only_1_>

  • In the phone web interface, set this field to Yes or No as needed.

Allowed values: Yes|No

  • Yes—The phone initiates or handles media plane security negotiations only when the signaling transport protocol is TLS.

  • No—The phone initiates and handles media plane security negotiations regardless of the signaling transport protocol.

Default: No

802.1X Authentication

Cisco IP Phones use Cisco Discovery Protocol (CDP) to identify the LAN switch and determine parameters such as VLAN allocation and inline power requirements. CDP does not identify locally attached workstations. Cisco IP Phones provide an EAPOL pass-through mechanism. This mechanism allows a workstation attached to the Cisco IP Phone to pass EAPOL messages to the 802.1X authenticator at the LAN switch. The pass-through mechanism ensures that the IP phone does not act as the LAN switch to authenticate a data endpoint before accessing the network.

Cisco IP Phones also provide a proxy EAPOL Logoff mechanism. In the event that the locally attached PC disconnects from the IP phone, the LAN switch does not see the physical link fail, because the link between the LAN switch and the IP phone is maintained. To avoid compromising network integrity, the IP phone sends an EAPOL-Logoff message to the switch on behalf of the downstream PC, which triggers the LAN switch to clear the authentication entry for the downstream PC.

Support for 802.1X authentication requires several components:

  • 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.

  • Cisco Secure Access Control Server (ACS) (or other third-party authentication server): The authentication server and the phone must both be configured with a shared secret that authenticates the phone.

  • A LAN switch supporting 802.1X: The switch acts as the authenticator and pass the messages between the phone and the authentication server. After the exchange completes, the switch grants or denies the phone access to the network.

You must perform the following actions to configure 802.1X.

  • Configure the other components before you enable 802.1X Authentication on the phone.

  • Configure PC Port: The 802.1X standard does not consider VLANs and thus recommends that only a single device should be authenticated to a specific switch port. However, some switches support multidomain authentication. The switch configuration determines whether you can connect a PC to the PC port of the phone.

    • Yes: If you are using a switch that supports multidomain authentication, you can enable the PC port and connect a PC to it. In this case, Cisco IP Phones support proxy EAPOL-Logoff to monitor the authentication exchanges between the switch and the attached PC.

    • No: If the switch does not support multiple 802.1X-compliant devices on the same port, you should disable the PC Port when 802.1X authentication is enabled. If you do not disable this port and subsequently attempt to attach a PC to it, the switch denies network access to both the phone and the PC.

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

    • Enabled: If you are using a switch that supports multidomain authentication, you can continue to use the voice VLAN.

    • Disabled: If the switch does not support multidomain authentication, disable the Voice VLAN and consider assigning the port to the native VLAN.

Enable 802.1X Authentication

You can enable 802.1X authentication on the phone. When 802.1X authentication is enabled, the phone uses 802.1X authentication to request network access.When 802.1X authentication is turned off, the phone uses CDP to acquire VLAN and network access. You can also view the transaction status on the phone screen menu.

Procedure

Step 1

Perform one of the following actions to enable 802.1X authentication:

  • In the phone web interface, select Voice > System and set the Enable 802.1X Authentication field to Yes. Then, click Submit All Changes.
  • In the configuration file (cfg.xml), entering a string in this format: 
    <Enable_802.1X_Authentication ua="rw">Yes</Enable_802.1X_Authentication>
  • On the phone, press Applications > Network configuration > Ethernet configuration > 802.1X authentication. Then, toggle the Device authentication field to On with the Select button.

Step 2

Select Transaction status to view the following:

  • Transaction status: Displays the state of 802.1x authentication. The state can be:

    • Authenticating: Indicates that the authentication process is in progress.

    • Authenticated: Indicates that the phone is authenticated.

    • Disabled: Indicates that 802.1x authentication is disabled on the phone.

  • Protocol: Displays the EAP method that is used for 802.1x authentication. The protocol can be EAP-FAST or EAP-TLS.

Step 3

Select User certificate type and choose the certificate for the 802.1X authentication during the initial enrollment and certificate renewal (if challenge password is empty).

  • Manufacturing installed: The Manufacturing Installed Certificate (MIC) and Secure Unique Device Identifier (SUDI) is used.
  • Custom installed: The Custom Device Certificate (CDC) is used. This type of certificate can be installed either by manual uploading on the phone web page or by installation from a Simple Certificate Enrollment Protocol (SCEP) server.

Step 4

Press Submit.

Manually install custom device certificate

You can manually install a Custom Device Certificate (CDC) on the phone by uploading the certificate from the phone administration web page.

Before you begin

Before you can install a custom device certificate for a phone, you must have:

  • A certificate file (.p12 or .pfx) generated by OPENSSL 3.0 or later. This file contains the certificate and private key. Save this file on your PC.

  • The extract password of the certificate. The password is used to decrypt the certificate file. Length of the password must be greater than 14 characters.

  • Access to the phone administration web page. See Access the Phone Web Interface.

Procedure

Step 1

Select Certificate > Custom.

Step 2

In the Add Certificate section, click Browse....

Step 3

Browse to the certificate on your PC.

Step 4

In the Extract password field, enter the certificate extract password.

Step 5

Click Upload.

If the certificate file and password are correct, you will receive the message "Certificate added.". Otherwise, the uploading fails with an error message indicating that the certificate can't be uploaded.

Step 6

To check details of the installed certificate, click View in the Existing Certificates section.

Step 7

(Optional) To remove the installed certificate from the phone, click Delete in the Existing Certificates section.

Once you click the button, the removal operation starts immediately without a confirmation.

If the certificate is removed successfully, you will receive the message "Certificate deleted.".

Automatically install custom device certificate by SCEP

You can set up the Simple Certificate Enrollment Protocol (SCEP) parameters to automatically install the Custom Device Certificate (CDC), if you don't want to manually upload the certificate file or you don't have the certificate file in place.

When the SCEP parameters are configured correctly, the phone sends requests to the SCEP server, and the CA certificate is validated by device using the defined fingerprint.

Before you begin

Before you can install a custom device certificate for a phone, you must have:

  • SCEP server address

  • SHA-1 or SHA-256 fingerprint of the root CA certificate for the SCEP server

  • Access to the phone administration web page. See Access the Phone Web Interface.

Procedure

Step 1

Access the phone administration web page.

Step 2

Select Certificate > Custom.

Step 3

In the SCEP Configuration 1 section, set the parameters as described in the following table Parameters for SCEP configuration.

Step 4

Click Submit All Changes.

Parameters for SCEP configuration

The following table defines the function and usage of SCEP configuration parameters in the SCEP Configuration 1 section under the Certificate > Custom tab in the phone administration web interface. It also defines the syntax of the string that is added in the phone configuration file (cfg.xml) to configure a parameter.

Table 8. Parameters for SCEP configuration
Parameter Description
Server

SCEP server address. This parameter is mandatory.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format:

    <CDC_Server_1_ ua="na">http://10.79.57.91</CDC_Server_1_>

  • On the phone administration web page, enter the SCEP server address.

Valid values: A URL or IP address. The HTTPS scheme is not supported.

Default: Empty
Root CA Fingerprint

SHA256 or SHA1 fingerprint of the Root CA for validation during the SCEP process. This parameter is mandatory.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format:

    <CDC_Root_CA_Fingerprint_1_ ua="na">12040870625C5B755D73F5925285F8F5FF5D55AF</CDC_Root_CA_Fingerprint_1_>

  • On the phone administration web page, enter a valid fingerprint.

Default: Empty
Challenge Password

The challenge password for Certificate Authority (CA) authorization against the phone during a certificate enrollment via SCEP. This parameter is optional.

According to the actual SCEP environment, the behavior of challenge password varies.

  • If the phone gets a certificate from a Cisco RA that communicates with CA, the challenge password is not supported on CA. In this case, Cisco RA uses the phone's MIC/SUDI for authentication to access to CA. The phone uses MIC/SUDI for both initial enrollment and certificate renewal.

  • If the phone gets a certificate by communicating with CA directly, the challenge password is supported on CA. If configured, it will be used for the initial enrollment only. For the certificate renewal, the installed certificate will be used instead.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format:

    <CDC_Challenge_Password_1_ ua="na">B36A11A834EED055</CDC_Challenge_Password_1_>

    The password is masked in the configuration file.

  • On the phone administration web page, enter the challenge password.

Default: Empty

SCEP parameters configuration via DHCP option 43

In addition to the SCEP certificate enrollment by the manual configurations on the phone web page, you can also use the DHCP option 43 to populate the parameters from a DHCP server. The DHCP option 43 is preconfigured with the SCEP parameters, later the phone can fetch the parameters from the DHCP server to perform the SCEP certificate enrollment.


Note

  • The SCEP parameters configuration via DHCP option 43 is only available for the phone where a factory reset is performed.

  • Phones shall not be placed in the network that supports both Option 43 and remote provisioning (for example, Options 66,160,159,150, or cloud provisioning). Otherwise, phones may not get the Option 43 configurations.

To enroll an SCEP certificate by configuring the SCEP parameters in the DHCP option 43, do the following:

  1. Prepare an SCEP environment.

    For information about SCEP environment setup, see your SCEP server documentation.

  2. Set up DHCP option 43 (defined in 8.4 Vendor Specific Information, RFC 2132).

    Suboptions (10–15) are reserved for the method:

    Parameter on phone web page Suboption Type Length (byte) Mandatory
    FIPS Mode 10 boolean 1 No
    Server 11 string The maximum length of Server + Challenge Password shall be less than 208 bytes. Yes
    Root CA Fingerprint 12 binary 20 (SHA-1) or 32 (SHA-256) Yes
    Challenge Password 13 string The maximum length of Server + Challenge Password shall be less than 208 bytes. No
    Enable 802.1X Authentication 14 boolean 1 No
    Certificate Select 15 unsigned 8-bit 1 No

    When you use the DHCP option 43, notice the following characteristics of the method:

    • Suboptions (10–15) are reserved for Custom Device Certificate (CDC).

    • The maximum length of DHCP option 43 is 255 bytes.

    • The value of FIPS Mode shall be consistent with the onboarding provisioning configuration. Otherwise, the phone fails to retrieve the previously installed certificate after onboarding. Specifically,

      • If the phone will be registered to an environment where the FIPS mode is disabled, you don't need to configure the parameter FIPS Mode in DHCP option 43. By default, the FIPS mode is disabled.

      • If the phone will be registered to an environment where the FIPS mode is enabled, you must enable the FIPS mode in DHCP option 43. See Enable FIPS Mode for details.

    • The password in Option 43 is in cleartext.

      If the challenge password is empty, the phone uses MIC/SUDI for the initial enrollment and certificate renewal. If the challenge password is configured, it is used only for the initial enrollment, and the installed certificate will be used for the certificate renewal.

    • Enable 802.1X Authentication and Certificate Select are used only for the phones in wired network.

    • DHCP option 60 (Vendor Class Identifier) is used to identify the device model.

    The following table provides an example of DHCP option 43 (suboptions 10–15):

    Suboption decimal/hex Value length (byte) decimal/hex Value Hex value
    10/0a 1/01 1 (0: Disabled; 1: Enabled) 01
    11/0b 18/12 http://10.79.57.91 687474703a2f2f31302e37392e35372e3931
    12/0c 20/14 12040870625C5B755D73F5925285F8F5FF5D55AF 12040870625C5B755D73F5925285F8F5FF5D55AF
    13/0d 16/10 D233CCF9B9952A15 44323333434346394239393532413135
    14/0e 1/01 1 (0: No; 1: Yes) 01
    15/0f 1/01 1 (0: Manufacturing installed; 1: Custom installed) 01

    Summary of the parameter values:

    • FIPS Mode = Enabled

    • Server = http://10.79.57.91

    • Root CA Fingerprint = 12040870625C5B755D73F5925285F8F5FF5D55AF

    • Challenge Password = D233CCF9B9952A15

    • Enable 802.1X Authentication = Yes

    • Certificate Select = Custom installed

    The syntax of the final hex value is: {<suboption><length><value>}...

    According to the parameter values above, the final hex value is as the follows:

    0a01010b12687474703a2f2f31302e37392e35372e39310c1412040870625C5B755D73F5925285F8F5FF5D55AF0d10443233334343463942393935324131350e01010f0101

  3. Configure DHCP option 43 on a DHCP server.


    Note
    This step provides an example of the DHCP option 43 configurations on Cisco Network Register.

    1. Add DHCP option definition set.

      The Vendor Option String is model name of the IP phones. For example, CP-8865-3PCC, CP-8832-3PCC, and so on.

    2. Add the DHCP option 43 and suboptions to the DHCP option definition set.

      Example:

    3. Add options 43 to the DHCP policy and set up the value as follows:

      Example:

      (10 1)(11 http://10.79.57.91)(12 12040870625C5B755D73F5925285F8F5FF5D55AF)(13 D233CCF9B9952A15)(14 1)(15 1)

    4. Verify the settings. You can use Wireshark to capture a trace of the network traffic between the phone and the service.

  4. Perform a factory reset for the phone.

    After the phone is reset, the parameters Server, Root CA Fingerprint, and Challenge Password will be filled in automatically. These parameters are located in the section SCEP Configuration 1 from Certificate > Custom on the phone administration web page.

    To check details of the installed certificate, click View in the Existing Certificates section.

    To check the certificate installation status, select Certificate > Custom Cert Status. The Download Status 1 shows the latest result. If any issue occurs during the certificate enrollment, the download status can show the problem reason for troubleshooting purposes.


    Note
    If the challenge password authentication fails, users will be prompted to enter the password on the phone screen.

  5. Optional: To remove the installed certificate from the phone, click Delete in the Existing Certificates section.


    Note
    Once you click the button, the removal operation starts immediately without a confirmation.

Certificate renewal by SCEP

The device certificate can be refreshed automatically by the SCEP process.

  • The phone checks whether the certificate will expire in 15 days every 4 hours. If so, the phone starts the certificate renewal process automatically.

  • If the challenge password is empty, the phone uses MIC/SUDI for both initial enrollment and certificate renewal. If the challenge password is configured, it is used for initial enrollment only, the existing/installed certificate is used for certificate renewal.

  • The phone doesn't remove the old device certificate until it retrieves the new one.

  • If certificate renewal fails because device certificate or CA expires, the phone triggers the initial enrollment automatically. In the meantime, if the challenge password authentication fails, a password input screen pops up on the phone screen, and users are prompted to enter the challenge password on the phone.

Set Up a Proxy Server

You can configure the phone to use a proxy server to enhance security. A proxy server acts as a firewall between the phone and Internet. After successful configuration, the phone connects to Internet through the proxy server which protects the phone from cyber attack.

You can set up a proxy server by either using an automatic configuration script or manually configuring the host server (hostname or IP address) and port of the proxy server.

When configured, the HTTP proxy feature applies to all the applications that use the HTTP protocol. The applications include the following:

  • GDS (Activation Code Onboarding)

  • EDOS Device Activation

  • Onboarding to Webex Cloud (via EDOS and GDS)

  • Certificate Authentication

  • Provisioning

  • Firmware Upgrade (not supported by Cisco IP Phone 6821 Multiplatform Phones)

  • Phone Status Report

  • PRT Upload

  • XSI Services

  • Webex Services

  • E911 Geolocation

Before you begin

Access the phone administration web page. See Access the Phone Web Interface.

Procedure

Step 1

Select Voice > System.

Step 2

In the section HTTP Proxy Settings, configure the parameter Proxy Mode and others according to your requirement. Detailed procedures are provided in the following steps.

Step 3

Do one of the following actions:

  • Proxy Mode is Auto:

    • If Use Auto Discovery (WPAD) is Yes, no further action is required. The phone will automatically retrieve a Proxy Auto-Configuration (PAC) file by the Web Proxy Auto-Discovery (WPAD) protocol.

    • If Use Auto Discovery (WPAD) is No, enter a valid URL in PAC URL.

  • Proxy Mode is Manual:

    • If Proxy Server Requires Authentication is No, enter a proxy server in Proxy Host and a proxy port in Proxy Port.

    • If Proxy Server Requires Authentication is Yes, enter a proxy server in Proxy Host and a proxy port in Proxy Port. And enter a username in Username and a password in Password.

  • Proxy Mode is Off, the HTTP proxy feature is disabled on the phone.

You can also configure the parameters in the phone configuration file (cfg.xml). To configure each parameter, see the syntax of the string in the Parameters for HTTP Proxy Settings.

Step 4

Click Submit All Changes.

Parameters for HTTP Proxy Settings

The following table defines the function and usage of the HTTP proxy parameters in the HTTP Proxy Settings section under the Voice > System tab in the phone web interface. It also defines the syntax of the string that is added in the phone configuration file (cfg.xml) with XML code to configure a parameter.

Table 9. Parameters for HTTP Proxy Settings

Parameter

Description and Default Value

Proxy Mode

Specifies the HTTP proxy mode that the phone uses, or disables the HTTP proxy feature.

  • Auto

    The phone automatically retrieves a Proxy Auto-Configuration (PAC) file to select a proxy server. In this mode, you can determine whether to use Web Proxy Auto-Discovery (WPAD) protocol to retrieve a PAC file or manually enter a valid URL of the PAC file.

    For details about the parameters, see Use Auto Discovery (WPAD) and PAC URL.

  • Manual

    You must manually specify a server (hostname or IP address) and a port of a proxy server.

    For details about the parameters, see Proxy Host and Proxy Port.

  • Off

    You disable the HTTP proxy feature on the phone.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format: 
    <Proxy_Mode ua="rw">Off</Proxy_Mode>

  • On the phone web interface, select a proxy mode or disable the feature.

Allowed values: Auto, Manual, and Off

Default: Off

Use Auto Discovery (WPAD)

Determines whether the phone uses the Web Proxy Auto-Discovery (WPAD) protocol to retrieve a PAC file.

WPAD protocol uses DHCP or DNS, or both network protocols to locate a Proxy Auto-Configuration (PAC) file automatically. PAC file is used to select a proxy server for a given URL. This file can be hosted locally or on a network.

  • The parameter configuration takes effect when Proxy Mode is set to Auto.

  • If you set the parameter to No, you must specify a PAC URL.

    For details about the parameter, see PAC URL.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format: 
    <Use_Auto_Discovery__WPAD_ ua="rw">Yes</Use_Auto_Discovery__WPAD_>

  • On the phone web interface, select Yes or No as needed.

Allowed values: Yes and No

Default: Yes

PAC URL

URL of a PAC file.

For example, http://proxy.department.branch.example.com

TFTP, HTTP, and HTTPS are supported.

If you set the Proxy Mode to Auto and Use Auto Discovery (WPAD) to No, you must configure this parameter.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format: 
    <PAC_URL ua="rw">http://proxy.department.branch.example.com/pac</PAC_URL>

  • On the phone web interface, enter a valid URL that locates to a PAC file.

Default: Empty

Proxy Host

IP address or hostname of the proxy host server for the phone to access. For example:

proxy.example.com

The scheme (http:// or https://) is not required.

If you set the Proxy Mode to Manual, you must configure this parameter.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format: 
    <Proxy_Host ua="rw">proxy.example.com</Proxy_Host>

  • On the phone web interface, enter an IP address or hostname of the proxy server.

Default: Empty

Proxy Port

Port number of the proxy host server.

If you set the Proxy Mode to Manual, you must configure this parameter.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format: 
    <Proxy_Port ua="rw">3128</Proxy_Port>

  • On the phone web interface, enter a server port.

Default: 3128

Proxy Server Requires Authentication

Determines whether the user needs to provide the authentication credentials (username and password) that the proxy server requires. This parameter is configured according to the actual behaviour of the proxy server.

If you set the parameter to Yes, you must configure Username and Password.

For details about the parameters, see Username and Password.

The parameter configuration takes effect when Proxy Mode is set to Manual .

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format: 
    <Proxy_Server_Requires_Authentication ua="rw">No</Proxy_Server_Requires_Authentication>

  • On the phone web interface, set this field Yes or No as needed.

Allowed values: Yes and No

Default: No

Username

Username for a credential user on the proxy server.

If Proxy Mode is set to Manual and Proxy Server Requires Authentication is set to Yes, you must configure the parameter.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format: 
    <Proxy_Username ua="rw">Example</Proxy_Username>

  • On the phone web interface, enter the username.

Default: Empty

Password

Password of the specified username for the proxy authentication purpose.

If Proxy Mode is set to Manual and Proxy Server Requires Authentication is set to Yes, you must configure the parameter.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format: 
    <Proxy_Password ua="rw">Example</Proxy_Password>

  • On the phone web interface, enter a valid password for the proxy authentication of the user.

Default: Empty

Enable FIPS Mode

You can make a phone Federal Information Processing Standards (FIPS) compliant.

FIPS are a set of standards that describe document processing, encryption algorithms, and other information technology standards for use within non-military government and by government contractors and vendors who work with the agencies. OpenSSL FOM (FIPS Object Module) is a carefully defined software component and designed for compatibility with the OpenSSL library, so products using the OpenSSL library and API can be converted to use FIPS 140-2 validated cryptography with minimal effort.

FIPS mode has limitations:

  • TR069 is Disabled

  • HTTP Digest Authentication is Disabled

Before you begin

Procedure

Step 1

Select Voice > System.

Step 2

In the Security Settings section, choose Yes or No from FIPS Mode parameter.

When you fail to enable FIPS mode, a security error message appears on the phone and the phone needs a restart.

Also, the phone displays a FIPS related error message in the Status messages screen when enabling FIPS mode fails.

Step 3

Click Submit All Changes.

When you enable FIPS, the following features work seamlessly on the phone:

Image authentication

PRT upload

One Button to Join (OBTJ)

Secure storage

Firmware upgrade

SIP over TLS

Config file encryption

Profile resync

SRTP

802.1x

Onboard service

SIP digest (RFC 8760)

HTTPs server

Webex on-boarding, Webex call logs, Webex directory

Http Proxy

Set Up a VPN Connection from the Phone

You can set up and enable the VPN connection from the phone.

Cisco IP Phone 6821 Multiplatform Phones doesn't support VPN connection.

Procedure

Step 1

Press Applications .

Step 2

Select Network configuration > VPN settings.

Step 3

Enter the IP address or FQDN of a VPN server in VPN server.

Step 4

Enter the user credentials in Username and Password.

Step 5

(Optional) If needed, enter the name of a tunnel group in Tunnel group.

If the field is empty, this means no tunnel group is used for this VPN connection.

Step 6

Highlight Connect to VPN on bootup, press the Select button of the navigation cluster to select On.

Step 7

Press Set to save the settings.

Currently, the VPN settings are finished. You can manually reboot the phone to trigger the automatic connection to the VPN server. If you want to enable the VPN connection immediately, proceed with the next step.

Step 8

Highlight Enable VPN connection, select On to enable the VPN connection.

Note

 

Once you set Enable VPN connection to On, the phone immediately tries to connect to the VPN server. During the process, the phone reboots automatically.

The VPN connection takes about one minute.

After the phone reboots, the VPN connection icon on the upper-right corner of the phone screen indicates that the VPN connection is established successfully.

If the VPN connection fails, the value of Enable VPN connection remains Off.

Step 9

(Optional) View the details of the VPN connection. For example, the current VPN connection status and VPN IP address. For details, see View the VPN Status.

Step 10

(Optional) You can disable the VPN connection from the phone.

  1. Press Applications .

  2. Select Network configuration > VPN settings.

  3. Highlight Connect to VPN on bootup, select Off.

  4. Highlight Enable VPN connection, select Off to disable the VPN connection. This causes an immediate reboot of the phone.

View the VPN Status

You can check the details of the VPN connection. For example, the current VPN status and VPN IP address of your phone.

You can also view the status from the phone web page by selecting Info > Status > VPN Status.

Procedure

Step 1

Press Applications .

Step 2

Select Status > VPN status.

You can view the following information:

  • VPN connection—Indicates whether the phone connects to the VPN server. The status can be either Connected or Disconnected.

  • VPN IP address—VPN IP address assigned from the VPN server.

  • VPN subnet mask—VPN subnet mask assigned from the VPN server.

  • Sent bytes—Total bytes the phone sent out to the network through the VPN server.

  • Received bytes—Total bytes the phone received from the network through the VPN server.

Set Up a VPN Connection from the Phone Web Page

You can set up a VPN connection from the phone web page.

Cisco IP Phone 6821 Multiplatform Phones doesn't supprt VPN connection.

Before you begin

Access the phone administration web page. See Access the Phone Web Interface.

Procedure

Step 1

Select Voice > System.

Step 2

In the section VPN Settings, configure the parameters as defined in Parameters for VPN Settings table.

Step 3

Click Submit All Changes to save the changes.

The changes don't take effect immediately. You need to manually reboot the phone or enable the VPN connection from the phone to trigger the VPN connection.

You can also configure the parameters in the phone configuration file with XML(cfg.xml) code. To configure each parameter, see the syntax of the string in the Parameters for VPN Settings table.

Step 4

(Optional) After the phone reboots successfully, you can view the status and other details of the VPN connection under the VPN Status section from Info > Status.

Step 5

(Optional) If you want to disable the VPN connection, set the parameter Connect on Bootup to No, and then manually reboot the phone. For details, see Reboot the Phone from the Phone Web Page.

Parameters for VPN Settings

The following table defines the function and usage of the VPN connection parameters in the VPN Settings section under the Voice > System tab in the phone web interface. It also defines the syntax of the string that is added in the phone configuration file (cfg.xml) with XML code to configure a parameter.

Table 10. Parameters for VPN Settings

Parameter

Description and Default Value

VPN Server

IP address or FQDN of the VPN server for the phone to access. For example:

100.101.1.218 or vpn_server.example.com

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format:

    <VPN_Server ua="rw"><Server IP or FQDN></VPN_Server>

  • On the phone web interface, enter an IP address or FQDN of the VPN server.

Default: Empty

VPN User Name

Username for a credential user on the VPN server.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format:

    <VPN_User_Name ua="rw">Example</VPN_User_Name>

  • On the phone web interface, enter the username.

Default: Empty

VPN Password

Password of the specified username to access the VPN server.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format:

    <VPN_Password ua="rw">Example</VPN_Password>

  • On the phone web interface, enter the password.

Default: Empty

VPN Tunnel Group

Tunnel group assigned to the VPN user.

Tunnel group is used to identify the group policy for the VPN connection.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format:

    <VPN_Tunnel_Group ua="rw">Example</VPN_Tunnel_Group>

  • On the phone web interface, enter the name of the tunnel group.

Default: Empty

Connect on Bootup

Enables or disables the automatic connection to the VPN server after the phone reboots.

Perform one of the following:

  • In the phone configuration file with XML(cfg.xml), enter a string in this format:

    <Connect_on_Bootup ua="rw">No</Connect_on_Bootup>

  • On the phone web interface, set this field Yes or No as needed.

Allowed values: Yes and No

Default: No

Cisco Product Security Overview

This product contains cryptographic features and is subject to U.S. and local country laws that govern import, export, transfer, and use. Delivery of Cisco cryptographic products does not imply third-party authority to import, export, distribute, or use encryption. Importers, exporters, distributors, and users are responsible for compliance with U.S. and local country laws. By using this product, you agree to comply with applicable laws and regulations. If you are unable to comply with U.S. and local laws, return this product immediately.

Further information regarding U.S. export regulations can be found at https://www.bis.doc.gov/policiesandregulations/ear/index.htm.