The Cisco Unified Wireless Network (UWN) security solution bundles potentially complicated Layer 1, Layer 2, and Layer 3 802.11 Access Point security components into a simple policy manager that customizes system-wide security policies on a per-WLAN basis. The Cisco UWN security solution provides simple, unified, and systematic security management tools.

One of the biggest hurdles to WLAN deployment in the enterprise is WEP encryption, which is a weak standalone encryption method. A newer problem is the availability of low-cost access points, which can be connected to the enterprise network and used to mount man-in-the-middle and denial-of-service attacks.

The Cisco UWN security solution ensures that all clients gain access within a user-set number of attempts. If a client fails to gain access within that limit, it is automatically excluded (blocked from access) until the user-set timer expires. The operating system can also disable SSID broadcasts on a per-WLAN basis.

If a higher level of security and encryption is required, you can also implement industry-standard security solutions such as Extensible Authentication Protocol (EAP), Wi-Fi Protected Access (WPA), and WPA2. The Cisco UWN solution WPA implementation includes AES (Advanced Encryption Standard), TKIP and Michael (temporal key integrity protocol and message integrity code checksum) dynamic keys, or WEP (Wired Equivalent Privacy) static keys. Disabling is also used to automatically block Layer 2 access after a user-set number of failed authentication attempts.

Regardless of the wireless security solution selected, all Layer 2 wired communications between controllers and lightweight access points are secured by passing data through CAPWAP tunnels.

The WEP problem can be further solved using industry-standard Layer 3 security solutions such as passthrough VPNs (virtual private networks).

The Cisco UWN solution supports local and RADIUS MAC (media access control) filtering. This filtering is best suited to smaller client groups with a known list of 802.11 access card MAC addresses.

The Cisco UWN solution supports local and RADIUS user/password authentication. This authentication is best suited to small to medium client groups.

The integrated security solutions are as follows:

• Cisco Unified Wireless Network (UWN) solution operating system security is built around a 802.1X AAA (authorization, authentication and accounting) engine, which allows users to rapidly configure and enforce a variety of security policies across the Cisco UWN solution.

• The controllers and lightweight access points are equipped with system-wide authentication and authorization protocols across all ports and interfaces, maximizing system security.

• Operating system security policies are assigned to individual WLANs, and lightweight access points simultaneously broadcast all (up to 16) configured WLANs, which can eliminate the need for additional access points, which can increase interference and degrade system throughput.

• Operating system security uses the RRM function to continually monitor the air space for interference and security breaches and to notify the user when they are detected.

• Operating system security works with industry-standard authorization, authentication, and accounting (AAA) servers.

Remote Authentication Dial-In User Service (RADIUS) is a client/server protocol that provides centralized security for users attempting to gain management access to a network. It serves as a backend database similar to local and TACACS+ and provides authentication and accounting services:

• Authentication—The process of verifying users when they attempt to log into the controller.

  Users must enter a valid username and password in order for the controller to authenticate users to the RADIUS server. If multiple databases are configured, you can specify the sequence in which the backend database must be tired.

• Accounting—The process of recording user actions and changes.

  Whenever a user successfully executes an action, the RADIUS accounting server logs the changed attributes, the user ID of the person who made the change, the remote host where the user is logged in, the date and time when the command was executed, the authorization level of the user, and a description of the action performed and the values provided. If the RADIUS accounting server becomes unreachable, users are able to continue their sessions uninterrupted.

RADIUS uses User Datagram Protocol (UDP) for its transport. It maintains a database and listens on UDP port 1812 for incoming authentication requests and UDP port 1813 for incoming accounting requests. The controller, which requires access control, acts as the client and requests AAA services from the server. The traffic between the controller and the server is encrypted by an algorithm defined in the protocol and a shared secret key configured on both devices.

You can configure multiple RADIUS accounting and authentication servers. For example, you may want to have one central RADIUS authentication server but several RADIUS accounting servers in different regions. If you configure multiple servers of the same type and the first one fails or becomes unreachable, the controller automatically tries the second one, then the third one if necessary, and so on.

When a management user is authenticated using a RADIUS server, only the PAP protocol is used. For web authentication users, PAP, MSCHAPv2 and MD5 security mechanisms are supported.

