Security

Wireless Security Fundamentals

Next, we cover in enough detail all the security settings that can be applied on an SSID so that you can feel comfortable understanding what you are configuring on a Catalyst 9800 WLAN.

Wired Equivalent Privacy (WEP)

Wired Equivalent Privacy is not supported by the Catalyst 9800. WEP is not considered security and has been deprecated by the IEEE for many years. History books are available to learn more about WEP.

Wi-Fi Protected Access (WPA)

Wi-Fi Protected Access is the Wi-Fi Alliance certification based on the 802.11i amendment to the standard. The first version was released as a stopgap for devices that did not have the hardware to implement the final 802.11i specifications, and therefore, WPA1 implemented the Temporal Key Integrity Protocol (TKIP), which was based on the same RC4 algorithm used by WEP. WPA2 uses only the Advanced Encryption Standard (AES) algorithm, which is still considered secure to this day.

WPA2 originally combines AES with Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP), which is, to make things simple, the way that the AES encryption algorithm is applied to the data.

WPA uses the existing legacy open system authentication, which basically consists of the client and AP sending each other empty successful authentication frames before being able to send the association request. Although this approach seems weird, the reason is that the only other authentication frame type at the time referred to share key WEP authentication and was very unsecure. Therefore, the core of the WPA exchange happens after the association. The association request and response are the opportunity for both the client and the AP to exchange their security capabilities. The Robust Security Network (RSN) Information Element (IE) is there to specify which authentication and encryption methods and ciphers can be used by both parties.

WPA comes in two flavors (aside from the WPA1 prestandard certification and WPA2 final certification): Personal and Enterprise. The encryption of the traffic between the wireless client and the AP is unique (that is, it’s different for every session) and securely created from the user authentication phase. It is important to note that only data frames are encrypted by WPA, and all the management frames are sent in clear text. WPA Personal is the most popular flavor out there due to the simplicity to deploy it: the wireless network (or SSID or WLAN) uses a preshared key that is known by all authorized clients and that serves as authentication (if you know it, you must be in on the secret and therefore allowed to join the network) as well as a seed for the unique encryption key. This means that every wireless client, in reality, uses a different key for sending and receiving traffic to and from the AP, but all those keys are generated from the same master secret. WPA Enterprise requires the use of a RADIUS server and relies on the 802.1X/EAP authentication framework (which typically works based on username/password pairs but can also accommodate certificates, tokens, smartcards, and the like) to generate the key seed. The benefits of WPA Enterprise are its use of different credentials for each user, and the fact that each user encryption key is based on those unique credentials rather than shared credentials. The 802.1X/EAP can come with stronger security during the authentication phase, but that largely depends on the EAP method chosen and the way it is implemented. The cost of WPA Enterprise includes setting up a RADIUS server (which can be more or less of a hassle depending on what you choose) and the management of unique credentials for every client (although they could technically still use identical credentials if you choose that for simplicity of management). IoT devices (printers, scanners, and so on) typically implement WPA Personal only for the simplicity of implementation and do not allow WPA Enterprise to be configured.

The security of both WPA flavors lies mainly in the credentials chosen. Even with the most secure EAP method for WPA Enterprise, if a user password is P@ssw0rd (even with that @ and 0 included), the most basic tools can guess or brute-force it very quickly. The same goes for PSK: if you choose a complex preshared key that is long enough, your network is very secure to brute-forcing, and the main weakness resides in the fact that all clients share this same key. Therefore, someone could leak it to an attacker, and all the clients are then compromised instead of just one. There are multiple proprietary implementations of PSK, which allow for having more than one PSK (up to having a different key for every device if you wanted to). The methods supported by the Catalyst 9800 are covered in the section “Preshared Key for WPA Personal.”

Protected Management Frames (PMF) is a standard amendment, compatible with WPA2 but ratified much later, that encrypts unicast management frames and provides protection against forgery to broadcast management frames as well. Thanks to PMF, it is not possible anymore for an attacker to impersonate the AP in an existing client-to-AP–established encrypted relationship. Probes and association frames, for example, are still in clear text because they happen before a key handshake can occur.

