Cisco IOS Configuration Guide for Autonomous Cisco Aironet Access Points - Release 15.3(3)JE and later

Open Authentication to the Access Point

Open authentication allows any device to authenticate and then attempt to communicate with the access point. Using open authentication, any wireless device can authenticate with the access point, Open authentication does not rely on a RADIUS server on your network.

In a scenario where you use Open authentication and WEP encryption, authentication will be successful even if the client and the AP WEP are mismatched. The client will not be able to send data (including DHCP requests) after Open authentication completes. However, with Open authentication and no encryption, the wireless client can transmit data as soon as the association phase is complete.

Figure 11-1 shows the authentication sequence between a device trying to authenticate and an access point using open authentication. In this example, the device’s WEP key does not match the access point’s key, so it can authenticate but not pass data.

Figure 11-1 Sequence for Open Authentication

WEP Shared Key Authentication to the Access Point

Cisco provides shared key authentication to comply with WEP authentication described in the 802.11 standard. However, because of a shared key’s security flaws WEP has been deprecated. The IEEE and Cisco recommend that you avoid using it.

During shared key authentication, the access point sends an unencrypted challenge text string to any device attempting to communicate with the access point. The device requesting authentication encrypts the challenge text and sends it back to the access point. If the challenge text is encrypted correctly, the access point allows the requesting device to authenticate. Both the unencrypted challenge and the encrypted challenge can be monitored, however, which leaves the access point open to attack from an intruder who calculates the WEP key by comparing the unencrypted and encrypted text strings. Because of this weakness, shared key authentication can be less secure than open authentication. Like open authentication, shared key authentication does not rely on a RADIUS server on your network.

Figure 11-2 shows the authentication sequence between a device trying to authenticate and an access point using shared key authentication. In this example the device’s WEP key matches the access point’s key, so it can authenticate and communicate.

Figure 11-2 Sequence for Shared Key Authentication

EAP Authentication to the Network

This authentication type provides the highest level of security for your wireless network. By using the Extensible Authentication Protocol (EAP) to interact with an EAP-compatible RADIUS server, the access point helps a wireless client device and the RADIUS server to perform mutual authentication and derive a dynamic unicast key. The RADIUS server sends the key to the access point, which uses it for all unicast data signals that it sends to or receives from the client. The access point also encrypts its broadcast key with the client’s unicast key and sends it to the client.

Depending on the underlying security framework (802.1X with dynamic WEP, WPA or WPA 2), the key is used:

• In the case of WEP – directly by the Access Point for all unicast data signals that it sends to or receives from the client,
• In the case of WPAv1/v2 – the key is used to derive unicast keys that are used for all unicast data signals that it sends to or receives from the client.

When you enable EAP on your access points and client devices, authentication to the network occurs in the sequence shown in Figure 11-3:

Figure 11-3 Sequence for EAP Authentication

In Steps 1 through 9 in Figure 11-3, a wireless client device and a RADIUS server on the wired LAN use 802.1x and EAP to perform a mutual authentication through the access point. The RADIUS server sends an authentication challenge to the client. The client uses a one-way encryption of the user-supplied or machine-supplied credentials to generate a response to the challenge and sends that response to the RADIUS server. Using information from its user database, the RADIUS server creates its own response and compares that to the response from the client. When the RADIUS server authenticates the client, the process repeats in reverse, and the client authenticates the RADIUS server.

When mutual authentication is complete, the RADIUS server and the client determine a a WEP key or a Pairwise Master Key (WPAv1/v2) that is unique to the client and provides the client with the appropriate level of network access, thereby approximating the level of security in a wired switched segment to an individual desktop. The client loads this key and prepares to use it for the logon session.

During the logon session, the RADIUS server encrypts and sends the WEP key, or the WPAv1/v2 Pairwise Master Key, over the wired LAN to the access point. The AP uses this key to encrypt its broadcast key, and sends the encrypted broadcast key to the client, which uses its identical unicast key to decrypt it. The client and access point activate encryption and use the unicast and broadcast keys for all communications during the remainder of the session.

There is more than one type of EAP authentication, but the access point behaves the same way for each type: it relays authentication messages from the wireless client device to the RADIUS server and from the RADIUS server to the wireless client device. See the “Assigning Authentication Types to an SSID” section for instructions on setting up EAP on the access point.

Note If you use EAP authentication, you can select open or shared key authentication, but you do not have to. EAP authentication controls authentication both to your access point and to your network.

MAC Address Authentication to the Network

The access point relays the wireless client device’s MAC address to a RADIUS server on your network, and the server checks the address against a list of allowed MAC addresses. Intruders can create counterfeit MAC addresses, so MAC-based authentication is less secure than EAP authentication. However, MAC-based authentication provides an alternate authentication method for client devices that do not have EAP capability. See the “Assigning Authentication Types to an SSID” section for instructions on enabling MAC-based authentication.

Tip If you do not have a RADIUS server on your network, you can create a list of allowed MAC addresses on the access point’s Advanced Security: MAC Address Authentication page. Devices with MAC addresses not on the list are not allowed to authenticate.

Tip If MAC-authenticated clients on your wireless LAN roam frequently, you can enable a MAC authentication cache on your access points. MAC authentication caching reduces overhead because the access point authenticates devices in its MAC-address cache without sending the request to your authentication server. See the “Configuring MAC Authentication Caching” section for instructions on enabling this feature.

Figure 11-4 shows the authentication sequence for MAC-based authentication.

Figure 11-4 Sequence for MAC-Based Authentication

Combining MAC-Based, EAP, and Open Authentication

You can set up the access point to authenticate client devices using a combination of MAC-based and EAP authentication. When you enable this feature, client devices that associate to the access point using 802.11 open authentication first attempt MAC authentication; if MAC authentication succeeds, the client device joins the network. If MAC authentication fails, EAP authentication takes place. See the “Assigning Authentication Types to an SSID” section for instructions on setting up this combination of authentications.

Using CCKM for Authenticated Clients

Using Cisco Centralized Key Management (CCKM), authenticated client devices can roam from one access point to another without any perceptible delay during reassociation. An access point on your network provides Wireless Domain Services (WDS) and creates a cache of security credentials for CCKM-enabled client devices on the subnet. The WDS access point’s cache of credentials dramatically reduces the time required for reassociation when a CCKM-enabled client device roams to a new access point. When a client device roams, the WDS access point forwards the client’s security credentials to the new access point, and the reassociation process is reduced to a two-packet exchange between the roaming client and the new access point. Roaming clients re associate so quickly that there is no perceptible delay in voice or other time-sensitive applications. See the “Assigning Authentication Types to an SSID” section for instructions on enabling CCKM on your access point. See the “Configuring Access Points as Potential WDS Devices” for detailed instructions on setting up a WDS access point on your wireless LAN.

Note The RADIUS-assigned VLAN feature is not supported for client devices that associate using SSIDs with CCKM enabled.

Figure 11-5 shows the reassociation process using CCKM.

Figure 11-5 Client Reassociation Using CCKM

Using WPA Key Management

WPAv1 is a Wi-Fi Alliance certification based on an early draft of the 802.11i amendment. WPAv1 leverages TKIP (Temporal Key Integrity Protocol) for data protection. WPAv2 is a Wi-Fi Alliance certification based on the final 802.11i amendment published in the year 2004. WPAv2 leverages AES (Advanced Encryption Standard) with the Counter-Mode Cipher Block Chaining (CBC) Message Authentication Code (MAC) Protocol. Both WPAv1 and WPAv2 allow authentication using pre-shared key (PSK) for home-type of deployment, and 802.1X for authenticated key management for enterprise-type of deployments.

Note WPA recommends the use of TKIP, and allows the use of AES. WPA2 recommends the use of AES-CCMP, and allows the use of TKIP for backward compatibility. Cisco and the Wi-Fi Alliance recommend that you do not use WPAv1 with AES, or WPAv2 with TKIP. The strongest level of security is achieved with WPAv2 and AES-CCMP. WPAv1 and TKIP can be used in networks where clients do not support WPAv2 with AES-CCMP.

