Security

Securing the Air

Many configuration examples are available on cisco.com, showing very specific configuration. Here, we highlight the usual security combinations and the configuration logic, not the detailed steps.

WPA2 Personal

When adding a WLAN, as depicted in Figure 5-26, simply choose WPA+WPA2 as the Layer 2 security mode. Fast Transition is possible to configure with a PSK but does not bring a lot of advantages to the table.

FIGURE 5-26 WPA 2 PSK SSID settings

The standard configuration, as shown in Figures 5-27 and 5-28, is PSK as AKM with AES128. GCMP is a protocol that allows for fast encryption of very high throughputs of data but is not required at typical Wi-Fi 6 speeds yet, and 256 bits of encryption is typically used in conjunction with WPA3 (although not necessarily, because not all clients support it).

FIGURE 5-27 WPA2 PSK Layer2 security settings

FIGURE 5-28 WPA2 PSK SSID key configuration

Enter the key as unencrypted if you are typing it manually. You would choose an AES key if the passphrase you were pasting is already AES-encrypted (if you were copying from an existing encrypted configuration file, for example).

Figure 5-29 shows the Robust Security Network (RSN) information element (a field from the beacon frame of the AP) of the WPA2 PSK SSID illustrated in Figure 5-26.

FIGURE 5-29 RSN information element of a beacon frame of a WPA PSK SSID

WPA3 SAE

For configuring SAE, select WPA3 (starting with 17.6 IOS-XE) or WPA2+WPA3 as the security mode, as shown in Figure 5-30. As a reminder, FT is not supported with SAE at this time.

FIGURE 5-30 SAE WLAN example configuration

Choose AES-128 and SAE for the AKM, as shown in Figure 5-31. WPA3 offers the same 128-bit encryption as was used with WPA2 but allows you to turn it up to 256 bits and offers the choice between the same CCMP mode of operation or to use Galois Counter Mode Protocol (GCMP). GCMP was meant to be used with 802.11ac wave 2 because it is better suited for very high throughput encryption, but it did not get traction in the field back then, especially on the client side. Many WPA3-certified devices now support 256-bit AES and GCMP.

FIGURE 5-31 Ciphers option example for SAE

Enter your preshared key unencrypted, as depicted in Figure 5-32, and you should be good to go.

FIGURE 5-32 PSK configuration for SAE

If you take a wireless capture and look at the beacon RSN IE, you can see SAE advertised as the authentication key management method (see Figure 5-33).

FIGURE 5-33 SAE advertised in the SSID beacon RSN IE

WPA2 with iPSK

The concept of Identity PSK is to use a different WPA preshared key depending on the identity of the client connecting. This differs from MPSK, where several keys are available, and anyone can use any key. In this method, you rely on the AAA server to return a specific key, depending on the authentication result. iPSK is covered in detail in Configure Catalyst 9800 WLC iPSK With Cisco ISE on cisco.com, but let’s tackle the important points and use the opportunity to explain the concepts of RADIUS attributes. On the WLC side, you need to create a WPA PSK WLAN and add MAC filtering, as illustrated in Figure 5-34. The MAC filtering is basically an excuse to reach out to the AAA server and initiate a RADIUS conversation; the intent is not necessarily to authorize the MAC address.

FIGURE 5-34 iPSK SSID security settings part 1

As you can see in Figure 5-35, you still need to configure a PSK that is the default key, used when the AAA server returns only a permit-access and not specifying any extra key.

FIGURE 5-35 iPSK SSID security settings part 2

The AAA method used in MAC filtering is a “aaa authorization network” type. The policy profile used also needs to allow AAA override for the WLC to accept RADIUS attributes returned by the AAA server.