The encryption key is derived from the seeding material through what is often called the WPA four-way handshake. In reality, several keys are created during this exchange because there exists a separate key for broadcast traffic called the Groupwise Transient Key (GTK) and a few others that are beyond the scope of this chapter. This four-way exchange is always the last step before traffic can be sent (typically the DHCP DISCOVER would be the first traffic sent by the client) in an encrypted manner on the network. This four-way handshake has to happen between every client and every AP the clients connect to: because the encryption key is unique to the client-AP session, a different key has to be negotiated when the client roams to another AP. This handshake is a ping-pong between the AP and the client exchanging nonces (that is, random and arbitrary numbers used to see the cryptographic communication) to derive the same encryption key without transmitting that key over the network and considering both parties know a shared secret (either the PSK or the result of the 802.1X/EAP authentication that occurred just before). Those messages are called EAPoL Message 1 to 4 or EAPoL M1, M2, M3, or M4.

Those four messages are enough to exchange all the needed session keys between the AP and the client. Because the broadcast traffic is encrypted by a separate group key that is identical between every device connected to the same AP, that group key may need to be rotated regularly or when clients join or leave the WLAN. The AP can sometimes send an M5 message to which clients reply with an M6 message to derive a new group key for broadcast traffic.

WPA3 recently became the latest cool thing in the domain of wireless security and is covered later. It was created to improve on the weaknesses of WPA2. Despite the fact that WPA2 has still not been fully cracked yet to this day, it still showed vulnerabilities that required improvements. The main issues of WPA2 are as follows:

• The passphrase/password is used for both authentication and encryption.

• It is susceptible to offline attacks if the four-way handshake is captured. The attacker can try a dictionary of keys or passphrases until they are able to verify message 3 and 4 with it. With the public cloud offering a lot of compute power at a rental cost, this is making dictionary or brute-force attacks possible for anyone, even on a budget.

• There is no forward secrecy, which means if you know the password or passphrase, you are able to derive all the session keys for all past, present, and future sessions.

• By default, only the data frames are encrypted, which means that all the control and management frames are in clear text, and this basically opens the door for impersonation and for attackers to pretend to be someone else and disconnect other clients remotely. PMF was released to take care of this issue but didn’t get much traction from a Wi-Fi device manufacturer’s standpoint and so was not widely implemented.

802.1X for WPA Enterprise

802.1X-2010 (yes the X is capital) is a protocol framework for Layer 2 access control. This implies that the network device controls the user identity before providing an IP address to it and permits or denies network connectivity based on the identity of the user or device requesting access. Built around a wired port concept, it still translates perfectly as a virtual port concept for wireless users. 802.1X allows you to authenticate wired and wireless devices similarly, as shown in Figure 5-18. The controlled port blocks all data except for 802.1X-related authentication frames (called EAPoL frames) until authentication has completed successfully. At that point, the port forwards all or some traffic only (based on the authentication result). Over wireless, each association between a client and access point generates a unique pair of 802.1X virtual ports. The only difference with 802.1X over wireless is that the authentication results in the generation of cryptographic keys that are used for traffic encryption (which is not necessarily the case over a wired connection).

FIGURE 5-18 802.1X port-based authentication system

802.1X Components

As specified in the standard, and as shown in the Figure 5-19, a few terms depict the various roles of devices taking part in an 802.1X authentication:

• The supplicant: The client requesting access to a network resource and submitting credentials for authentication.

• The authenticator: A network device controlling the access to the network and facilitating the authentication process by relaying the credentials of the supplicant to the authentication server. This typically is a switch or, in this case, a WLC.

• The authentication server: A server responsible for validating the credentials sent by the supplicant and determining the network access level to grant to the user. In this case, this is the ISE server.

FIGURE 5-19 802.1X components

EAP

