Cisco Converged Access Configuration Guide

Cisco Converged Access Configuration Guide
Cisco Converged Access
Configuration Guide
Preparative Procedures and Operational Guidance
for the Common Criteria Certified Configuration
Version 0.9
May 28, 2015
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
Table of Contents
1
INTRODUCTION ............................................................................................................................... 5
1.1
AUDIENCE ......................................................................................................................................... 5
1.2
PURPOSE ............................................................................................................................................ 5
1.3
DOCUMENTATION REFERENCES......................................................................................................... 5
2
EVALUATED CONFIGURATION COMPONENTS ..................................................................... 7
2.1
SUPPORTED HARDWARE/SOFTWARE ................................................................................................. 7
2.2
IDENTIFYING THE EVALUATED HARDWARE AND SOFTWARE............................................................. 7
2.3
SUPPORTED NON-TOE HARDWARE/SOFTWARE/FIRMWARE .............................................................. 8
2.4
PREPARATIVE PROCEDURES AND OPERATIONAL GUIDANCE FOR IT ENVIRONMENT ......................... 9
2.5
INSTALL AND CONFIGURE A RADIUS SERVER (CISCO ISE OR CISCO ACS)...................................... 9
2.5.1
Enable RADIUS Key Wrap .................................................................................................... 10
2.5.2
Optional: Configuring TACACS+ for Accounting ................................................................ 10
2.6
INSTALL AND CONFIGURE A SYSLOG SERVER.................................................................................. 10
2.7
OPTIONAL: INSTALL CISCO PRIME INFRASTRUCTURE SERVER FOR CENTRALIZED MANAGEMENT ... 10
2.8
OPTIONAL: INSTALL MOBILITY SERVICES ENGINE (MSE) FOR LOCATION TRACKING AND WIPS .... 11
3
PREPARATIVE PROCEDURES AND OPERATIONAL GUIDANCE FOR THE TOE ......... 11
3.1
GENERAL GUIDANCE ....................................................................................................................... 11
3.1.1
Roles and Privileges for Administrator and Wireless User Accounts ................................... 11
3.1.2
Programmatic accounts: ....................................................................................................... 11
3.1.3
Password Length and Complexity ......................................................................................... 12
3.1.4
Other Cryptographic Engines ............................................................................................... 12
3.2
INSTALL THE WLAN CONTROLLERS ............................................................................................... 12
3.3
CONFIGURE THE WLAN CONTROLLERS .......................................................................................... 12
2
3.3.1
Configure local AAA authentication...................................................................................... 13
3.3.3
Administrator Credentials ..................................................................................................... 13
3.3.4
Store password and keys in encrypted form .......................................................................... 13
3.3.5
Configure the Login Banner .................................................................................................. 13
3.3.6
Disable the Controller WebUI............................................................................................... 14
3.3.7
Configure SSH for Remote Access to the Controller CLI ...................................................... 14
3.3.8
Configure the Controller Time and Date .............................................................................. 15
3.3.9
Configure Logging to a Syslog Server ................................................................................... 15
3.3.10
Defining Logging Discriminators to Drop or Include Certain Messages ........................ 16
3.3.11
Configuring Other Logging Parameters ........................................................................... 19
3.3.12
Configuring multiple RADIUS Servers ............................................................................. 21
3.3.13
Configuring WPA2-Dot1X WLAN .................................................................................... 21
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
3.3.14
Configuring WPA2-PSK WLAN ....................................................................................... 22
3.3.15
Configuring 802.11w WLAN ............................................................................................ 22
3.3.16
Configuring 802.11r WLAN.............................................................................................. 22
3.3.17
Configure attributes to deny a wireless session ................................................................ 22
3.3.18
Optional: Configure the Controller Programmatic Interfaces ........................................ 23
3.4
INSTALL AND CONFIGURE ACCESS POINTS ...................................................................................... 24
3.5
VERIFYING INSTALLATION OF THE EVALUATED SOFTWARE VERSION ............................................. 25
4
3.5.1
Displaying Version Information ............................................................................................ 25
3.5.2
Confirming Image Integrity ................................................................................................... 25
SECURE MANAGEMENT .............................................................................................................. 25
4.1
IPSEC OVERVIEW............................................................................................................................. 25
4.2
IKEV2 TRANSFORM SETS ................................................................................................................ 27
4.3
CONFIGURE IPSEC TUNNELING OF RADIUS, SYSLOG, AND NTP .................................................... 28
4.3.1
Example IPsec Configuration from IOS to IOS using Pre-shared Keys................................ 29
4.3.2
Example IPsec Configuration from IOS to IOS using X509 Certificates .............................. 31
4.4
OPTIONAL: CONFIGURING IPSEC TUNNELING OF SNMPV3 TRAFFIC TO MANAGEMENT SERVER.... 33
4.5
X.509 CERTIFICATES ....................................................................................................................... 34
4.5.1
Storing Certificates to a Local Storage Location .................................................................. 34
4.5.2
How to Specify a Local Storage Location for Certificates .................................................... 34
4.5.3
Configuring a Revocation Mechanism for PKI Certificate Status Checking......................... 35
4.5.4
Manually Overriding the OCSP Server Setting in a Certificate ............................................ 35
4.5.5
Configuring Certificate Chain Validation ............................................................................. 36
4.5.6
Setting X.509 for use with IKE .............................................................................................. 36
4.5.7
IPsec Session Interruption/Recovery ..................................................................................... 36
4.6
OPTIONAL: CONFIGURING CISCO MOBILITY SERVICES ENGINE ...................................................... 37
4.7
OPTIONAL: CONFIGURE THE MANAGEMENT SERVER AS RECIPIENT OF SNMP TRAP OPERATIONS .. 37
4.8
CONFIGURE SECURE COPY OPERATIONS ......................................................................................... 37
4.8.1
Copying Files to or from IOS using the IOS CLI .................................................................. 37
4.8.2
(Optional) Enabling the SCP Server on IOS ......................................................................... 38
4.9
5
(OPTIONAL) NETWORK ADDRESS TRANSLATION TRAVERSAL (NAT-T) ......................................... 38
SECURITY RELEVANT EVENTS ................................................................................................. 38
5.1
DELETING AUDIT RECORDS ............................................................................................................. 39
5.2
AUDIT RECORDS DESCRIPTION ........................................................................................................ 39
6
NETWORK SERVICES AND PROTOCOLS................................................................................ 51
7
MODES OF OPERATION ............................................................................................................... 53
7.1
CONTROLLER MODES ...................................................................................................................... 53
7.2
AP MODES....................................................................................................................................... 53
3
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
8
SECURITY MEASURES FOR THE OPERATIONAL ENVIRONMENT................................. 54
9
RELATED DOCUMENTATION .................................................................................................... 54
Document Introduction
This document describes the installation, generation, and start-up procedures for the Cisco
Wireless Local Area Network Access System (WLAN) configuration evaluated under Common
Criteria.
Copyright 2015, Cisco Systems, Inc.
4
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
1 Introduction
This operational and preparative procedures guide documents the procedures and parameters
required for secure configuration and administration of the Cisco Wireless Local Area Network
Access System (WLAN) configuration evaluated under Common Criteria (CC).
The hardware and software included within the scope of this evaluation are detailed below in
section 2. This CC-evaluated WLAN solution is a multiple component solution composed of
Cisco products that are configured in a manner consistent with this document to satisfy the
requirements of the US Government Protection Profile for Wireless Local Area Network
(WLAN) Access Systems (WLANPP) version 1.0, December 1, 2011 (pp_wlan_as_v1.0.pdf).
1.1 Audience
This document is written for users of the Cisco WLAN solution. This document assumes that you
are familiar with the basic concepts and terminology used in internetworking, understand your
network topology and the protocols that the devices in your network can use, that you are a
trusted individual, and that you are trained to use the systems on which you are running the Cisco
WLAN solution.
1.2 Purpose
This document is the supplemental preparative and operational guidance for the Common Criteria
certification. It has been written to highlight the specific WLAN functions and interfaces that are
necessary to maintain the Cisco WLAN in the evaluated configuration. This document is not
meant to detail specific actions performed by the WLAN administrators but rather is a road map
for identifying the appropriate locations within Cisco documentation to get the specific details for
maintaining and employing Cisco WLAN operations.
1.3 Documentation References
This document makes reference to individual documents as needed by indicating the reference
number in brackets (e.g., [WLC1]). All of the referenced documents are downloadable from
www.cisco.com. Hardcopies are not provided with the product shipment.
Installation and Configuration Guides are generally included as part of a Cisco product delivery.
Since there are several components in this evaluation, it may be necessary for an administrator to
seek out additional documents listed below. The documents listed below are specific to the
evaluated configuration. When creating the evaluated configuration, the administrator must
verify that they are using the correct guide for the correct version of each component. The
documents listed below are available at www.cisco.com with the exception of the FIPS Security
Policy, which is publicly accessible via the FIPS website at
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm.
Table 1: Reference Documentation
[WLC1]
WLAN Controllers
Available at Cisco.com unless
otherwise noted
Release Notes for Catalyst 3650 Series Switch, Cisco
IOS XE Release 3.6.0E
3650: OL3264702.pdf
3850: 3dot7e-3850.pdf
Release Notes for Catalyst 3850 Series Switch, Cisco
5
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
IOS XE Release 3.6.0E
5760: OL32726.pdf
Release Notes for Cisco 5700 Series Wireless LAN
Controller, Cisco IOS XE Release 3.6.0E
[WLC2]
[WLC3]
[WLC4]
Catalyst 3650 Switch Hardware Installation Guide
Cat3650hig_book.pdf
Catalyst 3850 Switch Hardware Installation Guide
3850_hig.pdf
Cisco 5700 Series Wireless Controller Installation Guide
ctrl5760.pdf
Catalyst 3650 Switch Getting Started Guide
cat3650_gsg.pdf
Catalyst 3850 Switch Getting Started Guide
cat3850_gsg.pdf
CT5760 Controller Deployment Guide
CT5760_Controller_Deployment_
Guide.pdf
Consolidated Platform Configuration Guide, Cisco IOS
XE 3.3SE (Catalyst 3650 Switches)
b_consolidated_3650_3se_cg.pdf
Consolidated Platform Configuration Guide, Cisco IOS
XE 3.3SE (Catalyst 3850 Switches)
b_consolidated_3850_3se_cg.pdf
b_multi_3se_5700_cg.pdf
Consolidated Platform Configuration Guide, Cisco IOS
XE Release 3.3SE (Cisco WLC 5700 Series)
[WLC5]
Basic System Management Command Reference, Cisco
IOS XE Release 3SE (Catalyst 3650 Switches)
Basic System Management Command Reference, Cisco
IOS XE Release 3SE (Catalyst 3850 Switches)
bsm-xe-3se-3650-cr-book.pdf
bsm-xe-3se-3850-cr-book.pdf
bsm-xe-3se-5700-cr-book.pdf
Basic System Management Command Reference, Cisco
IOS XE Release 3SE (Catalyst 5700 Switches)
[WLC6]
Network Management Configuration Guide Cisco IOS
XE Release 3E
Network Management
[WLC7]
Cisco IOS Security Command Reference: Commands D
to L
Cisco IOS Security Command
Reference: Commands D to L
[WLC8]
Public Key Infrastructure Configuration Guide
PKI Configuration Guide
WLAN Access Points
[AP1]
Cisco Aironet 1600/2600/3600 Series Access Point
Deployment Guide
Cisco_Aironet.pdf
1550hig.pdf
Cisco Aironet 1550 Series Outdoor Mesh Access Point
Hardware Installation Guide
FIPS Security Policies
[FIPS1]
FIPS 140-2 Security Policy for Cisco Catalyst 3650 and
3850
Security Policy
[FIPS2]
FIPS 140-2 Security Policy for Cisco 5760 Wireless
LAN Controller
Security Policy
6
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
FIPS 140-2 Security Policy for Cisco Aironet 1552,
1602, 2602, 3502, 3602, and 3702 Wireless LAN Access
Points & AP3600-series Aironet Access Point Modules
3000M and 3000AC PS 140-2 Security Policy for Cisco
Aironet 1552E Outdoor Access Points
[FIPS3]
(In coordination phase at CMVP)
ACS or ISE
Cisco Identity Services Engine (ISE) 1.2 or later physical or virtual appliance:
[AAA1]
http://www.cisco.com/en/US/products/ps11640/tsd_products_support_series_home.html
Cisco Secure Access Control System (ACS) 5.3 or later:
http://www.cisco.com/c/en/us/support/security/secure-access-control-system/tsd-products-support-serieshome.html
2 Evaluated Configuration Components
2.1 Supported Hardware/Software
The following table identifies the hardware and software supported in the Cisco WLAN evaluated
configuration.
1.
The following Cisco WLAN products comprise the Common Criteria evaluated
configuration: Wireless LAN Controllers, hereafter referred to as the Controllers or
WLC: Cisco Catalyst 3650, Cisco Catalyst 3850, and Cisco 5760 Wireless LAN
Controller.
2.
Wireless Access Points, hereafter referred to as the AP: Cisco Aironet 1552e, 1600e,
1600i, 2600e, 2600i, 3500e, 3500i, 3600e, 3600i.
The following products support the Common Criteria evaluated security functionality of the
Cisco WLAN System:
3.
Cisco Secure Access Control Server (ACS) version 5.3 or later, or Cisco Identity
Services Engine (ISE) version 1.1 or later.
4.
Syslog server software that supports receiving syslog over TLS, supports filtering of
messages upon receipt prior to storage, and supports searching and sorting of stored
messages. Compatible syslog server options include, but are not necessarily limited to:
Kiwi Syslog Server release 9.2 or later; or syslog-ng release 2.0 or later.
2.2 Identifying the Evaluated Hardware and Software
All WLAN Controller and AP models will be labeled with the model number as listed above.
Hardware will be delivered in boxes labeled with the Cisco name and logo, and boxes will be
sealed with tamper-evident tape with the Cisco name and logo.
Software images downloaded from Cisco.com would have filenames consistent with those in the
following list. Note the Cisco Converged Access controller will perform a SHA-1 integrity check
during installation of the image. See section 3.5.2.
Hardware Models
Hardware Part Number
Software Filenames
Catalyst 3650
WS-C3650-24TS
WS-C3650-48TS
WS-C3650-24PS
cat3k_caa-universalk9.SPA.03.06.01.E.152-2.E1.bin
7
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Catalyst 3850
Controller 5760
(The number after
CT5760 indicates
licensing.)
AP 1552
(The “x” in AP part
numbers is
substituted with
regulatory domain
code for radio
frequencies.)
AP 1600e, 1600i
AP 2600e, 2600i
AP 3500e, 3500i
AP 3600e, 3600i
WS-C3650-48PS
WS-C3650-48FS
WS-C3650-24TD
WS-C3650-48TD
WS-C3650-24PD
WS-C3650-48PD
WS-C3650-48FD
WS-C3650-48TQ
WS-C3650-48PQ
WS-C3650-48FQ
WS-C3850-24T-S
WS-C3850-48T-S
WS-C3850-24P-S
WS-C3850-48P-S
WS-C3850-24F-S
WS-C3850-24T-E
WS-C3850-48T-E
WS-C3850-24P-E
WS-C3850-48P-E
WS-C3850-48F-E
AIR-CT5760-25-K9
AIR-CT5760-50-K9
AIR-CT5760-100-K9
AIR-CT5760-250-K9
AIR-CT5760-500-K9
AIR-CT5760-1k-K9
AIR-CT5760-HA-K9
AIR-CAP1552E-x-K9
AIR-CAP1552EU-x-K9
AIR-CAP1552C-x-K9
AIR-CAP1552CU-x-K9
AIR-CAP1552H-x-K9
AIR-CAP1552I-x-K9
AIR-CAP1602I-x-K9
AIR-SAP1602I-x-K9
AIR-CAP1602E-x-K9
AIR-SAP1602E-x-K9
AIR-CAP2602I-x-K9
AIR-SAP2602I-x-K9
AIR-CAP2602E-x-K9
AIR-SAP2602E-x-K9
AIR-CAP3502I-x-K9
AIR-CAP3501I-x-K9
AIR-CAP3502E-x-K9
AIR-CAP3501E-x-K9
AIR-CAP3602I-x-K9
AIR-CAP3602E-x-K9
cat3k_caa-universalk9.SPA.03.06.01.E.152-2.E1.bin
ct5760-ipservicesk9.SPA.03.06.01.E.152-2.E1.bin
Bundled in controller image.
Bundled in controller image.
Bundled in controller image.
Bundled in controller image.
Bundled in controller image.
2.3 Supported non-TOE Hardware/Software/Firmware
The TOE supports (in some cases optionally) the following hardware, software, and firmware in
its environment:
Table 2 Operational Environment Components
Component
RADIUS Server
8
Required
Yes
Usage/Purpose Description for TOE performance
Required for Wireless client authentication and optional administrator
authentication to the Web GUI on the Wireless Controller.
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Component
Syslog Server
Required
Yes
NTP Server
No
Cisco Prime
Infrastructure
Cisco Mobility
Services Engine
Certification
Authority
No
Local Console
Yes
Management
Workstation with
SSH Client
Yes
Management
Workstation with
TLS Client
No
No
No
Usage/Purpose Description for TOE performance
This includes any syslog server to which the TOE would transmit system
messages.
An NTP server is to maintain an accurate time and synchronize time
across different time zones. This ensures audit records in the audit logs
provide a reliable timestamp.
Provides centralized management of multiple controllers and APs across
the wireless enterprise.
Provides location tracking of wireless devices and wireless intrusion
detection/prevention (wIDS/wIPS)
This includes any IT Environment Certification Authority on the TOE
network. This can be used to provide the TOE with a valid certificate
during certificate enrollment.
This includes any IT Environment Console that is directly connected to
the TOE via the Serial Console Port and is used by the TOE administrator
to support TOE administration.
This includes any IT Environment Management workstation with a SSH
client installed that is used by the TOE administrator to support TOE
administration through SSH protected channels. Any SSH client that
supports SSHv2 may be used. Note: To enforce the required AES-CBC
128 bit or AES-CBC 256 bit cipher requirement and SHA macs when
connecting to the TOE, the SSH client must request these algorithms.
This includes any IT Environment Management workstation with a web
browser client installed that is used by the TOE administrator to support
TOE administration through TLS protected channels.
2.4 Preparative Procedures and Operational Guidance for IT
Environment
Install and configure a RADIUS server (Cisco ISE or Cisco ACS)
Install and configure the Syslog server
Optional: Install Cisco Prime Infrastructure server for centralized management.
Optional: Install Cisco Mobility Services Engine (MSE) for location tracking and
mobility analytics.
2.5 Install and Configure a RADIUS server (Cisco ISE or Cisco ACS)
Install Cisco Secure ACS v5.3 (or later), or Cisco ISE 1.1 (or later) in accordance with
installation guides and release notes appropriate for the ACS and ISE versions to be installed
[AAA1].
Configure the RADIUS Server to Accept Requests from the Controllers The RADIUS server
(Cisco Secure ACS or ISE) is used to authenticate wireless clients and optionally to authenticate
Controller administrators. The same RADIUS servers can optionally be used to authenticate
Administrators connecting to Prime Infrastructure (MSE is managed via Prime Infrastructure).
Each Controller must be configured as a RADIUS client in ACS or ISE, and uniquely identified
by its IP address and shared secret. RADIUS shared secrets used between the ACS/ISE and each
other component in the WLAN system (each RADIUS client) must be identical and be in the
same format (hex). Different shared keys can be used between the ACS/ISE and each of its
RADIUS clients.
9
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
When ISE is used as the RADIUS server for the Controller(s), the wireless client accounts can be
defined within ISE, but ISE must be configured to defer (proxy) authentication of Controller
Administrators to a separate (second-tier) authentication server that is able to enforce lockout
after failed login attempts. Those second-tier authentication servers could include Active
Directory, LDAP, or an ACS server. Refer to “Defining an External RADIUS Server” in the ISE
User Guide.
Refer to the ISE and ACS guidance documentation for how to define Controllers, Wireless
Clients, and WCS/NCS within ISE or ACS.
2.5.1 Enable RADIUS Key Wrap
Refer to the User Guide for ACS or ISE to enable RADIUS Key Wrap using AES [AAA1].
2.5.2
Optional: Configuring TACACS+ for Accounting
The AAA server can also have a TACACS+ server created for accounting purposes. To
configure TACACS+ accounting, refer to “Configuring TACACS+ Settings” in the ACS or ISE
User Guide [AAA1].
2.6 Install and Configure a Syslog Server
Any syslog server can be used as long as it provides the following functions:
Can be accessed over TLS
Provides filtering options to filter messages upon receipt, prior to local storage;
Provides the ability to search and sort messages; and
Installs to a host operating system configured to protect stored messages from
unauthorized modification or deletion.
Known compatible syslog servers include Kiwi Syslog Server release 9.2 or later; or syslog-ng
release 2.0 or later. Only one syslog server is required.
•
Kiwi Syslog Server software, installation instructions and guidance can be obtained
from: http://www.kiwisyslog.com/
•
Syslog-ng software, installation instructions and guidance can be obtained from:
http://www.balabit.com/network-security/syslog-ng
Install the syslog server per installation instructions provided with the syslog server software.
Configure the host operating system to restrict access to syslog data to authorized personnel only.
Configure the system to accept inbound syslog over a TLS from each WLAN Controller.
2.7 Optional: Install Cisco Prime Infrastructure server for centralized
management
The TOE is capable of being managed by an external IT entity such as Cisco Prime Infrastructure
using SNMPv3 over an IPsec tunnel provided by the TOE.
If the TOE is configured to be managed by Cisco PI using SNMPv3 over IPsec, install Cisco
Prime Infrastructure following the Hardware Installation Guide.
10
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
2.8 Optional: Install Mobility Services Engine (MSE) for location
tracking and wIPS
The TOE is capable of providing advanced location tracking and mobility analytics. If the TOE
is configured to provide this, install the Cisco Mobility Services Engine (MSE).
Refer to the “Installation and Initial Configuration” section of the Cisco 3355 Mobility Services
Engine Getting Started Guide for installation and initial configuration.
3 Preparative Procedures and Operational Guidance for the
TOE
This guidance document is a supplement to the following list of Cisco product documentation.
This document makes reference to individual documents as needed by indicating the reference
number in brackets (e.g., [WLC1]). This Cisco WLAN solution combines WLAN Controllers
and Access Points. Once the Access Points are joined with a Controller, the APs are managed via
the administrative interfaces of the Controller, and administrative interfaces on the AP are
disabled. In the sections below, installation instructions are provided to bring each of the WLAN
system components from their default settings into the Common Criteria evaluated configuration.
For best results, the components of the Cisco WLAN system and the supporting components of
the operational environment should be installed and configured in sequence outlined in this
document. Perform installation and configuration procedures of Section 3 in the following order:
Install and configure one or more WLAN Controllers
Install and configure Wireless Access Points
3.1 General Guidance
3.1.1 Roles and Privileges for Administrator and Wireless User Accounts
3.1.1.1 Administrative accounts:
The controllers maintain one type of administrative roles: Administrative accounts (assigned to
human users for access to interactive administrative interfaces)
•
Administrators connect to the Controller through the serial console, or SSH (the WebUI
GUI, which would be accessible via TLS, remains disabled in the CC-certified
configuration). Administrative accounts can be assigned to a privilege level to restrict
which commands are accessible, but all human users with valid passwords are considered
‘administrators’.
3.1.1.2 Non-administrative accounts:
Wireless user accounts have no administrative access to the WLAN system.
3.1.2 Programmatic accounts:
The TOE is capable of being managed by an external IT entity (PI or NCS) using SNMPv3 over
an IPsec tunnel provided by the TOE. SNMPv3 accounts are not considered administrative roles
since SNMPv3 is not an interactive interface. Refer to section 3.8
11
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
3.1.3 Password Length and Complexity
Administrators must ensure that all administrative and user passwords contain a minimum of 8
characters. Administrators must also define one or more “aaa common-criteria policy” and apply
a policy to each local account to ensure that new passwords must contain characters from at least
3 different classes of the four available classes: lower case letters, upper case letters, digits, and
special characters. Administrators should select passwords that do not contain dictionary words.
Usernames and passwords are case-sensitive and can contain up to 24 ASCII characters.
WPA2 uses 802.1X for authenticated key management by default however, it’s an option to use
of PSK (also known as WPA preshared key or WPA passphrase). When using PSK, a preshared
key (or a passphrase) needs to be set. This key is used as the pairwise master key (PMK) between
the clients and the authentication server. For greatest security, the PSK should be set to the
maximum allowable size of 63 ASCII text characters or 64 hexadecimal characters.
3.1.4
Other Cryptographic Engines
WARNING: Use of other cryptographic engines such as HTTPS are not evaluated nor tested
during the CC evaluation of the TOE. The HTTPS (Web GUI) server is to be disabled per the
guidance in section 3.3.6 below.
3.2 Install the WLAN Controllers
3.2.1.1 Install the Catalyst 3650 or 3850 Controllers
3.2.1.2 Initial Controller Start-up Procedures
The Controllers must be installed according to the instructions found in the Hardware Installation
Guide [WLC2], and the Getting Started Guide [WLC3].
3.2.1.3 FIPS 140-2 Configuration
The Controller is a FIPS validated cryptographic device, and as such there are specific FIPS
installation and configuration guidelines that must be followed for the device to be in the FIPS
validated configuration. Follow the instructions in the FIPS 140-2 Security Policy [FIPS1].
3.2.1.4 Install the 5760 Wireless LAN Controllers
3.2.1.5 Initial Controller Start-up Procedures
The Controllers must be installed according to the instructions found in the Controller Installation
Guide [WLC2], and the Deployment Guide [WLC3].
3.2.1.6 FIPS 140-2 Configuration
The 5508 WLAN Controller is a FIPS validated cryptographic device, and as such there are
specific FIPS installation and configuration guidelines that must be followed for the device to be
in the FIPS validated configuration. Follow the instructions in the FIPS 140-2 Security Policy
[FIPS2].
3.3 Configure the WLAN Controllers
The following guidance applies to all models of Controllers, 3650, 3850, and 5760. These
procedures should be completed only after all previous installation steps for the Controller have
12
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
been successfully completed. In the CC-certified configuration, administration of Controllers
from wireless networks is prohibited. Remote administrative access to Controllers must access
the wired interfaces of the Controllers using SSH (for CLI access).
3.3.1
Configure local AAA authentication
Controller(config)#aaa new-model
Controller(config)#aaa authentication login default local
Controller(config)#aaa authorization exec default local
3.3.2
User Lockout
User accounts must be configured to lockout after a specified number of authentication failures
Controller(config)# aaa local authentication attemp
ts max-fail
number-of-unsuccessful-attempts
To Unlock a Locked-Out User
Controller(config)# clear aaa local user lockoutusername
Note: this lockout only applies to privilege 14 users and below.
Note: this applies to consecutive failures, and is not affected by the SSH or Telnet session
disconnections after their default number of failures. In other words, if this lockout command is
set to 5 failures, and SSH disconnects after 3 failed attempts, if the user attempts another SSH
session and enters the wrong credentials two additional times, the account will lock.
3.3.3 Administrator Credentials
The Controllers must be configured to use a username and password for each administrator and
one password for the enable command. When creating administrator accounts, all individual
accounts are to be set to a privilege level of one. This is done by using the following commands:
Controller(config)#username <name> password <password>
Controller(config)#username <name> privilege 1
3.3.4 Store password and keys in encrypted form
Enable encryption of username passwords stored in the local configuration file:
Controller(config)#service password-encryption
Enable encryption of pre-shared keys stored in the config file:
Controller(config)#key config-key password-encrypt[key]
Controller(config)#passwd encryption on
Controller(config)#passwd key obfuscate
Controller(config)#password encryption aes
3.3.5
Configure the Login Banner
The login banner is the text that appears on the page before user authentication when accessing
the controller CLI using either SSH, or a console port connection. To create a login banner for
use on a Controller, issue the following command with the desired banner text in quotes:
13
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Controller(config)#banner login “This is the loginbanner.”
3.3.6 Disable the Controller WebUI
Disable the IOS HTTP server:
Controller(config)#no ip http server
Disable the IOS HTTPS server:
Controller(config)#no ip http secure-server
3.3.7
Configure SSH for Remote Access to the Controller CLI
The following steps configure the Controller to use SSH for remote administration purposes:
o Generate RSA key material – choose a longer modulus length for more secure keys
(i.e. 2048 for RSA):
Controller(config)#crypto key generate rsa
Controller(config)#How many bits in the modulus [512]: 2048
RSA keys are generated in pairs—one public key and one private key. This command is not
saved in the router configuration; however, the keys generated by this command are saved in the
private configuration in NVRAM (which is never displayed to the user or backed up to another
device) the next time the configuration is written to NVRAM.
Note: Only one set of keys can be configured using the crypto key generate command at a time.
Repeating the command overwrites the old keys.
Note: If the configuration is not saved to NVRAM with a “copy run start”, the generated keys
are lost on the next reload of the router.
Note: If the error “% Please define a domain-name first” is received, enter the command ‘ip
domain-name [domain name]’.
o Enable SSH v2
Controller(config)#ip ssh version 2
Controller(config)#ip ssh authentication-retries2
o Configure SSH timeout
Controller(config)#ip ssh time-out 60
o Ensure that the product is configured to use only Diffie-Hellman Group 14 (diffiehellman-group14-sha1) key exchange using the following command ‘ip ssh dh min
size 2048’:
Controller(config)#ip ssh dh min size 2048
o Configure vty lines to accept ‘ssh’ login services
Controller(config)#line vty 0 4
Controller(config-line)# transport input ssh
Note that the above disables telnet for management purposes in the evaluated configuration.
14
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
When SSH version 2 is enabled the Controller will support AES-CBC-128, and AES-CBC256, both of which are permitted in the certified configuration. The Controller will also
negotiate sessions using 3DES-CBC, which is not recommended for use in the certified
configuration, though it is approved for use in the FIPS validated configuration. Since
security-relevant use of the SSH connection only occurs after the session parameters are
negotiated (when authentication parameters are being exchanged during login, and after
successful authentication), Controller administrators configure their SSH clients to either:
not establish connections using 3DES-CBC; or
warn about potential use of 3DES-CBC, at which point the administrator must reject the
session and reconfigure the client, or use a different client.
To configure a Linux-based SSH client to support only the following specific encryption
algorithms AES-CBC-128 and AES-CBC-256 the following commands can be used:
peer#ssh -l cisco -c aes128-cbc 1.1.1.1
peer#ssh -l cisco -c aes256-cbc 1.1.1.1
Configure a SSH client to support message authentication. Only the following MACs are
allowed and “None” for MAC is not allowed:
hmac-sha1
hmac-sha1-96
peer#ssh -l cisco -m hmac-sha1-160 1.1.1.1
peer#ssh -l cisco -m hmac-sha1-96 1.1.1.1
To verify the proper encryption algorithms are used for established connections, use the show
ssh sessions command
Controller(config)#show ssh sessions
Note: To disconnect SSH sessions, use the ssh disconnect command:
Controller(config)#ssh disconnect
3.3.8
Configure the Controller Time and Date
In the CC-evaluated configuration, time updates to the Controller must be received over an
encrypted channel, such as IPsec. The Controller can be configured to use NTP over IPsec from
an NTP server, or to get clock updates via SNMPv3 over IPsec from a Prime Infrastructure
server. The APs will receive clock updates automatically from a Controller using CAPWAP over
DTLS. The Controller clock can also be set manually via the Controller CLI.
To configure ntp on the Controller, use the “ntp peer” command as described in [WLC5].
3.3.9
Configure Logging to a Syslog Server
Define the IP address of the remote syslog server and the level of syslog messages to be sent to
that server:
1. To configure the logs to be sent to a syslog server:
Controller (config)# logging host <ip address of syslog server>
Controller (config)# logging host 192.168.202.169
2. To specify the severity level for logging to the syslog host, use the logging trap
command. The standard syslog severity levels are:
15
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Emergencies = Severity level 0
Alerts = Severity level 1
Critical = Severity level 2
Errors = Severity level 3
Warnings = Severity level 4
Notifications = Severity level 5
Informational = Severity level 6
Debugging = Severity level 7
Error messages about software or hardware malfunctions are displayed at levels
warnings through emergencies. These types of messages mean that the functionality of
the TOE is affected.
Output from the debug commands are displayed at the debugging level.
Interface up or down transitions and system restart messages, displayed at the
notifications level. This message is only for information; switch functionality is not
affected.
Reload requests and low-process stack messages are displayed at the informational
level. This message is only for information.
A higher level increases the logging. Level 7 will send all logs required in the evaluation
up to the debug level logs to the syslog server. WARNING: A level 7 setting has the
ability to generate a large number of events that could affect the performance of your
device, network, and syslog host.
3.3.10 Defining Logging Discriminators to Drop or Include Certain Messages
Logging “discriminators” can be custom-defined as desired to ‘drop’ or ‘include’ messages based
on several attributes including the ‘mnemonics’ of the syslog message ID, or a string found
within the message body.
The following is an example of a system error message with its parts identified:
%LINK-2-BADVCALL: Interface [chars], undefined entry point
•
•
•
•
LINK is the facility code.
is the severity level.
BADVCALL is the mnemonic code.
"Interface [chars], undefined entry point" is the message text.
Multiple discriminators can be defined in the config file, but only one discriminator can be active
for each logging destination (e.g Console, Buffer, or Host). Note: To filter messages to a syslog
host, use the "logging host discriminator" command. Discriminators cannot be applied using the
"logging trap" command. The "logging trap" command can only be used so specify the
maximum severity level to be sent to all logging hosts.
Any one discriminator can be defined with a single filter, or multiple filters. When any one
discriminator includes multiple filter types (facility, severity, mnemonics, msg-body):
•
16
Each filter type can only be used once; and
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
•
•
To match the discriminator, the message must match *all* the filters within the
discriminator; and
If msg-body is used, the msg-body filter must be listed last because the string can
contain spaces; and
Sub-filters are checked in the following order. If a message is dropped by any of the sub-filters,
the remaining checks are skipped.
1. Severity level or levels specified
2. Facility within the message body that matches a regular expression
3. Mnemonic that matches a regular expression
4. Part of the body of a message that matches a regular expression
5. Rate-limit
Within any discriminator (containing single or multiple filter types):
•
•
•
•
Multiple facilities can be defined, separated by a "|"
o e.g. drops CDP|PARSER
Only one severity can be defined (use of "|" is not allowed)
Multiple mnemonics can be defined, separated by a "|"
o e.g. drops NATIVE|VLAN|MISMATCH
Multiple msg-body can be defined, separated by a "|"
o e.g. drops User:script|user\[script\]
Note: Use regular expression syntax with msg-body strings to 'escape' special characters as
needed.
To avoid stopping logging to any destination, modify the configuration for that logging
destination instead of using the "no logging" command. For example, to remove an active
logging discrimnator from "logging buffered", consider using “logging buffered 6” instead
of “no logging buffered discriminator DB_User”
Example message and corresponding discriminators:
%PARSER-5-CFGLOG_LOGGEDCMD: User:script logged command:logging buffered 7
Examples using a single filter (no sub-filter):
•
•
•
•
logging discriminator DF_PARSE facility includes PARSER
logging discriminator DM_CFGLO mnemonics drops CFGLOG
logging discriminator DS_5 severity includes 5
logging discriminator DB_User msg-body drops User:script|User:adminX
The last example above, will drop messages in which the message body contains either
“User:script” or “User:adminX”.
Example using multiple filters:
•
•
logging discriminator Inc_Drop facility includes PARSER mnemonics drops
CFGLOG severity drops 5 msg-body drops User:script|User:adminX
logging discriminator Drop_Inc facility drops PARSER mnemonics includes
CFGLOG severity includes 5 msg-body includes User:script|User:adminX
Activating the discriminators on the local logging buffer:
17
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Note: Only one discriminated can be active at any one time on the local logging buffer.
•
•
•
•
•
•
logging buffered discriminator DF_PARSE
logging buffered discriminator DM_CFGLO
logging buffered discriminator DS_6
logging buffered discriminator DB_User
logging buffered discriminator Inc_Drop
logging buffered discriminator Drop_Inc
Activating the discriminators for a logging host, use the following syntax:
logging host {ip-address | hostname} [discriminator discr-name]
Example: “logging host 10.1.2.3 discriminator DB_User”
To define a discriminator:
Use the following syntax:
logging discriminator discr-name [[facility] [mnemonics] [msg-body] {drops string | includes
string}] [severity {drops sev-num | includes sev-num}] [rate-limit msglimit]
Discriminator names are limited to eight characters.
Example of defining a discriminator:
logging discriminator msglog2 facility includes User msg-body
includes User
logging host 1.2.3.4 discriminator msglog2
logging trap 7
logging userinfo
logging console discriminator msglog2 debugging
logging monitor discriminator msglog2 debugging
logging buffered discriminator msglog2 debugging
To remove a defined discriminator:
Use the “no” form of the command to remove a discriminator.
no logging discriminator discr-name
To view all discriminators defined in the running config:
show run | include disc
To activate a discriminator:
A discriminator is not activated until IOS is told to monitor the discriminator.
Use the “logging monitor” command to activate a defined discriminator.
logging monitor [discriminator discr-name] [severity-level]
Use the “no” form of the command to deactivate the discriminator.
Both active and inactive discriminators are listed at the top of the output of “show logging”:
18
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Controller# show logging
Syslog logging: disabled (0 messages dropped, 0 messages ratelimited, 12165 flushes, 0 overruns, xml disabled, filtering
disabled)
No Active Message Discriminator.
Inactive Message Discriminator:
msglog01
msg-body
includes "user: auditperson"
Example of activating a discriminator:
Controller(config)# logging monitor discriminator msglog01
Controller(config)# do show logging
Syslog logging: disabled (0 messages dropped, 0 messages ratelimited, 12165 flushes, 0 overruns, xml disabled, filtering
disabled)
Active Message Discriminator:
msglog01
msg-body
includes "user: auditperson"
Inactive Message Discriminator:
3.3.11 Configuring Other Logging Parameters
Configure logging of all configuration changes:
Controller(config)#archive
Controller(config-archive)#log config
Controller(config-archive)#logging enable
Ensure passwords and keys typed into the CLI as plaintext will not be written to syslog messages:
Controller(config-archive)#hidekeys
Ensure the username will be included in syslog messages related to configuration changes:
Controller(config)#logging userinfo
Ensure syslog messages (and any debug messages, if any) will contain a timestamp. Note:
specification of localtime, and show-timezone are optional.
Controller(config)#service timestamps log datetimemsec year
Controller(config)#service timestamps debug datetim
e msec year
Enable logging of SSH events (optional):
Controller(config)#ip ssh logging events
Enable radius and tacacs+ debugging:
Controller(config)#debug radius authentication
Controller(config)#debug tacacs authentication
Set the size of the logging buffer. It is recommended to set it to at least 150000000:
Controller(config)#logging buffer 150000000
To generate logging messages for failed and successful login attempts in the evaluated
configuration, issue the login on-failure and login on-success commands:
19
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Controller(config)#login on-failure log
Controller(config)#login on-success log
For IPsec related debugging turn on the following:
Controller(config)#debug crypto isakmp
Controller(config)#debug crypto ipsec
Controller(config)#debug crypto ikev2
Turn on debugging for network time protocol (ntp):
Controller(config)#debug ntp all
For HTTPS related debugging turn on the following:
Controller(config)#debug ip tcp transactions port 43
4
3.3.11.1 Configure RADIUS Key Wrap (Required to Adhere to FIPS 140-2)
Enable RADIUS Key Wrap for use with each RADIUS server. When configuring each RADIUS
server via the Controller CLI, ensure the following settings are configured:
Key Wrap is enabled (config radius auth keywrap enable).
The Key Wrap Format is HEX (config radius auth keywrap hex).
The Key Encryption Key (KEK) matches the value set on the RADIUS server.
The Message Authentication Code Key (MACK) matches the value set on the RADIUS
server.
The UDP port number matches the port number on the RADIUS server.
The RADIUS server is enabled for authentication of Management Users.
Optional: The RADIUS server is enabled for authentication of Network Users.
o
Note: For more information on authentication of Network Users, refer to
guidance below regarding use of EAP.
For all other settings, any value is permissible.
The following commands show an example set of configuration steps for defining a RADIUS
server using AES Key Wrap:
Controller(config)#aaa new-model
Controller(config)#aaa group server radius my-rad-s
ervers
Controller(config-sg-radius)#server name name]
[
Controller(config-sg-radius)#server 10.1.1.1
Controller(config-sg-radius)#server 10.1.1.1 auth-p
ort 1812 acct-port
1813
Controller(config-sg-radius)#key-wrap enable
Controller(config)#aaa authentication dot1x my-auth
EN-list group myrad-servers
Controller(config)#aaa authorization network my-aut
hOR-list group myrad-servers
20
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Controller(config)#aaa accounting identity my-accou
nting-list startstop group my-rad-servers
Controller(config)#aaa server radius dynamic-author
Controller(config-locsvr-da-radius)#client 10.1.1.1server-key 7 [key]
auth-type any
Controller(config)#radius-server host 10.1.1.1 keywrap encryption-key
[encr-key] message-auth-code-key [auth-key]
Controller(config)#wlan fips-1x-ACS 11 fips-1x-ACS
Controller(config-wlan)#aaa-override
Controller(config-wlan)#accounting-list my-accounti
ng-list
Controller(config-wlan)#client vlan 48
Controller(config-wlan)#nac
Controller(config-wlan)#security dot1x authenticati
on-list 9.1.0.101Authentication-List
Controller(config-wlan)#no shutdown
3.3.12 Configuring multiple RADIUS Servers
It’s highly recommended to configure multiple RADIUS servers for redundancy. If a Controller
cannot access any RADIUS servers, the Controller will be unable to authenticate new connections
from wireless clients because the Common Criteria certified configuration requires that RADIUS
be used to authenticate wireless clients. Controllers can be configured to seek multiple RADIUS
servers, so if the active server fails or becomes unreachable the controller automatically tries the
next one in the list, and cycles through the list until it finds an available RADIUS server.
Note: For authentication to work properly/consistently regardless of which RADIUS server is
active, the user database must be identical across all RADIUS servers.
3.3.13 Configuring WPA2-Dot1X WLAN
Controller(config)#aaa new-model
Controller(config)#aaa group server radius rad-grou
p1
Controller(config)#server name rad-server1
Controller(config)#aaa authentication dot1x Authlis
t-IAS1 group radgroup1
Controller(config)#aaa authorization network Author
ization-List-IAS1
group rad-group1
Controller(config)#aaa accounting identity Accounti
ng-IAS1 start-stop
group rad-group1
Controller(config)#aaa local authentication Authlis
t-IAS1 authorization
Authorization-List-IAS1
Controller(config)#aaa server radius dynamic-author
Controller(config-locsvr-da-radius)#client 10.2.2.2server-key 0
Cisco!123 auth-type any
Controller(config)#aaa authentication login defaultgroup rad-group1
Controller(config)#radius server rad-server1
Controller(config-radius-server)#address ipv4 10.2.
2.2 auth-port 1812
acct-port 1813
21
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Controller(config-radius-server)#key 0 Cisco!123
Controller(config)#wlan FIPS-dot1x 1 FIPS-dot1x
Controller(config-wlan)#accounting-list AccountingIAS1
Controller(config-wlan)#client vlan VLAN0049
Controller(config-wlan)#security dot1x authenticati
on-list AuthlistIAS1
Controller(config-wlan)#session-timeout 1800
Controller(config-wlan)#no shutdown
3.3.14 Configuring WPA2-PSK WLAN
Controller(config)#wlan fips-wpa2psk 3 fips-wpa2psk
Controller(config-wlan)#client vlan 54
Controller(config-wlan)#no security wpa akm dot1x
Controller(config-wlan)#security wpa akm psk set-ke
y 0 ciscocisco
Controller(config-wlan)#session-timeout 1800
Controller(config-wlan)#shutdown
3.3.15 Configuring 802.11w WLAN
Controller(config)#wlan fips-11w-psk 4 fips-11w-psk
Controller(config-wlan)#client vlan VLAN0131
Controller(config-wlan)#ip multicast vlan 131
Controller(config-wlan)#no mfp client
Controller(config-wlan)#no mfp client required
Controller(config-wlan)#no security wpa akm dot1x
Controller(config-wlan)#security wpa akm psk set-ke
y ascii 0 ciscocisco
Controller(config-wlan)#security wpa akm pmf psk
Controller(config-wlan)#no security ft over-the-ds
Controller(config-wlan)#security pmf association-co
meback 10
Controller(config-wlan)#security pmf mandatory
Controller(config-wlan)#security pmf saquery-retrytime 100
Controller(config-wlan)#service-policy client inputclient-input
Controller(config-wlan)#service-policy client outpu
t client-output
Controller(config-wlan)#service-policy input ssid-i
nput
Controller(config-wlan)#service-policy output ssidoutput
Controller(config-wlan)#no shutdown
3.3.16 Configuring 802.11r WLAN
Controller(config)#wlan 11r-psk 7 11r-psk
Controller(config-wlan)#client vlan 131
Controller(config-wlan)#ip multicast vlan 131
Controller(config-wlan)#no security wpa akm dot1x
Controller(config-wlan)#security wpa akm ft psk
Controller(config-wlan)#security wpa akm psk set-ke
y ascii 0 ciscocisco
Controller(config-wlan)#security ft
Controller(config-wlan)#no shutdown
3.3.17 Configure attributes to deny a wireless session
To deny establishment of a wireless client session based on time/day use a Time Range with ACL
1. configure terminal
22
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
2. time-range time-range-name
3. Use one of the following:
• absolute [start time date] [end time date]
• periodic day-of-the-week hh:mm to [day-of-the-week] hh:mm
• periodic {weekdays | weekend | daily} hh:mm to hh:mm
Refer to Time Ranges with ACLs for more information
To deny session establishment based on location, the administrator should create AP groups and
add APs/WLANs/Vlan to that AP-group. The process is described below:
1. Create WLAN (with WLAN ID more than 16)
a. TOE-common-criteria (config)#wlan <apgroup > <17 > <ssid>
b. TOE-common-criteria (config-wlan)no shutdown
2. Create AP Group Name
a. TOE-common-criteria (config)#ap group <WORD>
b. TOE-common-criteria (config-apgroup)#wlan <apgroup>
c. TOE-common-criteria (config-apgroup)#vlan < VLAN0078>
d. TOE-common-criteria (config-apgroup)#exit
Note:vlan which mention in ap group,that vlan will get in client ,and vlan which
is mention in wlan mode,that for default ap group
3. Map AP in to AP Group
a. TOE-common-criteria #ap name AP1 ap-groupaname apgroup
This AP (AP1) will reload after the above command is executed and will
advertise wlan 17. To verify AP group enter:
b. TOE-common-criteria #show ap groups
The administrator can repeat these steps in order to create multiple AP groups to segregate clients
based on location:
•
Create 2 AP groups. For example Bldg18 and Bldg26.
•
When the Wlan is mapped to APgroup Bldg18 clients will be placed in that VLAN (for
example vlan48)
•
Wlan Bldg26-Alpha is mapped to APgroup Bldg26 clients will be placed in that VLAN
(for example vlan54)
3.3.18 Optional: Configure the Controller Programmatic Interfaces
The TOE is capable of being managed by an external IT entity (such as Cisco Prime
Infrastructure) using SNMPv3 over an IPsec tunnel provided by the TOE. SNMPv3 accounts are
not considered administrative roles since SNMPv3 is not an interactive interface.
SNMPv3 accounts can connect to the Controller via the Controller’s SNMPv3 interface, which is
used for remote/centralized administration from a Cisco Prime Infrastructure (PI) server. SNMP
v3 accounts can be configured with one of two privileges, Read-only, or Read-write. Each of the
23
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
two privilege levels can view all configuration settings, but only the read-write privilege level can
modify values.
Define an SNMPv3 MIB view:
Controller(config)#snmp-server view view1 mib-2 inc
luded
Define an SNMPv3 User Security Model group. Ensure the version is set to v3 and that the ‘priv’
parameter is set (do not use ‘auth’ or ‘noauth’)
Controller (config)#snmp-server group group1 v3 pri
v write view1
Define SNMPv3 user accounts. Ensure the version is set to v3 and ensure the auth is set to ‘sha’,
and the priv is set to ‘aes 128’.
Controller (config)#snmp-server user pi-server1 gro
up1 v3 auth
sha Cisco!123 priv aes 128 Cisco!123
Note: Ensure each “SNMPv3 User” account is used only for a single instance of any PI server in
the environment.
Each SNMPv3 account is used to authenticate the remote SNMPv3 client of the PI server, and is
not intended to (re)authenticate administrators who have individually authenticated to PI prior to
initiating SNMP GET or SET commands to a Controller. Thus, audit records generated by the
Controller of actions performed on a Controller by SNMPv3 accounts are actions performed by
the authenticated PI servers.
Additional information regarding configuration of SNMP can be found in [WLC6] under
“Configuring Simple Network Management Protocol”.
3.4 Install and Configure Access Points
3.4.1.1 Confirm Controllers Have Been Configured for FIPS
Before proceeding, confirm that all Controllers that will administer the APs have been configured
for FIPS according to FIPS Security Policies for each Controller referenced previously in this
document.
3.4.1.2 Confirm Necessary Network Connectivity for Initial Setup
Lightweight (LWAPP) access points are "zero-touch" deployed, which means that if the AP is on
the same subnet as the controller and DHCP server. Upon initial power-up the AP will initiate a
Discovery and Join Process.
3.4.1.3 Apply FIPS Security Policies to Access Points
Follow the Secure Configuration and Physical Security Policy instructions in the FIPS 140-2
Security Policy [FIPS3].
3.4.1.4 Configuring Data DTLS (optional)
In the Cisco WLAN system the control channel between APs and Controllers is always
encrypted. In the CC-certified configuration it’s optional to encrypt the data channel, which
carries wireless clients’ network traffic as that traffic traverses the wired network between APs
and Controllers. Encrypting the data channel is referred to enabling “Data DTLS” or “linkencryption”.
Controller(config)#ap link-encryption
24
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Enabling link-encryption globally will reboot the Ps
A with no
link-encryption.
Are you sure you want to continue? (y/n)[y]: y
Controller(config)#
3.5 Verifying Installation of the Evaluated Software Version
In order to ensure that your configuration matches the Common Criteria evaluated configuration,
hardware and software images should be verified.
3.5.1 Displaying Version Information
Below is a list of evaluated hardware and software, and instructions to verify the correct versions
have been installed.
Component
How to Verify the Software Version
Any Controller
The software version running on the Controller must be 3.6.0E.
Use the “show version” command via the Controller CLI to display
the version number.
Controller#show version
Access Points (via the
Controller CLI)
Verify the software version running on the AP is the same as the
image for the Controller.
Controller#show ap image
3.5.2
Confirming Image Integrity
The integrity of images is verified during the boot processes using SHA hash values and digital
signatures. If the SHA hash value check fails, the image will not continue to load. In order for
the SHA hash value check to succeed, the actual hash value (re-calculated during each boot cycle)
needs to match the digitally-signed hash value contained within the file. The digital signature is
verified against read-only public certificates that are written to each device by Cisco during
hardware manufacturing. During the boot process a message will be displayed to the console
indicating whether the integrity check failed or succeeded. If the check failed, the device will
automatically reload.
4 Secure Management
4.1 IPsec Overview
The TOE allows all privileged administrators to configure IPsec. IPsec provides the following
network security services:
25
•
Data confidentiality--The IPsec sender can encrypt packets before transmitting them
across a network.
•
Data integrity--The IPsec receiver can authenticate packets sent by the IPsec sender to
ensure that the data has not been altered during transmission.
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
•
Data origin authentication--The IPsec receiver can authenticate the source of the sent
IPsec packets. This service is dependent upon the data integrity service.
•
Anti-replay--The IPsec receiver can detect and reject replayed packets.
IPsec provides secure tunnels between two peers, such as two routers. The privileged
administrator defines which packets are considered sensitive and should be sent through these
secure tunnels and specifies the parameters that should be used to protect these sensitive packets
by specifying the characteristics of these tunnels. When the IPsec peer recognizes a sensitive
packet, the peer sets up the appropriate secure tunnel and sends the packet through the tunnel to
the remote peer.
More accurately, these tunnels are sets of security associations (SAs) that are established between
two IPsec peers. The SAs define the protocols and algorithms to be applied to sensitive packets
and specify the keying material to be used by the two peers. SAs are unidirectional and are
established per security protocol (AH or ESP).
With IPsec, privileged administrators can define the traffic that needs to be protected between
two IPsec peers by configuring access lists and applying these access lists to interfaces using
crypto map sets. Therefore, traffic may be selected on the basis of the source and destination
address, and optionally the Layer 4 protocol and port. (The access lists used for IPsec are only
used to determine the traffic that needs to be protected by IPsec, not the traffic that should be
blocked or permitted through the interface. Separate access lists define blocking and permitting at
the interface). For example:
TOE-common-criteria # conf t
TOE-common-criteria (config)# access-list 101 permit ip 192.168.3.0 0.0.0.255 10.3.2.0
0.0.0.255
When a packet matches a permit entry in a particular access list, the method of security in the
corresponding crypto map is applied. If the crypto map entry is tagged as ipsec-isakmp, IPsec is
triggered. For example:
TOE-common-criteria (config)#crypto map armadillo 10 ipsec-isakmp
The match address 101 command means to use access list 101 in order to determine which
traffic is relevant. For example:
TOE-common-criteria (config-crypto-map)#match address 101
The traffic matching permit ACL would then flow through the IPsec tunnel and be classified as
“PROTECTED”.
Traffic that does not match a permit crypto map ACL and does not match a non-crypto permit
ACL on the interface would be DISCARDED.
Traffic that does not match a permit ACL in the crypto map, but does match a non-crypto permit
ACL would be allowed to BYPASS the tunnel. For example, a non-crypto permit ACL for icmp
would allow ping traffic to flow unencrypted if a permit crypto map was not configured that
matches the ping traffic.
A crypto map set can contain multiple entries, each with a different access list. The crypto map
entries are searched in a sequence--the router attempts to match the packet to the access list
specified in that entry.
When a packet matches a permit entry in a particular access list, and the corresponding crypto
map entry is tagged as cisco, connections are established, if necessary. If the crypto map entry is
tagged as ipsec-isakmp, IPsec is triggered.
26
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
If there is no SA that the IPsec can use to protect this traffic to the peer, IPsec uses IKE to
negotiate with the remote peer to set up the necessary IPsec SAs on behalf of the data flow. The
negotiation uses information specified in the crypto map entry as well as the data flow
information from the specific access list entry.
Once established, the set of SAs (outbound to the peer) is then applied to the triggering packet
and to subsequent applicable packets as those packets exit the router. "Applicable" packets are
packets that match the same access list criteria that the original packet matched. For example, all
applicable packets could be encrypted before being forwarded to the remote peer. The
corresponding inbound SAs are used when processing the incoming traffic from that peer.
Access lists associated with IPsec crypto map entries also represent the traffic that the router
needs protected by IPsec. Inbound traffic is processed against crypto map entries--if an
unprotected packet matches a permit entry in a particular access list associated with an IPsec
crypto map entry, that packet is dropped because it was not sent as an IPsec-protected packet.
Crypto map entries also include transform sets. A transform set is an acceptable combination of
security protocols, algorithms, and other settings that can be applied to IPsec-protected traffic.
During the IPsec SA negotiation, the peers agree to use a particular transform set when protecting
a particular data flow.
4.2 IKEv2 Transform Sets
An Internet Key Exchange version 2 (IKEv2) proposal is a set of transforms used in the
negotiation of IKEv2 SA as part of the IKE_SA_INIT exchange. An IKEv2 proposal is regarded
as complete only when it has at least an encryption algorithm, an integrity algorithm, and a
Diffie-Hellman (DH) group configured. If no proposal is configured and attached to an IKEv2
policy, then the default proposal is used in the negotiation, and it contains selections that are not
valid for the TOE. Thus the following settings must be set in configuring the IPSec with IKEv2
functionality for the TOE:
TOE-common-criteria # conf t
TOE-common-criteria (config)#crypto ikev2 proposal sample
TOE-common-criteria (config-ikev2-proposal)# integrity sha1
This configures IPSec IKEv2 to use Secure Hash Algorithm (SHA-1-HMAC) as
the hash algorithm. SHA-256 can be selected with ‘integrity sha256’. SHA384 can be selected with ‘integrity sha384’. SHA-192 can be selected with
‘integrity sha192’.
TOE-common-criteria (config-ikev2-proposal)# encryption aes-cbc-128
This configures IPSec IKEv2 to use AES-CBC-128 for payload encryption.
AES-CBC-256 can be selected with ‘encryption aes-cbc-256’. AES-CBC-192
can be selected with ‘encryption aes-cbc-192
Note: the authorized administrator must ensure that the keysize for this setting is
greater than or equal to the keysize selected for ESP in Section 4.4 and 4.5
below. If AES 128 is selected here, then the highest keysize that can be selected
on the TOE for ESP is AES 128 (either CBC mode).
Note: Both confidentiality and integrity are configured with the hash sha and
encryption aes commands respectively. As a result, confidentiality-only mode is
disabled.
27
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
TOE-common-criteria (config-ikev2-proposal)# group 14
This selects DH Group 14 (2048-bit MODP) for IKE, but 19 (256-bit Random
ECP), 24 (2048-bit MODP with 256-bit POS), 20 (384-bit Random ECP), 15
(3072 bit MODP), and 16 (4096-bit MODP) are also allowed and supported.
TOE-common-criteria (config-ikev2-proposal)#exit
TOE-common-criteria (config)#crypto ikev2 profile profile-rsasig
TOE-common-criteria(config-ikev2-profile)#match certificate MyPeer
TOE-common-criteria(config-ikev2-profile)#identity local dn
TOE-common-criteria(config-ikev2-profile)#authentication remote rsa-sig
TOE-common-criteria(config-ikev2-profile)#authentication local rsa-sig
TOE-common-criteria(config-ikev2-profile)# lifetime 86400
The default time value for Phase 1 SAs is 24 hours (86400 seconds), but this setting can
be changed using the command above with different values.
TOE-common-criteria(config-ikev2-profile)#exit
This configures IPsec to use X.509 v3 certificates for authentication of IPsec peers. See
Section 4.6 below for additional information.
4.3 Configure IPsec Tunneling of RADIUS, Syslog, and NTP
In the following example:
•
IP address of the management interface of controller is 10.1.1.1
•
IP address of the remote IPsec peer is: 10.2.2.2
•
The RADIUS, NTP, and Syslog servers can reside on the IPsec termination point, or on a
protected network accessible through the IPsec peer. This example would support the
NTP server residing on the remote IPsec peer itself, and the RADIUS and Syslog servers
residing on an isolated subnet 10.3.3.0/24 protected by the IPsec peer.
Define an ikev2 policy using:
•
Authentication with x509v3 certificates.
•
Encryption set to AES 128, AES 192, or AES 256 (do not use DES or 3DES)
o
NOTE: Ensure that the AES bit size used for the IKE SA (as specified in the encr
aes size in the “ikev2 policy”) is always at least as large as the AES bit size used
for the IPsec SA (as specified in the esp-aes size in the “ipsec transform-set”).
•
DH Group set to one of: 14, 24, 19, 20, 15, or 16 (do not use 1, 2, or 5)
•
Hash set to SHA, SHA256, SHA384, or SHA512 (do not use MD5)
•
Ensure expiry of Phase 1 SAs after 24 hours and Phase 2 SAs after 8 hours. The
default time value for Phase 1 SAs is 24 hours. The default time value for Phase
2 SAs is 1 hour (86400 seconds). There is no configuration required for these
since the defaults are acceptable but this setting can be changed.
crypto ikev2 proposal ike2aes2sha2
28
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
encryption aes-cbc-256
integrity sha256
group 14
crypto ikev2 profile profile-rsa-sig
authentication remote rsa-sig
authentication local rsa-sig
lifetime 86400
Disable aggressive-mode (require main-mode for all tunnels):
crypto isakmp aggressive-mode disable
Define the IPsec transform-set to use:
•
ESP encryption with AES (AES-CBC 128 or 256)
o
•
NOTE: Ensure that the AES bit size used for the IKE SA (as specified in the encr
aes size in the “ikev2 policy”) is always at least as large as the AES bit size used
for the IPsec SA (as specified in the esp-aes size in the “ipsec transform-set”).
ESP integrity with SHA-HMAC (SHA1, SHA256, SHA384, or SHA512)
o
Note: Enabling ESP integrity as described here results in disabling what is called
“confidentiality-only” mode since it results in requiring confidentiality and
integrity.
crypto ipsec transform-set t-set-cbc esp-aes [128 |192 | 256]
esp-sha-hmac
Define a crypto map including the IPsec peer address, transform-set, and the access-list that
defines the traffic to be tunneled (all the RADIUS, NTP, and Syslog servers can exist across the
same IPsec tunnel, and don’t need to be on the same host).
Controller(config)#crypto map To_NTP_SYSLOG_RADIUS1 ipsec-isakmp
set peer 10.2.3.4
set transform-set my-t-set
match address hostacl_10.2.2.2
Controller(config)#interface Vlan48
ip address 10.1.1.1 255.255.255.0
ip helper-address 10.9.9.9
crypto map To_NTP_SYSLOG_RADIUS
Controller(config)#ip access-list extended hostacl_
10.2.2.2
permit ip host 10.1.1.1 host 10.2.2.2
permit ip host 10.1.1.1 10.3.3.0 0.0.0.255
Ensure the source address of packets sent from the Controller to the RADIUS, NTP, and Syslog
servers use the correct IP address to allow packets to be routed back to the Controller:
Controller(config)#ip radius source-interface vlan4
8
Controller(config)#logging source-interface vlan48
Controller(config)#ntp source vlan48
4.3.1 Example IPsec Configuration from IOS to IOS using Pre-shared Keys
In the following example, the RADIUS, syslog, and NTP hosts are located across another IOS
device from the controller. An IPsec tunnel is established between the controller and the remote
IOS device, and authenticated using pre-shared keys.
29
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
In this example:
•
The Controller’s interface IP facing the IPsec peer is: 10.11.12.99.
•
The IPsec peer’s IP address is 10.11.12.13.
•
The host beyond tunnel (could be running any of RADIUS, NTP, syslog): 50.0.0.1
!
configure terminal
!
!
<Define the IKE and IPsec properties for the tunnel.>
crypto ikev2 proposal ike2aes2sha2
encryption aes-cbc-256
integrity sha256
group 14
!
crypto ikev2 policy policy1
match fvrf any
proposal ike2aes2sha2
!
crypto ikev2 keyring keyring1
peer 10.11.12.13
address 10.11.12.13
pre-shared-key 0 myprekey
!
crypto ikev2 profile profile-preshare
match fvrf any
match address local 10.11.12.99
match identity remote address 10.11.12.13
identity local address 10.11.12.99
authentication local pre-share
authentication remote pre-share
keyring local keyring1
!
crypto ipsec transform-set aesset esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto ipsec profile ipsec-profile-preshare
set transform-set aesset
set ikev2-profile profile-preshare
!
crypto map cmap-preshare 10 ipsec-isakmp
set peer 10.11.12.13
set transform-set aesset
set ikev2-profile profile-preshare
match address acl_vpn
reverse-route
!
interface Loopback1
ip address 10.11.12.99 255.255.255.0
!
ip route 50.0.0.0 255.255.255.0 10.11.12.13
30
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
!
ip access-list extended acl_vpn
permit icmp host 10.11.12.99 host 50.0.0.1
permit tcp host 10.11.12.99 host 50.0.0.1
permit udp host 10.11.12.99 host 50.0.0.1
!
<Apply the crypto map to the inteface.>
interface GigabitEthernet1/0/0
crypto map cmap-preshare
!
<Send a ping to initiate the tunnel:>
ping ip 50.0.0.1 source 10.11.12.99
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 50.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.11.12.99
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
4.3.2 Example IPsec Configuration from IOS to IOS using X509 Certificates
In the following example, the RADIUS, syslog, and NTP hosts are located across another IOS
device from the controller. An IPsec tunnel is established between the controller and the remote
IOS device, and authenticated using X509v3 certificates issued from an OpenSSL CA server.
The following examples shows steps to configure an IPsec tunnel that will be authenticated using
ECDSA X509 certificates.
In this example:
•
The Controller’s interface IP facing the IPsec peer is: 10.11.12.99.
•
The IPsec peer’s IP address is 10.11.12.13.
•
The host beyond tunnel (could be running any of RADIUS, NTP, syslog): 50.0.0.1
!
configure terminal
!
crypto key generate ec keysize 256 exportable label IpsecEC
!
crypto pki trustpoint CA_ECDSA_SHA256
enrollment terminal pem
eckeypair IPsecEC
storage nvram:
revocation-check none
serial-number none
ip-address none
subject-name CN=MyDevice,OU=MyGroup,O=MyCompany,L=MyTown,ST=MyState,C=US
hash sha256
!
exit
!
crypto pki authenticate CA_ECDSA_SHA256
!
<Follow instructions to paste the CA certificate via the CLI.>
31
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
!
crypto pki enroll CA_ECDSA_SHA256
<Follow instructions to display the certificate enrollment request at the CLI.>
!
<Submit the CSR to the CA server>
<If using ECDSA, ensure the certificate is signed using a prime curve, e.g. prime256v1.>
<Obtain the device certificate from the CA server.>
<Import the device certificate, specifying the “trustpoint” name as defined previously>
crypto pki import CA_ECDSA_SHA256 certificate
<Follow instructions to paste the new device certificate via the CLI.>
<Create a “certificate map” to define some attributes of the IPsec peer’s certificate.>
Crypto pki certificate map MyPeer 1
subject-name co TrustedDevice
exit
!
<Define the IKE and IPsec properties for the tunnel.>
crypto ikev2 proposal ike2aes2sha2
encryption aes-cbc-256
integrity sha256
group 14
!
crypto ikev2 policy policy1
match fvrf any
proposal ike2aes2sha2
!
crypto ikev2 profile profile-ecdsa
match fvrf any
match certificate MyPeer
identity local dn
authentication remote ecdsa-sig
authentication local ecdsa-sig
pki trustpoint CA_ECDSA_SHA256
!
crypto ipsec transform-set aesset esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto ipsec profile ipsec-profile-ecdsa
set transform-set aesset
set ikev2-profile profile-ecdsa
!
crypto map cmap-ecdsa 10 ipsec-isakmp
set peer 10.11.12.13
set transform-set aesset
set ikev2-profile profile-ecdsa
match address acl_vpn
reverse-route
!
interface Loopback1
ip address 10.11.12.99 255.255.255.0
!
ip route 50.0.0.0 255.255.255.0 10.11.12.13
!
32
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
ip access-list extended acl_vpn
permit icmp host 10.11.12.99 host 50.0.0.1
permit tcp host 10.11.12.99 host 50.0.0.1
permit udp host 10.11.12.99 host 50.0.0.1
!
<Apply the crypto map to the interface.>
interface GigabitEthernet1/0/0
crypto map cmap-ecdsa
!
<Send a ping to initiate the tunnel:>
ping ip 50.0.0.1 source 10.11.12.99
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 50.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.11.12.99
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
4.4 Optional: Configuring IPsec Tunneling of SNMPv3 traffic to
Management Server
If the TOE communicates with an external management server (such as Cisco Prime
Infrastructure server) it must do so using IPsec.
The following are sample instructions to configure the TOE to support an IPSec tunnel using
x.509v3 authentication, AES encryption, with 10.10.10.102 as the IPSec peer IP on the PI,
10.10.10.110 as the local TOE IP.
TOE-common-criteria#configure terminal
TOE-common-criteria(config)#crypto ikev2 proposal ikev2aes128sha1
TOE-common-criteria(config-ikev2-proposal)#encryption aes-cbc-128
TOE-common-criteria(config-ikev2-proposal)#authentication [remote | local] rsa-sig
TOE-common-criteria(config-ikev2-proposal)#group 14
TOE-common-criteria(config-ikev2-proposal)#exit
TOE-common-criteria(config)# crypto ikev2 profile profile-rsasig
TOE-common-criteria(config-ikev2-profile)#match certificate MyPeer
TOE-common-criteria(config-ikev2-profile)#identity local dn
TOE-common-criteria(config-ikev2-profile)#authentication remote rsa-sig
TOE-common-criteria(config-ikev2-profile)#authentication local rsa-sig
TOE-common-criteria(config-ikev2-profile)#exit
TOE-common-criteria(config)#crypto ipsec transform-set sampleset esp-aes esp-shahmac
TOE-common-criteria(cfg-crypto-trans)#mode tunnel
Note: Configures IPsec for esp in tunnel mode
33
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
-- OR -TOE-common-criteria(cfg-crypto-trans)#mode transport
Note: Configures IPsec for esp in transport mode
TOE-common-criteria(config)#crypto map sample 19 ipsec-isakmp
TOE-common-criteria(config-crypto-map)#set peer 10.10.10.102
TOE-common-criteria(config-crypto-map)#set transform-set sampleset
TOE-common-criteria(config-crypto-map)#set pfs group14
TOE-common-criteria(config-crypto-map)#match address 170
TOE-common-criteria(config-crypto-map)#exit
TOE-common-criteria(config)#interface g0/0
TOE-common-criteria(config-if)#ip address 10.10.10.110 255.255.255.0
TOE-common-criteria(config-if)#crypto map sample
TOE-common-criteria(config-if)#exit
TOE-common-criteria(config)# access-list 170 permit ip 10.10.10.0 0.255.255.255
10.10.10.0 0.255.255.255
4.5 X.509 Certificates
The TOE must be configured by the privileged administrators to use X.509v3 certificates to
authenticate IPsec peers in place of pre-shared keys.
Manual certificate enrollment employing a manual cut-and-paste method shall be used.
For details on the manual cut-and-paste method, the administrator shall refer to the “Configuring
Cut-and-Paste Certificate Enrollment” section of the Configuring Certificate Enrollment for a
PKI chapter of Public Key Infrastructure Configuration Guide [WLC8]
4.5.1 Storing Certificates to a Local Storage Location
Certificates are stored to NVRAM by default; however, some routers do not have the required
amount of NVRAM to successfully store certificates. All Cisco platforms support NVRAM and
flash local storage. Depending on the platform, an authorized administrator may have other
supported local storage options including bootflash, slot, disk, USB flash, or USB token. During
run time, an authorized administrator can specify what active local storage device will be used to
store certificates.
4.5.2 How to Specify a Local Storage Location for Certificates
The summary steps for storing certificates locally to the TOE are as follows:
1. Enter configure terminal mode:
Device# configure terminal
2. Specify the local storage location for certificates: crypto pki certificate
storage location-name
Device(config)# crypto pki certificate storage flash:/certs
34
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
3. Exit:
Device(config)# exit
4. Save the changes made:
Device# copy system:running-config nvram:startup-config
5. Display the current setting for the PKI certificate storage location:
Device# show crypto pki certificates storage
The following is sample output from the show crypto pki certificates storage command, which
shows that the certificates are stored in the certs subdirectory of disk0:
TOE-common-criteria# show crypto pki certificates storage
Certificates will be stored in disk0:/certs/
For more information refer to the Storing PKI Credentials chapter of the PKI Configuration
Guide [WLC8]
4.5.3
Configuring a Revocation Mechanism for PKI Certificate Status Checking
Perform this task to set up the certificate revocation mechanism--CRLs or OCSP--that is used
to check the status of certificates in a PKI.
Use the revocation-check command to specify at least one method (OCSP or CRL) that is to be
used to ensure that the certificate of a peer has not been revoked. For multiple methods, the
order in which the methods are applied is determined by the order specified via this command.
If the TOE does not have the applicable CRL and is unable to obtain one, or if the OCSP server
returns an error, the TOE will reject the peer’s certificate--unless an administrator includes the
‘none’ keyword in your configuration. If the 'none' keyword is configured, a revocation check
will not be performed and the certificate will always be accepted.
When using OCSP, nonces, unique identifiers for OCSP requests, are sent by default during
peer communications with a OCSP server. The use of nonces offers a more secure and reliable
communication channel between the peer and OCSP server. If the OCSP server does not support
nonces, an authorized administrator may disable the sending of nonces.
For more information refer to the CRLs or OCSP Server Choosing a Certificate Revocation
Mechanism chapter of the PKI Configuration Guide [WLC8]
In addition, this Cisco document provides supplemental information about using X.509 digital
certificates issued by a Cisco IOS CA server to authenticate VPN tunnels between Cisco routers.
It provides design considerations, step-by-step configuration instructions, and basic management
options (including CRL checking) for devices using X.509 digital certificates.
4.5.4 Manually Overriding the OCSP Server Setting in a Certificate
Administrators can override the OCSP server setting specified in the Authority Information
Access (AIA) field of the client certificate or set by the issuing the ocsp url command. One or
more OCSP servers may be manually specified, either per client certificate or per group of client
certificates by the match certificate override ocsp command. The match certificate override
ocspcommand overrides the client certificate AIA field or the ocsp urlcommand setting if a client
certificate is successfully matched to a certificate map during the revocation check
35
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
4.5.5
Configuring Certificate Chain Validation
Perform this task to configure the processing level for the certificate chain path of peer
certificates.
Prerequisites:
•
•
The device must be enrolled in your PKI hierarchy.
The appropriate key pair must be associated with the certificate.
1. Enter configure terminal mode:
TOE-common-criteria# configure terminal
2. Set the crypto pki trustpoint name:
TOE-common-criteria(config)# crypto pki trustpoint ca-sub1
3. Configure the level to which a certificate chain is processed on all certificates
including subordinate CA certificates using the chain-validation [{stop |
continue} [parent-trustpoint]] command:
TOE-common-criteria(ca-trustpoint)# chain-validation continue ca-sub1
• Use the stop keyword to specify that the certificate is already trusted. This
is the default setting.
• Use the continue keyword to specify that the that the subordinate CA
certificate associated with the trustpoint must be validated.
• The parent-trustpoint argument specifies the name of the parent trustpoint
the certificate must be validated against.
Note: A trustpoint associated with the root CA cannot be configured to be validated to
the next level. The chain-validation command is configured with the continue keyword
for the trust point associated with the root CA, an error message will be displayed and
the chain validation will revert to the default chain-validation command setting.
4. Exit:
TOE-common-criteria(ca-trustpoint)# exit
For more information refer to the PKI Certificate Chain Validation chapter of the PKI
Configuration Guide [WLC8]
4.5.6 Setting X.509 for use with IKE
Once X.509v3 keys are installed on the TOE, they can be set for IKEv2 with the commands:
TOE-common-criteria (config)#crypto ikev2 profile sample
TOE-common-criteria(config-ikev2-profile)#authentication [remote | local] rsa-sig
If an invalid certificate is loaded, authentication will not succeed.
4.5.7 IPsec Session Interruption/Recovery
If an IPsec session with an IT environment component is unexpectedly interrupted, the
connection will be broken. In these cases the IPsec session will need to be reestablished (a new
SA set up) once the peer is back online.
36
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
4.6 Optional: Configuring Cisco Mobility Services Engine
If the TOE communicates with the Cisco Mobility Services Engine, it must do so with TLS.
TLS is used to authenticate and encrypt NMSP sessions between Controllers and MSE. The
Cisco-proprietary Network Mobility Services Protocol (NMSP) runs on the mobility services
engine.
For NMSP to function, the TCP port (16113) over which the controller and the mobility services
engine communicate must be open (not blocked) on any firewall that exists between these two
devices.
If the TLS session with MSE is unexpectedly interrupted, the administrator of the Cisco Prime
Infrastructure server shall use the PI GUI interface to synchronize communications. Refer to the
“Synchronizing Controllers with Mobility Services Engines” section of the Cisco Prime
Infrastructure Configuration Guide.
4.7 Optional: Configure the management server as recipient of SNMP
trap operations
The TOE is capable of being managed by an external IT entity (such as Cisco Prime
Infrastructure) using SNMPv3 over an IPsec tunnel provided by the TOE.
If the TOE is configured to be managed by an external IT entity (such as Cisco Prime
Infrastructure) using SNMPv3 over IPsec, configure wireless device notifications be sent as traps
to the Management Server:
Example:
Controller (config)#snmp-server host [PI Server] ve
rsion 3 priv
pi-server1 wireless
If the IPsec session is unexpectedly interrupted refer to the instructions in 4.6.7 above.
For SNMPv3 communications over the IPsec tunnel the administrator can monitor SNMP
including potential errors from unexpected interruptions in SNMP communications. Refer to
“Monitoring SNMP Status” in [WLC6]
4.8 Configure Secure Copy Operations
The file copy operations described in this section are initiated as needed by authorized
administrators, and file copy operations can be interrupted by conditions in the operational
environment outside the control of the WLAN roller. If any file operation fails, the administrator
will need to re-initiate the operation by re-entering the command that was used.
4.8.1
Copying Files to or from IOS using the IOS CLI
Transferring of files such as certificate signing requests and certificates can be done over TLS (or
SSH, or even IPsec) using the “copy” command on IOS and specifying the source or destination
URL as “https:” or “scp:”.
Example of copying a file from nvram to a remote SCP fileserver:
Controller# copy nvram:my-csr.req scp://smith@hostname/
Example of copying a file from a remote HTTPS fileserver to nvram:
37
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Controller# copy https://hostname/my-cert.pem nvram:
4.8.2
(Optional) Enabling the SCP Server on IOS
The controller running IOS has an SCP server which is disabled by default, but can be enabled to
support copying of files to be initiated from a remote workstation to the controller. To enable the
Wireless Controller to support copying of files (such as patches and new images) from a remote
workstation in the IT environment, use the ip scp server enable command.
Refer to the ip scp server enable command usage and guidelines in [WLC7]
4.9 (Optional) Network Address Translation Traversal (NAT-T)
If the Controller needs to establish an IPsec connection with an IPsec peer located behind a NAT
device (e.g. router or firewall) such that the real IP address of the peer is being translated and the
Controller is not seeing the real IP of the peer, follow the guidance in this section. The Controller
requires some additional commands to ensure NAT-T is enabled, and the NAT device between
the IPsec endpoints may need some additional configuration to ensure NAT is properly applied to
IPsec traffic.
For an overview of configuring NAT on Cisco IOS devices, refer to the following Cisco
document for setting up NAT: Configuring Network Address Translation: Getting Started.
On the Controller, add the following command in config mode:
controller(config)#crypto ipsec nat-transparency spi-matching
When the NAT device is a Cisco IOS device, add the following commands in config mode. If the
NAT device is another product, refer to that product’s guidance documentation for configuring
NAT to support IPsec. The following example uses the following parameters:
WLAN Controller
172.16.1.222
Router
(facing the Controller)
172.16.1.1
NAT IP for the peer:
172.16.1.99
Router
(facing the peer)
192.168.1.1
IPsec Peer
192.168.1.99
1) Configure NAT for the IPsec peer’s IP address:
router(config)#ip nat inside source static 192.168.1.99 172.16.1.99
2) Define an access-list to match all traffic between the IPsec endpoints:
router(config)#access-list 150 permit ip host 172.16.1.222 host 172.16.1.99
3) Apply that access-list to an “IP NAT service list” for ESP.
router(config)#ip nat service list 150 ESP spi-match
5 Security Relevant Events
The controller can maintain logs in multiple locations: local storage of the generated audit
records, and an external syslog server. Administrators should review logs at both locations.
38
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
The administrator is responsible for maintaining the connection between the appliance and audit
server. If the connection is unintentionally broken, the administrator should perform the following
steps to diagnose and fix the problem:
•
•
•
Check the physical network cables.
Check that the audit server is still running.
Reconfigure the audit log settings.
The TOE generates an audit record whenever an audited event occurs. The types of events that
cause audit records to be generated include, cryptography related events, identification and
authentication related events, and administrative events. (Each of the events is specified in syslog
records in enough detail to identify the user for which the event is associated, when the event
occurred, where the event occurred, the outcome of the event, and the type of event that occurred.
Additionally, the startup and shutdown of the audit functionality is audited.
The Controller can maintain logs in multiple locations: local storage of the generated audit
records, and when configured for a syslog backup will simultaneously offload those events to the
external syslog server. The administrator should review logs at both locations. The details for
protection of that communication are covered in section 4.4 above
The administrator can set the level of the audit records to be stored in a local buffer, displayed on
the console, sent to the syslog server, or all of the above. The details for configuration of these
settings are covered in Section 3.3.9 above.
The local log buffer is circular. Newer messages overwrite older messages after the buffer is full.
Administrators are instructed to monitor the log buffer using the show logging privileged EXEC
command to view the audit records. The first message displayed is the oldest message in the
buffer.
When configured for a syslog backup the TOE will simultaneously offload events from a separate
buffer to the external syslog server. This buffer is used to queue events to be sent to the syslog
server if the connection to the server is lost. It is a circular buffer, so when the events overrun the
storage space overwrites older events.
The table below includes the security relevant events that are applicable to the TOE.
5.1 Deleting Audit Records
The TOE provides the privileged Administrator the ability to delete audit records audit records
stored within the TOE.
This is done with the clear logging command.
TOE-common-criteria# clear logging
Clear logging buffer [confirm] <ENTER>
TOE-common-criteria#
5.2 Audit Records Description
The TOE generates an audit record whenever an audited event occurs. The types of events that
cause audit records to be generated include, cryptography related events, identification and
authentication related events, and administrative events (the specific events and the contents of
each audit record are listed in the table below). Each of the events is specified in syslog records
in enough detail to identify the user for which the event is associated, when the event occurred,
39
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
where the event occurred, the outcome of the event, and the type of event that occurred.
Additionally, the startup and shutdown of the audit functionality is audited.
The local audit trail consists of the individual audit records; one audit record for each event that
occurred. The audit record can contain up to 80 characters and a percent sign (%), which follows
the time-stamp information. The audit fields in each audit event will contain at a minimum the
following:
Date: Nov 19
Time: 13:55:59
Type of event: %CRYPTO-6-SELF_TEST_RESULT
Subject identity: Available when the command is run by an authorized TOE
administrator user such as “user: lab”. In cases where the audit event is not associated
with an authorized user, an IP address may be provided for the Non-TOE endpoint and/
or TOE.
Outcome (Success or Failure): Success may be explicitly stated with “success” or
“passed” contained within the audit event or is implicit in that there is not a failure or
error message.
40
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
As noted above, the information includes at least all of the required information. Example audit events are included below:
Additional Audit Information: As described in Column 3 of Table 3: Auditable Events
below:
Nov 19 13:55:59: %CRYPTO-6-SELF_TEST_RESULT: Self test info: (Self test activated by user: lab)
Nov 19 13:55:59: %CRYPTO-6-SELF_TEST_RESULT: Self test info: (Software checksum
... passed)
Nov 19 13:55:59: %CRYPTO-6-SELF_TEST_RESULT: Self test info: (DES encryption/decryption
... passed)
Nov 19 13:55:59: %CRYPTO-6-SELF_TEST_RESULT: Self test info: (3DES encryption/decryption
... passed)
Nov 19 13:55:59: %CRYPTO-6-SELF_TEST_RESULT: Self test info: (SHA hashing
... passed)
Nov 19 13:55:59: %CRYPTO-6-SELF_TEST_RESULT: Self test info: (AES encryption/decryption
... passed)
Table 3: Auditable Events
Requirement
FAU_GEN.1
Auditable Events
Additional Audit
Record Contents
Start-up and shut-down of audit functions;
All administrative actions.
Sample Record
Audit startup (local):
%INIT-7-SWITCH_BOOTING
Audit startup (remote):
%SYS-6-LOGGINGHOST_STARTSTOP: Logging to host 10.1.2.3 port 514
started
Audit shutdown (remote):
%SYS-6-LOGGINGHOST _STARTSTOP: Logging to host 10.1.2.3 port 514
stopped
FAU_GEN.2
FAU_SEL.1
FAU_STG.1
FAU_STG_EXT.1
FAU_STG_EXT.3
Audit messages of administrative actions include
the identity of the administrator.
None.
All modifications to the
audit configuration that
occur while the audit
collection functions are
operating.
None.
None.
Loss of connectivity.
None.
41
Administrative actions: See FAU_GEN.2.
%PARSER-5-CFGLOG_LOGGEDCMD: User:admin logged command:username
admin common-criteria-policy cc1
%PARSER-5-CFGLOG_LOGGEDCMD: User:console logged command:archive
%PARSER-5-CFGLOG_LOGGEDCMD: User:console logged command:log
config
Not applicable.
Not applicable.
%SYS-6-LOGGINGHOST_STARTSTOP: Logging to host 10.1.2.3 port 514
stopped
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Requirement
FCS_CKM.1(1)
FCS_CKM.1(2)
FCS_CKM.2(1)
FCS_CKM.2(2)
FCS_CKM_EXT.4
Auditable Events
Failure of the key
generation activity.
Failure of the key
generation activity.
Failure of the key
distribution activity.
Failure of the key
distribution activity,
including failures related
to wrapping the GTK.
Failure of the key
zeroization process.
FCS_COP.1(1)
Failure of encryption or
decryption.
FCS_COP.1(2)
Failure of cryptographic
signature.
FCS_COP.1(3)
Failure of hashing
function.
42
Additional Audit
Record Contents
None.
None.
None.
Identifier(s) for
intended recipients
of wrapped key.
Identity of subject
requesting or
causing zeroization,
identity of object or
entity being cleared.
Cryptographic mode
of operation,
name/identifier of
object being
encrypted/decrypted.
Cryptographic mode
of operation,
name/identifier of
object being
signed/verified.
Cryptographic mode
of operation,
name/identifier of
object being hashed.
Sample Record
%CCAUDIT-3-CC_MSG: 1 wcm: WLC - User ID: <Wireless-Client-MACaddress> - Unable to derive pairwise transient key
%IOSXE_RP_SPA-3-IFCFG_NO_UNIQUE_KEY: No unique-key generator
registered for interface configuration command %u.
%SSH-3-KEYPAIR: Attempt to generate server keys failed - error code: [chars]
%CCAUDIT-3-CC_MSG: 1 wcm: WLC - User ID: <Wireless-Client-MACaddress> - Unable to derive pairwise transient key
%CCAUDIT-3-CC_MSG: 1 wcm: WLC - User ID: - Unable to send Client
<MAC-address> Keys to AP <MAC-address> .
%PARSER-5-CFGLOG_LOGGEDCMD: User:test_admin logged
command:crypto key zeroize
%SESA-3-ZEROIZATION_FAIL, MSG_TRACEBACK: Key Zeroizatiion failed
on switch [dec]
%CCAUDIT-3-CC_MSG: 1 wcm: WLC - User ID: NA - Cryptographic key
zeroization failed
%SSH-3-NO_MATCH: No matching cipher found: client <cipher-list> server
<cipher-list>
%IOSXEBOOT-4-SWTREE: (rp/0): Signature Verification Failed on <imagefilename>
%IOSXEBOOT-4-ABORT: (rp/0): Signature Verification Failed on <imagefilename>.
Tbd
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Requirement
Auditable Events
FCS_COP.1(4)
Failure in Cryptographic
Hashing for Non-Data
Integrity.
FCS_COP.1(5)
Failure of WPA2
encryption or decryption.
FCS_HTTPS_EXT.1
Protocol failures;
Establishment/Termination
of a HTTPS session.
FCS_IPSEC_EXT.1
Protocol failures;
Establishment/Termination
of an IPsec SA;
Negotiation “down” from
an IKEv2 to IKEv1
exchange.
43
Additional Audit
Record Contents
Cryptographic mode
of operation,
name/identifier of
object being hashed.
Cryptographic mode
of operation,
name/identifier of
object being
encrypted/decrypted,
non-TOE endpoint
of connection (IP
address).
Reason for failure.
Non-TOE endpoint
of connection (IP
address) for both
successes and
failures.
Reason for failure.
Non-TOE endpoint
of connection (IP
address) for both
successes and
failures.
Sample Record
%SSH-3-NO_MATCH: No matching mac found: client <hmac-list> server <hmaclist>
*Apr 15 08:15:43.529: D686C0F2 r 11 11/ 80- 0842 000 m01005E 31A162
B9BA40 E9C0 l62 *wep*
IV 00000000 794E CA40 E5E7 3F4F 2C0D 0846 4424 3E8E AA0F E1DF 3CBA
9FB6
1D36 FFC0 AE89 787F F21B 7E98 EC25 8991 2E00 174B 4CEC 38A2 927F
B029 93E8
A69F 48DF
*Apr 15 08:15:43.530: D686C115-0 31A162 - decrypt failed
*Apr 15 08:15:48.537: D6D328DB r 54 20/ 70- 8843 02C FFB085 31A162
CA96F6 E280 C673C3 q0 l56
IV 180050F2-3A64FE00
IP 50.50.2.231 < 50.50.2.1 id 79AB ttl255 sum D8D8 prot 6 len 40
Protocol Failure:
%WA-HTTPD:[<ip-address>] fd=0 HTTP Intercept, session not found
%HTTPS: SSL read fail (-6992)
%HTTPS: SSL handshake fail (-6992)
Establishment/Termination: Refer to FCS_TLS_EXT.1
Protocol Failures (IKEv2):
%IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= <IP-address>, remote= <IP-address>,
local_proxy= <protected-subnet>,
remote_proxy= <remote-subnet>,
protocol= ESP, transform= NONE (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 192, flags= 0x0
%IPSEC(ipsec_process_proposal): transform proposal not supported for identity:
{esp-aes 192 esp-sha256-hmac }
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Requirement
Auditable Events
Additional Audit
Record Contents
Sample Record
Establishment of IPsec SA (IKEv2):
%IKEv2:New ikev2 sa request activated
%IKEv2:(SESSION ID = <Session-number>,SA ID = <SA-number>):Session with
IKE ID PAIR (remote-IP, <local-IP>) is UP
%IPSEC:(SESSION ID = <Session-number>) (create_sa) sa created,
(identity) local= <local-IP>, remote= <remote-IP>,
%IKEv2:(SA ID = <SA-number>):[IPsec -> IKEv2] Creation of IPsec SA into
IPsec database PASSED
Termination of IPsec SA
%Removing child SA with spi <SPI-number>
FCS_SSH_EXT.1
Protocol failures
Establishment/Termination
of an SSH session
Reason for failure
Non-TOE endpoint
of connection (IP
address) for both
successes and
failures.
Negotiation “down”: Not applicable. Tunnels are configured by administrators as
either IKEv1 or IKEv2.
SSH Protocol Failure:
%SSH-3-NO_MATCH: No matching kex algorithm found: client ecdh-sha2nistp256 server diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
%SSH-5-SSH2_SESSION: SSH2 Session request from 10.31.0.101 (tty = 0) using
crypto cipher '', hmac '' Failed
%SSH-5-SSH2_CLOSE: SSH2 Session from 10.31.0.101 (tty = 0) for user '' using
crypto cipher '', hmac '' closed
SSH0: Session disconnected - error 0x07
Establishment of an SSH session: %SSH-5-SSH2_SESSION: SSH2 Session
request from [chars] (tty = [dec]) using crypto cipher '[chars]', hmac '[chars]'
[chars]
%SSH-5-SSH2_USERAUTH: User '[chars]' authentication for SSH2 Session
from [chars] (tty = [dec]) using crypto cipher '[chars]', hmac '[chars]' [chars]
Termination of an SSH session: %SSH-5-SSH2_CLOSE: SSH2 Session from
[chars] (tty = [dec]) for user '[chars]' using crypto cipher '[chars]', hmac '[chars]'
closed
FCS_RBG_EXT.1
Failure of the
randomization process.
44
None.
%ENTROPY-0-ENTROPY_ERROR: Unable to collect sufficient entropy
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Requirement
FCS_TLS_EXT.1
Auditable Events
Protocol failures.
Establishment/Termination
of a TLS session.
Additional Audit
Record Contents
Reason for failure.
Non-TOE endpoint
of connection (IP
address) for both
successes and
failures.
Sample Record
%SSHPM-3-NOT_INIT: 1 wcm: Random context not initialized -Traceback:
<thread-ID(s)>
TLS Protocol Failure:
%IOS-3-PEER_CERT_ZERO_LEN: OPSSL_PARSER: Received a zero len cert
from peer for session 0x%x
%DTLS-3-HANDSHAKE_FAILURE: 1 wcm: Failed to complete DTLS
handshake with peer <IP-address> for AP <MAC-address> Reason: <Reason>
Establishment of a TLS session:
%TCP0: state was SYNRCVD -> ESTAB [443 -> <ip-address>(port-number)]
%TCP: tcb <session-identifier> connection to <ip-address>:<port-number>, peer
MSS <value>, MSS is <value>
Establishment of NMSP (TLS session with MSE):
To enable logging of NMSP (TLS) messages between the controller and MSE:
debug nmsp event
debug nmsp connection
debug ssl openssl errors
%IOSXE-7-PLATFORM: 1 process wcm: SSL_state_string=SSL negotiation
finished successfully
%IOSXE-7-PLATFORM: 1 process wcm: current_cipher_str=<cipher>
%IOSXE-7-PLATFORM: 1 process wcm: SSL_state_string=SSL negotiation
finished successfully
%IOSXE-7-PLATFORM: 1 process wcm: SSL_do_handshake() succeeded for
conn ssl a925e820
%IOSXE-7-PLATFORM: 1 process wcm: NMSP connection success! for conn 0
%IOSXE-7-PLATFORM: 1 process wcm: NMSP SPI Callback mse_id = <IPaddr>
%IOSXE-7-PLATFORM: 1 process wcm: Successfully sent NMSP callback
message with SPI.
%IOSXE-7-PLATFORM: 1 process wcm: NMSP SPI Callback mse_id = <IPaddr>
%IOSXE-7-PLATFORM: 1 process wcm: Successfully sent NMSP callback
message with SPI.
NMSP: Server data app - lh 0xFB00003E rh 0x9C000064 len 0.
45
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Requirement
Auditable Events
Additional Audit
Record Contents
Sample Record
NMSP: Connection to MSE is present.
NMSP: Server data app - lh 0xFB00003E rh 0x9C000064 len 8.
NMSP: Connection to MSE (ip: <IP-addr>) is up.
Termination of a TLS session:
%TCP0: FIN processed
%TCP0: state was ESTAB -> CLOSEWAIT [443 -> <ip-address>(port-number)]
%TCP0: state was CLOSEWAIT -> LASTACK [443 -> <ip-address>(portnumber)]
%TCP0: sending FIN
%TCP0: Got ACK for our FIN
%TCP0: state was LASTACK -> CLOSED [443 -> <ip-address>(port-number)]
FDP_RIP.2
FIA_AFL.1
FIA_PMG_EXT.1
FIA_UIA_EXT.1
None.
The reaching of the
threshold for the
unsuccessful
authentication attempts
and the actions taken (e.g.,
disabling of an account)
and the subsequent, if
appropriate, restoration to
the normal state (e.g., reenabling of a terminal).
None.
All use of the
identification and
authentication mechanism.
Termination of NMSP (TLS session with MSE):
%NMSP: Connection to MSE (ip: 9.5.79.51) is down.
%NMSP: Lost connection to MSE (ip: 9.5.79.51).
Not applicable.
To enable the feature: aaa local authentication attempts max-fail <number>
To reset current failure counters: clear aaa local user fail-attempts …
To unlock an account: clear aaa local user lockout …
Limit reached:
%AAA-5-USER_LOCKED: User admin1 locked out on authentication failure
Provided user
identity, origin of
the attempt (e.g., IP
address).
Account unlocked:
%AAA-5-USER_UNLOCKED: User admin1 unlocked by admin2 on vty0 (<IPaddr>)
Not applicable.
Login Success (console):
%SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: auditperson] [Source:
0.0.0.0] [localport: 0] at 07:11:56 UTC Thu Apr 23 2009
Login Success (SSH):
%SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: admin] [Source:
46
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Requirement
Auditable Events
Additional Audit
Record Contents
Sample Record
10.5.34.254] [localport: 22] at 10:52:12 UTC Tue Dec 17 2013
Login Failure (console):
%SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: auditperson] [Source:
0.0.0.0] [localport: 0] [Reason: Login Authentication Failed] at 23:45:43 a Sat Apr
25 2009
FIA_UAU_EXT.5
FIA_UAU.6
FIA_UAU.7
FIA_8021X_EXT.1
All use of the
authentication mechanism.
Attempts to reauthenticate.
None.
Attempts to access to the
802.1X controlled port.
Origin of the attempt
(e.g., IP address).
Origin of the attempt
(e.g., IP address).
Provided client
identity (IP address).
Login Failure (SSH):
%SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: admin] [Source:
10.5.34.254] [localport: 22] [Reason: Login Authentication Failed] at 10:49:33
UTC Tue Dec 17 2013
See FIA_UIA_EXT.1.
See FIA_UIA_EXT.1.
Not applicable.
%SECURITY-7-DOT1X_AUTHENTICATOR_STATE: DOT1X: Port [#]/[#] is in
[one of: disconnected, connecting, held, authenticating, authenticated, aborting,
force_auth, or force_unath] state
%DOT1X-3-CLIENT_NOT_FOUND: Unable to process 802.1X %u msg - client
PRINT_FORMAT_MAC_ADDR not found
%DOT1X-1-AUTHENTICATOR_ERR: Could not function as authenticator - %s;
client PRINT_FORMAT_MAC_ADDR
FIA_PSK_EXT.1
FIA_X509_EXT.1
None.
Attempts to load
certificates.
Attempts to revoke
certificates.
47
None.
%DOT1X-3-ABORT_AUTH: Authentication aborted for client
PRINT_FORMAT_MAC_ADDR
See FCS_IPSEC_EXT.1 audit events
%PARSER-5-CFGLOG_LOGGEDCMD: User:<username> logged
command:crypto pki authenticate <trustpoint-name>
%PARSER-5-CFGLOG_LOGGEDCMD: User:<username> logged
command:crypto pki import <trustpoint-name> certificate
%PARSER-5-CFGLOG_LOGGEDCMD: User: <username> logged command:no
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Requirement
Auditable Events
FMT_MOF.1
FMT_MTD.1(1)
FMT_MTD.1(2)
FMT_MTD.1(3)
FMT_SMF.1
FMT_SMR.1
FPT_ITT.1
FPT_FLS.1
None.
None.
None.
None.
None.
None.
None.
Failure of the TSF.
FPT_RPL.1
Detected replay attacks.
FPT_STM.1
FPT_TST_EXT.1
None.
Execution of this set of
TSF self-tests.
Additional Audit
Record Contents
Indication that the
TSF has failed with
the type of failure
that occurred.
Identity of the user
that was the subject
of the reply attack.
Identity (e.g., source
IP address) of the
source of the replay
attack.
For integrity
violations, the TSF
code file that caused
the integrity
violation.
Sample Record
crypto pki trustpoint <trustpoint-name>
Not applicable.
Not applicable.
Not applicable.
Not applicable.
Not applicable.
Not applicable.
Not applicable.
%IOSXEBOOT-4-ABORT: (rp/0): Signature Verification Failed on <imagefilename>.
%SSH-4-SSH2_UNEXPECTED_MSG: Unexpected message type has arrived.
Terminating the connection
%IPSEC-4-ANTI_REPLAY: SA <SA-identifier>
%LWAPP-3-REPLAY_ERR: Received replay error on slot <value>, WLAN ID
<value>, count <value> from AP <identifier>
%CCAUDIT-3-CC_MSG: 1 wcm: WLC - User ID: <MAC-address> - Replay
Packets detected in DTLS handshake
Not applicable.
Output to console during Power-On Self-Test:
POST: CRYPTO Tests : Begin
POST: CRYPTO Tests : End, Status Passed
%IOSXEBOOT-4-SWTREE: (rp/0): Signature Verification Failed on <imagefilename>
%IOSXEBOOT-4-ABORT: (rp/0): Signature Verification Failed on <imagefilename>.
Syslog message after POST:
%SOAP_FIPS-2-SELF_TEST_IOS_SUCCESS: …
%SOAP_FIPS-2-SELF_TEST_HW_SUCCESS: HW crypto FIPS self test passed
48
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Requirement
FPT_TUD_EXT.1
FRU_RSA.1
FTA_SSL_EXT.1
FTA_SSL.3
FTA_SSL.4
FTA_TAB.1
FTA_TSE.1
FTP_ITC.1
Auditable Events
Additional Audit
Record Contents
Detected integrity
violations.
Maximum quota being
exceeded.
Locking of an interactive
session by the session
locking mechanism.
Any attempts at unlocking
of an interactive session.
The termination of a
remote session by the
session locking
mechanism.
Terminating a session by
quitting or logging off.
No additional
information.
Resource identifier.
None.
Denial of a session
establishment due to the
session establishment
mechanism.
All attempts to establish a
trusted channel.
Detection of modification
of channel data.
49
None.
Sample Record
%CRYPTO-6-SELF_TEST_RESULT: Self test info: …
%Error verifying flash:<filename>
Requires enabling “debug ip ssh”:
SSH: Could not get a vty line for incoming session
Not applicable (idle sessions are terminated, not locked, after the administratorspecified idle timeout limit).
None.
%SYS-6-TTY_EXPIRE_TIMER: (exec timer expired, tty <number> (<ipaddress>)), user <username>
None.
Console:
%HA_EM-6-LOG: cli_log: host[hostname] user[username] port[number]
exec_lvl[level] command[logout ] Executed
Reason for denial,
origin of
establishment
attempt.
Identification of the
initiator and target
of channel.
SSH:
%SYS-6-LOGOUT: User <name> has exited tty session <number>(<IP-addr>)
%SSH0: Session terminated normally
Not applicable.
Location-based denial:
Changing state for mobile 2477.0340.05e8 on AP 2c3f.38aa.b500 to
Disassociated
Day/Time-based denial:
%IOSXE-7-PLATFORM: 2 process wcm: 0040.96b9.4a8b 0.0.0.0 DHCP_REQD
(7) Changing ACL 'timeBasedACL' ===> 'timeBasedACL' --- (caller
acl_shim.c:900)
See events for FCS_IPSEC_EXT.1, FCS_TLS_EXT.1, and FCS_SSH_EXT.1.
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Requirement
FTP_TRP.1
Auditable Events
All attempts to establish a
remote administrative
session.
Detection of modification
of session data.
50
Additional Audit
Record Contents
Identification of the
initiating IT entity
(e.g., IP address).
Sample Record
See events for FCS_IPSEC_EXT.1, FCS_TLS_EXT.1, and FCS_SSH_EXT.1.
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
6 Network Services and Protocols
The table below lists the network services/protocols available on the TOE as a client (initiated
outbound) and/or server (listening for inbound connections), all of which run as system-level
processes. The table indicates whether each service or protocol is allowed to be used in the
certified configuration.
For more detail about each service, including whether the service is limited by firewall mode
(routed or transparent), or by context (single, multiple, system), refer to the Command Reference
guides listed Table 1.
Table 4: Protocols and Services
Service or
Protocol
Description
Client
(initiating)
Allowed
Server
(terminating)
Allowed
Allowed use in
the certified
configuration
AH
Authentication
Header (part of
IPsec)
Yes
Yes
Yes
Yes
No restrictions.
ESP must be used
in all IPsec
connections. Use
of AH in addition
to ESP is optional.
DHCP
Dynamic Host
Configuration
Protocol
Yes
Yes
Yes
Yes
No restrictions.
DNS
Domain Name
Service
Yes
Yes
No
n/a
No restrictions.
ESP
Encapsulating
Security Payload
(part of IPsec)
Yes
Yes
Yes
Yes
Configure ESP as
described in the
IPsec
configuration
section of this
document.
FTP
File Transfer
Protocol
Yes
No
No
n/a
Use HTTPS
instead.
HTTP
Hypertext
Transfer
Protocol
Yes
No
Yes
No
Use HTTPS
instead.
HTTPS
Hypertext
Transfer
Protocol Secure
Yes
Yes
Yes
Yes
No restrictions.
ICMP
Internet Control
Message
Protocol
Yes
Yes
Yes
Yes
No restrictions.
51
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Service or
Protocol
Description
Client
(initiating)
Allowed
Server
(terminating)
Allowed
Allowed use in
the certified
configuration
IKE
Internet Key
Exchange
Yes
Yes
Yes
Yes
As described in
section 3.5 of this
document.
IPsec
Internet Protocol
Security (suite of
protocols
including IKE,
ESP and AH)
Yes
Yes
Yes
Yes
Only to be used for
Tunneling
SNMPv3,
RADIUS, Syslog,
and NTP traffic.
See IKE and ESP
for other usage
restrictions.
NTP
Network Time
Protocol
Yes
Yes
No
n/a
Any configuration.
Use of key-based
authentication is
recommended.
RADIUS
Remote
Authentication
Dial In User
Service
Yes
Yes
No
n/a
If used for
authentication of
TOE
administrators,
secure through
HTTPS or TLS.
SNMP
Simple Network
Management
Protocol
Yes (snmptrap)
Yes
Yes
No
Over IPsec only.
SSH
Secure Shell
Yes
Yes
Yes
Yes
As described in
section 3.5.1.3
SSL (not
TLS)
Secure Sockets
Layer
Yes
No
Yes
No
Use TLS instead.
TACACS+
Terminal Access
Controller
Access-Control
System Plus
Yes
Yes
No
n/a
If used for
authentication of
administrators,
secure through
IPsec.
Telnet
A protocol used
for terminal
emulation
Yes
No
Yes
No
Use SSH or
HTTPS instead.
TLS
Transport Layer
Security
Yes
Yes
Yes
Yes
As described in the
section 3.6.2 of
this document.
The table above does not include the types of protocols and services listed here:
52
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
•
•
OSI Layer 2 protocols such as CDP, VLAN protocols like 802.11q, Ethernet encapsulation
protocols like PPPoE, etc. The certified configuration places no restrictions on the use of these
protocols; however evaluation of these protocols was beyond the scope of the Common Criteria
product evaluation. Follow best practices for the secure usage of these services.
Routing protocols such as OSPF, the certified configuration places no restrictions on the use of
these protocols, however evaluation of these protocols was beyond the scope of the Common
Criteria product evaluation, so follow best practices for the secure usage of these protocols.
7 Modes of Operation
When configured in the Common Criteria evaluated configuration, which requires that they
operate in FIPS mode, the Controllers and APs support the following modes of operation.
7.1 Controller Modes
Controllers have four (4) modes of operation.
1. Booting, including power-on self tests (POST), including cryptographic self tests.
•
In this mode all network connectivity is disabled.
•
The serial console port is covered with a tamper-evident seal from the FIPS kit,
so nothing is visible or accessible via the console port.
•
The boot process cannot be interrupted, and no maintenance mode.
2. Normal operation.
3. Partial loss of connectivity to servers.
a. Loss of connectivity to a syslog server. The controller will continue to send
syslog messages to accessible syslog servers, and continue attempts to reestablish connections to any other syslog servers.
b. Loss of connectivity to a RADIUS server. In the CC-certified configuration,
wireless clients must be authenticated using RADIUS, so when all RADIUS
servers are inaccessible, no new wireless client sessions can be established. In
the CC-certified configuration RADIUS can optionally be used for authentication
of Administrators, can Controllers can be configured to fall-back to use a
local/internal accounts when RADIUS is inaccessible.
c. Loss of connectivity to Prime Infrastructure. The Controller will continue to
operate normally.
d. Loss of connectivity to MSE. The Controller will continue to operate normally,
though wIPS messages will not get sent, and will continue to be lost until
connectivity is restored.
4. Shutdown. There is no state in which a Controller is shutting down, it’s either powered
off (or unplugged), or it reloads (changes from normal operation to booting).
7.2 AP Modes
APs have three (3) modes of operation. There is no state in which the AP is shutting down, it’s
either powered off (or unplugged), or it reloads (changes from normal operation to booting).
53
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
1. Booting, including power-on self tests (POST), including cryptographic tests.
a. In this mode, all network connectivity is disabled (wired and wireless).
b. The boot process cannot be interrupted.
2. Normal operation (joined with a Controller). During normal operation the APs operate as
‘Lightweight’ APs, maintaining constant communication with a Controller for remote
management, authentication of wireless clients, and transmission of audit messages.
3. Joining. When an AP is not actively joined with a Controller, it will continue to send
attempt to contact or “join” one of its configured Controllers. In this mode, the AP does
not forward traffic from wireless clients, nor authenticate wireless clients.
Note: The following AP modes are not permitted/supported in the Common Criteria certified
configuration: Autonomous (standalone); Remote-Edge Access Point (REAP); FlexConnect
(formerly Hybrid REAP or HREAP); or Teleworker AP.
8 Security Measures for the Operational Environment
Proper operation of the TOE requires functionality from the environment. It is the responsibility
of the authorized administrator of the TOE to ensure that the Operational Environment provides
the necessary functions, and adheres to the environment security objectives listed below. The
environment security objective identifiers map to the environment security objectives as defined
in the Security Target.
Table 5: Securing the Operational Environment
Environmental Security Objective
How to Achieve the Objective
There are no general-purpose computing
capabilities (e.g., compilers or user applications)
available to the WLAN system, other than those
services necessary for the operation, administration
and support of the WLAN system.
This objective is achieved by using the evaluated
Cisco WLAN system components, which are all
appliance or service-module solutions, not
software-only application components installed to a
host operating system (OS) which is not part of the
CC-certified WLAN system.
Information cannot flow between external and
internal networks located in different enclaves
without passing through the WLAN system.
Wireless clients are configured so that information
cannot flow between a wireless client and any other
wireless client or host networked to the WLAN
system without passing through the WLAN system.
Physical security, commensurate with the value of
the TOE and the data it contains, is assumed to be
provided by the operational environment.
Ensure all deployed components of the operational
environment (those mentioned in section 2.1 of this
document) are physically secured in a manner that
restricts access to authorized personnel only.
TOE Administrators are trusted to follow and apply Administrators of the technical and physical
all administrator guidance in a trusted manner.
operational environment must be appropriately
trained and trusted.
9 Related Documentation
Use this document in conjunction with the Cisco WLAN documentation at the following location:
http://www.cisco.com/en/US/products/hw/wireless/index.html
Obtaining Documentation
54
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
The following sections provide sources for obtaining documentation from Cisco Systems.
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at the following sites:
http://www.cisco.com
http://www-china.cisco.com
http://www-europe.cisco.com
Documentation CD-ROM
Cisco documentation and additional literature are available in a CD-ROM package, which ships
with your product. The Documentation CD-ROM is updated monthly and may be more current than
printed documentation. The CD-ROM package is available as a single unit or as an
annual subscription.
Ordering Documentation
Cisco documentation is available in the following ways:
Registered Cisco Direct Customers can order Cisco Product documentation from the Networking
Products MarketPlace:
http://www.cisco.com/cgi-bin/order/order_root.pl
Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription
Store:
http://www.cisco.com/go/subscription
Non-registered Cisco.com users can order documentation through a local account representative by
calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, in North America, by
calling 800 553-NETS (6387).
Documentation Feedback
If you are reading Cisco product documentation on the World Wide Web, you can submit technical
comments electronically. Click Feedback in the toolbar and select Documentation. After you complete
the form, click Submit to send it to Cisco.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, for your convenience many documents contain a response card
behind the front cover. Otherwise, you can mail your comments to the following address:
Cisco Systems, Inc., Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can
obtain documentation, troubleshooting tips, and sample configurations from online tools. For
Cisco.com registered users, additional troubleshooting tools are available from the TAC website.
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate,
open access to Cisco information and resources at anytime, from anywhere in the world. This highly
integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.
55
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Cisco.com provides a broad range of features and services to help customers and partners streamline
business processes and improve productivity. Through Cisco.com, you can find information about
Cisco and our networking solutions, services, and programs. In addition, you can resolve technical
issues with online technical support, download and test software packages, and order Cisco learning
materials and merchandise. Valuable online skill assessment, training, and certification programs are
also available.
Customers and partners can self-register on Cisco.com to obtain additional personalized information
and services. Registered users can order products, check on the status of an order, access technical
support, and view benefits specific to their relationships with Cisco.
To access Cisco.com, go to the following website:
http://www.cisco.com
56
Cisco WLAN Controllers 3650, 3850, and 5760 Common Criteria Configuration Guide
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising