Cisco Systems 2504, 5520, 8510 and 8540 Wireless LAN Controllers
FIPS 140-2 Non Proprietary Security Policy
Level 1 Validation
Version 0.1
December 22, 2017
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
1
Table of Contents
1 INTRODUCTION.................................................................................................................. 3
1.1 PURPOSE............................................................................................................................. 3
1.2 MODELS ............................................................................................................................. 3
1.3 MODULE VALIDATION LEVEL ............................................................................................ 3
1.4 REFERENCES....................................................................................................................... 4
1.5 TERMINOLOGY ................................................................................................................... 4
1.6 DOCUMENT ORGANIZATION ............................................................................................... 4
2 CISCO SYSTEMS 2504, 5520, 8510 AND 8540 WIRELESS LAN CONTROLLERS... 5
2.1 CRYPTOGRAPHIC MODULE PHYSICAL CHARACTERISTICS .................................................. 5
2.2 MODULE INTERFACES......................................................................................................... 5
2.3 ROLES, SERVICES AND AUTHENTICATION ........................................................................ 11
2.4 NON-FIPS APPROVED SERVICES ...................................................................................... 15
2.5 UNAUTHENTICATED SERVICES ......................................................................................... 15
2.6 CRYPTOGRAPHIC ALGORITHMS ........................................................................................ 15
2.7 CRYPTOGRAPHIC KEY MANAGEMENT.............................................................................. 16
2.8 SELF-TESTS ...................................................................................................................... 25
3 SECURE OPERATION ...................................................................................................... 26
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2
1 Introduction
1.1 Purpose
This is a non-proprietary Cryptographic Module Security Policy for the Cisco Systems 2504,
5520, 8510 and 8540 Wireless LAN Controllers, and Firmware 8.3; referred to in this document
as controllers or the module. This security policy describes how the modules meet the security
requirements of FIPS 140-2 Level 1 and how to run the modules in a FIPS 140-2 mode of
operation and may be freely distributed.
1.2 Models
• Cisco 2504 Wireless Controller (HW: 2504)
• Cisco 5520 Wireless Controller (HW: 5520)
• Cisco 8510 Wireless Controller (HW: 8510)
• Cisco 8540 Wireless Controller (HW: 8540)
FIPS 140-2 (Federal Information Processing Standards Publication 140-2 — Security
Requirements for Cryptographic Modules) details the U.S. Government requirements for
cryptographic modules. More information about the FIPS 140-2 standard and validation program
is available on the NIST website at http://csrc.nist.gov/groups/STM/index.html.
1.3 Module Validation Level
The following table lists the level of validation for each area in the FIPS PUB 140-2.
No. Area Title Level
1 Cryptographic Module Specification 1
2 Cryptographic Module Ports and Interfaces 1
3 Roles, Services, and Authentication 2
4 Finite State Model 1
5 Physical Security 1
6 Operational Environment N/A
7 Cryptographic Key management 1
8 Electromagnetic Interface/Electromagnetic Compatibility 1
9 Self-Tests 1
10 Design Assurance 1
11 Mitigation of Other Attacks N/A
Overall module validation level 1
Module Validation Level
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
3
1.4 References
This document deals only with operations and capabilities of the Cisco Systems 2504, 5520,
8510 and 8540 Wireless LAN Controllers, in the technical terms of a FIPS 140-2 cryptographic
module security policy.
For answers to technical or sales related questions please refer to the contacts listed on the Cisco
Systems website at www.cisco.com.
The NIST Validated Modules website (http://csrc.nist.gov/groups/STM/cmvp/validation.html)
contains contact information for answers to technical or sales-related questions for the module.
1.5 Terminology
In this document, the Cisco Systems 2504, 5520, 8510 and 8540 Wireless LAN Controllers are
referred to as controllers, WLC, or the modules.
1.6 Document Organization
The Security Policy document is part of the FIPS 140-2 Submission Package. In addition to this
document, the Submission Package contains:
Vendor Evidence document
Finite State Machine
Other supporting documentation as additional references
This document provides an overview of the Cisco Systems 2504, 5520, 8510 and 8540 Wireless
LAN Controllers and explains the secure configuration and operation of the module. This
introduction section is followed by Section 2, which details the general features and functionality
of the appliances. Section 3 specifically addresses the required configuration for the FIPS-mode
of operation.
With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation
Submission Documentation is Cisco-proprietary and is releasable only under appropriate non-
disclosure agreements. For access to these documents, please contact Cisco Systems.
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
4
2 Cisco Systems 2504, 5520, 8510 and 8540 Wireless LAN Controllers
The Cisco 2504 Wireless Controller, designed for 802.11n and 802.11ac performance, enables
system wide wireless functions in small to medium-sized enterprises and branch offices.
The Cisco 8510 Wireless Controller, designed for 802.11n and 802.11ac performance, provides
centralized control, management, and troubleshooting for enterprise and service provider
deployments.
The Cisco 5520 and 8540 Wireless Controllers, optimized for 802.11ac Wave2 performance,
provide centralized control, management, and troubleshooting for high-scale deployments in
service provider and large campus deployments.
2.1 Cryptographic Module Physical Characteristics
Each module is a multi-chip standalone security appliance, and the cryptographic boundary is
defined as encompassing the “top,” “front,” “back,” “left,” “right,” and “bottom” surfaces of the
case.
2.2 Module Interfaces
The module provides a number of physical and logical interfaces to the device, and the physical
interfaces provided by the module are mapped to the following FIPS 140-2 defined logical
interfaces: data input, data output, control input, status output, and power. The logical interfaces
and their mapping are described in the following tables:
Module Physical Interface FIPS 140-2 Logical Interface
• Four 1 Gbps Ethernet (RJ-45) Data Input Interface
• Four 1 Gbps Ethernet (RJ-45) Data Output Interface
• Four 1 Gbps Ethernet (RJ-45)
• Console port
• Reset button
Control Input Interface
• LEDs Status Output Interface
• Power Connector Power Interface
Cisco 2504 Wireless LAN Controller Physical Interface/Logical Interface Mapping
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
5
Cisco 2504 Wireless LAN Controller Front Panel
Cisco 2504 Wireless LAN Controller Back Panel
Module Physical Interface FIPS 140-2 Logical Interface
• Two 1/10 G SFP/SFP+ Ports
• Four 10/100/1000 Base-T Ports
Data Input Interface
• Two 1/10 G SFP/SFP+ Ports
• Four 10/100/1000 Base-T Ports
Data Output Interface
• KVM connector
• Serial port
• Power button
• Locator button
• Reset button
• USB ports
Control Input Interface
• LEDs
• VGA Connector
Status Output Interface
• Power Connector Power Interface
Cisco 5520 Wireless LAN Controller Physical Interface/Logical Interface Mapping
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
6
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
7
Module Physical Interface FIPS 140-2 Logical Interface
• Two 10 Gigabit SFP interfaces Data Input Interface
• Two 10 Gigabit SFP interfaces Data Output Interface
• Two 10 Gigabit SFP interfaces
• Service Port
• Serial Connector
• HA Port
• IMM Port
• Four USBs
Control Input Interface
• Two 10 Gigabit SFP interfaces
• Service Port
LEDs
• Operator Information Panel
• Serial Connector
• HA Port
• IMM Port
• Four USBs
• Video connector
Status Output Interface
• Power Connector Power Interface
Cisco 8510 Wireless LAN Controllers Physical Interface/Logical Interface Mapping
Note: Small Form-Factor Pluggable (SFP) listed in table above is only referred to Cisco SFP
Cisco 8510 Wireless LAN Controller Front Panel
Note: Optical Drive interface (Not used)
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
8
Cisco 8510 Wireless LAN Controller Rear Panel
Module Physical Interface FIPS 140-2 Logical Interface
• Four 1/10 G SFP/SFP+ Ports
• Four 10/100/1000 Base-T Ports
Data Input Interface
• Four 1/10 G SFP/SFP+ Ports
• Four 10/100/1000 Base-T Ports
Data Output Interface
• KVM connector
• Serial port
• Power button
• Locator button
• Reset button
• USB ports
Control Input Interface
• LEDs
• VGA Connector
Status Output Interface
• Power Connector Power Interface
Cisco 8540 Wireless LAN Controller Physical Interface/Logical Interface Mapping
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
9
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
10
2.3 Roles, Services and Authentication
The module supports role-based authentication. There are four roles in the module that the
operators may assume in the FIPS mode:
• AP Role -This role is filled by an access point associated with the controller.
• Client Role -This role is filled by a wireless client associated with the controller.
• User Role -This role performs general security services including cryptographic
operations and other approved security functions. The product documentation refers to
this role as a management user with read-only privileges.
• Crypto Officer (CO) Role -This role performs the cryptographic initialization and
management operations. In particular, it performs the loading of optional certificates and
key-pairs and the zeroization of the module. The product documentation refers to this role
as a management user with read-write privileges.
The Module does not support a Maintenance Role.
User Services
The services available to the User role consist of the following:
Services &
Access Description Keys & CSPs
System Status The LEDs show the network activity and
overall operational status and the command
line status commands output system status.
N/A
Random Number
Generation
Key generation and seeds for asymmetric key
generation
DRBG entropy input, DRBG seed, DRBG
v, DRBG Key – r, w, d
Key Exchange Key exchange over Diffie-Hellman and EC
Diffie-Hellman
Diffie-Hellman public key, Diffie-
Hellman private key, Diffie-Hellman
shared secret, EC Diffie-Hellman Public
Key, EC Diffie-Hellman Private Key, EC
Diffie-Hellman shared secret – w, d
TACACS+ User & CO authentication to the module using
TACACS+.
TACACS+ authentication secret,
TACACS+ authorization secret,
TACACS+ accounting secret, User
password, Enable secret – w, d
IPSec Secure communications between module and
RADIUS server.
skeyid, skeyid_d, IKE session encryption
key, IKE session authentication key, IKE
ECDSA private key, IKE ECDSA public
key, IPSec session encryption key, IPSec
session authentication key, ISAKMP
preshared – r, w,d
RADIUS Key Wrap Establishment and subsequent receive 802.11
PMK from the RADIUS server.
RADIUSOverIPSecEncryptionKey,
RADIUSOverIPSecIntegrityKey,
RADIUS KeyWrap MACK, RADIUS
AES KeyWrap KEK, RADIUS Server
Shared Secret, – w, d
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
11
HTTPS/TLS • Establishment and subsequent data
transfer of a TLS session for use
between the module and the user.
• Protection of syslog messages
HTTPS TLS Pre-Master secret, HTTPS
TLS Encryption Key, HTTPS TLS
Integrity Key, TLS pre-master secret, TLS
encryption key, TLS integrity key, TLS
ECDSA private key – w, d
Module Read-only
Configuration
Viewing of configuration settings N/A
User Services
Crypto Officer Services
The Crypto Officer services consist of the following:
Services & Access Description Keys & CSPs
Self Test and Initialization Cryptographic algorithm tests, firmware
integrity tests, module initialization.
N/A (No keys are accessible)
System Status The LEDs show the network activity and overall
operational status and the command line status
commands output system status.
N/A (No keys are accessible)
Random Number
Generation
Key generation and seeds for asymmetric key
generation
DRBG entropy input, DRBG seed,
DRBG v, DRBG Key – r, w, d
Key Exchange Key exchange over Diffie-Hellman and EC
Diffie-Hellman
Diffie-Hellman public key, Diffie-
Hellman private key, Diffie-Hellman
shared secret, EC Diffie-Hellman
Public Key, EC Diffie-Hellman
Private Key, EC Diffie-Hellman
shared secret – w, d
TACACS+ User & CO authentication to the module using
TACACS+.
TACACS+ authentication secret,
TACACS+ authorization secret,
TACACS+ accounting secret, User
password, Enable secret – w, d
IPSec Secure communications between module and
RADIUS server.
skeyid, skeyid_d, IKE session
encryption key, IKE session
authentication key, IKE ECDSA
private key, IKE ECDSA public key,
IPSec session encryption key, IPSec
session authentication key, IPSec
authentication key, IPSec encryption
key, ISAKMP preshared – r, w,d
Zeroization Zeroize CSPs and cryptographic keys by calling
‘switchconfig key-zeroize controller’ command
or cycling power to zeroize all cryptographic
keys stored in SDRAM. The CSPs (password,
secret, cscoCCDefaultMfgCaCert, engineID)
stored in Flash can be zeroized by overwriting
with a new value.
All Keys and CSPs will be destroyed
Module Configuration Selection of non-cryptographic configuration
settings
N/A
SNMPv3 Non-security related monitoring by the CO
using SNMPv3
snmpEngineID, SNMPv3 Password,
SNMP session key – w, d
SSH • Establishment and subsequent data
transfer of a SSH session for use
between the module and the CO.
SSH encryption key, SSH integrity
key, SSH ECDSA private key – w, d
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
12
HTTPS/TLS • Establishment and subsequent data
transfer of a TLS session for use
between the module and the CO.
• Protection of syslog messages
HTTPS TLS Pre-Master secret,
HTTPS TLS Encryption Key, HTTPS
TLS Integrity Key, TLS pre-master
secret, TLS encryption key, TLS
integrity key, TLS ECDSA private
key – w, d
DTLS Data Encrypt Enabling optional DTLS data path encryption
for Office Extended AP’s
DTLS Pre-Master Secret, DTLS Master
Secret, DTLS Encryption/Decryption
Key (CAPWAP session keys), DTLS
Integrity Keys, DTLS ECDSA private
key – w, d
RADIUS Key Wrap Establishment and subsequent receipt of 802.11
PMK from the RADIUS server.
RADIUSOverIPSecEncryptionKey,
RADIUSOverIPSecIntegrityKey,
RADIUS KeyWrap MACK, RADIUS
AES KeyWrap KEK, RADIUS
Server Shared Secret, – w, d
Crypto Officer Services (r = read, w = write, d = delete)
AP and Client Services
The AP and Client services consist of the following:
Services & Access Description Keys & CSPs
MFP (AP Role) Generation and subsequent distribution of MFP
key to the AP over a CAPWAP session.
Infrastructure MFP MIC Key,
cscoCCDefaultMfgCaCert – w, d
Local EAP Authenticator
(Client Role)
Establishment of EAP-TLS or EAP-FAST based
authentication between the client and the
Controller.
TLS Pre-Master Secret, TLS
Encryption Key, TLS Integrity Key,
TLS ECDSA private key – w, d
802.11 (AP Role) Establishment and subsequent data transfer of an
802.11 session for use between the client and
the access point
802.11 Pre-Shared Key (PSK),
802.11 Pairwise Transient Key
(PTK), 802.11 Group Temporal
Key (GTK), 802.11 Key
Confirmation Key (KCK)
802.11 Key Encryption Key (KEK),
802.11 Pairwise Transient Key
(PTK) – w, d
RADIUS Key Wrap (AP
and Client Role)
Establishment and subsequent receipt of 802.11
PMK from the RADIUS server.
RADIUS KeyWrap MACK, RADIUS
AES KeyWrap KEK – w, d
AP and Client Services
User and CO Authentication
The Crypto Officer role is assumed by an authorized CO connecting to the module via CLI. The
OS prompts the CO for their username and password, if the password is validated against the
CO’s password in memory, the user is allowed entry to execute CO services. The password
feedback mechanism does not provide information that could be used to determine the
authentication data.
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
13
CO passwords must be at least eight (8) characters long, including at least one letter and at least
one number character, in length (enforced procedurally). If six (6) integers, one (1) special
character and one (1) alphabet are used without repetition for an eight (8) digit PIN, the
probability of randomly guessing the correct sequence is one (1) in 251,596,800 (this calculation
is based on the assumption that the typical standard American QWERTY computer keyboard has
10 Integer digits, 52 alphabetic characters, and 32 special characters providing 94 characters to
choose from in total. The calculation should be 10×9×8×7×6×5×32×52 = 251,596,800).
Therefore, the associated probability of a successful random attempt is approximately 1 in
251,596,800, which is less than the 1 in 1,000,000 required by FIPS 140-2.
AP Authentication
The module performs mutual authentication with an access point through the CAPWAP
protocol.
RSA has a modulus size of 2048 bit, thus providing 112 bits of strength. An attacker would have
a 1 in 2112
chance of randomly obtaining the key, which is much stronger than the one in a
million chance required by FIPS 140-2. To exceed a one in 100,000 probability of a successful
random key guess in one minute, an attacker would have to be capable of approximately
5.2x1028
attempts per minute, which far exceeds the operational capabilities of the modules to
support.
ECDSA P-256 provides 128 bits of strength and P-384 provides 192 bits of strength. An
attacker would have a 1 in 2128
chance of randomly obtaining the key, which is much stronger
than the one in a million chance required by FIPS 140-2. To exceed a one in 100,000 probability
of a successful random key guess in one minute, an attacker would have to be capable of
approximately 3.4x1033
attempts per minute, which far exceeds the operational capabilities of the
modules to support.
Client Authentication
The module performs mutual authentication with a wireless client through EAP-TLS or EAP-
FAST protocols. EAP-FAST is based on EAP-TLS and uses EAP-TLS key pair and certificates.
RSA has modulus size of 2048 bit, thus providing 112 bits of strength. An attacker would have a
1 in 2112
chance of randomly obtaining the key, which is much stronger than the one in a million
chance required by FIPS 140-2. To exceed a one in 100,000 probability of a successful random
key guess in one minute, an attacker would have to be capable of approximately 5.2x1028
attempts per minute, which far exceeds the operational capabilities of the modules to support.
ECDSA P-256 provides 128 bits of strength and P-384 provides 192 bits of strength. An
attacker would have a 1 in 2128
chance of randomly obtaining the key, which is much stronger
than the one in a million chance required by FIPS 140-2. To exceed a one in 100,000 probability
of a successful random key guess in one minute, an attacker would have to be capable of
approximately 3.4x1033
attempts per minute, which far exceeds the operational capabilities of the
modules to support.
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
14
2.4 Non-FIPS Approved Services
• SSHv1 with RC4 and HMAC-MD5
• SNMP v1 and v2
• IPSec/IKE with Diffie-Hellman 768-bit/1024-bit modulus, EC Diffie-Hellman 163/192
curves, and Triple-DES
The above services shall not be used in the FIPS approved mode of operation.
2.5 Unauthenticated Services
An unauthenticated operator may observe the System Status by viewing the LEDs on the
module, which show network activity and overall operational status. A solid green LED indicates
normal operation and the successful completion of self-tests. The module does not support a
bypass capability.
2.6 Cryptographic Algorithms
The module implements a variety of approved and non-approved algorithms.
Approved Cryptographic Algorithms
The modules support the following FIPS 140-2 approved algorithm implementations, CiscoSSL
FOM 6.0, CN56xx Data Path (Firmware version: FP-CRYPTO-7.0.0), and OCTEON II
CN6700/CN6800 Series Die (Hardware version: CN6870).
Approved Cryptographic Algorithms
• KTS (AES Cert. #4409; key wrapping; key establishment methodology provides 128 or
256 bits of encryption strength)
Algorithm
Cisco SSL
FOM
CN56xx
(2504/8510)
CN6870
(5520/8540)
AES 128/256 (ECB, CBC, CFB, CTR, CMAC, GCM, CCM, KW, KWP) #4409
AES 128/256 (ECB, CBC, GCM) #2346
AES 128/256 (CBC) #1348
SHA (SHA-1/256/384/512) #3635 #2023
SHA (SHA-1) #1230
HMAC SHA (SHA-1/256/384/512) #2931 #1455
HMAC SHA (SHA-1) #787
DRBG (AES CTR-256) #1422
RSA ((KeyGen; PKCS1_V1_5; Siggen/Sigver) 2048 bits) #2396
ECDSA (KeyPair, PKV, SigGen, SigVer (NIST curves P-256 and P-384)) #1061
CVL (SP800-135) (IKE, TLS, IPsec, SSH, SNMP) #1115
CVL (SP800-56A) (ECC CDH) #1116
KBKDF (SP800-108) #126
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
15
Note:
• CVL Cert. #1115 supports the KDF (key derivation function) used in each of IKE, TLS,
SSH and SNMPv3 protocols.
• IKE, TLS, SSH and SNMPv3 protocols have not been reviewed or tested by the CAVP
and CMVP. Please refer IG D.11, bullet 2 for more information.
• There are algorithms, modes, and keys that have been CAVs tested but not implemented
by the module. Only the algorithms, modes/methods, and key lengths/curves/moduli
shown in this table are implemented by the module.
Non-Approved Cryptographic Algorithms but Allowed in FIPS mode
The module supports the following non-approved, but allowed cryptographic algorithms:
• Diffie-Hellman (CVL Cert. #1115, key agreement; key establishment methodology
provides 112 bits of encryption strength)
• EC Diffie-Hellman (CVL Certs. #1115 and #1116, key agreement; key establishment
methodology provides 128 or 192 bits of encryption strength)
• MD5 (MD5 is allowed in DTLS)
• NDRNG
Non-Approved Cryptographic Algorithms
• Diffie-Hellman (less than 112 bits of encryption strength)
• EC Diffie-Hellman (less than 112 bits of encryption strength)
• HMAC-MD5
• RC4
• Triple-DES (non-compliant)
2.7 Cryptographic Key Management
Cryptographic keys are stored in plaintext form, in flash for long-term storage and in SDRAM
for active keys. The AES key wrap KEK, AES key wrap MACK keys, and the Pre shared key
(PSK) are input by the CO in plaintext over a local console connection. The PMK is input from
the RADIUS server encrypted with the AES key wrap protocol or via IPSec. RSA public keys
are output in plaintext in the form of X.509 certificates. The CAPWAP session key is output
wrapped with the AP's RSA key, and the MFP MIC key and 802.11 PTK, 802.11 GTK are
output encrypted with the CAPWAP session key. Asymmetric key establishment is used in the
creation of session keys during EAP-TLS and EAP-FAST. Any keys not explicitly mentioned
are not input or output. Key generation and seeds for asymmetric key generation is performed as
per SP 800-133 Scenario 1. The DRBG is seeded with a minimum of 256 bits of entropy
strength prior to key generation.
CSPs below are stored in plaintext in both SDRAM and Flash.
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
16
Key/CSP Name
Generation
/ Algorithm Description
Key
Size Storage Zeroization
General Keys/CSPs
DRBG entropy input SP 800-90A
CTR_DRBG
HW-based entropy
source output used to
construct seed
256-bits SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
DRBG seed SP 800-90
ACTR_DRBG
Input to the DRBG that
determines the internal
state of the DRBG.
Generated using DRBG
derivation function that
includes the entropy
input from a hardware-
based entropy source.
384 bits SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
DRBG V SP 800-90A
CTR_DRBG
Internal V value used
as part of SP 800-90A
CTR_DRBG
128 bits SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
DRBG Key SP 800-90A
CTR_DRBG
This is the 256-bit
DRBG key used for SP
800-90A CTR_DRBG
256 bits SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
cscoCCDefaultMfgCaCert rsa-pkcs1-sha2 Verification certificate,
used with CAPWAP to
validate the certificate
that authenticates the
access point
generated/installed at
manufacturing
2048 Flash Overwrite with
new certificate
Diffie-Hellman public key Diffie-Hellman
(Group 14)
The public key used in
Diffie-Hellman (DH)
exchange
2048 bits SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
Diffie-Hellman private key Diffie-Hellman
(Group 14)
The private key used in
Diffie-Hellman (DH)
exchange
224 bits SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
Diffie-Hellman shared secret Diffie-Hellman
(Group 14)
The shared key used in
Diffie-Hellman (DH)
Exchange. Created per
the Diffie-Hellman
protocol
2048 bits SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
17
Key/CSP Name
Generation
/ Algorithm Description
Key
Size Storage Zeroization
EC Diffie-Hellman public key Diffie-Hellman
(Groups 19 and
20)
P-256 and P-384 public
key used in EC Diffie-
Hellman exchange.
This key is derived per
the Diffie-Hellman key
agreement.
P-256
and P-
384
SDRAM
(plaintext)
‘switchconfig
key-zeroize
controller’
command or
Power cycle
EC Diffie-Hellman private key Diffie-Hellman
(Groups 19 and
20)
P-256 and P-384 private
key used in EC Diffie-
Hellman exchange.
Generated by calling
the SP 800-90A CTR-
DRBG.
P-256
and P-
384
SDRAM
(plaintext)
‘switchconfig
key-zeroize
controller’
command or
Power cycle
EC Diffie-Hellman shared secret Diffie-Hellman
(Groups 19 and
20)
P-256 and P-384 shared
secret derived in EC
Diffie-Hellman
exchange
P-256
and P-
384
SDRAM
(plaintext)
‘switchconfig
key-zeroize
controller’
command or
Power cycle
RADIUS Server Shared Secret Shared secret This is the shared secret
between the RADIUS
server and Controller.
Entered by the Crypto
Officer in plaintext
form and stored in
plaintext form.
22 bytes Flash Overwrite with
new password
RADIUSOverIPSecEncryptionKey AES-CBC,
AES-GCM
AES-128/AES-256
encryption/decryption
key, used in IPSec
tunnel between module
and RADIUS to
encrypt/decrypt EAP
keys.
128-256
bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
RADIUSOverIPSecIntegrityKey HMAC Integrity/authentication
key, used in IPSec
tunnel between module
and RADIUS
160-384
bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
User password Shared Secret Identity based
authentication data for
user
Variable
(8+
character
s)
Flash Overwrite with
new password
Enable secret Password Identity based
authentication data for
CO
Variable
(8+
character
s)
Flash Overwrite with
new secret
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
18
Key/CSP Name
Generation
/ Algorithm Description
Key
Size Storage Zeroization
TACACS+ authentication secret Shared secret This is the
authentication shared
secret between the
TACACS+ server and
Controller. Entered by
the Crypto Officer in
plaintext form and
stored in plaintext form.
64 bytes Flash Overwrite with
new secret
TACACS+ authorization secret Shared secret This is the authorization
shared secret between
the TACACS+ server
and Controller. Entered
by the Crypto Officer in
plaintext form and
stored in plaintext form.
64 bytes Flash Overwrite with
new secret
TACACS+ accounting secret Shared secret This is the accounting
shared secret used for
authentication between
the TACACS+ server
and Controller. Entered
by the Crypto Officer in
plaintext form and
stored in plaintext form.
64 bytes Flash Overwrite with
new secret
IKE/IPSEC
skeyid HMAC It was derived by
using ‘ISAKMP pre-
shared’ and other non-
secret values through
the key derivation
function defined in
SP800-135 KDF
(IKE).
160-384
bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
skeyid_d HMAC It was derived by
using skeyid, Diffie-
Hellman shared secret
and other non-secret
values through key
derivation function
defined in SP800-135
KDF (IKE).
160-384
bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
19
Key/CSP Name
Generation
/ Algorithm Description
Key
Size Storage Zeroization
IKE session encryption key AES-CBC,
AES-GCM
The IKE session
encrypt key is derived
by using skeyid_d,
Diffie-Hellman shared
secret and other non-
secret values through
the key derivation
functions defined in
SP800-135 KDF (IKE).
Used for IKE payload
protection
256-bit
AES
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
IKE session authentication key HMAC The IKE session)
authentication key is
derived by using
skeyid_d, Diffie-
Hellman shared secret
and other non-secret
values through the key
derivation functions
defined in SP800-135
KDF (IKE). Used for
payload integrity
verification.
160-384
bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
IKE ECDSA public key ECDSA P-256 and P-384
generated by calling the
SP 800-90A CTR-
DRBG.
P-256
and P-
384
SDRAM
(plaintext)
‘switchconfig
key-zeroize
controller’
command or
Power cycle
IKE ECDSA private key ECDSA P-256 and P-384
generated by calling the
SP 800-90A CTR-
DRBG.
P-256
and P-
384
SDRAM
(plaintext)
‘switchconfig
key-zeroize
controller’
command or
Power cycle
ISAKMP pre-shared Shared secret This shared secret was
manually entered by
CO for IKE pre-shared
key based
authentication
mechanism.
8 chars Flash Overwrite with
new secret
IPSec authentication key HMAC The IPsec
authentication key is
derived via using the
KDF defined in SP800-
135 KDF (IKE). Used
to authenticate the
IPSec peer.
160 bits SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
20
Key/CSP Name
Generation
/ Algorithm Description
Key
Size Storage Zeroization
IPSec encryption key AES-CBC,
AES-GCM
The IPsec encryption
key is derived via a key
derivation function
defined in SP800-135
KDF (IKE).Used to
Secure IPSec traffic.
256-bit
AES
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
DTLS
DTLS Pre-Master Secret Shared Secret Generated by approved
DRBG for generating
the DTLS encryption
key
48 bytes SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
DTLS Master Secret Shared Secret Derived from DTLS
Pre-Master Secret. Used
to create the DTLS
encryption and integrity
keys
48 bytes SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
DTLS Encryption/Decryption Key
(CAPWAP session keys)
AES-CBC,
AES-GCM
Session Keys used to
e/d CAPWAP control
messages
128-256
bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
DTLS Integrity Keys HMAC- Session keys used for
integrity checks on
CAPWAP control
messages
160-384
bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
DTLS ECDSA private key ECDSA P-256 and P-384
generated by calling the
SP 800-90A CTR-
DRBG.
P-256
and P-
384
SDRAM
(plaintext)
‘switchconfig
key-zeroize
controller’
command or
Power cycle
SNMPv3
snmpEngineID Shared secret 32-bits Unique
string to
identify
the
SNMP
engine
Flash Overwrite with
new engine ID
SNMPv3 Password
Shared Secret This secret is used to
derive HMAC-SHA1
key for SNMPv3
Authentication
32 bytes Flash Overwrite with
new password
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
21
Key/CSP Name
Generation
/ Algorithm Description
Key
Size Storage Zeroization
SNMPv3 session key AES-CFB 128-bit Encrypts
SNMPv3
traffic
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
HTTPS/TLS
HTTPS TLS Pre-Master secret Shared secret Shared secret created
using asymmetric
cryptography from
which new HTTPS
session keys can be
created.
48 bytes SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
HTTPS TLS Encryption Key AES-CBC,
AES-GCM
AES key used to
encrypt TLS data
128 and
256 bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
HTTPS TLS Integrity Key HMAC HMAC key used for
HTTPS integrity
protection
160-384
bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
TLS Pre-Master Secret Shared secret Shared secret used to
generate new TLS
session keys.
48 byte SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
TLS Encryption Key AES-CBC,
AES-GCM
Symmetric AES key for
encrypting TLS.
128 and
256 bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
TLS Integrity Key HMAC Used for TLS integrity
protection.
160-384
bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
TLS ECDSA private key ECDSA P-256 and P-384
generated by calling the
SP 800-90A CTR-
DRBG.
P-256
and P-
384
SDRAM
(plaintext)
‘switchconfig
key-zeroize
controller’
command or
Power cycle
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
22
Key/CSP Name
Generation
/ Algorithm Description
Key
Size Storage Zeroization
Infrastructure MFP MIC Key AES-CMAC,
AES-GMAC
This key is generated in
the module by calling
FIPS approved DRBG
and then is transported
to the Access Point
(AP) protected by
DTLS
Encryption/Decryption
Key. The Access Point
(AP) uses this key with
sign management
frames when
infrastructure MFP is
enabled.
128 and
256 bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
802.11
802.11 Pre-Shared Key (PSK) Shared secret This is the shared secret
used for 802.11 client
authentication.
63 bytes Flash Overwrite with
new secret.
802.11 Pairwise Master Key
(PMK)
HMAC The PMK is transferred
to the module, protected
by RADIUS AES
KeyWrap key. Used to
derive the Pairwise
Transient Key (PTK)
for 802.11
communications
160-384
bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
802.11 Key Confirmation Key
(KCK)
HMAC The KCK is used by
IEEE 802.11 to provide
data origin authenticity
in the 4-Way
Handshake and Group
Key Handshake
messages.
160-384
bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
802.11 Key Encryption Key (KEK) AES Key Wrap The KEK is used by the
EAPOL-Key frames to
provide confidentiality
in the 4-Way
Handshake and Group
Key Handshake
messages.
128 and
256 bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
23
Key/CSP Name
Generation
/ Algorithm Description
Key
Size Storage Zeroization
802.11 Pairwise Transient Key
(PTK)
AES-CCM,
AES-GCM
The PTK is the 802.11
session key for unicast
communications. This
key is derived using the
SP 800-108 KDF from
the PMK and then is
transported into the
Access Point (AP)
protected by DTLS
Encryption/Decryption
Key. The Access Point
(AP) uses this key with
AES-CCM function to
implement 802.11
unicast communications
service.
128 and
256 bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
802.11 Group Temporal Key
(GTK)
AES-CCM,
AES-GCM
The GTK is the 802.11
session key for
broadcast
communications. This
key is generated in the
module by calling FIPS
approved DRBG and
then is transported into
the Access Point (AP)
protected by DTLS
Encryption/Decryption
Key. The Access Point
(AP) uses this key with
AES-CCM function to
implement 802.11
broadcast
communications
service.
128 and
256 bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
RADIUS AES KeyWrap KEK AES-ECB This key is used by the
RADIUS Keywrap
service to protect the
PMK for the 802.11
protocol.
16 bytes SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
RADIUS KeyWrap MACK HMAC-SHA1 The MAC key used by
the RADIUS Keywrap
service to authenticate
RADIUS traffic.
16 bytes SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
SSHv2
SSH Encryption Key AES-CBC,
AES-GCM
Symmetric AES key for
encrypting SSH.
128 and
256 bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
24
Key/CSP Name
Generation
/ Algorithm Description
Key
Size Storage Zeroization
SSH Integrity Key HMAC Used for SSH integrity
protection.
160-384
bits
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
SSH ECDSA Private Key ECDSA P-256 and P-384
generated by calling the
SP 800-90A CTR-
DRBG.
P-256
and P-
384
SDRAM ‘switchconfig
key-zeroize
controller’
command or
Power cycle
Cryptographic Keys and CSPs
Note 1 to table: The KDF infrastructure used in DTLS v1.0/1.2 is identical to the ones used in
TLS v1.0/1.1/1.2, which was certified by CVL Cert. #1115.
Note 2 to table: The module meets IG A.5 for TLS, IKE and 802.11 protocols.
2.8 Self-Tests
The modules include an array of self-tests that are run during startup and periodically during
operations to prevent any secure data from being released and to insure all components are
functioning correctly.
Power On Self-Tests Performed:
• Firmware Integrity Test RSA 2048
• CiscoSSL FOM algorithm implementation
o AES encryption KAT
o AES decryption KAT
o AES GCM encryption KAT
o AES GCM decryption KAT
o SHA-1 KAT
o SHA-256 KAT
o SHA-384 KAT
o HMAC SHA-1 KAT
o HMAC SHA-256 KAT
o HMAC SHA-384 KAT
o ECDSA KAT
o ECDH KAT
o RSA sign and verify KATs
o SP 800-90A DRBG KAT
o SP 800-90A Section 11 Health Tests
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
25
• CN56xx algorithm implementation (2504/8510)
o AES encryption KAT
o AES decryption KAT
o SHA-1 KAT
o HMAC SHA-1 KAT
• CN68xx algorithm implementation (5520/8540)
o AES encryption KAT
o AES decryption KAT
o SHA-1 KAT
o HMAC SHA-1 KAT
o HMAC SHA-256 KAT
The module performs all power-on self-tests automatically at boot. All power-on self-tests must
be passed before a role can perform services. The power-on self-tests are performed after the
cryptographic systems are initialized but prior to the initialization of the LAN’s interfaces; this
prevents the module from passing any data during a power-on self-test failure.
Conditional Tests Performed:
o Continuous Random Number Generator Test for the FIPS-approved DRBG
o Continuous Random Number Generator Test for the non-approved NDRNG
o ECDSA pairwise consistency test
o RSA pairwise consistency test
3 Secure Operation
Cisco Systems 2504, 5520, 8510 and 8540 Wireless LAN Controllers meet all the Level 1
requirements for FIPS 140-2 once configured as a FIPS 140-2 compliant module. The Cisco
Systems 2504, 5520, 8510 and 8540 Wireless LAN Controllers are shipped only to authorized
operators by the vendor, and the devices are shipped in Cisco boxes with Cisco adhesive, so if
tampered with the recipient will notice. Follow the setting instructions provided below to place
the module in a FIPS-approved mode. Operating this module without maintaining the following
settings will remove the module from the FIPS approved mode of operation.
It should also be noted that the Cisco Systems 2504, 5520, 8510 and 8540 Wireless LAN
Controllers are shipped to the customer site without the FIPS compliant firmware pre-installed
on the device. This means that the module arrives at the customer in a non-compliant state until
such time as the Crypto Officer has performed the following steps:
• downloaded the module’s correct FIPS firmware image
(via a secure method from https://software.cisco.com/)
• verified the integrity of the firmware image file
(by calculating an MD5 or a SHA512 checksum value of the downloaded image file and
comparing it with values provided on the Cisco download page),
• installed the firmware onto the module, and
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
26
• has performed all of the correct initialization steps (see below) after which time the
module will then be in a FIPS compliant state.
Only after a successful completion of all required FIPS POSTs in the FIPS compliant state, will
the module be considered to be in a FIPS validated module.
The module was validated with firmware version 8.3 with Cisco FOM 6.0 and CN56xx Datapath
(This is the only allowable firmware image for a FIPS validated module.). Follow the setting
instructions provided below to configure the device as a FIPS validated module. Operating the
module without maintaining the following settings will remove the module as a FIPS validated
module.
The Crypto Officer must configure and enforce the following initialization steps:
1. Enable the FIPS validated module
The following CLI command places the controller in a FIPS validated module, enabling
all necessary self-tests:
> config switchconfig fips-prerequisite enable
2. Configure HTTPS Certificate
The following command configures the controller to use the manufacture-installed Cisco
device certificate for the HTTPS server. It must be executed after enabling FIPS validated
module:
> config certificate use-device-certificate webadmin
3. Configure Authentication Data
All users shall have a password containing 8 or more characters, including numbers and
letters. A crypto officer can use the following CLI command to set user passwords:
>config mgmtuser password username password read-write
Note that this and all subsequent configuration steps may also be performed through
HTTPS. However, only the CLI commands are included in this document. It is the
Crypto Officer’s responsibility to securely deliver the password over to User.
4. Configure Communications with RADIUS
Communications between the controller and RADIUS may be configured for RADIUS
KeyWrap or IPSec.
5. RADIUS KeyWrap and MACK Keys
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
27
The following CLI commands configure the RADIUS secret and AES-key wrap KEK
and MACK:
> config radius auth add index ip-address port hex secret
> config radius auth keywrap add hex kek mack index
> config radius auth keywrap enable
6. IPSec/IKE
Optionally, the controller may be configured to communicate with RADIUS via
IPSec/IKE. Refer to the document at the following link for additional instructions:
http://www.cisco.com/en/US/products/ps6366/products_tech_note09186a0080a829b8.shtml
In addition, please be aware that AES is the only allowed symmetric algorithm used in
IPSec/IKE encryption/decryption operations in the FIPS validated module.
7. Configure Pre-shared Keys for 802.11
802.11 Pre-shared key (PSK) is an optional mode permitted by this security policy.
Generation of this key is outside the scope of this security policy, but it should be 64
hexadecimal values (256 bits) and entered by Crypto Officer using the following
commands:
> config wlan security wpa akm psk enable index
> config wlan security wpa akm psk set-key hex key index
Refer to Cisco Wireless LAN Controller Configuration Guide for additional instructions.
8. Configure Ciphersuites for 802.11
The following CLI commands create a wireless LAN, configure it to use WPA2,
associate it with a RADIUS server, and enable it:
> config wlan create index profile_name ssid
> config wlan radius_server auth add index radius-server-index
> config wlan enable index
9. Configure SNMPv3
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
28
Only SNMPv3 with HMAC-SHA-1 is permitted by this security policy. The user
passwords shall be selected to be 8 or more characters, including numbers and
letters. This has been tested and is FIPS compliant.
The following CLI commands enable SNMPv3 with HMAC-SHA1:
> config snmp version v1 disable
> config snmp version v2c disable
> config snmp version v3 enable
> config snmp v3user create username <ro|rw> hmacsha aescfb128 authkey
encryptkey
10. Configure TACACS+ secret
The crypto officer may configure the module to use TACACS+ for authentication,
authorization and accounting. Configuring the module to use TACACS+ is
optional. If the module is configured to use TACACS+, the Crypto-Officer must
define TACACS+ shared secret keys that are at least 8 characters long. The
following CLI command configures TACACS+ for authentication (auth),
authorization (athr) and accounting (acct):
config tacacs <auth|athr|acct> add index ip port <ascii|hex> secret
Refer to the Cisco Wireless LAN Controller Configuration Guide for additional
instructions.
11. Configure Data DTLS (optional)
The crypto officer may configure the module to use CAPWAP data encryption.
CAPWAP data packets encapsulate forwarded wireless frames. Configuring the
module to use CAPWAP data encryption is optional.
The following CLI commands enable DTLS data encryption for access points on
the controller:
To enable or disable data encryption for all access points or a specific access
point, enter this command:
a. config ap link-encryption {enable | disable} {all | Cisco_AP}
When prompted to confirm that you want to disconnect the access point(s) and
attached client(s), enter
b. >Y
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
29
To save your changes, enter this command:
c. save config
Refer to the Cisco Wireless LAN Controller Configuration Guide for additional
instructions.
12. Save and Reboot
After executing the above commands, you must save the configuration and reboot the
system:
a. save config
b. reset system
Once these configuration steps are completed, it is the responsibility of the CO to ensure the
module only uses Approved algorithms and services to keep the module in a FIPS Approved
mode of operation. Using any of the non-approved algorithms and services switches the module
to a non-FIPS mode of operation. Prior to switching between modes the CO should ensure all
keys and CSPs are zeroized to prevent sharing of keys and CSPs between FIPS Approved and
non-FIPS mode of operation.
© Copyright 2017 Cisco Systems, Inc.
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
30