• Specify whether the IP address, system MAC address, AP MAC address, AP Ethernet MAC address of the originator will be sent to the RADIUS server in the Access-Request message by entering this command:

  config radius callStationIdType {ipaddr | macaddr | ap-macaddr-only | ap-macaddr-ssid | | | ap-group-name | ap-location | ap-name | ap-name-ssid | flex-group-name | vlan-id}

  Note	The default is System MAC Address.

  Caution

  Do not use Call Station ID Type for IPv6-only clients.

• Specify the delimiter to be used in the MAC addresses that are sent to the RADIUS authentication or accounting server in Access-Request messages by entering this command:

  config radius {auth | acct} mac-delimiter {colon | hyphen | single-hyphen | none}

  where

  • colon sets the delimiter to a colon (the format is xx:xx:xx:xx:xx:xx).

  • hyphen sets the delimiter to a hyphen (the format is xx-xx-xx-xx-xx-xx). This is the default value.

  • single-hyphen sets the delimiter to a single hyphen (the format is xxxxxx-xxxxxx).

  • none disables delimiters (the format is xxxxxxxxxxxx).

• Configure a RADIUS authentication server by entering these commands:

  • config radius auth add index server_ip_address port_number {ascii | hex} shared_secret—Adds a RADIUS authentication server.

  • config radius auth keywrap {enable | disable}—Enables AES key wrap, which makes the shared secret between the controller and the RADIUS server more secure. AES key wrap is designed for Federal Information Processing Standards (FIPS) customers and requires a key-wrap compliant RADIUS authentication server.

  • config radius auth keywrap add {ascii | hex} kek mack index—Configures the AES key wrap attributes

    where

    • kek specifies the 16-byte Key Encryption Key (KEK).

    • mack specifies the 20-byte Message Authentication Code Key (MACK).

    • index specifies the index of the RADIUS authentication server on which to configure the AES key wrap.

  • config radius auth rfc3576 {enable | disable} index—Enables or disables RFC 3576, which is an extension to the RADIUS protocol that allows dynamic changes to a user session. RFC 3576 includes support for disconnecting users and changing authorizations applicable to a user session and supports disconnect and change-of-authorization (CoA) messages. Disconnect messages cause a user session to be terminated immediately where CoA messages modify session authorization attributes such as data filters.

  • config radius auth retransmit-timeout index timeout—Configures the retransmission timeout value for a RADIUS authentication server.

  • config radius auth mgmt-retransmit-timeout index timeout—Configures the default management login retransmission timeout for a RADIUS authentication server.

  • config radius auth network index {enable | disable}—Enables or disables network user authentication. If you enable this feature, this entry is considered the RADIUS authentication server for network users. If you did not configure a RADIUS server entry on the WLAN, you must enable this option for network users.

  • config radius auth management index {enable | disable}—Enables or disables management authentication. If you enable this feature, this entry is considered the RADIUS authentication server for management users, and authentication requests go to the RADIUS server.

  • config radius auth ipsec {enable | disable} index—Enables or disables the IP security mechanism.

  • config radius auth ipsec authentication {hmac-md5 | hmac-sha1} index—Configures the authentication protocol to be used for IP security.

  • config radius auth ipsec encryption {3des | aes | des | none} index—Configures the IP security encryption mechanism.

  • config radius auth ipsec ike dh-group {group-1 | group-2 | group-5} index—Configures the IKE Diffie-Hellman group.

  • config radius auth ipsec ike lifetime interval index—Configures the timeout interval for the session.

  • config radius auth ipsec ike phase1{aggressive | main} index—Configures the Internet Key Exchange (IKE) protocol.

  • config radius auth ipsec ike auth-method {PSK | certificate} index—Configures the IKE authentication methods. By default PSK is be used for IPSEC sessions.

  • config radius auth ipsec ike auth-mode pre-shared-key index hex/asciisecret—Configures the IPSEC pre-shared key.

  • config radius auth {enable | disable} index—Enables or disables a RADIUS authentication server.

  • config radius auth delete index—Deletes a previously added RADIUS authentication server.

