10.2 Using Dynamic WEP (802.1x and EAP) to Address Authentication and Encryption Flaws in 802.11

802.11 unauthenticated, cleartext management, and control frames mitigate the basic security flaws that have resulted in numerous attack scenarios targeted at WLANs. There are numerous authentication and encryption technologies and products that can be added to WLANs to address these vulnerabilities. Attack methodologies used against WLANs are based on the exploitation of additional vulnerabilities found in the existing standard. These vulnerabilities are mitigated with the release of the 802.11i standard [5].

Other attack methodologies are addressed by proprietary solutions. Proprietary protocols and solutions often provide security that is superior to published standards. Such proprietary solutions often include the utilization of leading-edge encryption and authentication. Proprietary protocols do not have a large market share at this time and tend to lack standardization. They have increased implementation times because of longer learning curves. 802.1 x /EAP or TKIP solutions use keyed MICs to prevent the forgery and tampering of packets through the use of an algorithm that allows the receiver or access point to verify that a known sender has sent a packet and the packet has not been altered or spoofed in transit. This prevents an attacker from telling the access point to drop the connections to other nodes by sending disassociation frames to the access point using a spoofed MAC address.

Dynamic WEP [6] refers to the combination of 802.1 x technology and the EAP. EAP is a flexible Layer 2 authentication protocol and a replacement to PAP and CHAP under Point-to-Point Protocol (PPP). The term dynamic WEP is derived from its unique ability to change (rekey) encryption keys. This prevents an attacker from being able to collect enough data to crack the current encryption keys. Each time a user logs into the network, a new key is created for that session. No other user will have the same session key, and the key lengths are such that reuse of the keys would be impossible to predict. Dynamic WEP also initiates more frequent key updates during the user's session, constantly changing the user's key by periodically renewing the keys every few minutes. This prevents an attacker from capturing significant data with the same key, thereby preventing any meaningful decryption of the WEP key.

Between one and five million encrypted packets can be captured in a high-traffic environment in about four to five hours. This would be a sufficient volume of data to make it possible for an attacker to crack the WEP. The encryption keys in Dynamic WEP should be set to expire frequently, normally every 15 minutes, to prevent an attacker from successfully conducting this type of attack. Frequent rekeying has a negligible effect on network performance, and its use should be maximized where possible.

Broadcast Key Rotation (BKR) is another security solution, but it is not specifically addressed by the 802.11i working group . Broadcast keys are a major security risk because they are normally implemented in a static fashion. Periodically rotating the broadcast WEP key at a user-defined interval will eliminate this problem. There is an option for enabling or disabling this function so administrators or users can configure and implement BKR through a time-interval setting in the access point. As a result of implementing 802.1 x /EAP, WEP keys are not entered on access points or into wireless client utility software manually. User authentication has been added and, as a result, data encryption and user authentication are easier to administer. 802.1 x and EAP allow flexibility and increased security for user authentication and connectivity through the use of personalized, unique user credentials such as usernames and passwords, certificates, SmartCards, and other user-centric methods . This is a much stronger solution than the single passphrase authentication and access control used in WEP. In some cases, TKIP is enabled as part of a dynamic WEP solution. Although it is somewhat redundant, this practice creates an even stronger WLAN security solution.

10.2.1 802.1 x

802.1 x is not solely an IEEE wireless standard because it provides an authentication framework for all 802-based Local Area Networks (LANs) that can be applied to most IEEE 802 technologies. Rather than using hardware identifiers such as MAC addresses, 802.1 x uses individualized user credentials in addition to port-based access control. Port-based access control means the user credentials must be verified before the switch (wired network) or access point (wireless connection) will establish a Layer 2 link connection (Figure 10.1). Although physical access characteristics are used for IEEE 802.3 LAN infrastructures , a virtual port is used between a client and an access point in 802.11 WLANs.

Figure 10.1: The OSI model and an example of functional layering for WLANs.

Over the last couple of years , the 802.1 x standard has been adapted to wireless networks, resulting in a flexible security framework. This framework enables the plug-in of new authentication or key management methodologies without forcing changes to be made to existing hardware, such as wireless Network Interface Cards (NICs) or access points that allow a security session to occur between the client and the authentication server.