The Extensible Authentication Protocol (EAP) is at the heart of the 802.1X authentication process and provides a flexible framework and protocol, which supports multiple methods that are negotiated between the client and the authentication server and used to mutually authenticate them. EAP messages between the supplicant and the authenticator run directly over the data link using EAP over LAN (EAPoL) encapsulation (as shown in Figure 5-20). The authenticator can then extract the EAP payload and forward it to the authentication server over the wired network, typically inside a RADIUS packet. There is a clear demarcation between the EAP exchange over EAPoL between the client and the authenticator, which uses no addressing because the link is point to point and is supposed to be the only traffic allowed, and the transport of this EAP exchange over the IP network to the authentication server, which can be much further away on the network.

FIGURE 5-20 EAP authentication workflow

EAP is a request-response protocol consisting of only four EAP type packets identified in the “code” field:

• Request: This packet is sent by the authenticator to the supplicant and uses the type field to indicate what is requested (for example, identity, or EAP method to use).

• Response: This packet is sent by the supplicant in response to a valid request from the authenticator.

• Success: This packet is sent by the authenticator to signify a successful completion of an authentication.

• Failure: This packet is used by the authenticator if the authentication ends in a ­failure.

EAPoL frames also have several types and can be an EAPoL START (to signify one party wants to start a new authentication) or an EAPoL key (which transports a key).

EAP Methods

EAP is a framework protocol allowing for many different authentication methods (each having a unique ID) that define how credentials are exchanged. Although many exist, only a handful are used for authentication over wireless, and they are covered here.

• PEAP (Protected EAP): As depicted in Figure 5-21, this method relies on server-side TLS authentication to create an encrypted tunnel using a valid certificate that the authentication server sends to the supplicant at the beginning of the handshake. Just like during HTTPS web browsing, a TLS tunnel is built, and the server side always has to provide a certificate to validate its identity. The client doesn’t have to provide anything. Historically, many operating systems allowed the supplicant to not enforce validation of the server certificate, which means you could run a bogus certificate on your ISE server without issues, but more and more operating systems started to enforce this validation with no option to disable it manually. This means it is becoming a requirement to have a certificate on your ISE server that the client has in its trust store. Some clients allow you to manually import the ISE certificate in real time, whereas others require you to preload it. When this TLS tunnel is established, a new EAP negotiation using a new/another EAP method takes place inside the tunnel.

  

  FIGURE 5-21 PEAP authentication high-level workflow

  Therefore, the goal of PEAP is only to provide an encrypted tunnel to securely use another (even less secure normally) EAP method inside it. That new inner EAP method is typically EAP-GTC, MS-CHAPv2, or EAP-TLS.

  • PEAP with inner EAP-GTC: This EAP method was originally designed for one-time password authentication or token authentication. This means sending the password in clear text (but it’s inside the PEAP original TLS tunnel, so it’s not visible to an attacker/eavesdropper). This method is required if you are using a third-party user credentials database like LDAP or such, as is typically the case when using one-time passwords. The external user database needs to get the password in clear text to verify it because it is not able to verify the MS-CHAPv2 encrypted version of it.

  • PEAP with inner EAP-MS-CHAPv2: This is the most popular EAP method so far among Windows PCs and smartphones. EAP-MS-CHAPv2 is a way to exchange a username and password in encrypted form (it’s encrypted twice because CHAP already encrypts the password and it’s inside the PEAP TLS tunnel as well).

  • PEAP with inner EAP-TLS: This is maybe the most secure method because another TLS authentication happens inside the encrypted TLS tunnel. This inner TLS authentication, this time, requires both server- and client-side certificate authentication. This means typically running an Enterprise PKI (something ISE can do for you with BYOD workflows) and issuing your own certificates to your clients. The client certificate is encrypted to any attacker/eavesdropper, so it is impossible for anyone other than ISE to know the certificate fields such as the username. Considering it involves two TLS handshakes, this method is quite slow if the client has to reauthenticate fully every time it roams to another access point. Fast roaming is advised if you want to deploy it.

