FIPS

Federal Information Processing Standard (FIPS)

A Federal Information Processing Standard (FIPS) is a security standard that

  • defines requirements for cryptographic modules intended to secure sensitive but unclassified (SBU) information

  • is mandated for use by U.S. government agencies and adopted by many regulated industries such as finance and healthcare, and

  • establishes assurance levels to validate the strength and reliability of cryptographic implementations.

Sensitive but unclassified (SBU) information: Data that, while not classified for national security, still requires protection due to its sensitive nature and potential impact if disclosed.

Additional reference information

Federal Information Processing Standard (FIPS) 140-2 is a well-known FIPS standard specifying security requirements for cryptographic modules protecting SBU information. These cryptographic modules are produced by the private sector for use in government and regulated environments.

With FIPS in the enabled state, some passwords and pre-shared keys must have the following minimum lengths:

  • For Software-Defined Access Wireless, between the controller and map server, a pre-shared key (such as the LISP authentication key) used for authenticating TCP messages must be at least 14 characters long.

  • The ISAKMP key (for example, the Crypto ISAKMP key) must also be at least 14 characters long.

Guidelines and restrictions for FIPS

  • Controller switches use a legacy key to support legacy APs. In FIPS mode, the crypto engine identifies the key as weak and displays this error message: % Error in generating keys: could not generate test signature. Ignore error messages during controller startup in FIPS mode.

  • When you enable FIPS, SSH clients that use SHA1 cannot access the controller.

  • You need to use FIPS-compliant SSH clients to access the controller.

  • You cannot use TrustSec in FIPS mode.

  • You cannot configure PAC keys in FIPS mode.

  • You cannot use level-6 encrypted passwords in FIPS mode. Also, 802.1X authentications fail if the RADIUS shared secret uses a type-6 encryption key.

  • The console of APs get disabled when the controller is operating in FIPS mode.

  • The weak or legacy cipher like SHA1 is not supported in FIPS mode.

  • The AES128-SHA option is not supported for AP-dtls-ciphersuite when the controller is operating in CC mode.

  • We recommend a minimum RSA key size of 2048 bits under RADSEC when operating in FIPS or CC mode. Otherwise, the RADSEC fails.

FIPS self-tests

A FIPS self-test is a cryptographic module validation mechanism that

  • verifies functionality and integrity during device power-up

  • performs conditional checks whenever security functions are invoked, and

  • ensures FIPS 140-2 compliance by enforcing automated self-testing procedures.

Power-up self-tests

Power-up self-tests run automatically after the device powers up. A device enters FIPS mode only after all self-tests are successfully completed. If any self-test fails, the device logs a system message and transitions into an error state. If the power-up self-test fails, the device also fails to boot.

The module uses a known-answer test (KAT), in which a cryptographic algorithm runs on data for which the correct output is already known, and then the calculated output is compared to this expected value. If the calculated output does not equal the known answer, the known-answer test fails.

Power-up self-tests include:

  • Software integrity: Validates the integrity of module software as it loads.

  • Algorithm tests: Verifies correct operation of cryptographic algorithms using KATs.

Conditional self-tests

Conditional self-tests are performed each time an applicable security function or operation is accessed, unlike power-up self-tests that run only at startup.

The device uses a cryptographic algorithm known-answer test (KAT) on each FIPS 140-2-approved function, which includes encryption, decryption, authentication, and random number generation. The algorithm is applied to a set of data with a known correct output, and the calculated output is compared to this known value. If the calculated output is different, the KAT fails.

Conditional self-tests run automatically whenever their associated security function or operation is invoked. They include the following:

  • Pair-wise consistency test: Runs when a public or private key-pair is generated to confirm the correct relationship.

  • Continuous random number generator test: Runs each time a random number is generated to check the quality of randomness.

  • Bypass: Evaluates bypass operations if performed.

  • Software load: Validates integrity when new software is loaded.

Examples

  • When a device boots, it performs power-up self-tests to confirm its cryptographic algorithms work as intended before entering FIPS mode.

  • Whenever the device generates a new cryptographic key pair, a pair-wise consistency test is executed.

  • If a random number is generated, the system runs a continuous random number generator test, verifying the output for compliance.

Configure FIPS (CLI)

Enable or disable FIPS mode on controllers for compliance and security.

Ensure that both the active and standby controllers have the same FIPS authorization key.

Procedure

Step 1

Enter global configuration mode.

Example:


                        Device
                        # configure terminal

Step 2

Enable FIPS mode.

Example:


                        Device
                        (config)# 
                        fips authorization-key key