Using WPA (WPAv1 or WPAv2) key management, clients and the authentication server authenticate to each other using an EAP authentication method, and the client and server generate a pairwise master key (PMK). Using WPA, the server generates the PMK dynamically and passes it to the access point. Using WPA-PSK, however, you configure a pre-shared key on both the client and the access point, and that pre-shared key is used as the PMK.

WPA key management supports two mutually exclusive management types: WPA and WPA-pre-shared key (WPA-PSK). Using WPA key management, clients and the authentication server authenticate to each other using an EAP authentication method, and the client and server generate a pairwise master key (PMK). Using WPA, the server generates the PMK dynamically and passes it to the access point. Using WPA-PSK, however, you configure a pre-shared key on both the client and the access point, and that pre-shared key is used as the PMK.

Note Unicast and multicast cipher suites advertised in WPA information element (and negotiated during 802.11 association) may potentially mismatch with the cipher suite supported in an explicitly assigned VLAN. If the RADIUS server assigns a new vlan ID which uses a different cipher suite from the previously negotiated cipher suite, there is no way for the access point and client to switch back to the new cipher suite. Currently, the WPA and CCKM protocols does not allow the cipher suite to be changed after the initial 802.11 cipher negotiation phase. In this scenario, the client device is disassociated from the wireless LAN.

See the “Assigning Authentication Types to an SSID” section for instructions on configuring WPA key management on your access point.

Figure 11-6 shows the WPA key management process.

Figure 11-6 WPA Key Management Process

Assigning Authentication Types to an SSID

The SSID you configure will be mapped to a VLAN or a radio interface. Hence, make sure that the authentication type you define for the SSID is compatible with the encryption type defined for the associated VLAN or radio interface. See “Understanding Authentication and Encryption Mechanisms,” for more details.

Beginning in privileged EXEC mode, follow these steps to configure authentication types for SSIDs:

Use the no form of the SSID commands to disable the SSID or to disable SSID features.

This example sets the authentication type for the SSID batman to Network-EAP with CCKM authenticated key management. Client devices using the batman SSID authenticate using the adam server list. After they are authenticated, CCKM-enabled clients can perform fast reassociations using CCKM.

Configuring WPA Migration Mode for Legacy WEP SSIDs

WPA migration is a specific mode intended for SSIDs needing to support legacy WEP client types while still allowing for more secure authentication and encryption. This specific mode allows for the following client device types:

• WPA clients capable of TKIP and authenticated key management
• 802.1X-2001 clients (such as legacy LEAP clients and clients using TLS) capable of authenticated key management but not TKIP
• Static-WEP clients not capable of TKIP or authenticated key management

If all three client types associate using the same SSID, the multicast cipher suite for the SSID must be WEP. If only the first two types of clients use the same SSID the multicast key can be dynamic, but if the static-WEP clients use the SSID, the key must be static. The access point can switch automatically between a static and a dynamic group key to accommodate associated client devices. To support all three types of clients on the same SSID, you must configure the static key in key slots 2 or 3.

To set up an SSID for WPA migration mode, configure these settings:

• WPA optional
• A cipher suite containing TKIP and 40-bit or 128-bit WEP
• A static WEP key in key slot 2 or 3

This example sets the SSID migrate for WPA migration mode:

Configuring Additional WPA Settings

Use two optional settings to configure a pre-shared key on the access point and adjust the frequency of group key updates.

Setting a pre-shared Key

To support WPA (WPAv1 or WPAv2) on a wireless LAN where 8021X/EAP-based authentication is not available, you must configure a pre-shared key on the access point. You can enter the pre-shared key as ASCII or hexadecimal characters. If you enter the key as ASCII characters, you enter between 8 and 63 characters, and the access point expands the key using the process described in the Password-based Cryptography Standard (RFC2898). If you enter the key as hexadecimal characters, you must enter 64 hexadecimal characters.

Configuring Group Key Updates