On the Cisco ISE side, you have many options. You can enter specific devices’ MAC addresses in the endpoint database so that MAC addresses are authenticated. You could also configure your authentication policy to proceed and continue with the authorization despite the authentication failing if the user is not found. Figure 5-36 illustrates an example of authorization rules you could configure. The first rule returns an access-accept along with the PSK “Cisco123” that the client has to use. The second rule illustrates the fact that you do not necessarily have to enter specific MAC addresses in your RADIUS server database but can use any of the RADIUS attributes present in the authentication request.

FIGURE 5-36 ISE authorization policies for IPSK

This example uses the called-station-id and relies on the fact that the 9800 is configured to specify the AP locations in that attribute. You can configure it under Configuration > Security > AAA > AAA Advanced > Global Config > Show Advanced Settings, as shown in Figure 5-37. The same page also allows you to specify the MAC address format that will be handy if you are using a third-party RADIUS server such as FreeRadius You can therefore define a specific key to use in a specific area of the network, regardless of who the client is. It could also be an option to write a rule based on the device group the client MAC belongs to (either through static group membership in the ISE endpoint database or through profiling dynamic rules): your creativity and the existing RADIUS attributes set are the limit.

FIGURE 5-37 Customization of the called-station-id RADIUS field

The custom authorization results are straightforward and only need two attributes that are Cisco proprietary and called cisco-av-pair (they are shown in Figure 5-38). The first attribute is cisco-av-pair, and the value is psk=<actual key you want to use>, whereas the other is an identical cisco-av-pair and its value is ascii because you probably want to use your WPA key as an ASCII key.

FIGURE 5-38 ISE authorization result

iPSK works because the MAC filtering is an authentication that happens at the 802.11 association phase. The AP or WLC authenticates the MAC address before replying with an association response, and therefore, this is a time-sensitive process where the client can give up on waiting for this association response and move to another channel if your RADIUS server is not quick enough.

Let’s take a look at the RADIUS exchange from the RadioActive Trace output taken from the Catalyst 9800. The exchange is simple: the controller sends an access-request mentioning the MAC address of the client as both username and password. The RADIUS server is expected to reply with access-accept or access-reject. Example 5-2 shows the request, as sent by the 9800 for an iPSK SSID.

Example 5-2 Always-On Logs Corresponding to a RADIUS Access-Request Packet Being Sent

wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Send Access-Request to
192.168.1.99:1812 id 0/59, len 384
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: authenticator 9b 9e 12
1c 3b d9 d2 b3 - 53 4d f5 f0 2b 63 ae 1c
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: User-Name        [1] 
14  "e87f95532012"
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: User-Password    [2] 
18  *
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Service-Type     [6]     
6  Call Check  [10]
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Vendor, Cisco    [26]   
31
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS:  Cisco AVpair    [1] 
25  “service-type=Call Check”
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Framed-MTU       [12]    
6  1485
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Message-
Authenticator[80]    18  ...
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: EAP-Key-Name     [102]
2  *
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Vendor, Cisco    [26]   
49
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS:  Cisco AVpair    [1] 
43  “audit-session-id=8501A8C00000004ECC162224”
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Vendor, Cisco    [26]   
18
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS:  Cisco AVpair    [1] 
12  “method=mab”
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Vendor, Cisco    [26]   
30
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS:  Cisco AVpair    [1] 
24  “client-iif-id=50334480”
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Vendor, Cisco    [26]   
17
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS:  Cisco AVpair    [1] 
11  "vlan-id=1"
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: NAS-IP-Address   [4]     
6  192.168.1.133
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: NAS-Port-Id      [87] 
17  "capwap_9000001b"
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: NAS-Port-Type    [61]    
6  802.11 wireless           [19]
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: NAS-Port         [5]
6  116
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Vendor, Cisco    [26] 
28
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS:  Cisco AVpair    [1] 
22  "cisco-wlan-ssid=iPSK"
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Vendor, Cisco    [26] 
30
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS:  Cisco AVpair    [1] 
24  "wlan-profile-name=iPSK"
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Called-Station-Id  
[30]    24  "d4-ad-bd-a2-8f-20:iPSK"
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Calling-Station-Id  
[31]    19  "e8-7f-95-53-20-12"
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Vendor, Airespace  
[26]    12
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS:  Airespace-WLAN-ID  [1]  
6  5
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Nas-Identifier  
[32]    7   "Katar"