The key length must be 32 hexadecimal characters.

To disable FIPS mode on the device, use the no form of this command.

Step 3

Return to privileged EXEC mode.

Example:


                        Device
                        (config)# 
                        end

Enable or disable FIPS mode. Reboot the controller to apply changes. After the controller reboots, access points also reboot once they rejoin.

What to do next

Reboot the controller each time you enable or disable FIPS mode.

How FIPS configuration works in high availability setups

Set up a high availability (HA) pair in FIPS mode by configuring both controllers with the same FIPS authorization key before forming the HA pair.

If you configure the key after forming the HA pair, it will not sync to the standby. This may cause reload loops when you reboot.

  • Break the HA pair if you configured the FIPS key after pairing.

  • Configure the same FIPS authorization key on both members independently.

  • Form the HA pair again.

Summary

In this process, you configure FIPS in an HA setup by setting the same FIPS authorization key on both members before forming the HA pair.

  • You must perform the configuration steps on both controllers.

  • Configure and pair both controllers (member1 and member2) in HA mode.

Matching FIPS authorization keys on both controllers in the HA pair prevent synchronization issues and reload loops.

Workflow

These stages describe the steps to configure FIPS in an HA setup.

  1. Turn off both members of the stack.
  2. Power on only member1 and wait for the controller to start. Log in from the console when prompted.
  3. Log in to member1 with valid credentials and use the following commands to verify FIPS status and configuration:
    • Use the show fips status command
    • Use the show fips authorization-key command
    • Use the show romvar command
    • Use the show chassis command

    Note

    Keep the configured FIPS authorization key available.
  4. Configure the FIPS key on member1 if you have not already configured it.
    • conf t
    • fips authorization-key <thirty-two hexadecimal characters>
  5. Save your changes and power off member1.
  6. Power on only member2 and wait for the controller to start. Log in from the console when prompted.
  7. Log in to member2 with valid credentials and use the following commands to verify FIPS status and configuration:
    • Use the show fips status command
    • Use the show fips authorization-key command
    • Use the show romvar command
    • Use the show chassis command

    Note

    Keep the configured FIPS authorization key available.
  8. Configure the FIPS key on member2 if you have not already configured it.

    Note

    The key value must be the same on both members of the stack.
    • conf t
    • fips authorization-key <thirty-two hexadecimal characters>
  9. Save your changes and power off member2.
  10. Power on both members together and wait for the stack to form.
  11. Monitor the system for any crash or unexpected reload events.

    Note

    The members are not expected to reload because of FIPS issues.

Result

Both controllers in the HA pair operate in synchronized FIPS mode. Correct configuration prevents synchronization issues and reload loops caused by mismatched or improperly applied FIPS authorization keys.

Monitor FIPS

Use these commands to view information about FIPS:

Table 1. FIPS Monitoring Commands

Command

Purpose

show fips authorization-key

Displays the installed authorization key.

show fips status

Displays the status of FIPS on the device.

CC

Common criteria

A Common Criteria certificate is a security assurance certification that

  • provides independent verification that IT products meet specified security requirements,

  • twenty-four countries worldwide officially recognize this certification,

  • and this scheme uses defined protection profiles for requirements, tests, and evaluation methodologies.

Common Criteria protection profiles and further information

Common Criteria (CC) is a global testing standard. It verifies whether a device provides the security functionalities claimed by product developers. The standard establishes requirements, tests, and an evaluation methodology to ensure that IT products comply with recognized security standards.

The Target of Evaluation (ToE) is the product or system under evaluation. It must conform to protection profiles under the Common Criteria scheme. The applicable protection profiles are:

  • Collaborative Protection Profile for Network Devices (NDcPP) version 2 dated 2017-05-05,

  • Wireless Local Area Network (WLAN) Access Systems Extended Package version 1 dated 2015-05-29.

The CC certificate’s recognition by twenty-four countries ensures that vendors can demonstrate compliance with internationally accepted security requirements.

For more information about CC, refer to the Cisco Common Criteria documentation.

Configure the common criteria (CLI)

Enable common criteria mode for enhanced security compliance on your wireless controller.

Procedure

Step 1

Enter global configuration mode.

Example:

Device# configure terminal

Step 2

Configure the common criteria mode for the controller.

Example:

Device(config)# wireless wlancc

Note

 

Reboot the controller after enabling the common criteria mode.

Step 3

Configure the cipher suite supported by DTLS.

Example:

Device(config)# ap dtls-cipher ciphersuite

Note

 

Reboot the controller to activate the selected cipher suite.

Step 4

Configure DTLS version 1.0 or 1.2.

Example:

Device(config)# ap dtls-version dtls_1_0 dtls_1_2

Note

 

Save the configuration and reload the controller for the changes to take effect.

Step 5

Exit the configuration mode and enter the privileged EXEC mode.

Example:

Device(config)# end

The controller operates in common criteria mode with the chosen DTLS cipher suite and protocol version. The changes take effect after you reboot the controller.

Verify CC configuration

Use the this show command to display the wireless certification configurations: 


Device# show wireless certification config
Wireless Certification Configurations

WLANCC                                    : Configured
AP DTLS Cipher Suite                      : DHE-RSA-AES128-SHA
                                            DHE-RSA-AES256-SHA
                                            DHE-RSA-AES256-SHA256
                                            ECDHE-ECDSA-AES128-GCM-SHA256
                                            ECDHE-ECDSA-AES256-GCM-SHA384
AP DTLS Version                           : DTLS v1.2

Check points for CC mode operation

This topic describes the key check points and considerations for CC mode operation on Cisco Catalyst 9800 Series Wireless Controllers.

Check points for CC mode operation

You need to be aware of these for CC mode operation:

Table 2. Check points for CC mode operation

Features

Description

Link encryption

Data link encryption is not supported for C91xx wireless mobility express platform.

Link encryption

For non-C91xx wireless mobility express platfoms - Enabling Data link encryption (using ECDHE keypair) would make AP flap continually.

LDAP

Secure LDAP does not support strong ciphers and is not part of CC certification.

Mobility

Mobility between Cisco Catalyst 9800 Series Wireless controllers is possible with LSC as wireless management trustpoint (having RSA based keys).

Mobility

Mobility between AireOS WLC and Cisco Catalyst 9800 Series Wireless controllers is supported (using SUDI and MIC certificates for wireless management trustpoint).

Mobility

Mobility between AireOS WLC and Cisco Catalyst 9800 Series Wireless controllers is not supported (if using LSC certficates for wireless management trustpoint).

CC mode

The show wireless certification config command displays the configured values for WLANCC, or AP-dtls-ciphersuite, or AP-dtls-version, and needs reload after re-configuring these parameters.

CC mode

The AES128-SHA option is not supported for AP-dtls-ciphersuite when Cisco Catalyst 9800 Series Wireless Controller is operating in CC mode.

CC mode

The AES128-SHA option is supported for AP-dtls-ciphersuite when Cisco Catalyst 9800 Series Wireless Controller is operating in FIPS mode.

CC mode

If you want your Cisco Catalyst 9800 Series Wireless Controller to operate in CC mode (you need to enable both FIPS mode and CC mode).

LSC

To secure communication between Cisco Catalyst 9800 Series Wireless Controller and LSC server, you need to deploy ESTCA as LSC server (which uses TLS to secure related communication).

LSC

Cisco Catalyst 9800 Series Wireless Controllers do not support HTTPS to secure its communication with the LSC server.

LSC

During LSC provisioning, APs generate EC based keys only when related Cisco Catalyst 9800 Series Wireless Controller is operating in CC mode.

LSC

During LSC provisioning, APs generate RSA based keys when related Cisco Catalyst 9800 Series Wireless Controller is operating in FIPS mode.

LSC

During LSC provisioning, APs generate RSA based keys when related Cisco Catalyst 9800 Series Wireless Controlle is operating in non-FIPS or non-CC mode.

Password Obfuscation

You can use the following commands for password obfuscation:

  • key config-key password-encrypt

  • service password-encryption

  • password encryption aes

  • passwd key obfuscate

CC mode

APs reload immediately, if you change the wlancc status.

FIPS mode

APs do not reload immediately, if you change the FIPS status.

Cisco 1562 AP

To assist Cisco 1562 APs join the Cisco Catalyst 9800 Series wireless controller, you need to have the ethernet MAC of the AP in the username list.

AP serial number authorization

Serial number authorization is possible only when Cisco Catalyst 9800 Series wireless controller is in FIPS and CC mode, and with LSC based trustpoints/certficates only (not with SUDI trustpoint).

Display

FIPS suitability displays Suitable only if the controller is in CC mode and LSC certificate is compatible. Both wireless management and Certs CN should match the hostname of the controller and length of RSA Key (> 2048) (or) EC keys being used.

RADSEC

RSA key size must contain a minimum of 2048 bits (of certificate under RADSEC) when operating in FIPS or CC mode, else RADSEC fails.