In the last step in the WPA process, the access point distributes a group key to the authenticated client device. You can use these optional settings to configure the access point to change and distribute the group key based on client association and disassociation:

• Membership termination—the access point generates and distributes a new group key when any authenticated device disassociates from the access point. This feature keeps the group key private for associated devices, but it might generate some overhead traffic if clients on your network roam frequently among access points.
• Capability change—the access point generates and distributes a dynamic group key when there is a change in the cell clients capability. For example, in a cell allowing AES, TKIP and WEP and currently containing only AES clients, the broadcast key uses AES. The access point generates a new broadcast key using TKIP when the first TKIP client joins the cell, and generates a new broadcast key when the first WEP client joins the cell. Symmetrically, the access point generates a new broadcast key when the last WEP client leaves the cell. If at that time all clients support AES, the new broadcast key will use AES. If some clients use TKIP and others use AES (AES clients also support TKIP), the new broadcast key will use TKIP. When the last TKIP client leaves the cell, with only AES clients left in the cell, the access point generates a new broadcast key using AES.

Beginning in privileged EXEC mode, follow these steps to configure a WPA pre-shared key and group key update options:

This example shows how to configure a pre-shared key for clients using WPA and static WEP, with group key update options:

Configuring MAC Authentication Caching

If MAC-authenticated clients on your wireless LAN roam frequently, you can enable a MAC authentication cache on your access points. MAC authentication caching reduces overhead because the access point authenticates devices in its MAC-address cache without sending the request to your authentication server. When a client device completes MAC authentication to your authentication server, the access point adds the client’s MAC address to the cache.

Beginning in privileged EXEC mode, follow these steps to enable MAC authentication caching:

This example shows how to enable MAC authentication caching with a one-hour timeout:

Use the no form of the dot11 aaa authentication mac-authen filter-cache command to disable MAC authentication caching. For example:

or

Configuring Authentication Holdoffs, Timeouts, and Intervals

Beginning in privileged EXEC mode, follow these steps to configure holdoff times, reauthentication periods, and authentication timeouts for client devices authenticating through your access point:

Use the no form of these commands to reset the values to default settings.

Creating and Applying EAP Method Profiles for the 802.1X Supplicant

This section describes the optional configuration of an EAP method list for the 802.1X supplicant. Configuring EAP method profiles enables the supplicant not to acknowledge some EAP methods, even though they are available on the supplicant. For example, if a RADIUS server supports EAP-FAST and LEAP, under certain configurations, the server might initially employ LEAP instead of a more secure method. If no preferred EAP method list is defined, the supplicant supports LEAP, but it may be advantageous to force the supplicant to force a more secure method such as EAP-FAST.

See Creating a Credentials Profile for additional information about the 802.1X supplicant.

Creating an EAP Method Profile

Beginning in privileged exec mode, follow these steps to define a new EAP profile:

Use the no command to negate a command or set its defaults.

Use the show eap registrations method command to view the currently available (registered) EAP methods.

Use the show eap sessions command to view existing EAP sessions.

Applying an EAP Profile to the Fast Ethernet Interface

This operation normally applies to access points that need to be authenticated against a RADIUS server, when they are connected to a switch port that is configured to perform 802.1x authentication of connected devices. The AP will act as a 802.1x client, and will need to provide credentials to be authenticated.

Beginning in privileged exec mode, follow these steps to apply an EAP profile to the Fast Ethernet interface:

Applying an EAP Profile to an Uplink SSID

This operation typically applies to repeater access points, non-root bridges and workgroup bridges needing to authenticate over their radio link to a root-AP or root bridge. Beginning in the privileged exec mode, follow these steps to apply an EAP profile to the uplink SSID.

Web Authentication

Web authentication enables the Autonomous AP to block IP traffic (except DHCP & DNS-related packets) until the guest provides a valid username and password.

In web authentication, a separate username and password must be defined for each guest. Using the username and password, the guest is authenticated either by the local radius server or an external RADIUS server.

Web authentication is supported with Open, dot1x. and PSK authentication types. All encryption types are allowed.