Note a couple of interesting RADIUS attributes:

• User-name: In this case, the client didn’t initiate any authentication and therefore does not provide any username. It’s the 9800 that decides to fill the User-name field with the MAC address using a specific format.

• User-password: This is one of the few fields that is encrypted with the RADIUS shared secret.

• Service-type: Although the naming of the possible options doesn’t match current usages (they go back to the origin of RADIUS for dial-up communications), they depict whether the authentication is a MAC authentication or an 802.1X authentication, for example (“Call check” in the case of MAC, “Framed” in case of 802.1X).

• Framed MTU: The controller expresses the MTU it can honor for RADIUS. It is interesting to note that the RADIUS server is not required to follow this value, and Cisco ISE doesn’t follow it; therefore, fragmentation of RADIUS packets can occur.

• Message authenticator: This field is encrypted using the shared secret, to make sure the WLC is allowed to communicate with the RADIUS server.

• Cisco AVPair : A couple of Cisco AVPairs mention some additional and optional information such as the SSID name, the WLAN profile name, the VLAN, or the fact that it’s a MAC address filtering authentication (“method=mab”).

• Audit-session-id : It is created by the WLC and serves as session ID (for example, if you want to terminate the session via CoA from ISE) even when accounting is not in use.

• Airespace-WLAN-ID : The Catalyst 9800 keeps using the same Airespace proprietary attributes introduced by the former generation of WLCs, which specifies the WLAN ID the client is connecting to.

• Calling-station-id : This attribute is always the MAC address of the client.

• Called-station-id : This attribute is, by default, the MAC address of the AP but can be customized to append other values. Here, the SSID name is appended to it.

All these attributes can be used to create authentication and authorization rules in the ISE, which means it is possible to authenticate the client based on where it is trying to connect, on which SSID it is trying to connect, its MAC address, and so on.

After this request, the RADIUS server replies with an access-accept, authorizing the client on the network and also providing the PSK that this client should be using, as shown in Example 5-3.

Example 5-3 Always-On Logs Corresponding to a RADIUS Access-Accept Packet Being Received

wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Received from id
1812/59 192.168.1.99:0, Access-Accept, len 185
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: authenticator 2c d3 14
54 c5 e4 f2 7d - e1 4a b3 ee 80 ba 3f 2f
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: User-Name           [1]  
19  "E8-7F-95-53-20-12"
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Class  
[25]    50  ...
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Message-
Authenticator[80]    18  ...
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Vendor, Cisco  
[26]    23
wncd_x_R0-0{1}: [radius] [25734]: (info): *
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS:  Cisco AVpair      [1]
17
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Vendor, Cisco  
[26]    22
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS:  Cisco AVpair      [1]  
16  "psk-mode=ascii"
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS: Vendor, Cisco  
[26]    33
wncd_x_R0-0{1}: [radius] [25734]: (info): RADIUS:  Cisco AVpair      [1]  
27  "profile-name=Apple-Device"

iPSK becomes a bit trickier to use for clients such as smartphones that now typically use a private MAC address by default (that is subject to change) but stays relevant for IoT devices that typically have a fixed MAC address because privacy is not their concern.

iPSK is supported in FlexConnect local switching mode. The P2P blocking action configuration drop-down in the WLAN advanced settings allows for an “allow private group” intriguing setting. This, when combined with iPSK, allows users using the same PSK to talk to each other but not talk to users using a different PSK.

Enhanced Open

Let’s cover a typical use case where you, as administrator, want to configure Enhanced Open but still allow older clients to be able to connect to the guest SSID. Figure 5-39 shows the final result: one WLAN is configured for WPA3 Enhanced Open (called OWE), and the other is a fully open SSID. Only the fully open SSID called “Open” has its name broadcasted in the beacons while Enhanced Open is hidden.