• EAP-FAST (EAP-Flexible Authentication via Secure Tunneling): Depicted in Figure 5-22, developed by Cisco, and published as IETF RFC 4851, EAP-FAST enables mutual authentication by using a shared secret, called the Protected Access Credential (PAC), to establish a TLS tunnel that secures the exchange of user authentication messages. It has similarities to PEAP in this regard, but the PAC is at the core of EAP-FAST and allows for more deployment options. The PAC can be manually distributed to the client out-of-band if you want to ensure the most secure deployment. EAP-FAST has three phrases. Phase 0 is required only if you opted out of manually distributing the PAC out of band. During that phase, the PAC is provisioned in-band on the supplicant using either an anonymous TLS handshake (using the Diffie-Hellman protocol) or an authenticated tunnel using the server certificate. Concretely, this means you can avoid using a valid and trusted certificate on the authentication server in case you are doing manual PAC out-of-band provisioning or if you provision in-band but decided to use an anonymous TLS tunnel. Phase 1 is the TLS tunnel establishment using the PAC, which takes care of mutual authentication (if both sides have the PAC, they must know each other). Finally in phase 2, user authentication credentials are passed within the TLS tunnel created in phase 1. Either EAP-MS-CHAPv2 or EAP-TLS is available as the inner method, just like for PEAP. EAP-FAST also allows for proprietary features such as EAP-chaining where two identities (the device itself and the user on it) can be provided in the same authentication flow. The security of EAP-FAST depends greatly on your deployment options and the inner method used. Most people use it with anonymous in-band provisioning, which typically requires a first failed authentication to deliver the PAC before authentications can succeed after the client has installed the PAC correctly.

  

  FIGURE 5-22 EAP-FAST high-level overview

• EAP-TLS: Depicted in Figure 5-23 and described in IETF RFC 5216, this method was covered previously as an inner method to PEAP or EAP-FAST. It is also available as a standalone method. A TLS tunnel is then built based on both a server-side as well as a client-side certificate. The tunnel itself is the authentication, and no other inner method occurs. It is therefore possible for an eavesdropper to read certificate details (which is not necessarily a major security concern) during the authentication. For an EAP-TLS authentication to succeed, the client device should have the root CA that issued the authentication server certificate chain in its trusted root CA store, and the authentication server should similarly have the root CA on top of the client certification chain in its trusted root CA store. This way, both parties can authenticate the other party certificate as issued by a trusted chain of CAs. It is interesting to note that there is technically no username in EAP-TLS authentication: a certificate is provided, and it’s either trusted by the other side or it is not. The certificate is not issued to a username but to specific fields such as Common Name (CN), Country (C), and Organization (OU). To be able to identify the certificate uniquely to return a specific set of privilege, the authentication server can be configured to consider any of these certificate fields (or a combination of fields) as a username.

  

  FIGURE 5-23 EAP-TLS high-level overview

The validity of a certificate in an 802.1X context consists of verifying whether the certificate is still in its validity period and if it is issued by a trusted root CA on top of the chain and optionally if the certificate hasn’t been revoked in a certificate revocation list (CRL). Some authentication servers can proceed in making a binary comparison of the certificate; that is, they compare bit by bit that the certificate presented is the same one as the one stored in the authentication server database, but that is uncommon. Being issued by a trusted source is typically enough. There is no verification of the name on the certificate because users don’t really map to domain names like web servers do. The client also can hardly verify the authentication server DNS FQDN because 802.1X is a Layer 2 authentication method happening before any sort of IP connectivity. The client only relies on having the trusted CA installed in its store as well as the validity period. On its side, the ISE can be configured to read one field of the certificate (typically the CN) to obtain a username out of the certificate if that can be useful for matching authorization policies.

WPA3 Enterprise

WPA3 also comes with a revision of the Enterprise flavor of WPA. There is no major advertised change, but the main thing is that WPA is also an interoperability certification, and this certification was revised to take care of many previous flaws and attack vectors around its implementation. More notably, WPA3 Enterprise brings a 192-bit cryptographic strength aimed at sensitive government and finance sectors, while the 128-bit security remains the default. The list of supported and allowed cryptographic protocols is revised and updated in WPA3, and a more restrictive option called SuiteB brings a uniform list of very secure protocols for the most demanding customers. PMF is now a requirement for WPA3, which means that clients supporting WPA3 support PMF, and on the administrator side, it is impossible to configure a WPA3 SSID without PMF being enabled.

