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.

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	208 - length (Challenge Password)	Yes
   Root CA Fingerprint	12	binary	20 or 32	Yes
   Challenge Password	13	string	208 - length (Server)	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 maximum length of Server + Challenge Password shall be less than 208 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.
   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. The valid value is: DP-9841, DP-9851, DP-9861, DP-9871, or CP-8875.

   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.

   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.
   Once you click the button, the removal operation starts immediately without a confirmation.

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.

The Cisco IP Phones support 802.1X Authentication.

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. CDP doesn’t 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 doesn’t act as the LAN switch to authenticate a data endpoint before accessing the network.

Cisco IP Phones also provide a proxy EAPOL Logoff mechanism. If the locally attached PC disconnects from the IP phone, the LAN switch doesn’t 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.

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

• Switch: The switch must support 802.1X, so it can act 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 doesn’t 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.

  • Enabled: If you’re 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.

    For more information about IEEE 802.1X support on the Cisco Catalyst switches, see the Cisco Catalyst switch configuration guides at:

    http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

  • Disabled: If the switch doesn’t support multiple 802.1X-compliant devices on the same port, you should disable the PC Port when 802.1X authentication is enabled. If you don’t disable this port and then 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 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 continue 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.
• (For Cisco Desk Phone 9800 Series only)

  Cisco Desk Phone 9800 Series 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 Desk Phone 9800 Series.

  For example, the PID of phone 9841 is DP-9841; you can set Radius·User-Name to Start with DP or Contains DP. You can set it in both of the following sections:

  • Policy > Conditions > Library Conditions

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

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 format. You must use this format when setting up a WPA/WPA2/SAE Pre-shared key:

  ASCII: an ASCII-character string with 8 to 63 characters in length (0-9, lowercase and uppercase A-Z, and special characters)

  Example: GREG123567@9ZX&W

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

• WPA/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. Cisco Desk Phone 9861 and 9871 and Cisco Video Phone 8875 support 802.11r (FT). Both over the air and over the DS are supported to allow for fast secure roaming. But we strongly recommend utilizing the 802.11r (FT) over air method.

With WPA/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 ensure that voice traffic is secure, the phone supports TKIP and AES for encryption. When these mechanisms are used for encryption, both the signaling SIP packets and voice Real-Time Transport Protocol (RTP) packets are encrypted between the AP and the phone.

TKIP

WPA uses TKIP encryption that has several improvements over WEP. TKIP provides per-packet key ciphering and longer initialization vectors (IVs) that strengthen encryption. In addition, a message integrity check (MIC) ensures that encrypted packets aren’t being altered. TKIP removes the predictability of WEP that helps intruders decipher the WEP key.

AES

An encryption method used for WPA2/WPA3 authentication. This national standard for encryption uses a symmetrical algorithm that has the same key for encryption and decryption. AES uses Cipher Blocking Chain (CBC) encryption of 128 bits in size, which supports key sizes of 128 bits, 192 bits and 256 bits, as a minimum. The phone supports a key size of 256 bits.

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 the phone that corresponds to AP configuration.