• Configure a RADIUS accounting server by entering these commands:

  • config radius acct add index server_ip_address port# {ascii | hex} shared_secret—Adds a RADIUS accounting server.

  • config radius acct server-timeout index timeout—Configures the retransmission timeout value for a RADIUS accounting server.

  • config radius acct network index {enable | disable}—Enables or disables network user accounting. If you enable this feature, this entry is considered the RADIUS accounting server for network users. If you did not configure a RADIUS server entry on the WLAN, you must enable this option for network users.

  • config radius acct ipsec {enable | disable} index—Enables or disables the IP security mechanism.

  • config radius acct ipsec authentication {hmac-md5 | hmac-sha1} index—Configures the authentication protocol to be used for IP security.

  • config radius acct ipsec encryption { 3des | aes | des | none} index—Configures the IP security encryption mechanism.

  • config radius acct ipsec ike dh-group {group-1 | group-2 | group-5} index—Configures the IKE Diffie Hellman group.

  • config radius acct ipsec ike lifetime interval index—Configures the timeout interval for the session.

  • config radius acct ipsec ike phase1{aggressive | main} index—Configures the Internet Key Exchange (IKE) protocol.

  • config radius acct {enable | disable} index—Enables or disables a RADIUS accounting server.

  • config radius acct delete index—Deletes a previously added RADIUS accounting server.

  • config radius auth callStationIdType {ap-macaddr-only | ap-macaddr-ssid}—Sets the Called Station ID type to be AP’s radio MAC address or AP’s radio MAC address with SSID in the <AP radio MAC address>:<SSID> format.

  • config radius auth callStationIdType {ipaddr | macaddr}—Sets the Called Station ID type to use the IP address (only Layer 3) or system's MAC address.

• Configure the RADIUS server fallback behavior by entering this command:

  config radius fallback-test mode {off | passive | active}

  where

  • off disables RADIUS server fallback.

  • passive causes the controller to revert to a server with a lower priority from the available backup servers without using extraneous probe messages. The controller simply ignores all inactive servers for a time period and retries later when a RADIUS message needs to be sent.

  • active causes the controller to revert to a server with a lower priority from the available backup servers by using RADIUS probe messages to proactively determine whether a server that has been marked inactive is back online. The controller simply ignores all inactive servers for all active RADIUS requests. Once the primary server receives a response from the recovered ACS server, the active fallback RADIUS server no longer sends probe messages to the server requesting the active probe authentication.

• If you enabled Active mode in Step 5, enter these commands to configure additional fallback parameters:

  • config radius fallback-test username username—Specifies the name to be sent in the inactive server probes. You can enter up to 16 alphanumeric characters for the username parameter.

  • config radius fallback-test interval interval—Specifies the probe interval value (in seconds).

• Save your changes by entering this command: save config

• Configure the order of authentication when multiple databases are configured by entering this command:

  config aaa auth mgmt AAA_server_type AAA_server_type

  where AAA_server_type is local, radius, or tacacs.

  To see the current management authentication server order, enter the show aaa auth command.

• See RADIUS statistics by entering these commands:

  • show radius summary—Shows a summary of RADIUS servers and statistics with AP Ethernet MAC configurations.

  • show radius auth statistics—Shows the RADIUS authentication server statistics.

  • show radius acct statistics—Shows the RADIUS accounting server statistics.

  • show radius rfc3576 statistics—Shows a summary of the RADIUS RFC-3576 server.

• See active security associations by entering these commands:

  • show ike {brief | detailed} ip_or_mac_addr—Shows a brief or detailed summary of active IKE security associations.

  • show ipsec {brief | detailed} ip_or_mac_addr—Shows a brief or detailed summary of active IPSec security associations.

• Clear the statistics for one or more RADIUS servers by entering this command:

  clear stats radius {auth | acct} {index | all}

• Make sure that the controller can reach the RADIUS server by entering this command:

  ping server_ip_address

Terminal Access Controller Access Control System Plus (TACACS+) is a client/server protocol that provides centralized security for users attempting to gain management access to a controller. It serves as a backend database similar to local and RADIUS. However, local and RADIUS provide only authentication support and limited authorization support while TACACS+ provides three services:

• Authentication—The process of verifying users when they attempt to log into the controller.

  Users must enter a valid username and password in order for the controller to authenticate users to the TACACS+ server. The authentication and authorization services are tied to one another. For example, if authentication is performed using the local or RADIUS database, then authorization would use the permissions associated with the user in the local or RADIUS database (which are read-only, read-write, and lobby-admin) and not use TACACS+. Similarly, when authentication is performed using TACACS+, authorization is tied to TACACS+.

  Note	When multiple databases are configured, you can use the controller GUI or CLI to specify the sequence in which the backend databases should be tried.