A transition mode exists to allow WPA3 clients to use PMF while WPA2 clients can still connect. WPA transition mode basically downgrades the security of your SSID to a regular WPA2 SSID though.

Fast Transition (FT), the standard for fast and secure roaming (covered in more detail in the next chapter, along with client mobility), is not supported with 192-bit WPA3 Enterprise at this time; this would need a new AKM for 192 bits + FT and would need clients to support it, so it’s an industrywide limitation. Also, Catalyst 9115 and 9120 access points do not support WPA3 SuiteB GCMP256 ciphers (AES256 is okay).

Preshared Key for WPA Personal

When you’re configuring WPA Personal with a preshared key, what you typically think of as “the key” is actually the passphrase. It is not what is used to encrypt the traffic and not even what is used to generate the actual encryption key. Details are beyond the scope of this book, but the passphrase is converted to a 256-bit key, called a Pairwise Master Key (PMK), using a standard conversion method. That 256-bit key is used to generate the actual final encryption key. This allows you to have a variable-length passphrase (imagine having to remember a 64-character passphrase, for example), which is easier to remember. The requirements for the passphrase are that it must contain between 8 and 63 printable ASCII characters. Eight characters is really not a lot and should definitely not be used in production because it is a reasonable length to brute-force by using dictionaries of commonly used passphrases. Using a longer passphrase (including fancier characters) randomizes the 256-bit final key better and protects you from brute-force attacks.

One of the inherent weaknesses of the PSK authentication and key management protocol is that even if the encryption/session key is unique for each client, these keys are derived from the same seeding material (the passphrase). In practice, this means that if an attacker starts to listen to over-the-air traffic and knows the passphrase, it is not able to decrypt the traffic because it cannot derive the same session key. However, if the attacker is listening when a given client is associating and the attacker hears the four-way handshake, the attacker is able to derive the same session key as the client because they know the passphrase.

WPA3 SAE

WPA3 Personal is also called SAE for Simultaneous Authentication of Equals and brings much more than just a change of name. Contrary to its predecessors (WPA1 and 2), SAE does not rely on the open authentication mechanism but adds a new SAE authentication frame type, as shown in Figure 5-24. This adds two frames to the overall frame exchange count because there are four SAE authentication frames exchanged in total (two back and forth between the client and the AP), then the association and the typical four-way handshake.

FIGURE 5-24 WPA3 SAE workflow

The SAE authentication frame exchange consists of four frames because it is a kind of key exchange by itself. Finishing the SAE initial four-frame exchange results in deriving a Pairwise Master Key (PMK) already. The concept of SAE is to protect the actual four-way key exchange by having it encrypted thanks to an SAE exchange done first,which allows you to exchange anonymously session keys. This process is similar in principle to the PEAP concept of building a secure tunnel to exchange credentials more securely. The effect of this is that even if an attacker knows the passphrase (which is still the weakest attack vector to get on to your network), the attacker is not able to decrypt the traffic from any wireless client, and that is a strong advantage over WPA2. In summary, SAE strongly enhances privacy while authentication security stays related to the strength of your passphrase and how you share it with your users. The SAE handshake also prevents the attacker from doing offline brute-force attacks on a captured handshake because that attacker has to be online and try one key at a time, which drastically reduces the speed of brute-forcing (and allows you to detect the attack).

WPA3 SAE requires PMF to be enabled (as for all WPA3 deployment types) and does not support Fast Transition (FT) at the time of this writing.

MPSK

MPSK (Mulitple PreShared Key) is an option you can configure in the WLAN settings (as shown in Figure 5-25); it allows you to configure up to five preshared keys for a given WLAN. This allows you to rotate keys or to use specific keys for specific devices. Keep in mind, however, that there is no authentication: anyone can connect using any of the keys entered.

FIGURE 5-25 MPSK configuration in WLAN settings

Due to the way SAE works, MPSK is not supported with WPA3.

Identity PSK (iPSK)

