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.1x provides port-based access control. In this manner, EAP and 802.1x 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.1x authentication process begins with the wired clients using switches as authenticators and either TACACS+ or RADIUS authentication servers. An 802.1x wireless access point will filter or block all non-802.1x 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.1x/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.1x/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.