The 802.1 x authentication process begins as a start message is sent to an access point in response to a query from the client for its identity. A response packet is forwarded to an authentication server from the access point. The authentication server sends an "accept" packet back to the access point once authentication is successful. The client port is put into an authorized state by the access point when the "accept" packet is received, and the traffic is permitted to proceed.

Three entities are defined and used by the IEEE 802.1 x standard: supplicant, authenticator, and authentication server. The authenticator authenticates a client called a supplicant. The authenticator may connect (authenticate) the supplicant at one end of the wireless segment when using 802.11 or to one end of a point-to-point link of a wired segment. Supplicants must be authenticated to an access layer device called an authenticator in order to pass traffic through the access layer device. An 802.1 x authenticator is usually an access point or bridge. An authentication server authenticates a supplicant.

If the identity (credentials) of the supplicant is valid and properly verified, authorization is granted and the authenticator is notified. A RADIUS server is typically used as the authentication server in wireless 802.1 x /EAP implementations . The authenticator acts as a pass-through device while the supplicant and the authentication server leverage the main CPU resources for cryptographic calculations. This 802.1x configuration is ideal for wireless access points because they typically have small processors, little memory, and low processing power.

EAP uses dynamic key generation during authentication, eliminating the problems introduced by static WEP keys. As a result of an 802.1 x /EAP solution, lost laptops or wireless cards no longer have to present a security risk because they hold WEP information that could be useful to a hacker. The performance of 802.1 x in wired networks showed that it could have many advantages for mobile users, including maturity and interoperability, user-based identification, dynamic key management, and flexible authentication method support. Industry eventually chose to use it in wireless networks. 802.1 x supports mature open standard protocols such as the EAP and RADIUS standards, [7] which provide leading-edge flexibility, options for authentication, and maximum interoperability in an environment where centralized user identification and key management is desirable.

802.1 x /EAP-based wireless security identification is no longer based on a particular wireless network device connecting to the network, but on the actual user. Using a scalable authentication database such as RADIUS, or other databases that RADIUS can support (i.e., Active Directory, NDS, LDAP, Windows NT), it allows for hundreds or even thousands of authenticated users to be securely managed in a WLAN environment. Administration time and money is saved through a centralized authentication and management scheme such as that provided by RADIUS. This functionality is also valuable in meeting various regulatory and security governance requirements, providing the organization with the historical knowledge of who has been using the network and how they used it. This eliminates the ability to exploit the deficiencies of static WEP keys that can result in attacks based on obtaining the key through the use of 802.1 x /EAP solutions utilizing per-user, per-session keys. Allowing keys to be reissued without an administrator's intervention through the use of automated key management systems poses a great risk in this type of situation.

Changing authentication methods is simplified in 802.1 x /EAP solutions and allows for increased flexibility in responding to security vulnerabilities. The latest and best authentication methods can be implemented at lower cost because the authentication change does not require hardware to be replaced . This eliminates the need for expensive special hardware and its associated costs. Several supported authentication solutions are available with different features and benefits to meet the customer's needs. Each one of these is described in the following sections.

10.2.2 EAP and its Variants

An understanding of Point-to-Point Protocol (PPP) is required before you can understand EAP. PPP is used for dial-up connections to the Internet and to establish a connection over a point-to-point link. Once a link is established, PPP provides an optional authentication before proceeding to the network-layer protocol phase. EAP was originally designed to provide a flexible and extensible method for a PPP server to authenticate its clients . The EAP protocol is used in wireless network implementations as a method to conduct an authentication conversation through an access point between a wireless user and an authentication server such as RADIUS. EAP provides the authentication methodology, while 802.1 x provides port-based access control. In this manner, EAP and 802.1 x are intimately interwoven. In an 802.1x/EAP solution, both the client and the server are authenticated by each other through mutual authentication. This process can be specialized to fit particular implementations of EAP. This is why there are so many kinds of EAP. The 802.1 x authentication process begins with the wired clients using switches as authenticators and either TACACS+ or RADIUS authentication servers. An 802.1 x wireless access point will filter or block all non-802.1 x traffic from the client before authentication. The access point only accepts EAP packets until the time that authentication is successful. The access point will then remove the filter and allow the supplicant to access the upstream network.

EAP is advantageous over password-based authentication methods such as PAP and CHAP because it supports two-and three-factor authentication (passwords, certificates, biometrics, etc.). EAP doesn't require the installation of new code on Network Access Servers (NAS) when implementing new authentication methods. EAP just passes through the request because NAS does not need to be aware of the specific EAP type. Some access points do not support all EAP types.