FIGURE 5-39 A pair of Open/Enhanced Open SSIDs for Enhanced Open Transition mode

For this example, create the first SSID, call it EnhancedOpen (in reality, choose a name that is relevant for your company), and make sure it is hidden by disabling Broadcast SSID, as depicted in Figure 5-40.

FIGURE 5-40 Enhanced Open SSID general settings

Configure the security settings to be WPA3 with OWE as AKM and choose a cipher (AES 128 is a good conservative choice for a guest SSID), as shown in Figures 5-41 and 5-42. The last field asks you for the transition mode WLAN ID. This basically asks you for the “other SSID in the pair.” So, when configuring the Enhanced Open SSID, enter the WLAN ID of the open SSID (4 in this example).

FIGURE 5-41 Enhanced Open security settings part 1

FIGURE 5-42 Enhanced Open SSID security settings part 2

Proceed with the creation of the regular open SSID, which is broadcasted and with no particular security settings other than enabling OWE transition mode and specifying the WLAN ID of the Enhanced Open SSID, as shown in Figure 5-43.

FIGURE 5-43 Regular open SSID linked with transition mode to an Enhanced Open SSID

When you’re done, if you look at the scan list of SSIDs for a wireless client present in the area where the WLANs are active, no matter what it supports, it shows only the Open SSID (because it is the only one broadcasted). If your client does not support Enhanced Open, it connects to the Open SSID, and it is business as usual. If your client supports Enhanced Open, even if you click the “Open” SSID in the list of heard SSIDs, in reality you are connected to the secure SSID. You can see from the Monitor > Clients page in the WebUI that the client is, in fact, using encryption, as depicted in Figure 5-44.

FIGURE 5-44 Security details of a client connected to an Enhanced Open SSID

(Local) Web Authentication

Cisco.com offers a great guide titled Configuring Web-based Authentication on Cisco Catalyst 9800 Series Controllers covering the various types of web authentication available on the Catalyst 9800 as well as recommendations and limitations.

Web authentication is a Layer 3 security policy (contrary to central web authentication, which is covered in the next section) and is sometimes called local web authentication because the ACL and portal URL are locally configured on the WLC. It does not mean that the portal cannot be hosted on an external server but only that the configuration of these details has to appear in the WLC configuration. The naming convention can quickly become confusing around this feature; therefore, it is better and easier to fully refer to each component. The authentication part of the web authentication can be hosted locally on the controller or distributed to an LDAP database or a RADIUS server. The portal page can also be hosted on the WLC (and even customized) or on an external web server (that only has a web server role and does not authenticate the user). For example, saying you need to configure “Local web authentication with a local user database and an external login page” is easier to understand (although much longer to articulate) than saying you are configuring external web authentication. Figure 5-45 depicts the workflow of web authentication, although many different examples would be needed to cover all the possibilities, depending on where each part is hosted, but the concepts stay the same.

FIGURE 5-45 Local web authentication workflow

Web authentication can be configured on top of an existing preshared key or even 802.1X SSID. What defines a local web authentication SSID is the fact that the Layer 3 security tab of the WLAN configuration shows one type of web authentication configured. When a client connects to a web authentication SSID, a hidden preauthentication ACL is applied to it; it blocks all traffic except for DHCP and DNS while HTTP traffic is intercepted and redirected for web authentication. The wireless client can obtain an IP address (step 3) and detect the web portal by sending HTTP packets (step 4). The WLC spoofs whatever IP address was the destination of this HTTP packet and replies back with a redirection to the login page (whether it is hosted on the WLC or not). The login page can potentially be external and is only an HTML repository. The authentication process is completely separate, and the WLC either authenticates the user credentials locally or sends them via LDAP or RADIUS to an external server for validation. When the authentication is complete, the WLC moves the client to the RUN state, and the preauthentication ACL is removed.