• Authorization—The process of determining the actions that users are allowed to take on the controller based on their level of access.

  For TACACS+, authorization is based on privilege (or role) rather than specific actions. The available roles correspond to the seven menu options on the controller GUI: MONITOR, WLAN, CONTROLLER, WIRELESS, SECURITY, MANAGEMENT, and COMMANDS. An additional role, LOBBY, is available for users who require only lobby ambassador privileges. The roles to which users are assigned are configured on the TACACS+ server. Users can be authorized for one or more roles. The minimum authorization is MONITOR only, and the maximum is ALL, which authorizes the user to execute the functionality associated with all seven menu options. For example, a user who is assigned the role of SECURITY can make changes to any items appearing on the Security menu (or designated as security commands in the case of the CLI). If users are not authorized for a particular role (such as WLAN), they can still access that menu option in read-only mode (or the associated CLI show commands). If the TACACS+ authorization server becomes unreachable or unable to authorize, users are unable to log into the controller.

  Note

  If users attempt to make changes on a controller GUI page that are not permitted for their assigned role, a message appears indicating that they do not have sufficient privilege. If users enter a controller CLI command that is not permitted for their assigned role, a message may appear indicating that the command was successfully executed although it was not. In this case, the following additional message appears to inform users that they lack sufficient privileges to successfully execute the command: “Insufficient Privilege! Cannot execute command!”

• Accounting—The process of recording user actions and changes.

  Whenever a user successfully executes an action, the TACACS+ accounting server logs the changed attributes, the user ID of the person who made the change, the remote host where the user is logged in, the date and time when the command was executed, the authorization level of the user, and a description of the action performed and the values provided. If the TACACS+ accounting server becomes unreachable, users are able to continue their sessions uninterrupted.

TACACS+ uses Transmission Control Protocol (TCP) for its transport, unlike RADIUS which uses User Datagram Protocol (UDP). It maintains a database and listens on TCP port 49 for incoming requests. The controller, which requires access control, acts as the client and requests AAA services from the server. The traffic between the controller and the server is encrypted by an algorithm defined in the protocol and a shared secret key configured on both devices.

You can configure up to three TACACS+ authentication, authorization, and accounting servers each. For example, you may want to have one central TACACS+ authentication server but several TACACS+ authorization servers in different regions. If you configure multiple servers of the same type and the first one fails or becomes unreachable, the controller automatically tries the second one and then the third one if necessary.

Note	If multiple TACACS+ servers are configured for redundancy, the user database must be identical in all the servers for the backup to work properly.

• Configure a TACACS+ authentication server by entering these commands:

  • config tacacs auth add index server_ip_address port# {ascii | hex} shared_secret—Adds a TACACS+ authentication server.

  • config tacacs auth delete index—Deletes a previously added TACACS+ authentication server.

  • config tacacs auth (enable | disable} index—Enables or disables a TACACS+ authentication server.

  • config tacacs auth server-timeout index timeout—Configures the retransmission timeout value for a TACACS+ authentication server.

• Configure a TACACS+ authorization server by entering these commands:

  • config tacacs athr add index server_ip_address port# {ascii | hex} shared_secret—Adds a TACACS+ authorization server.

  • config tacacs athr delete index—Deletes a previously added TACACS+ authorization server.

  • config tacacs athr (enable | disable} index—Enables or disables a TACACS+ authorization server.

  • config tacacs athr server-timeout index timeout—Configures the retransmission timeout value for a TACACS+ authorization server.

• Configure a TACACS+ accounting server by entering these commands:

  • config tacacs acct add index server_ip_address port# {ascii | hex} shared_secret—Adds a TACACS+ accounting server.

  • config tacacs acct delete index—Deletes a previously added TACACS+ accounting server.

  • config tacacs acct (enable | disable} index—Enables or disables a TACACS+ accounting server.

  • config tacacs acct server-timeout index timeout—Configures the retransmission timeout value for a TACACS+ accounting server.

• See TACACS+ statistics by entering these commands:

  • show tacacs summary—Shows a summary of TACACS+ servers and statistics.

  • show tacacs auth stats—Shows the TACACS+ authentication server statistics.

  • show tacacs athr stats—Shows the TACACS+ authorization server statistics.

  • show tacacs acct stats—Shows the TACACS+ accounting server statistics.

• Clear the statistics for one or more TACACS+ servers by entering this command:

  clear stats tacacs [auth | athr | acct] {index | all}

• Configure the order of authentication when multiple databases are configured by entering this command. The default setting is local and then radius.

  config aaa auth mgmt [radius | tacacs]

  See the current management authentication server order by entering the show aaa auth command.

• Make sure the controller can reach the TACACS+ server by entering this command:

  ping server_ip_address

• Enable or disable TACACS+ debugging by entering this command:

  debug aaa tacacs {enable | disable}

• Save your changes by entering this command:

  save config

You can configure the controller to specify the maximum number of local database entries used for storing user authentication information. The database entries include local management users (including lobby ambassadors), local network users (including guest users), MAC filter entries, exclusion list entries, and access point authorization list entries. Together they cannot exceed the configured maximum value.

The password policies allows you to enforce strong password checks on newly created passwords for additional management users of controller and access point. The following are the requirements enforced on the new password:

• When the controller is upgraded from old version, all the old passwords are maintained as it is, even though the passwords are weak. After the system upgrade, if strong password checks are enabled, the same is enforced from that time and the strength of previously added passwords will not be checked or altered.

• Depending on the settings done in the Password Policy page, the local management and access point user configuration is affected.

• Enable or disable strong password check for AP and WLC by entering this command:

  config switchconfig strong-pwd {case-check | consecutive-check | default-check | username-check | all-checks} {enable | disable}

  where
  • case-check—Checks the occurrence of same character thrice consecutively
  • consecutive-check—Checks the default values or its variants are being used.
  • default-check—Checks either username or its reverse is being used.
  • all-checks—Enables/disables all the strong password checks.

• See the configured options for strong password check by entering this command:

  show switchconfig

  Information similar to the following appears:

  
  802.3x Flow Control Mode......................... Disabled
  FIPS prerequisite features....................... Disabled
  secret obfuscation............................... Enabled
  Strong Password Check Features:
  
           case-check ...........Enabled
           consecutive-check ....Enabled
           default-check .......Enabled
           username-check ......Enabled
  

This section explains how to configure a Lightweight Directory Access Protocol (LDAP) server as a backend database, similar to a RADIUS or local user database.

The Cisco Identity Services Engine (ISE) is a next-generation, context-based access control solution that provides the functions of Cisco Secure Access Control System (ACS) and Cisco Network Admission Control (NAC) in one integrated platform.

ISE has been introduced in the 7.0.116.0 release of the Cisco Unified Wireless Network. ISE can be used to provide advanced security for your deployed network. It is an authentication server that you can configure on your controller. When a client associates to the controller on a RADIUS NAC–enabled WLAN, the controller forwards the request to the ISE server.

The ISE server validates the user in the database and on successful authentication, the URL and pre-AUTH ACL are sent to the client. The client then moves to the Posture Required state and is redirected to the URL returned by the ISE server.

Note	The client moves to the Central Web Authentication state, if the URL returned by the ISE server has the keyword 'cwa'.

The NAC agent in the client triggers the posture validation process. On successful posture validation by the ISE server, the client is moved to the run state.

Note	Flex local switching with Radius NAC support is added in Release 7.2.110.0. It is not supported in 7.0 Releases and 7.2 Releases. Downgrading 7.2.110.0 and later releases to either 7.2 or 7.0 releases will require you to reconfigure the WLAN for Radius NAC feature to work.

The management over wireless feature allows you to monitor and configure local controllers using a wireless client. This feature is supported for all management tasks except uploads to and downloads from (transfers to and from) the controller.

You can access the controller with one of its dynamic interface IP addresses. Both the wired and wireless clients can access the dynamic interface of the controller using the CLI and GUI. To access the GUI of the controller enter the dynamic interface IP address of the controller in the address field of either Internet Explorer or Mozilla Firefox browser. For wired clients, you must enable management of dynamic interface and must ensure that the wired client is in the VLAN that is mapped to the dynamic interface.

A device, when the management using dynamic interfaces is disabled, can open an SSH connection, if the protocol is enabled. However, you are not prompted to log on. Additionally, the management address remains accessible from a dynamic interface VLAN, unless a CPU ACL is in place. When management using dynamic interface is enabled along with CPU ACL, the CPU ACL has more priority.

Here, management is not the management interface but the configuration access. If the Cisco WLC configuration is accessed from any other IP address on the Cisco WLC other than the management IP, it is management using dynamic interface.