EAP was developed to mitigate the proliferation of proprietary authentication solutions. It was believed that such proprietary solutions would have had a negative effect on interoperability and compatibility between systems. EAP software supports almost any EAP type and resides on the authentication server, within the operating system, or within the application software on the client devices. Each EAP implementation offers different features and functionality. It is important to analyze several factors before deciding which EAP solution is appropriate for your use. These factors include industry acceptance, standardization, support costs, management overhead, availability, implementation requirements, budget constraints, dynamic key generation, dynamic key rotation and distribution, and the relative difficulties involved in an implementation in your particular environment.

Mutual authentication support is recommended for any EAP method chosen for use with a WLAN. This means the client authenticates the server and the server authenticates the client. This ensures that a client connects to the correct network and prevents intermediate rogue device and rogue server attacks from occurring. Using only client authentication, as with EAP-MD5, is not recommended because it will leave a network susceptible to man-in-the-middle attacks.

Dynamic keys are generated per user for each login session. The EAP authentication process creates a new WEP key each time a user logs into the wireless network for the duration of the session or until the end of the preconfigured rekeying period. This makes it nearly impossible to crack WEP keys because they are not reused. The authentication server redistributes keys to the wireless clients as they are regenerated. Broadcast keys are not per-user, per-session based and are a key risk factor to consider. Implementing a feature such as broadcast key rotation can eliminate this potentially serious security risk.

Costs associated with implementation, ongoing maintenance, management, training, and long-term staffing need to be documented and agreed upon before embarking on an EAP implementation. EAP can be a cost-effective solution when compared to the total cost of implementation and ownership of a PKI or other certificate-based authentication systems. Significant costs for PKI certificate-based systems can result from the significant work of installing and managing client certificates on each machine and revoking certificates when machines are lost or stolen. Other costs could come from additional hardware and software, such as software licenses for server applications and per-machine licenses for client software that needs to be purchased. Another option may be to purchase a certificate server software package instead of purchasing hundreds of certificates through a certificate authority. In regard to costs associated with more traditional solutions, some RADIUS software packages are more expensive than others. Some 802.1 x /EAP client software packages are free, but others are not. The reader is advised to carefully consider these options before making a decision on which 802.1 x /EAP products to use.

Proprietary solutions such LEAP (Cisco), PEAP (Microsoft, Cisco, and RSA), EAP/TLS (Microsoft), and Symbol's implementation of Kerberos can lock an organization into one vendor's hardware or software solution, leaving a company at the mercy of the vendor for support and upgrades. On the other hand, an industry-standard solution backed by one or more major vendors could result in more hardware and software manufacturer support, providing a lower Total Cost of Ownership (TCO). For example, EAP-TTLS and PEAP both have gained acceptance because of the organizational clout behind each protocol. Although both have IETF drafts in place, they will each most likely become ratified standards in time. Their future lies in industry acceptance, support, and marketing.

As the wireless market continues to evolve rapidly , new standards and more sophisticated products continue to be made available. No single product meets every need, so careful scrutiny is warranted in order to save time and money. One commonly used approach is to have prospective vendors review the organization's network needs, suggest possible solutions, and explain how one solution may fit better than another. Unfortunately, their suggestions may be based on self-interest and must be weighed carefully. To ensure that you can weigh this decision carefully, you must be well-versed in a wide variety of available WLAN security solutions. One word of caution: there are many facets to a good solution, and your network may already have some of these needed parts . For example, you may have RADIUS in place already, but the RADIUS software package in use may not support the latest EAP standards. Perhaps only an upgrade to the next version is required to support the WLAN that you want to deploy, but it may also be possible that an entirely new package will be required.

Other selection issues may revolve around operating system support and interoperability. For example, what if the organization has a Linux-based RADIUS package and Linux-trained administrators, yet the only RADIUS package available to support the EAP standard chosen runs on Windows? What if the organization is Windows-centric and the appropriate RADIUS package is available, but it is far more expensive than one implemented on Linux? Do you have the correct administrator to support either solution? Would you have to hire a new administrator just for the wireless network? Is it less expensive or appropriate to outsource this functionality? These are but a few of the many questions that must be asked in such situations. The answers to these questions should be considered carefully before a decision is made.