A very focused reader wonders how the WLC can know the user credentials if they are entered in a web page that is not necessarily hosted on it. The controller has to use a trick for this. When the page is hosted on the WLC, the controller uses its virtual IP (a nonroutable IP like 192.0.2.1 typically) to serve it. The user credentials are then submitted to it, and this is how the WLC knows the credentials. A similar system is used even if the page is hosted externally: the web redirection sends the client first to the virtual IP anyway, which then sends the user again to the external login page while it adds arguments to the URL, such as the location of the virtual IP. Even when the page is hosted externally, the user still submits its credentials to the virtual IP thanks to this trick so that the WLC can receive the user credentials and authenticate them. If you are to write your own login page, refer to the HTML example provided in the Catalyst 9800 wireless controller download section on cisco.com to see how to have the credentials properly submitted to the WLC.

When we talk about web authentication, it is important to talk about the certificate validation. For a good web authentication experience, it is crucial to install a trusted certificate on the controller and apply it for use with web authentication. There are multiple criteria for a browser to validate a certificate; the main ones are

• The certificate must be within its validity period.

• The certificate must have a Common Name (CN) field that corresponds to the URL visited.

• The certificate must be issued by trusted certificate authorities (CAs).

The second criterion is also related to the fact that you typically cannot issue certificates to IP addresses. You must configure a virtual hostname linked to the virtual IP you are using. Instead of being redirected to the virtual IP, the clients are then redirected to the hostname entered. That’s the hostname you need to issue your web authentication portal certificate to. It is also expected that the DNS used by the wireless client redirects requests to the virtual hostname toward the virtual IP.

The third one does not necessarily mean that you need to have a public third-party-signed certificate, but if you use an enterprise PKI, you need to make sure that the root CA is installed on every wireless client (which can be challenging in the case of a guest SSID).

The catch is that if you are hosting your login page on an external web server, the client is presented with two certificates during the login experience: the WLC virtual IP certificate and the external login page certificate.

There are other slight variations of web authentication:

• Webconsent: Sometimes also called web passthrough, this variation removes the authentication phase. The page typically displays only the terms and conditions and asks the user to agree before letting them through on the network. The page can optionally ask the user to leave an email address, but no validation is performed. This type is used by many external portals relying on social network login credentials because the controller is not able to perform the authentication of the credentials. It is then the login page that is expected to perform the credentials validation, but in the back end, the controller has no means of verifying it.

• Web authentication on MAC filter failure: This variation is a MAC filtering SSID where the client is put in a web authentication pending state if the MAC authentication fails and is fully allowed on the network if it is successful.

Central Web Authentication

Central web authentication (CWA) is named this way because the configuration of the web authentication details (such as the ACL and the redirect URL) are configured centrally on the RADIUS servers. This means that the SSID on the WLC is configured with MAC filtering enabled (to have a pretext to send RADIUS requests to the ISE server) and optionally a preshared key or Enhanced Open. The ISE server then replies with an access-accept, along with a redirect URL and redirect ACL, as depicted in step 3 in Figure 5-46. The redirect ACL is a punt ACL that needs to be predefined on the WLC (or the AP in the case of FlexConnect local switching). The ISE server just returns the name of the ACL and not its definition. The redirect ACL defines traffic (matching “deny” statements because it denies redirection for it) that is allowed through on the data plane and traffic (matching “permit” statements) that is sent to the control plane toward the CPU for further processing (that is, web interception and redirection in this case). The ACL has implicit (that is, invisible) statements allowing DHCP and DNS traffic toward all IPs, just like the case with LWA. It also ends with an implicit deny statement, which is acting as security ACL implicit deny (which means it drops traffic). This means that the last invisible statement of the redirect ACL drops all the traffic that does not match any previous punt statement. An example of a redirect ACL would be (considering 10.48.39.28 is the ISE IP address):

FIGURE 5-46 Central Web Authentication workflow