DHCP option 82 provides additional security when DHCP is used to allocate network addresses. It enables the controller to act as a DHCP relay agent to prevent DHCP client requests from untrusted sources. You can configure the controller to add option 82 information to DHCP requests from clients before forwarding the requests to the DHCP server.

The access point forwards all DHCP requests from a client to the controller. The controller adds the DHCP option 82 payload and forwards the request to the DHCP server. The payload can contain the MAC address or the MAC address and SSID of the access point, depending on how you configure this option.

Note	Any DHCP packets that already include a relay agent option are dropped at the controller.

For DHCP option 82 to operate correctly, DHCP proxy must be enabled.

On the controller CLI, you can enable DHCP option 82 on the dynamic interface to which the WLAN is associated by entering this command:

• Configure the format of the DHCP option 82 payload by entering one of these commands:

  • config dhcp opt-82 remote-id ap_mac—Adds the radio MAC address of the access point to the DHCP option 82 payload.
  • config dhcp opt-82 remote-id ap_mac:ssid—Adds the radio MAC address and SSID of the access point to the DHCP option 82 payload.
  • config dhcp opt-82 remote-id ap-ethmac—Adds the Ethernet MAC address of the access point to the DHCP option 82 payload.

• Enable DHCP Option 82 on the dynamic interface to which the WLAN is associated by entering this command:

  config interface dhcp dynamic-interface interface-name option-82 enable

• See the status of DHCP option 82 on the dynamic interface by entering the show interface detailed dynamic-interface-namecommand.

An Access Control List (ACL) is a set of rules used to limit access to a particular interface (for example, if you want to restrict a wireless client from pinging the management interface of the controller). After ACLs are configured on the controller, they can be applied to the management interface, the AP-manager interface, any of the dynamic interfaces, or a WLAN to control data traffic to and from wireless clients or to the controller central processing unit (CPU) to control all traffic destined for the CPU.

You may also want to create a preauthentication ACL for web authentication. Such an ACL could be used to allow certain types of traffic before authentication is complete.

Both IPv4 and IPv6 ACL are supported. IPv6 ACLs support the same options as IPv4 ACLs including source, destination, source and destination ports.

Note	You can enable only IPv4 traffic in your network by blocking IPv6 traffic. That is, you can configure an IPv6 ACL to deny all IPv6 traffic and apply it on specific or all WLANs.

Management frame protection (MFP) provides security for the otherwise unprotected and unencrypted 802.11 management messages passed between access points and clients. MFP provides both infrastructure and client support.

• Infrastructure MFP—Protects management frames by detecting adversaries that are invoking denial-of-service attacks, flooding the network with associations and probes, interjecting as rogue access points, and affecting network performance by attacking the QoS and radio measurement frames. Infrastructure MFP is a global setting that provides a quick and effective means to detect and report phishing incidents.

  Specifically, infrastructure MFP protects 802.11 session management functions by adding message integrity check information elements (MIC IEs) to the management frames emitted by access points (and not those emitted by clients), which are then validated by other access points in the network. Infrastructure MFP is passive. It can detect and report intrusions but has no means to stop them.

• Client MFP—Shields authenticated clients from spoofed frames, preventing many of the common attacks against wireless LANs from becoming effective. Most attacks, such as deauthentication attacks, revert to simply degrading performance by contending with valid clients.

  Specifically, client MFP encrypts management frames are sent between access points and CCXv5 clients so that both the access points and clients can take preventative action by dropping spoofed class 3 management frames (that is, management frames passed between an access point and a client that is authenticated and associated). Client MFP leverages the security mechanisms defined by IEEE 802.11i to protect the following types of class 3 unicast management frames: disassociation, deauthentication, and QoS (WMM) action. Client MFP protects a client-access point session from the most common type of denial-of-service attack. It protects class 3 management frames by using the same encryption method used for the session’s data frames. If a frame received by the access point or client fails decryption, it is dropped, and the event is reported to the controller.

  To use client MFP, clients must support CCXv5 MFP and must negotiate WPA2 using either TKIP or AES-CCMP. EAP or PSK may be used to obtain the PMK. CCKM and controller mobility management are used to distribute session keys between access points for Layer 2 and Layer 3 fast roaming.

  Note

  To prevent attacks using broadcast frames, access points supporting CCXv5 will not emit any broadcast class 3 management frames (such as disassociation, deauthentication, or action). CCXv5 clients and access points must discard broadcast class 3 management frames. Client MFP supplements infrastructure MFP rather than replaces it because infrastructure MFP continues to detect and report invalid unicast frames sent to clients that are not client-MFP capable as well as invalid class 1 and 2 management frames. Infrastructure MFP is applied only to management frames that are not protected by client MFP. Infrastructure MFP consists of three main components:

• Management frame protection—The access point protects the management frames it transmits by adding a MIC IE to each frame. Any attempt to copy, alter, or replay the frame invalidates the MIC, causing any receiving access point configured to detect MFP frames to report the discrepancy. MFP is supported for use with Cisco Aironet lightweight access points.

• Management frame validation—In infrastructure MFP, the access point validates every management frame that it receives from other access points in the network. It ensures that the MIC IE is present (when the originator is configured to transmit MFP frames) and matches the content of the management frame. If it receives any frame that does not contain a valid MIC IE from a BSSID belonging to an access point that is configured to transmit MFP frames, it reports the discrepancy to the network management system. In order for the timestamps to operate properly, all controllers must be Network Time Protocol (NTP) synchronized.

• Event reporting—The access point notifies the controller when it detects an anomaly, and the controller aggregates the received anomaly events and can report the results through SNMP traps to the network management system.

  Note	Client MFP uses the same event reporting mechanisms as infrastructure MFP.

Infrastructure MFP is disabled by default and can be enabled globally. When you upgrade from a previous software release, infrastructure MFP is disabled globally if access point authentication is enabled because the two features are mutually exclusive. Once infrastructure MFP is enabled globally, signature generation (adding MICs to outbound frames) can be disabled for selected WLANs, and validation can be disabled for selected access points.

Client MFP is enabled by default on WLANs that are configured for WPA2. It can be disabled, or it can be made mandatory (in which case, only clients that negotiate MFP are allowed to associate) on selected WLANs.

• Enable or disable infrastructure MFP globally for the controller by entering this command: config wps mfp infrastructure {enable | disable}

• Enable or disable client MFP on a specific WLAN by entering this command:

  config wlan mfp client {enable | disable} wlan_id [required ]

  If you enable client MFP and use the optional required parameter, clients are allowed to associate only if MFP is negotiated.

• See the controller’s current MFP settings by entering this command:

  show wps mfp summary

• See the current MFP configuration for a particular WLAN by entering this command:

  show wlan wlan_id

• See whether client MFP is enabled for a specific client by entering this command:

  show client detail client_mac

• See MFP statistics for the controller by entering this command: show wps mfp statistics

  Note	This report contains no data unless an active attack is in progress. This table is cleared every 5 minutes when the data is forwarded to any network management stations.

• Use this command if you experience any problems with MFP:

  debug wps mfp ? {enable | disable}

  where ? is one of the following:

  client—Configures debugging for client MFP messages.

  capwap—Configures debugging for MFP messages between the controller and access points.

  detail—Configures detailed debugging for MFP messages.

  report—Configures debugging for MFP reporting.

  mm—Configures debugging for MFP mobility (inter-controller) messages.

In most wireless LAN systems, each WLAN has a static policy that applies to all clients associated with an SSID. Although powerful, this method has limitations because it requires clients to associate with different SSIDs to inherit different QoS and security policies.

However, the Cisco Wireless LAN solution supports identity networking, which allows the network to advertise a single SSID but allows specific users to inherit different QoS or security policies based on their user profiles. The specific policies that you can control using identity networking are as follows:

• ACL—When the ACL attribute is present in the RADIUS Access Accept, the system applies the ACL name to the client station after it authenticates, which overrides any ACLs that are assigned to the interface.

• VLAN—When a VLAN Interface-name or VLAN tag is present in a RADIUS Access Accept, the system places the client on a specific interface.

  Note	The VLAN feature only supports MAC filtering, 802.1X, and WPA. The VLAN feature does not support web authentication or IPsec.

• Tunnel Attributes.

  Note	When any of the other RADIUS attributes (QoS-Level, ACL-Name, Interface-Name, or VLAN-Tag), which are described later in this section, are returned, the Tunnel Attributes must also be returned.

The operating system’s local MAC filter database has been extended to include the interface name, allowing local MAC filters to specify to which interface the client should be assigned. A separate RADIUS server can also be used, but the RADIUS server must be defined using the Security menus.