Selecting an authentication method is a relatively straightforward process, but it is critical to the success of securing your WLAN deployment. The choice of authentication method will drive both the choice of authentication server and client software. To avoid the client certificate administration overhead, do not consider using EAP-TLS unless an existing PKI is in place. TTLS has a few advantages over PEAP: it has a greater degree of flexibility at the protocol level than PEAP, it supports a wider variety of client operating systems, and its products are more readily available. If PEAP gains greater support and use in the marketplace , it may be even more difficult to decide which is the better choice.

10.2.3 EAP Authentication Types

Several different EAP protocol types are used with WLANs today. Some are complicated to deploy, some are more secure than others, and some are not considered secure. The differences between the types of EAP that can be deployed in a WLAN environment are important to understand in relation to costs, security, and timely deployments. The EAP types to be discussed in this section are LEAP, EAP-TLS, EAP-TTLS, EAP-MD5, PEAP, and proprietary protocols.

LEAP

Cisco developed their proprietary Lightweight Extensible Authentication Protocol (LEAP) as an 802.1 x -standard EAP-based authentication type to support networks under a variety of operating systems that may not natively support EAP [8]. LEAP offered a convenient way to ensure mutual authentication between a client and a RADIUS server when authentication standards for use in wireless environments were still evolving rapidly. LEAP provides user-based centralized authentication and per-user, per-session WEP keys. LEAP is widely, but not exclusively, used in Cisco Aironet products. The supplicant, authenticator, and authentication server 802.1 x design features are part of the Cisco LEAP deployment.

LEAP has become the most popular form of EAP currently in use because of its relatively simple deployment requirements and the popularity of the Cisco Aironet product line. It runs on most popular operating systems and hardware platforms and is supported by nearly all RADIUS vendors. Because LEAP uses password-only authentication, its security level is determined by the strength of the passwords employed. Over the last couple of years, Cisco has begun moving toward a new standard called Protected EAP (PEAP).

EAP-TLS

Microsoft developed EAP-Transport Level Security (EAP-TLS) authentication, and it has been standardized by the IETF [9]. EAP-TLS is based on the Secure Socket Layer (SSL) protocol used for secure Web traffic [10]. EAP-TLS is more appropriate for organizations that have already deployed a PKI because it uses both server-side and client-side certificates for user identification. If PKI is not already in place, a new infrastructure will require installing, configuring, and maintaining or outsourcing the use of a Certificate Authority (CA), registration authority, a directory, and a certificate management system. Managing both server-side and client-side certificates across a large enterprise can be a time-consuming , expensive, and overwhelming task for organizations with limited resources.

Digital certificates are data structures distributed by a CA that identify a public key as belonging to a particular user. In most cases, a digital certificate complies with the X.509 standard and is generally made up of the following: certificate version, serial number, certificate issuer, user name , user's public key, validity period, optional extensions, signature algorithm, and signature. The certificate version, serial number, issuer, user, user's public key, and validity period are combined, and the values are run through a keyed hash function to derive the digital signature. The certificate authority keys the hash with its own private key. Other authentication systems, such as token-based authentication, are being selected by organizations because they align more closely with their business models and security policies. Not all RADIUS servers that support EAP will support the EAP-TLS authentication method.

EAP-TLS was the only EAP method used in Windows XP until the recent introduction of PEAP and when Windows XP Service Pack 1 introduced Microsoft's first support for PEAP [11]. EAP-TLS provides for mutual authentication between the supplicant and the authentication server, negotiation of the encryption method, and secured private key exchange. TLS authentication is relatively straightforward in EAP. Each part of the session establishment dialog between the supplicant and the authentication server is placed inside of an EAP-TLS packet, and when the TLS authentication dialog succeeds, the authenticator is informed and access to the network is granted.

A segment of the keying data created during the TLS session initiation for that channel is sent to the authenticator and the supplicant, which already knows the TLS-established secret key, and the authenticator uses that key for WEP encryption. Because the supplicant wants to talk to the authenticator, the authentication server encrypted channel configured by TLS between the authentication server and the supplicant is not used.