ip access-list extended REDIRECT
 deny ip any host 10.48.39.28
 deny ip host 10.48.39.28 any
 permit tcp any any eq 80

The first two statements allow traffic toward ISE to not be redirected and follow regular processing. The last statement sends all HTTP traffic toward the CPU for URL redirection, and an implicit security ACL ACE “deny” is present afterward to drop all the other types of traffic.

The redirect URL simply defines toward which URL the WLC redirects the guest clients.

The Wi-Fi client can then obtain an IP address (DHCP and DNS traffic are allowed by default, HTTP traffic is intercepted for redirection, and the rest is dropped). All modern operating systems have a portal detection mechanism that works by sending HTTP probe packets to specific test URLs. If the device obtains the requested page, the device must have Internet access. If the device does not obtain the page, that’s where you get the famous “limited or no connectivity” sign or any of its variations on your device. However, if the HTTP request gets a reply that is a redirection, it means the device is behind a captive portal. The behavior then varies based on operating systems and even from version to version, but overall, the operating system either shows a pop-up that the user needs to log in to get Internet access or automatically opens a browser window showing the login page. This means that you probably do not have to open your web browser manually to test for a login portal.

The fifth step of the workflow includes all the login details (depending on the type of portal you choose, you can self-register or enter an authorization code) on the portal page(s) until the user has submitted their credentials and received the success message. Something unique about CWA is that after a successful login, the user is basically reauthenticated.

In step 6, the ISE sends a RADIUS Change of Authorization message to the WLC, containing the user session ID (from the audit-session-id attribute, it does not require accounting necessarily) and a reauthentication action. The WLC then restarts all the client state machines back to square one.

Step 7 is then a repetition of step 2 (but with a twist): the WLC sends a MAC authentication request to the ISE, which still simply contains the MAC address of the wireless client to the ISE. However, the ISE remembers that this client just logged in and appends an internal attribute containing the client username entered on the portal page to the authentication workflow. The client authentication can then hit authorization rules that are based on the client user identity and return any other authorization attribute: a VLAN (even if it is not recommended to change the VLAN of a client after it already obtained an IP address), a session timeout, an ACL, an SGT, and so on. This “trick” is done because the portal authentication happens via HTTPS, and the WLC knows nothing from the credentials that the user typed in the login page; therefore, no RADIUS authentication can happen at that stage containing the portal page username. This way, it is still possible to return various authorization results depending on the client login page identity, and they are applied during the Layer 2 authentication phase. The key is that the second MAC authentication taking place returns an access-accept that can contain various authorization attributes but should not contain any redirect URL/ACL again; otherwise, the portal page is shown again to the user in a loop.

One benefit of the CWA workflow is that the WLC Virtual IP is not used, and therefore, the WLC does not have to present its certificate to the user. Only the ISE login portal page gives its certificate to the client, so this reduces some of the administrative burden. Another benefit is that there is a load balancing of the portal pages taking place naturally: the redirect URL points to the portal page of the specific ISE policy node against which the client authenticated previously. This means that your portal load balancing is, in fact, following your RADIUS load-balancing strategy.

Web Authentication Best Practices

There are many mistakes when it comes to web authentication that lead to a poor user experience or simply a nonworking wireless network. Let’s look at the most common points.

HTTPS Redirection

HTTPS redirection is bad and should never be configured. When doing an HTTP redirection, the wireless client triggers the TCP handshake (on port 80) with whatever website it requested, but in reality, the WLC is intercepting this traffic, spoofing the website IP, and doing the TCP handshake. The client then sends its HTTP GET to request whatever page it intended to, and the WLC replies with a redirection to the login page. Intercepting HTTP sessions is not too hard for the controller, and there are no obstacles to task.