Identity PSK is a standard PSK SSID where the administrator configures MAC filtering to have a pretext to reach out to a RADIUS server (you don’t necessarily want to validate the MAC addresses). The RADIUS server can then return, through specific attributes, a (possibly) unique key for use with the wireless client. It is assumed the wireless client knows the right key to use. Although many people think this means they have to add wireless device MAC addresses in the RADIUS server and return specific PSKs depending on the MAC used for authentication, this is not the only possibility. As a matter of fact, the RADIUS server can use any RADIUS attribute in its authorization policy to determine which key to return: the location of the AP/WLC, the type of client device used (through profiling), or any creative combination based on the RADIUS attributes present in the MAC filtering authentication request. An example is shown later, but first let’s look at MAC filtering itself and RADIUS concepts.

MAC Filtering

If you configure MAC filtering (also sometimes called MAC bypass) on a WLAN, the controller basically verifies the client MAC address authorization after the client sends the association request frame and before sending the association response. The wireless controller can either check locally in its local database or send the request to an external authentication server. The association response status code sent back to the client then depends on the authentication result: the association is rejected if the MAC address is not authorized to access the network.

There are several concerns with this system:

• It is not a security measure. A MAC address can be spoofed, and MAC addresses can be easily discovered by eavesdropping because they are always in clear text, and therefore it cannot be considered as a proper security measure.

• The fact that more and more devices use a randomized MAC address to connect to networks makes this measure completely unpractical and unmanageable. The last remaining use case could be IoT devices that do not perform MAC randomization or devices where the administrator manually configured the wireless adapter to not change the MAC address. But again, it cannot be considered secure because a MAC can be spoofed.

• It can be used as a pretext to trigger a RADIUS authentication to the external authentication server, as is the case with central web authentication (covered later).

• The MAC filtering authentication happens between the association request and the association response, which means that if the wireless controller has to verify the MAC address with an external RADIUS server, this can add a great deal of latency, and the association response sent back to the client can be delayed. There is no standard recommended maximum latency, but after more than 50 ms, most clients do not wait for an association response anymore and try to connect to other APs, possibly on other channels. MAC filtering has to be implemented with a low-latency nearby MAC address database.

Enhanced Open

Not part of the WPA3 specification but released at the same time, Enhanced Open brings more privacy to open networks by encrypting all the guest traffic without requiring any key to be shared. Guest networks are here to stay, and although some administrators configured a preshared key on their guest WLAN, it is clear that this approach is neither secure nor practical: you have to share the key with your guests one way or another, and this often leads to anyone being able to figure out what the key is. This means that anyone can get on your network without having to type in anything. Enhanced Open does not bring any security in the authentication sense of the word; anyone can still onboard the network without any form of verification of identity. However, based on Opportunistic Wireless Encryption (OWE), the client and AP securely derive an encryption session key pretty much out of thin air (that is, without having a shared secret known beforehand from both parties).

Once connected, their traffic is private, meaning no attacker is able to decrypt their traffic (offline dictionary attacks are rendered impossible). Enhanced Open also requires PMF, which means it is not possible anymore for an attacker to remotely deauthenticate anyone else or impersonate certain management frames. Interestingly, Enhanced Open even beats WPA2-PSK from a privacy standpoint because when the attacker knows the WPA2-PSK, they can decode everyone’s traffic, which is not the case with Enhanced Open, because every client uses a different master key that differs at each session.

Enhanced Open comes with a great transition mode because client support for Enhanced Open is still limited at this time. When using Enhanced Open transition mode, the controller creates two SSIDs in fact. One is broadcasted and is a regular open SSID, and the second is hidden (that is, its name is not present in beacons) and uses Enhanced Open as security. The regular open SSID beacons contain an information element advertising the presence of a hidden Enhanced Open BSS. This behavior is standardized, which means it is not a Cisco hack, and any client supporting Enhanced Open is aware of this technique. The result is that the legacy clients not supporting Enhanced Open simply see a regular open guest SSID and connect to it without seeing anything different (and do not benefit from any improved privacy, of course), whereas clients supporting Enhanced Open automatically connect to the Enhanced Open SSID even when the user selected the regular one on their device.