Certificates are used to authenticate the authentication server to the supplicant in EAP-TLS with an option to authenticate the supplicant to the authentication server. The process is started when the authentication server sends its digital certificate to the supplicant. In one-way authentication, a server sends its certificate to a browser to prove its identity. SSL version 3 is supported by all current versions of Web browsers and is very similar to TLS. For many people, all that matters is that the results of SSL or TLS are the same ”an encrypted session between the browser and the Web server ” and both methods start with the same authentication phase. As discussed earlier, EAP-TLS administrators should be more interested in using mutual authentication than one-way authentication because it protects the network against man-in-the-middle attacks.

Because both wireless clients and access points are strongly authenticated using digital certificates, the deployment of certificate authorities has become much easier and more cost effective. The advantages of EAP-TLS make it a preferred authentication method for WLANs. The client can be reauthenticated and rekeyed as often as needed without inconveniencing the end user as a result of per-session WEP keys. Although EAP-TLS has had some software bug implementation problems, it has been tested extensively without being broken or revealing any significant security flaws in the protocol itself; however, it should be noted that the username is passed from client to server in a TLS exchange before certificates are exchanged, and it is possible to observe the username's passive packet analysis. If remote access connections are being made in the Windows environment and SmartCards are being used, EAP-TLS authentication should be mandatory.

EAP-TTLS