When doing an HTTPS redirection, the wireless client still triggers the TCP handshake (on port 443), and the controller still has an easy time spoofing the website IP address and completing the TCP handshake. But before the client can send a GET request, the TLS handshake of HTTPS must happen, and the server side (the controller here) is supposed to send a certificate to prove its identity. Even if the controller has a valid certificate installed, this certificate is issued to the controller hostname and definitely not to whatever website the client was requesting. This is the whole point of HTTPS—being able to verify the identity of the site you are visiting—and therefore, any other certificate presented depicts a session hijacking (which web authentication is, in fact).

There are no good solutions to this situation because this is the whole point of the protocol and why it is secure in the first place. The controller sends its certificate to complete the TLS handshake. The client browser always throws at least an error on this, and most of the time it is even impossible to ignore or avoid. Some browsers do not even show the page or do not show any error at all. This is why HTTPS redirection is a broken concept to begin with. On top of that, simply enabling it is extremely resource intensive for the controller.

The rationale behind this feature comes from people noticing that the Internet is now mostly HTTPS, and therefore, when a user opens up a browser, there is a good chance that an HTTPS URL is entered or that the home page is HTTPS, even if the user does not type HTTPS in the address bar. Therefore, for a time, this was indeed an issue, and the only way to have people notice there is a portal page was to enable HTTPS redirection. However, as explained in the previous section on CWA, most operating systems today have a portal detection mechanism relying on HTTP probes. Even for operating systems not benefiting from this feature, web browsers themselves implement this detection too and send an HTTP probe when opened to warn the user whether a captive portal is in place. There are therefore little to no reasons to still need to have HTTPS redirection enabled.

Some networks have configured all their laptops to use a web proxy to access the Internet or even an intranet, which means the clients never send their packets on ports 80 or 443 but typically on a higher port used by the web proxy. This issue is once again solved by relying on the operating system HTTP probe that is sent on port 80 no matter what the proxy configuration in the browser is.

Captive Portal Bypass

Captive portal bypass is a feature that administrators often enable out of a trial-and-error process when something is not working right with web authentication. It is important to understand its origin and purpose. Apple was the first company to implement the captive portal detection system on its company phones. What is now considered a great feature started with a few concerns because the captive portal page is not opened in the favorite or default browser but in a pseudo-browser called Apple Captive Network Assistant. The problem was that this pseudo-browser did not support dynamic pages very well and would display a blank page on many bring-your-own-device (BYOD) portals. The captive portal bypass feature on the WLC then made the WLC spoof an “HTTP 200 OK” reply from the captive detection URL, pushing the client to believe it had full Internet connectivity and therefore not show any pop-up at all. The user was then expected to open their browser and get redirected to the captive portal BYOD page displayed on this full-blown browser. The problem, as mentioned previously, is that nowadays most websites are HTTPS, so this workflow would typically not work at all. But this is not a concern because both the Apple CNA pseudo-browser solved some of its limitations, and the ISE BYOD portal page got adapted to fully display on those pseudo-browsers. Android now also uses a pseudo-browser, and no problems are reported with the vast majority of captive login pages. It is therefore recommended to disable captive portal bypass in the webauth parameter map, as shown in Figure 5-47, and to fully rely on the captive portal detection system. One limitation of those pseudo-browsers, still, is their inability to do the client provisioning flow from ISE.

FIGURE 5-47 Do not enable Captive Bypass Portal unless you really have a good reason

Web Authentication Takeaways

It is important to summarize the key points of web authentication because they will save you a lot of headaches when deploying your configuration:

• Do not enable HTTPS redirection; it’s pointless.

• Do not enable captive portal bypass.

• Make sure you have valid certificates on your portal page (always) and on the WLC (if you are not using CWA).

• You need a working DNS. Really.

• Rely on the client devices’ captive portal detection pop-up.

• Configure both an IPv4 and an IPv6 virtual IP; there’s little reason not to.

RFC 8910 is also something to watch out for because it is a new standard for detecting captive portals. Whether it becomes popular will depend on its client adoption rate.

Rogue Detection and WIPS

Rogue detection, WIPS, and more generally protecting against wireless attacks are covered in Chapter 7, “RF Deployment and Guidelines.”