Configuring Web Authentication (GUI)

Perform these steps to enable web authentication:

Step 1 Browse to the Security page on the access point GUI.

Step 2 Select SSID Manager.

Step 3 Check the Web Authentication check box.

Configuring Web Authentication (CLI)

Beginning in privileged EXEC mode, use these commands to enable web authentication with Open authentication:

• To configure web authentication with Open authentication.

– ap(config)# dot11 ssid guestssid

– ap(config-ssid)# web-auth

– ap(config-ssid)# authentication open

– ap(config-ssid)# exit

• To enable web authentication:

– ap(config)# ip admission name Web_auth proxy http

– ap(config)# interface dot11Radio 0

– ap(config-if)# ip admission Web_auth

Beginning in privileged EXEC mode, use these commands to enable web authentication with dot1x authentication:

• To configure web authentication with web authentication.

– ap(config)# dot11 ssid guestssid

– ap(config-ssid)# web-auth

– ap(config-ssid)# authentication open eap eap_methods

– ap(config-ssid)# authentication network-eap eap_methods

– ap(config-ssid)# authentication key-management wpa version 2

– ap(config-ssid)# exit

• To enable web authentication:

– ap(config)# ip admission name Web_auth proxy http

– ap(config)# interface dot11Radio 0

– ap(config-if)# ip admission Web_auth

– ap(config-if)# encryption mode ciphers aes-ccm

A sample configuration for web authentication with dot1x authentication is shown below:

Web Pass-through

Web Pass-through is similar to Web Authentication. However, the guest is not required to provide authentication details.

In Web Pass-through, guests are redirected to the usage policy page when they use the Internet for the first time. When the policy is accepted, access is granted. The access point redirects the guest to the policy page.

Perform these steps to enable web authentication:

Step 1 Browse to the Security page on the access point GUI.

Step 2 Select SSID Manager.

Step 3 Check the Web Pass check box.

Beginning in privileged EXEC mode, use these commands to enable Web Pass-through:

– ap(config)# ip admission name Web_passthrough consent

– ap(config)# interface dot11Radio 0

– ap(config-if)# ip admission Web_passthrough

Note Web Authentication or Web Pass-through works in an interface only when there is no VLAN. The IP admission Web_auth or IP admission Web_passthrough must be configured in the VLAN when the SSID is mapped to the VLAN.

Guest Account Creation

Perform these steps to create new guest accounts:

Step 1 Browse to Management > Guest Management Services page on the access point in the GUI.

Step 2 Select New to create a new guest account.

The Webauth page is displayed.

Step 3 Enter these values:

• Username
• Password
• Confirm Password
• Lifetime

Step 4 To let the system automatically generate a random string as a password, check the Generate Password check box. Alternatively, you can manually enter the password value.

Step 5 Click Apply.

Perform these steps to delete an existing user:

Step 1 Browse to the Guest Management Services page on the access point GUI.

Step 2 Select the username to be deleted.

Step 3 Click Delete.

A confirmation message appears.

Step 4 Click Ok to delete the user or Cancel to cancel the changes.

Beginning in privileged EXEC mode, use these commands to create guest accounts using CLI commands:

– ap(config)# dot11 guest

– ap(config-guest-mode)# username Gues-1 lifetime 40 password t_ksdgon

– ap(config-guest-mode)# username Gues-2 lifetime 35 password gp2

– ap(config)# exit

Guest access is allowed for a maximum of twenty-four days (35791 minutes) and a minimum of five minutes.

Beginning in privileged EXEC mode, use this command to delete a guest user:

ap# clear dot11 guest-user Gues-1

Beginning in privileged EXEC mode, use this command to display guest users:

ap# show dot11 guest-users

Customized Guest Access Pages

The Webauth Login guest access pages can be customized to display a custom logo or other images. You can customize the Login page, Success page, Failure page, or the Expired page. To customize a page, follow these steps:

Step 1 Save the image to be displayed in the customized page, on a web server and set the web server's IP address as allowed in the ACL in/out lists.