EAP-TTLS is an IETF draft standard and is an extension to the functionality of the EAP-TLS authentication protocol, removing the EAP-TLS requirement of the supplicant-side certificate by requiring only an authentication server certificate, greatly easing deployment overhead. Funk Software [12] and Certicom (http://www.certicom.com) codeveloped and designed EAP-TTLS as a more secure and easily managed version of EAP.

In a manner similar to RADIUS, TTLS uses the TLS channel to exchange Attribute Value Pairs (AVPs). The TTLS server validates AVPs against any type of authentication mechanism through the general encoding of its information. All methods defined by EAP, as well as several older methods, are currently supported by TTLS implementations. New attributes to support new protocols can easily be extended in TTLS to work with new protocols. As EAP-TTLS products become more common in the market, one must remember that the RADIUS server and the supplicant software must support this type of EAP authentication for the solution to work.

The authentication server is authenticated using its digital certificate, and an encrypted tunnel is established between the supplicant and the authentication server during the initial authentication phase of EAP-TTLS. The supplicant's authentication credentials, such as a digital certificate or password, are passed to the authentication server in the tunnel and authenticated using the administrator's authentication algorithm of choice. Nearly every type of supplicant authentication credentials (passwords, certificates, tokens, etc.) can be used inside the encrypted tunnel using EAP-TTLS. Also, having only a server-side certificate requirement eliminates much of the overhead associated with client-side certificate deployment; most types of authentication algorithms can be used inside the encrypted tunnel (MS-CHAPv2, MS-CHAP, CHAP, PAP, EAMD5, and others).

Some other key security features of EAP-TTLS include strong protection against eavesdroppers seeking to perform dictionary attacks, mutual authentication, fast reconnections while roaming, and automatic rekeying of encryption keys. Enterprise users that want the security of TLS, but have legacy authentication methods or token-based authentication methods, should regard TTLS as a viable EAP method. In TTLS, the client validates the server's certificate by sending a copy of the server's certificate as part of the supplicant software package. In this way, the supplicant can compare the certificate it was given during installation with the one given to it by the server when it authenticates to the wireless network.

EAP-MD5

RFC 2284 considers EAP-MD5 mandatory, and it was the first authentication type created by this RFC for 802.1x [13]. MD5 is a password-based protocol that is easy to implement. EAP-MD5 uses the same challenge handshake protocol as used in PPP-based CHAP; however, the challenges and responses are sent as EAP messages. The authentication server challenges the supplicant with a random string of text, and then the supplicant hashes the challenge with its password and sends the response back to the server.

The response to the server is validated based on its knowledge of the password. Unfortunately, EAP-MD5 allows an eavesdropper to obtain both the challenge and the encrypted response, making it possible to conduct a dictionary attack using the same algorithm that was used to obtain the user's password. Also, because MD5 authenticates only the supplicant and does nothing to authenticate the authentication server, a rogue RADIUS server could be added to the WLAN by an attacker to obtain the login credentials of a legitimate user.

One other security risk is that MD5 does not use per-session WEP keys. Immediately after authentication, communication between the client and the access point is either not encrypted or is encrypted with a static WEP key, which allows eavesdropping to occur on data communications over a WLAN because static WEP can be broken. Many companies have chosen not to use MD5 as an authentication method because of its inherent vulnerabilities when used in a WLAN. Of particular concern, MD5 lacks persession WEP keys, one-way authentication, and challenge passwords. These shortcomings make use of MD5 a risky proposition.

PEAP

Several weaknesses in EAP were identified shortly after it was released. While using EAP, it was found that the initial identity request and corresponding response is sent in cleartext, so an attacker capturing and analyzing packets could obtain user identities for use in later attacks. There is no support in EAP for fast reconnections when roaming. This creates a problem when a client is trying to associate with a new access point while network traffic is flowing . EAP does not include packet management, so individual vendors are required to handle packet fragments and reassembly.

Multiple EAP types were developed to remedy these problems. Each type is based on EAP-TLS, which is regarded by experts as providing suitable security for wireless networks. Each one of these EAP types corrects the deficiencies described for EAP WLAN implementations. Microsoft, Cisco, and RSA Security developed PEAP to address these deficiencies by wrapping EAP in a TLS tunnel. PEAP is now an IETF draft [14]. PEAP is designed to protect EAP communication between clients and authenticators. PEAP uses TLS to create an encrypted tunnel from the authentication server to the supplicant after verifying the identity of the authentication server, providing support for identity protection. Once the encrypted tunnel is established, a second EAP authorization process occurs inside the tunnel to extend the TLS connection. Any implemented EAP authorization type (tokens, passwords, certificates, etc.) can be used as the client is authenticated in the second EAP authentication process running inside the TLS connection. PEAP also provides built-in support for packet fragmentation, packet reassembly, and fast reconnects.

The administrator must configure PEAP as an EAP type for a given connection policy as managed through a RADIUS server. PEAP must be supported by the client software and, in some cases, the firmware. Several older methods of user authentication such as MS-CHAPv2 are generally used as secure certificate-based authentication. They do not require the added management overhead necessary to implement and manage certificates. Both EAP-TTLS and PEAP were designed to use older authentication methods while maintaining the strong cryptographic foundation of TLS.

Both TTLS and PEAP are two-stage protocols that establish security in stage one and then exchange authentication in stage two. Both protocols establish a TLS tunnel in stage one and authenticate the authentication server to the client with a certificate. Although TTLS and PEAP still use certificates to authenticate the wireless network to the user, only server-side certificates are required. This results in a much more manageable system than that provided by a complete PKI certificate-based authentication system. In stage two, a secure tunnel is established and the client authentication credentials are exchanged. A TLS tunnel is used by PEAP to protect a second EAP exchange. The authentication must be performed using an EAP-defined protocol. Microsoft and Cisco both support PEAP. Client software is built into Microsoft's operating systems. Third-party add-on software is now available.

TTLS has a much larger market presence and acceptance than PEAP, resulting in much broader RADIUS support for TTLS than PEAP. Cisco and Microsoft's support of PEAP may drive expanded PEAP support in RADIUS. Both Cisco's Aironet Client Utility (ACU) and Windows XP with Service Pack 1 support PEAP. Currently, Microsoft provides native support for PEAP in Windows operating systems such as Windows XP and Windows.NET. Cisco's development of cross-platform clients may also assist in driving the growth of wireless PEAP implementations and applications.

Microsoft currently supports two types of PEAP: PEAP-EAP-MS-CHAPv2 and PEAP-EAP-TLS. Client-side passwords or certificates are used in PEAP-EAP-MS-CHAPv2. MS-CHAPv2 supports certificate authentication as part of the PEAP process, but only supports password authentication apart from PEAP. Server-side and client-side certificates are required in PEAP-EAP-TLS, providing the strongest possible level of security. When used as stand-alone authentication protocols, aside from PEAP, MS-CHAPv1 supports only one-way authentication, whereas MS-CHAPv2 supports mutual authentication between client and server using hashed shared passwords.

This section has provided a brief overview on WEP's usage and its inherent insecurity. TKIP and MIC were discussed as a solution to WEP's weaknesses. The different types of EAPs were reviewed in detail to provide a better understanding of how each protocol performs authentication. Advantages of dynamic key management and implementation methodologies were compared, along with the EAP types, including EAP-MD5, EAP-TLS, LEAP, EAP-TTLS, and PEAP. We next turn our attention to the use of Virtual Private Networks (VPNs) in a WLAN environment.