Step 2 Get the default HTML code of the page to be customized.

Step 3 Edit the source code of the page to insert the images, by specifying the full path of the image files on the web-server. For example: <Body background="http://40.40.5.10/image.jpg" width="600" height="600">, where the image.jpg file resides on the web server with IP address 40.40.5.10.

Note When editing the HTML code of the default page, do not make any changes to the code for the submit function and for the fields of Username and Password.

Step 4 Save the customized pages to the web server.

Step 5 In the access point GUI, browse to the Management > Guest Management Services page.

Step 6 Select Webauth Login.

Step 7 Browse and upload these pages from the web server:

• Login Page
• Success Page
• Failure Page
• Expired page

Note It is mandatory to load the Login page, Success page, Failure page, and Expired page when you customize the guess access login.

Step 8 Select the file transfer method: FTP or TFTP.

Step 9 Enter the Username.

Step 10 Enter the Password.

Step 11 Enter the Allowed-In ACL Name and the Allowed-Out ACL Name.

Step 12 Click Close Window to save your changes.

Alternatively, you can use the following CLI commands to configure a customized guest access page. Copy all edited files to the flash memory. Then, beginning in privileged EXEC mode, use these commands to load all the edited files from flash:

– ap(config)# ip auth-proxy proxy http login page file flash:web_login.html

– ap(config)# ip auth-proxy proxy http success page file flash:web_success.html

– ap(config)# ip auth-proxy proxy http failure page file flash:web_fail.html

– ap(config)# ip auth-proxy proxy http login expired page file flash:web_logout.html

To configure the IP address of the web server (IP address here is 40.40.5.10) in the ACL, the following commands are also required. Beginning in privileged EXEC mode, use these ACL commands:

– ap(config)# dot11 webauth allowed incoming webauth_acl_in outgoing webaut_acl_out

– ap(config)# ip access-list extended webauth_acl_in

– ap(config-ext-nacl)# permit tcp any host 40.40.5.10 eq www

– ap(config-ext-nacl)# permit tcp any host 40.40.5.10 eq 443

– ap(config-ext-nacl)# permit tcp any host 40.40.5.10 eq 443

– ap(config-ext-nacl)# exit

– ap(config)# ip access-list extended webauth_acl_out

– ap(config-ext-nacl)# permit tcp any host 40.40.5.10 eq www

– ap(config-ext-nacl)# permit tcp any host 40.40.5.10 eq 443

– ap(config-ext-nacl)# exit

Note In the previous commands acl-in and acl-out are the names of the Access-list. These ACLs allow you to download the image file from the machine, where it is stored and use it for the customization of web page.

The default page displays only the username, password, OK page.

Guest access does not support these:

• IPv6
• SNMP
• Roaming

Bypassing Captive Portals

Android, Apple, and Windows clients connect to a Wi-Fi network using a captive portal. These devices check whether Internet connectivity is available at the time of association itself. If no connectivity is available then the client does not associate with the wireless network. This can be a problem in autonomous AP networks if Web Authentication or Web Pass-through is enforced.

In autonomous AP networks where web authentication or web pass-through is enforced, network connectivity is provided only upon successful authentication or pass-through. However, since the captive portal happens before web authentication or web pass-through, the clients will fail to join the network.

To overcome this, on Android and Windows clients, you can perform a web authentication or web pass-through using a browser, even when captive portal fails. However, Apple clients do not allow user to open a web browser if captive portal has failed. To resolve this, for Apple clients you can set the Captive Portal Bypass feature.

Captive Portal Bypass for Apple Clients (CLI)

To bypass the captive portal feature of apple clients, use the command dot11 captive-portal-bypass.

This command works for both web authentication and web pass-through.

To disable this bypass, use the command no dot11 captive-portal-bypass.

Captive Portal Bypass for Apple Clients (GUI)

To bypass the captive portal feature of apple clients, choose Management > Webauth Login.

You can enable or disable this bypass feature by clicking the corresponding option in Captive Portal Bypass (only for Apple clients) field.