Chapter 4 802.1X/EAP Authentication

IN THIS CHAPTER, YOU WILL LEARN ABOUT THE FOLLOWING:

✓ WLAN authentication overview

✓ AAA

• Authentication

• Authorization

• Accounting

✓ 802.1X

• Supplicant

• Authenticator

• Authentication server

✓ Supplicant credentials

• Usernames and passwords

• Digital certificates

• Protected Access Credentials (PACs)

• One-time passwords

• Smart cards and USB tokens

• Machine authentication

✓ 802.1X/EAP and certificates

• Server certificates and root CA certificates

• Client certificates

✓ Shared secret

✓ Legacy authentication protocols

• PAP

• CHAP

• MSCHAP

• MSCHAPv2

✓ EAP

• Weak EAP protocols

• EAP-MD5

• EAP-LEAP

• Strong EAP protocols

• EAP-PEAP

• EAP-TTLS

• EAP-TLS

• EAP-FAST

• Miscellaneous EAP protocols

• EAP-SIM

• EAP-AKA

This chapter discusses the key concepts, components, and methods involved in WLAN authentication. You will learn about authentication, authorization, and accounting (AAA); what roles are played in the authentication process; 802.1X; and all of the EAP methods you will encounter in the real world that will assist you in securing your enterprise WLAN. 802.1X/EAP authentication, in particular, can be a difficult topic to grasp. This chapter will describe how EAP authentication works within an 802.1X network access control framework when used in enterprise WLANs. As we introduce each topic, we will provide real-world examples and design principles to help solidify each major concept.

WLAN Authentication Overview

WLAN authentication, in all of its many flavors, is what needs to occur before an individual or a device is allowed to access network resources. Authentication is the verification of users’ identity and credentials. Users must identify themselves and present credentials, such as usernames and passwords or digital certificates. Systems with higher levels of authentication use multifactor authentication, which requires at least two sets of different credentials to be presented. In a nutshell, authentication is based on who you are. Furthermore, who you are may indeed require more than one identifying element, but more on that later. After you successfully authenticate (via whatever method), encryption can then take place, but an important distinction must be made; authentication should be considered mutually exclusive from encryption. In Chapter 5, “802.11 Layer 2 Dynamic Encryption Key Generation,” you will learn that the authentication process provides the seeding material to create the necessary encryption keys, but conceptually it is still a separate concept and process. While the encryption process is a by-product of the authentication process, understand that the goals of authentication and encryption are very different. Authentication provides mechanisms for validating user and device identity; encryption provides mechanisms for data privacy and confidentiality.

Since authentication requires proving who you are, you must present credentials that fall into three categories:

• Something you know

• Something you have

• Something you are

If multiple credentials are provided for validating identity, greater trust can be assigned to the identity of the party requesting access to the WLAN. Requiring multiple credentials to be presented for user validation is known as multifactor authentication. Requiring two sets of credentials to be presented for user validation is often called two-factor authentication. Some of the EAP authentication methods you will learn about in this chapter are capable of two-factor authentication.

For example, consider your bank debit card. When you insert your physical card (something you have) into the ATM machine, it then requests your PIN (something you know). Some banks even have a picture of the card owner imprinted on the card. The ATM machine can’t verify that, but what about the cashier clerk at your local supermarket? It immediately tells the clerk that when you present the card that it is indeed yours (and not someone else’s). The picture on the debit card immediately ties together for the clerk both something you are and something you have. If the debit card was used along with the PIN to complete a debit transaction and the clerk verifies your face with the picture identity on your card, three forms of credentials will have been used for authentication.

Biometrics, such as fingerprint, retina, and other biological verification methods, can also be used as something you are to prove your identity. Although biometrics are not usually employed in WLAN security authentication, biometric devices have become commonplace as built-in components in laptops, tablets, and smart phones. Even facial recognition, using the built-in video cameras in laptop displays, is being discussed as an additional form of authentication.

As these technologies develop, you can rest assured that yet another new authentication standard will emerge. The important thing to remember is that it will be just another authentication method using the principles presented in this chapter.

AAA

While we have already addressed authentication at a conceptual level, who or what is the one performing the authorization? Can we also have a record of this activity? In fact, how about having a record of when this authorization activity occurred, how long the user was on the network, where the user went, and whether the user is either still online or has ended their session? Authentication, authorization, and accounting (AAA) is a common computer security concept that defines the protection of network resources.

As we have already discussed, authentication is the verification of user identity and credentials. Users must identify themselves and present credentials, such as usernames and passwords or digital certificates. More secure authentication systems use multifactor authentication, which requires at least two sets of different credentials to be presented.

Authorization involves granting access to network resources and services. Before authorization to network resources can be granted, proper authentication must occur.

Accounting is tracking the use of network resources by users and devices. It is an important aspect of network security, used to keep a paper trail of who used what resource, when, and where. A record is kept of user identity, which resource was accessed, and at what time. Keeping an accounting trail is often a requirement of many industry regulations, such as the U.S. Health Insurance Portability and Accountability Act of 1996 (HIPAA).

Authentication

Let’s discuss authentication in a more technical manner now. What can we take advantage of in order to prove the identity of someone wanting to gain access to your precious WLAN and, therefore, potentially all the data you consider secure? Answers to that question will vary depending on the level of concern over the access to that network and thus the data that resides on it. Understanding this concept is critical from a design perspective when you are being consulted to help an enterprise decide how to best perform authentication.

The following are common examples of authentication credentials used in enterprise WLANs today:

• Usernames and passwords

• Digital certificates

• Dynamic/one-time passwords (for example, RSA SecurID)

• Smart cards or credentials stored on USB devices

• Machine authentication (based on an embedded machine identity)

• Preshared keys (PSK)

A bank system processing billions of dollars every second would have very different security concerns than a small company that sells, say, car tires. Both may consider their data secure, but there is additional cost and/or complexity in both deploying and operating stronger authentication types such as two-and three-factor authentication.

Two-factor authentication would function just as in our previous example where we are using the bank ATM with a debit card (first factor = something you have) and having to enter our PIN (second factor = something you know). A specific WLAN security example of two-factor authentication would be using a computer (a computer object) that is part of a Microsoft Active Directory (AD) and then having to use a Windows AD user account to log in from that computer. The purpose is to ensure access is only granted to your WLAN by being from both a valid and current AD computer and AD user account. For example, if you brought in your laptop from home that isn’t known by AD, the entity performing the authorization will not let you on the network regardless of your valid AD user credentials because you are not accessing the network from a valid “enterprise asset.”

People will typically opt to have their network secure as long as it does not become overly burdensome. However, at some level, the concern for security takes a front seat over the amount of burden an end user will have to endure to use the WLAN. In one of our previous examples, not only does the bank processing billions of dollars per second have concerns over the direct financial impact to the viability of its core business should somebody have access to manipulate this data, but there are also regulatory requirements such as PCI that dictate the minimum requirements to which the bank must adhere. Furthermore, there may also be trade secrets that could be gleaned from this data that competitors would want to access. Quite literally, a security breach of this network might mean the end of the bank’s business. The bank scenario is an example of when multifactor authentication may be required regardless of the additional burden placed on the end users. Later in this chapter, all of the commonly used and available enterprise EAP authentication methods will be discussed in detail.

Authorization

When you log into your email account, you will likely enter a username and a password. Who is authorizing your username and password? This is conceptually the email application server itself. The difference with WLAN security is that there are multiple applications being used via the WLAN portal, so some sort of overlay authorization solution is needed to validate user identity. An 802.11 WLAN normally serves as a portal to preexisting wired network resources, such as a corporate server farm. Authorization is about properly protecting network resources. Authorization allows authenticated users access to network resources, but users who cannot provide the proper authentication credentials will not be authorized. Authorization should be considered as a framework in which proper authentication can occur. Enterprise WLANs should use an 802.1X authorization framework.

In WLANs, a RADIUS server is typically the entity performing the authorization from the WLAN hardware’s perspective. Remote Authentication Dial-in User Service (RADIUS) is a networking protocol that provides AAA capabilities for computers to connect to and use network services. RADIUS authentication and authorization is defined in IETF RFC 2865. Accounting is defined in IETF RFC 2866. RADIUS servers are sometimes referred to as AAA servers. While a RADIUS server may actually communicate with other systems like Windows Active Directory or an LDAP server, from the WLAN’s perspective it is convenient to think of the RADIUS server as the single authorization entity. You will, in fact, find that many WLAN vendors offer RADIUS server capabilities directly in their access points and WLAN controllers. A deeper discussion on RADIUS deployment and scalability will be covered in Chapter 9, “RADIUS and LDAP.”

The IEEE 802.11-2012 standard does not dictate the use of a RADIUS server. However, the IEEE 802.11-2012 WLAN standard does dictate the use of the IEEE 802.1X-2004 standard for authentication and port control within an enterprise robust security network (RSN). 802.1X is a port-based access control standard that defines the mechanisms necessary to authenticate and authorize devices to network resources. This was a clever and logical way for IEEE 802.11 designers to leverage the use of a preexisting and popular standards-based authorization method and inherit all its strengths and benefits. RADIUS servers are usually one of the main components of an 802.1X authorization framework.

Accounting

When you purchase a gallon of milk from the supermarket with a check, many accounting records are generated from this transaction. For example, if you wrote the check, it is always wise to write down the check number in your check ledger, as well as the date, merchant, and amount of the check you just wrote. Better yet, much of the manual effort can be eliminated by using a checkbook with carbon copies. Next, the merchant will make their own accounting records, and then the bank, and so on. We can refer to this as the accounting trail.

An accounting trail is considered to be the Holy Grail if you are ever audited by the Internal Revenue Service (IRS), the U.S. government agency that ensures proper tax contributions. An IRS agent can follow the entire transaction from beginning to end with a proper accounting trail.

In the case of WLANs, an accounting record is also quite useful in security forensics in attempting to analyze a security breach or even when evaluating normal network activities. An accounting server will typically contain information such as the user account logged in, where it was logged in from (the actual AP or the controller), the time the transaction started, the amount of traffic sent and received by the user, when the user logged off, and so forth. Figure 4.1 shows an example of an accounting record from an accounting server.

FIGURE 4.1 Accounting trail

RADIUS accounting records typically contain the following elements at a minimum:

• Date

• Time

• Username

• RADIUS group

• Accounting status type

• Accounting session ID

• Accounting session time

• Service type

• Framed protocol

• Input octets

• Output octets

• Input packets

• Output packets

• Framed IP address

• NAS port

• NAS IP address

• Attribute value pairs

Vendors make use of their own attribute value pairs (AVPs) that can be captured by a RADIUS accounting service. Consult the manual for your particular RADIUS accounting system if there is other information not included in the standard reporting that you may want to have included.

Together, authentication, authorization, and accounting are commonly referred to as AAA. You will also find RADIUS servers typically referred to as AAA servers as most RADIUS servers perform the role of all three services. RADIUS accounting is defined in RFC 2866.

From a WLAN hardware device’s perspective, the authentication and authorization is typically broken off separately in the device configuration from the accounting server.

802.1X

The IEEE 802.1X-2004 standard is not specifically a wireless standard and is often mistakenly referred to as 802.11x. As mentioned earlier, the 802.1X standard is a port-based access control standard. The 802.1X-2001 standard was originally developed for 802.3 Ethernet networks. Later, 802.1X-2004 provided additional support for 802.11 wireless networks and Fiber Distributed Data Interface (FDDI) networks. The current version of the port-based access control standard, 802.1X-2010, defined further enhancements. 802.1X provides an authorization framework that allows or disallows traffic to pass through a port and thereby access network resources. An 802.1X framework may be implemented in either a wireless or wired environment. The 802.1X authorization framework consists of three main components, each with a specific role. These three 802.1X components work together to make sure only properly validated users and devices are authorized to access network resources. A Layer 2 authentication protocol called Extensible Authentication Protocol (EAP) is used within the 802.1X framework to validate users at Layer 2. EAP will be discussed in detail later in this chapter. The three major components of an 802.1X framework are as follows:

Supplicant A host with software that is requesting authentication and access to network resources. Each supplicant has unique authentication credentials that are verified by the authentication server. In a WLAN, the supplicant is often the laptop or wireless handheld device trying to access the network.

Authenticator A device that blocks or allows traffic to pass through its port entity. Authentication traffic is normally allowed to pass through the authenticator, while all other traffic is blocked until the identity of the supplicant has been verified. The authenticator maintains two virtual ports: an uncontrolled port and a controlled port. The uncontrolled port allows EAP authentication traffic to pass through, whereas the controlled port blocks all other traffic until the supplicant has been authenticated. In a WLAN, the authenticator is usually either an AP or a WLAN controller.

Authentication Server A server that validates the credentials of the supplicant that is requesting access and notifies the authenticator that the supplicant has been authorized. The authentication server will maintain a native database or may proxy query with an external database, such as an LDAP database, to authenticate the supplicant credentials. A RADIUS server normally functions as the authentication server.

You will see this terminology repeatedly over the course of your reading and hands-on work in WLAN security both inside this study guide and throughout industry publications. Each of these 802.1X components will now be discussed in further detail in the sections that follow.

Supplicant

The supplicant is the device that will need to be validated by the authentication server before being allowed access to network resources. The supplicant will use an EAP protocol to communicate with the authentication server at Layer 2. The supplicant will not be allowed to communicate at the upper Layers of 3–7 until the supplicant’s identity has been validated at Layer 2 by the authentication server. Once again, this EAP authentication process will be described in great detail later in this chapter.

Think of the supplicant as the client software on a Wi-Fi device where the WLAN client security is configured. This isn’t to be confused with the driver for the 802.11 radio of the device. The supplicant is a software application that performs the 802.1X endpoint services on a client device such as a laptop or smart phone. Fully featured enterprise supplicants can offer support for the wired Ethernet adapter and perhaps multiple 802.11 network adapters if necessary. Different types of supplicant client utility software exist, including

• Integrated OS supplicant

• Vendor-specific supplicant

• Third-party supplicant

The software interface that is most widely used to configure a Wi-Fi radio is usually the integrated operating system Wi-Fi client utilities. The client utilities are where the 802.1X supplicant security settings are defined. Laptop users will most likely use the Wi-Fi NIC configuration interface that is a part of the OS running on the laptop. The client software utilities are different depending on the OS of the laptop being used. The Wi-Fi client utilities also vary between different versions of operating systems, but they all support 802.1X supplicant capabilities. Support for 802.1X/EAP configuration in the supplicant software has improved over the years. For example, the Wi-Fi client utility in Windows 7 is much improved and drastically different from the client utility found in Windows XP. The Windows 8 client utility is different than the Windows 7 client utility. Figure 4.2 shows the most recent supplicant interface found in Windows 10. The Mac OS X 10.6 (Snow Leopard) client utility is different from the Mac OS X 10.11 (El Capitan) client utility. The operating systems of handheld devices usually also include some sort of Wi-Fi client utility that includes the supplicant security settings integrated into the OS of the device.

FIGURE 4.2 Integrated OS supplicant for Windows 10

Vendor-specific software supplicants are sometimes available for use instead of an integrated operating system software interface. SOHO client utilities are usually simplistic in nature and are designed for ease of use for the average home user. The majority of vendor-specific software utilities are for peripheral device WLAN radios such as a USB 802.11 radio. The use of vendor-specific client utilities has decreased dramatically in recent years as the use of peripheral Wi-Fi radios has also declined. Enterprise-grade vendor client utilities provide the software interface for the more expensive enterprise-grade vendor radios.

In the past, third-party 802.1X supplicant client utilities often brought the advantage of supporting many different EAP types, giving a WLAN administrator a wider range of security choices. The main disadvantage of third-party client utilities is that they cost extra money. Because integrated client utilities have improved over the years, the use of third-party Wi-Fi client utilities as supplicants has declined. As shown in Figure 4.3, the supplicant software is where all the 802.1X security settings are defined. Later in this chapter, you will learn about EAP protocols. The supplicant software must support the same EAP protocol as the RADIUS server. The majority of the EAP protocols require the use of X.509 digital certificates, which must be defined within the supplicant configuration. A root certificate from a trusted certificate authority (CA) must be designated, as shown in Figure 4.4. Some flavors of EAP also make use of client-side certificates, which must be defined in the supplicant configuration. Certificates and their role within 802.1X/EAP will be discussed in greater detail later in this chapter.

FIGURE 4.3 Supplicant EAP configuration

FIGURE 4.4 Supplicant Root CA certificate

Finally, the user security credentials are also configured within the supplicant software. As shown in Figure 4.5, supplicant software will allow for single sign-on capabilities for domain users in Active Directory. Although username and password credentials are what are normally validated within the 802.1X/EAP process, machine credentials can also be designated for validation with some supplicants. Remember that the role of the supplicant is to request network access within an 802.1X authorization framework. You will learn later in this chapter that the authentication server validates the supplicant credentials using a Layer 2 EAP authentication protocol.

FIGURE 4.5 Supplicant user credentials

Authenticator

From the context of EAP authentication, the role of the authenticator is quite simple. The authenticator plays the role of the intermediary, passing messages between the supplicant and the authentication server. These messages travel via an EAP authentication protocol. Remember that authenticator is an 802.1X term. Also remember that 802.1X was described as a port-based access control standard. 802.1X essentially blocks traffic until a successful Layer 2 EAP authentication occurs. As mentioned earlier, the authenticator maintains two virtual ports: an uncontrolled port and a controlled port. The uncontrolled port only allows EAP authentication traffic to pass through, while the controlled port blocks all other traffic until the supplicant has been authenticated. EAP will be discussed later in this chapter, so don’t worry about how it works at this point.

As shown in Figure 4.6, a standalone access point functions as the authenticator and the authentication server is typically a RADIUS server. Figure 4.7 shows that when an 802.1X security solution is used with a WLAN controller solution, the WLAN controller is the authenticator—and not the controller-based access points. In either case, directory services are often provided by a Lightweight Directory Access Protocol (LDAP) database that the RADIUS server queries. Active Directory would be an example of an LDAP database that is queried by a RADIUS server. Note that some WLAN vendors offer solutions where either a standalone AP or a WLAN controller can dual-function as a RADIUS server and perform direct LDAP queries, thus eliminating the need for an external RADIUS server.

FIGURE 4.6 802.1X comparison-standalone vs. controller-based APs

FIGURE 4.7 WLAN bridging and 802.1X

What about using an 802.1X framework with a WLAN bridging solution? As you can see in Figure 4.8, the root bridge would be the authenticator and the nonroot bridge would be the supplicant if 802.1X security is used in a WLAN bridged network.

FIGURE 4.8 Authenticator bouncer analogy

The term authenticator is a misnomer because the authenticator does not validate the supplicant’s credentials. The authenticator’s job is simply to either let traffic pass through or not pass through. As shown in Figure 4.8, a common analogy used to describe the authenticator is a bouncer at an exclusive nightclub that everybody is trying to get into. Picture some big, buff dude with a dark suit and an earpiece to communicate with the person holding the “guest list.” The bouncer serves the role of the authenticator. He holds out his hand in a blocking fashion as would-be party-goers request entrance to the club. The would-be party guest (supplicant) shows their ID and the bouncer passes the identity to the guest list holder on the other end of his communication link. The guest list holder or nightclub owner (authentication server) looks up the identity on the list and simply responds with a verbal thumbs up or thumbs down.

If the bouncer gets a thumbs up, he will unblock the entrance for the authorized party guest to enter. Once the guest enters the nightclub, the bouncer will then block the entrance again for all new attempts to enter the nightclub. If the bouncer receives a thumbs down from the nightclub owner, he will kick the posing party guest out of line and send them away.

As mentioned previously, the authenticator is either an AP or WLAN controller in your enterprise WLAN. What the authenticator needs to know is essentially who is going to provide the guest list services—which is the role of the authentication server. Therefore, when configuring a WLAN controller or AP as an authenticator, you would need to be able to point the authenticator in the direction of an authentication server. Typically, the authentication server is a RADIUS server. As shown in Figure 4.9, the authenticator would need to be configured with the RADIUS server’s IP address and along with a shared secret in order to communicate with the server. A shared secret is only used to validate and encrypt the communication link between the authenticator and the authentication server. The shared secret configured on both the authenticator and authentication server is not used for any part of supplicant validation. The shared secret is only for the authenticator-to-authentication server communication link. The authenticator and authentication server should be configured to use UDP port 1812 for authentication communications and UDP port 1813 for accounting communications. It should also be noted that the authenticator will be configured to “require” EAP authentication, but a specific EAP type is not chosen. Remember that the authenticator is essentially a pass-through device that either allows or disallows traffic to flow through the authenticator’s virtual ports.

FIGURE 4.9 Authenticator configuration

Authentication Server

As mentioned earlier, the authentication server (AS) validates the credentials of a supplicant that is requesting access and notifies the authenticator that the supplicant has been authorized. The authentication server will maintain a user database or may proxy with an external user database to authenticate user or device credentials. The authentication server and the supplicant communicate using a Layer 2 EAP authentication protocol. In almost all cases, a RADIUS server functions as the authentication server. The RADIUS server may indeed hold a master native user database, but usually will instead query to a preexisting external database. Any Lightweight Directory Access Protocol (LDAP)-compliant database can be queried by the RADIUS authentication server. LDAP is an application protocol for querying and modifying directory services running over TCP/IP networks. Active Directory is the most commonly used external LDAP database, but a RADIUS server can also query LDAP-compliant databases such as Apple Open Directory and Novell eDirectory. As shown in Figure 4.10, typically a RADIUS server performs authentication server duties and the RADIUS server initiates a proxy query to a preestablished LDAP-compliant database, such as Active Directory. This is referred to as proxy authentication.

FIGURE 4.10 Proxy authentication

Some WLAN controller vendors allow for direct queries from the authenticator (WLAN controller) to an LDAP database. This method may have design constraints for some situations but may be desirable for some enterprises wanting to increase authentication performance where RADIUS servers aren’t adding special features or additional user databases.

Although LDAP and direct AD integration is an option, RADIUS has been around for a very long time in WLAN security and is by far the most common method used for authentication servers. Table 4.1 contains examples of authentication servers.

TABLE 4.1 Examples of authentication servers

Product name	Protocol
Cisco ACS	RADIUS
Juniper Steel Belted RADIUS	RADIUS
Microsoft Network Policy Server (NPS)	RADIUS
Microsoft AD 2003 and higher	Kerberos and LDAP
FreeRADIUS (open source)	RADIUS

When configuring a RADIUS server, you need to be able to point the authentication server back in the direction of the authenticator. Typically the authenticator is a WLAN controller or access point. As shown in Figure 4.11, the AS would need to be configured with the authenticator’s IP address and shared secret in order to communicate with the authenticator. A more detailed discussion of RADIUS server configuration can be found in Chapter 9.

FIGURE 4.11 Authentication server configuration

From years of experience, most RADIUS servers used in enterprise WLAN security implementations are implemented quite simply. As mentioned earlier, RADIUS servers usually are only used to proxy a user authentication to some master list of users, which is typically Active Directory. Although there are several features that can be used to enhance security and operational features, most enterprises do not take advantage of them. One example of this is a feature called dynamic VLAN assignment. If a user who is requesting authentication is part of the Accounting group, that user will be assigned to a specific VLAN by passing down a VLAN identifier RADIUS attribute in the RADIUS response message when a user authentication is accepted. If the user requesting authentication is part of the Marketing group or General Staff group, those users can be placed in a different VLAN based on RADIUS attributes. RADIUS attributes carry the specific authentication, authorization information, and configuration details for requests and replies, including VLAN identifiers. RADIUS servers are also often used for dynamic role assignment.

Additional information such as user roles can be sent using vendor-specific attributes (VSAs). Without digressing too much, this capability would allow the WLAN administrator to inherit any currently implemented role-based access control (RBAC) mechanisms already implemented on the wired network, dynamically assigning them to the proper VLAN. For example, we generally want to keep the hands of non-accounting employees from accessing accounting applications like paycheck and expense approval systems, so typically most networks already employ some level of segmentation and access control to accomplish this for the wired network.

That being said, there is another server that can, in a way, be referred to as a new type of authentication server—NAC. Network Access Control (NAC) is a computer network security methodology that integrates endpoint security technology with user authentication. NAC can allow for access decisions to be based on a client’s antivirus state and OS patch version. NAC is an upcoming security enhancement gaining a lot of industry attention, and is typically designed to work with RADIUS servers. NAC servers are often being tied into an 802.1X framework design.

The NAC server could interrogate the user’s machine when attempting to authenticate, and it could additionally make sure the computer being used has the most recent antivirus definitions update installed. Therefore, not only is the 802.1X framework validating that the user is valid, it is also validating other factors important to controlling virus outbreaks and patching operating system and software security vulnerabilities. If a NAC server determines a computer does not meet certain minimum criteria, it then dynamically assigns the WLAN device to a “quarantine network” VLAN whereby the user only has access to update the virus definitions and download the necessary software patch.

Authentication servers provide the following key features:

Client/server model RADIUS servers receive user connection requests, authenticate the user, and provide any other information required to support the user network connection.

Network security Transactions between the authenticator and the RADIUS server contain sensitive user identity information and are encrypted by the RADIUS protocol.

Flexible authentication mechanisms RADIUS can support a variety of authentication methods that can, in turn, support a wide variety of applications and systems.

Extensible Authentication Protocol This protocol was designed to be flexible and to accommodate new attributes or enhancements easily.

Some vendors may supply features in addition to the ones listed here, but you will only be tested on your understanding of these topics.

Supplicant Credentials

As you have learned, the supplicant is the device that will need to be validated by the authentication server before being allowed access to network resources. The supplicant will use an EAP protocol to present credentials to the authentication server to prove identity. Depending on which type of EAP protocol is used, the supplicant identity credentials can be in many different forms, including

• Usernames and passwords

• Digital certificates

• Protected Access Credentials (PACs)

• Dynamic security token devices

• Smart cards

• USB devices

• Machine authentication

How these supplicant user credentials are used with EAP will be discussed later in this chapter. The following sections will offer a broad overview of the various types of supplicant identity credentials.

Usernames and Passwords

Simple usernames and their respective passwords are the most common form of identity information that is supplied by a supplicant to an authentication server. Many EAP methods use usernames and passwords. What may also be used is a domain name or realm that might tell the RADIUS server what master database to use. This is a clever way to use a single RADIUS infrastructure that proxies the correct user database based on the domain or realm. For example, if you are using Windows Active Directory and have more than one domain where user accounts exist, the supplicant can pass its credentials in a DOMAIN/username format. Here’s an example:

CWNP/Tom Carpenter

Most RADIUS servers accept multiple formats of the domain or realm identifier. It can, in some cases, also be accepted in the form of

Tom Carpenter@CWNP

Basically, the RADIUS server will dictate what forms are acceptable for this identity to be formatted. Be careful, though—some supplicants try to tinker with this format, making the assumption that the RADIUS server might always want to see it in the first form DOMAIN-NAME/username even if a user entered it using the second method.

Digital Certificates

Any Internet user who browses to a website with the https:// prefix encounters digital certificates. Likewise, every time an Internet user logs into a website or uses online banking, they are using digital certificates.

Most of us know that the web server’s certificate is used for encryption—a technology called Secure Socket Layer (SSL). SSL is a cryptographic protocol normally used to provide secure communications over the Internet. SSL uses end-to-end encryption at the Transport layer of the OSI model. What may not be self-evident is that your computer is also authenticating the web server based on the contents of the SSL certificate, as shown in Figure 4.12. In this example, we used the Wells Fargo website. The bank uses a Public Key Infrastructure (PKI) digital certificate. Notice that the URL matches exactly the “Issued to” statement in the certificate. You can also see the certificate was issued by Symantec, who provides the PKI management service for the bank’s website.

FIGURE 4.12 SSL certificate

Then by utilizing the X.509 PKI certificate, we were able to verify the identity of the remote computer. In this case, it is the web server for the bank. If you have ever viewed a certificate, you will see that it contains information about the holder, such as

• Common name

• Subject

• Issuer

• Valid dates

EAP authentication protocols can use both server-side and client-side certificates. Later in this chapter, we will discuss how some EAP protocols use server-side certificates to create an encrypted tunnel during the authentication process. If the EAP protocol supports client-side certificates, the implementation of a PKI will be necessary. Unique client certificates will have to be created, issued, and managed for every WLAN user or device. Upon expiration, certificates will also require updating. Because the client-side certificates are being used as credentials to validate the supplicant, the 802.1X authentication server validates the client-side certificate issued by a PKI.

Protected Access Credentials (PACs)

Another certificate-like credential that can be used by supplicants is called a Protected Access Credential (PAC). EAP-FAST uses PACs as credentials instead of the more standards-based X.509 certificates. EAP-FAST is an EAP protocol that was originally developed by Cisco as a replacement for EAP-LEAP and was designed for ease of deployment and renewal.

Because using client-side certificates requires the implementation of a PKI, the installation, administration, and cost of the PKI is often considered to be undesirable to maintain just for WLAN devices. Cisco knew this when they designed EAP-FAST and designed a PAC file. A PAC file is a close cousin of a digital certificate, but the RADIUS server is the issuing party. We already know the RADIUS server is also the authenticating party that validates the supplicant. While it is not quite the same, as a mental model you can think of an EAP-FAST PAC/RADIUS infrastructure as a mini-PKI. The RADIUS server issues and validates the correct PAC that is used by the supplicant. Each PAC is tied to an individual user identity. EAP-FAST will be discussed in greater detail later in this chapter.

One-Time Passwords

A security token is any physical device that is issued to an authorized user of computer services to enhance authentication strength. Some security tokens also incorporate one-time password capabilities. A one-time password (OTP) is a password that is only valid for a single login session or transaction. RSA Security is largely considered the inventor of the one-time password and is the dominant market leader in this space at the time of this writing. RSA developed a technology called SecurID that uses a dynamically updated one-time password at fixed intervals—usually 30 or 60 seconds. OTP security tokens can exist in either a hardware or software form factor. A hardware OTP security token device is shown in Figure 4.13.

Each token device is unique and is assigned to an individual user ID. The OTP generated from the token device is designed to be different from other token devices at any given time. When that user requests an authentication, the token device OTP must be supplied with the user’s normal password. If the user’s password is correct but the one-time password is wrong, the authentication fails. Therefore, this protects against stolen user identities.

FIGURE 4.13 OTP token device

Courtesy of RSA

The OTP token devices and the OTP authentication server verifying the passwords work off a precise time clock. A mathematical calculation is performed using the token device clock value as well as other token information. The OTP authentication server’s clock runs a similar calculation because it is synchronized with the token device. The OTP server already knows the other token device identity for each unique user in order to construct the same calculated result the token device uses.

OTP achieves a two-factor authentication for the user requesting access based on their user identity and something that user has in their possession. In theory, using OTP security tokens with 802.1X/EAP WLAN security sounds like a great idea because of the two-factor authentication. Several flavors of the EAP protocol can support OTP tokens. In reality, OTP tokens have not really been deployed extensively with WLANs because of issues during roaming. If a user roams from one AP to another AP and if a full 802.1X/EAP authentication occurs, a new OTP must be entered into the token. Because of the complexity, cost, and potential complications during roaming, OTP security with 802.1X/EAP has not really caught on.

Smart Cards and USB Tokens

Smart cards and USB tokens can also be used for a single-factor authentication. They really haven’t gained the mass popularity that was once anticipated, but they do have their niche. As shown in Figure 4.14, a smart card is any pocket-sized card with embedded integrated circuits that can process data. A smart card is also often referred to as an integrated circuit card (ICC). The key concept around a smart card or a USB token is to store unique user identity information securely on the integrated circuit chip. Typically, this data cannot be modified or copied. The contents can be nearly any type of information, but it is usually similar to or quite literally a client-side digital certificate. Most smart card technology is based on X.509 certificates. The core problem behind this identity method falls into the same PKI cost and management issues that are needed for client-side certificates on a per-user and perhaps even a per-machine basis. Effectively, a smart card or USB token functions as a client-side certificate and is often used when the EAP-TLS protocol is deployed with 802.1X.

FIGURE 4.14 Smart card

The United States Department of Defense (DoD) uses a Common Access Card (CAC) for identification of active-duty military personnel, reserve personnel, civilian employees, and contractor personnel. The CAC is based on X.509 certificates, with software middleware enabling an operating system to interface with the card via a hardware smart card reader. As shown in Figure 4.15, most smart card readers are external devices; however, internal smart card readers are now being built into laptops, handheld scanners, and even phones. As shown in Figure 4.16, USB security tokens can also function as client-side credentials. However, it should be noted that most government agencies and many corporations do not allow the use of any kind of USB device due to the security risks associated with the USB interface.

FIGURE 4.15 Smart card reader

FIGURE 4.16 USB security token

Courtesy of Aladdin

Machine Authentication

Although 802.1X/EAP is most often used to authenticate and authorize network access for users of a WLAN, computer devices can also be authorized. Computer authentication, more often know as machine authentication, is the concept of ensuring the device requesting access to the network is authorized in a separate but chained authentication process. Machine authentication is often deployed as an extra layer of security in Active Directory environments. As shown in Figure 4.17, when a Windows-based computer (machine) joins Active Directory, there is a computer account that gets created and a unique password is negotiated between the machine and AD. In the case of Windows, the machine credentials are based on a System Identifier (SID) value that is stored on a Windows domain computer after being joined to a Windows domain with Active Directory. The information stored in this SID is unique for each AD machine.

The computer account is used to identify the machine, even when no user is logged in, which can be used to provide the machine access to the network. Usually the machine does not need full access to the entire network and is often very restricted. Machine authentication is usually more about validating through 802.1X/EAP that the computer is authorized on the corporate network. 802.1X/EAP user authentication can then be used to grant further access. As shown in Figure 4.18, a computer might be placed into a unique VLAN after machine authentication and is transitioned to a different VLAN after user authentication. The machine authenticates using the cached machine credentials and the user authenticates when logging into the domain. Machine authentication is often used in enterprise environments where the computer is shared by multiple employees with different user accounts.

In Figure 4.18 the advanced settings show that the default User Or Computer Authentication mode is selected. The following process will occur if the computer is part of a domain. On boot, the computer domain account will be used to authenticate. This will mean the computer appears in the RADIUS server log as authenticating with HOSTcomputername as the username. Once the user logs into the computer, Windows will authenticate again using the username and end the machine authenticated session. If the user logs out, then Windows will again switch to authenticating with the computer domain account. This maintains the security concept of individual user authentication for the system.

FIGURE 4.17 Computer domain account

FIGURE 4.18 Supplicant: machine authentication

Many RADIUS servers are designed to note the multiple accounts authenticating from the same MAC and use this to chain the authentication process together to provide multiple authentication factors that are used to evaluate the security level of the device. An example would be a person with a user account logging into a network with their own device being put into a more restricted VLAN than if they had logged in with a corporate approved Windows computer.

It should be noted that machine authentication with 802.1X/EAP and Active Directory was designed for devices using the Windows OS. This is because when a user logs into a Windows system, the context of the system on the network changes and a new 802.1X/EAP authentication occurs. Your options for machine authentication with non-Windows operating systems are limited and complex. Although Macs have three different modes for configuring authentication (System, Login Window, and User), it’s not possible to use multiple modes and switch context as in Windows. Machine authentication is also not really an option for mobile devices using iOS and Android OS. Instead, mobile device management (MDM) solutions are often deployed for authorization purposes of company-owned and personal mobile devices. MDM is discussed in greater detail in Chapter 10, “Bring Your Own Device (BYOD) and Guest Access.”

802.1X/EAP and Certificates

You have already learned that within any 802.1X framework the authentication server validates the supplicant’s credentials. The most secure EAP authentication methods incorporate the concept of mutual authentication. We already know that the supplicant’s identity gets validated, but how about validating the authentication server’s identity? In other words, the EAP-protocol allows the supplicant to also validate the authentication server. Mutual authentication validates both the supplicant and the AS and, if implemented properly, will prevent man-in-the-middle attacks. If the authentication server is to be validated by the supplicant, the AS must present credentials to the supplicant. Most EAP protocols use a server-side certificate for the authentication server credentials. A server-side certificate can also be used to provide protection of username/password credentials in a process known as tunneled authentication.

Server Certificates and Root CA Certificates

As shown in Figure 4.19, a server certificate must be created and installed on the authentication server. Additionally, the root Certificate Authority (CA) public certificate that was used to create the server certificate must be installed on the supplicants. Distribution and installation of the root CA certificate to multiple WLAN supplicants is often the biggest challenge when deploying 802.1X/EAP security.

FIGURE 4.19 Server certificate and Root CA certificate

The authentication server certificate, in conjunction with the root CA public certificate, serves two major purposes:

Validates the Authentication Server The AS certificate is first used to validate the identity of the server to the WLAN supplicant. This process is akin to the supplicant saying, “Oh, I know who you are,” before the supplicant submits its own sensitive identity information. The server certificate is validated by the root CA certificate that resides on the supplicant. This is possible because the server certificate was created and signed by the root CA.

Creates an Encrypted TLS Tunnel EAP protocols that require a server-side certificate for the authentication server are used to create Transport Layer Security (TLS) encryption tunnels. TLS is a cryptographic protocol normally used to provide secure communications at the Transport layer of the OSI model. However, in the case of 802.1X/EAP, TLS technology is leveraged at Layer 2. Similar to a browser-based HTTPS session, the TLS protocol uses end-to-end encryption. Once the supplicant is sure of the identity of the authentication server, the supplicant then uses the certificate to establish an encrypted TLS tunnel. The supplicant identity credentials are then exchanged within the encrypted TLS tunnel. This process is known as tunneled authentication. The supplicant identity, you have already learned, can come in many forms. Whatever form of identity that is passed by supplicant, it will be passed within the encrypted TLS tunnel. The TLS tunnel protects the supplicant credentials from offline dictionary attacks and from eavesdropping. This is just like the method employed with e-commerce websites using HTTPS where credit card and personal information is passed securely through an SSL/TLS tunnel.

So where does the server certificate get created before it is installed on the RADIUS server? The simple method is to purchase a server certificate from a trusted root Certificate Authority (CA) such as GoDaddy (www.godaddy.com) or Verisign (www.verisign.com). The server certificates usually cost several hundred dollars a year for each RADIUS server you deploy. The good news is that the root CA certificate already resides on most WLAN devices that can function as supplicants, as seen in Figure 4.20. The major trusted CAs pay a lot of money to have their public root certificates accessible within the various operating systems. The main advantage of purchasing a server certificate from a trusted CA is that there is no need to distribute and install root certificates on WLAN clients because they already are there.

The other option is to create a server certificate signed by an internal private CA such as Microsoft Certificate Services. Much like a public CA, a private CA establishes an internal company trust chain using separate certificates for the root and the servers. Many companies choose this method because they prefer to keep all the security in-house. One downside of using a public CA with 802.1X/EAP is that an attacker can possibly perform a man-in-the middle attack. An attacker can use a rogue AP along with a rogue RADIUS server and a server certificate that was also created from the same public CA. This attack is complex and has many moving parts. But because the chain of trust might actually be compromised, most organizations instead choose to install a server certificate signed by an internal CA on the RADIUS server. The main challenge with using an internal private CA is the distribution and installation of the root CA certificate from the internal CA to all the supplicants.

FIGURE 4.20 Trusted Root CA certificates

802.1X using EAP protocols that require certificates provides solid WLAN security solution when properly configured at both the client and server side. Trusted root certificate authorities are being updated all of the time and distributed with regular OS service patches, or if you’re using Windows Active Directory, can be passed via a domain Group Policy automatically. The list of trust root authorities, sometimes referred to as a Certified Trust List (CTL), keeps on growing. Put simply, a client should be configured to be skeptical of the RADIUS server identity. Most supplicants allow this in the simple form of a Validate Server Certificate checkbox, just as with Windows supplicants, as shown in Figure 4.21.

FIGURE 4.21 Server certificate validation

Once this is checked, known trusted root authorities and imported computer certificates are listed. In some supplicants, when you click this checkbox with default options, you are essentially saying that any server with a certificate issued from any one of these trusted root authorities is fine with you. This leaves a potentially large security hole for a hacker to perform a man-in-the-middle attack. All an attacker would have to do is purchase a valid, current certificate from any one of those sources, and it would pass the supplicant’s acceptance criteria. To prevent this, always have the supplicant validate the server certificate and select the proper trusted root CA certificate that is used for the validation. This provides an additional check that validates the name of the certificate being sent to the client.

Client Certificates

A common mistake that people make is to confuse the root CA certificate that is installed on the supplicants with client-side certificates. A client certificate is an entirely different animal within a PKI infrastructure. As shown in Figure 4.22, client certificates can also be installed on a WLAN supplicant and be used as client credentials with some types of EAP authentication. The most commonly deployed protocol that uses client certificates is EAP-TLS, which will be discussed in greater detail later in this chapter. Server certificates and a root CA certificate are still used in conjunction to validate the RADIUS server; however, the client certificate is used as the validation credentials for the supplicant. Adding client certificates into the mix with 802.1X/EAP security does provide an extra level of security but also adds an extra level of management and cost. Client certificates or smart cards with EAP-TLS security are often used in verticals such as military, government, and the finance industry.

FIGURE 4.22 Client certificate – supplicant

Using a public CA is usually cost-prohibitive because every client certificate costs several hundred dollars. Therefore, a private CA with an internal PKI is used to create and manage the client certificates. Management of client-side certificates requires much more time and proper skill sets, which many administrators might not have. Furthermore, the client certificates need to be provisioned onto the WLAN clients along with the root CA certificates. The provisioning of client certificates to company devices can be automated via a GPO in Windows. However, challenges also remain for distribution of client certificates for employee personal devices and devices using a non-Windows OS. As previously stated, for non-Windows OS devices, an MDM or certificate onboarding solution is usually needed for certificate distribution.

Shared Secret

A shared secret is used between the authenticator and the authentication server for the RADIUS protocol exchange. As shown in Figure 4.23, Layer 2 EAP protocol communications occur between the supplicant and the AS. The 802.11 frames use what is called EAP over LAN (EAPOL) encapsulation between the supplicant and the authenticator to carry the EAP data. On the wired side, the RADIUS protocol is used between the authenticator and the AS. The EAP data is encapsulated within a RADIUS packet. A shared secret exists between the authenticator and the AS so that they can validate each other with the RADIUS protocol.

FIGURE 4.23 Shared secret

As mentioned earlier in this chapter, when configuring a RADIUS server, you need to configure each authenticator’s identity within each authentication server. Typically, the authenticator is a WLAN controller or an access point. The AS would need to be configured with each authenticator’s IP address and the shared secret in order to communicate with each authenticator.

Conversely, the authenticator itself is configured to point to a prioritized list of authentication servers (RADIUS server, in this example) with the following information:

• IP address of the RADIUS server

• UDP ports (1645 or 1812 for authentication; 1646 or 1813 for accounting)

• Shared secret

Usually, APs and WLAN controllers allow designation of up to three RADIUS servers for redundancy purposes.

Legacy Authentication Protocols

Before explaining EAP, it is important to discuss some legacy authentication protocols that have contributed to the history of network security. Some of these legacy protocols are still used within the stronger EAP authentication protocols. However, the legacy authentication protocols are used inside a TLS tunnel. You will see that the TLS tunnel is used to encrypt and protect the legacy authentication encryption methods. Let’s take a closer look at the legacy authentication protocols relevant to WLAN security.

PAP

Password Authentication Protocol (PAP) is defined in RFC 1334 and provides no protection to the peer identity. It was originally designed for use with Point-to-Point Protocol (PPP). Although rarely used, it would be logical to use PAP inside an encrypted TLS tunnel because of its nonsecure nature.

CHAP

Challenge Handshake Authentication Protocol (CHAP) is defined in RFC 1994 and is slightly more evolved than PAP. CHAP is used with PPP as well and differs in that the password of the user identity is encrypted with an MD5 hash. Because MD5 is not considered secure by today’s standards, CHAP should never be used outside of a TLS tunnel.

MS-CHAP

Microsoft developed a proprietary version of CHAP and later defined it in RFC 2433. Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) also uses a hash of the password in a transmitted user identity. Early versions of Active Directory (AD) store an MS-CHAP compatible hash of a user’s password in the AD database in lieu of the actual password. This hash can then be compared to the hash presented by the supplicant.

This initial version of MS-CHAP is considered weak, and many freely available software packages exist that can recover the password from the MS-CHAP hash. Therefore, MS-CHAP should be used only inside a TLS tunnel.

MS-CHAPv2

Of course, whenever vulnerability is discovered, a new version is ushered along. MS-CHAPv2 is defined in RFC 2759 and was first released with the Microsoft Windows 2000 family.

MS-CHAPv2 uses a much stronger hashing algorithm and also supports mutual authentication during an MS-CHAPv2 exchange. EAP-PEAP, EAP-TTLS, and EAP-FAST all optionally use MS-CHAPv2, or in the case of EAP-LEAP, it is exclusively used. MS-CHAPv2 has also been found vulnerable and should also be used only inside a TLS tunnel.

EAP

The Extensible Authentication Protocol (EAP), as defined in IETF RFC 2284, provides support for many authentication methods. EAP was originally adopted for use with PPP. EAP has since been redefined in the IETF RFC 3748 for use with 802.1X port-based access control.

As noted earlier, EAP stands for Extensible Authentication Protocol. The key word in EAP is extensible. EAP is a Layer 2 protocol that is very flexible, and many different flavors of EAP exist. Some, such as Cisco’s Lightweight Extensible Authentication Protocol (LEAP), are proprietary, whereas others, such as EAP-TLS, are considered standard based. Some may provide for only one-way authentication, whereas others provide two-way authentication, more commonly called mutual authentication. Mutual authentication requires not only that the authentication server validate the client credentials, but also that the supplicant authenticate the validity of the authentication server. Most types of EAP that require mutual authentication use a server-side digital certificate to validate the authentication server. As stated earlier, a server certificate will also be used to create an encrypted TLS tunnel. This tunnel is used to protect the exchange of client credentials.

As you learned earlier in this chapter, 802.1X is an authorization framework with the three components of the supplicant, authenticator, and authentication server. The main purpose of an 802.1X solution is to authorize the supplicant to use network resources. The supplicant will not be allowed to communicate at the upper Layers of 3–7 until the supplicant’s identity has been validated at Layer 2. EAP is the Layer 2 protocol used within an 802.1X framework.

The EAP messages are encapsulated in EAP over LAN (EAPOL) frames. There are five major types of EAPOL messages, as shown in Table 4.2.

TABLE 4.2 EAPOL messages

Packet type	Name	Description
0000 0000	EAP-Packet	This is an encapsulated EAP frame. The majority of EAP frames are EAP-Packet frames.
0000 0001	EAPOL-Start	This is an optional frame that the supplicant can use to start the EAP process.
0000 0010	EAPOL-Logoff	This frame terminates an EAP session and shuts down the virtual ports. Hackers sometimes use this frame for DoS attacks.
0000 0011	EAPOL-Key	This frame is used to exchange dynamic keying information. For example, it is used during the 4-Way Handshake.
0000 0100	EAPOL-Encapsulated - ASF-Alert	This frame is used to send alerts, such as SNMP traps, to the virtual ports.

Let’s review a generic EAP exchange. The two workhorses are the supplicant and the authentication server because they both use the EAP protocol to communicate with each other at Layer 2. The authenticator is the bouncer that sits between the two devices. As you have already learned, the authenticator maintains two virtual ports: an uncontrolled port and a controlled port. When open, the uncontrolled port allows EAP authentication traffic to pass through. The controlled port blocks all other traffic until the supplicant has been authenticated. When the controlled port is open, upper Layer 3–7 traffic can pass through. Dynamic IP addressing with DHCP is performed once the controlled port is opened.

As shown in Figure 4.24, 802.1X/EAP authentication works together with standard 802.11 Open System authentication and association. An 802.11 client station will actually establish a Layer 2 connection with the AP by associating and joining the basic service set (BSS). However, if 802.1X/EAP is implemented, Layer 2 is as far as the 802.11 station gets until the client also goes through the entire 802.1X/EAP process.

FIGURE 4.24 802.11 associations and 802.1X/EAP

Figure 4.25 displays all the steps in a generic EAP exchange. The authenticator in this example is an access point. Please refer to the figure as we go over each of these steps.

1. The 802.11 client (supplicant) associates with the AP and joins the BSS. Both the controlled and uncontrolled ports are blocked on the authenticator.

2. The supplicant initiates the EAP authentication process by sending an 802.11 EAPOL-Start frame to the authenticator. This is an optional frame and may or may not be used by different types of EAP.

   FIGURE 4.25 Generic EAP exchange

   

3. The authenticator sends an 802.11 EAP-Request frame requesting the identity of the supplicant. The EAP-Request Identity frame is always a required frame.

4. The supplicant sends an EAP response frame with the supplicant’s identity in clear text. The username is always in clear text in the EAP-Response Identity frame. At this point, the uncontrolled port opens to allow EAP traffic through. All other traffic remains blocked by the controlled port.

5. The authenticator encapsulates the EAP response frame in a RADIUS packet and forwards it to the authentication server.

6. The AS looks at the supplicant’s name and checks the database of users and passwords. The AS will then create a password challenge and send the challenge to the supplicant encapsulated in a RADIUS packet.

7. The authenticator forwards the password challenge to the supplicant in an 802.11 EAP frame.

8. The supplicant takes the password and hashes it with a hash algorithm such as MD-5 or MS-CHAPv2. The supplicant then sends the hash response in an EAP frame back to the AS.

9. The authenticator forwards the challenge response in a RADIUS packet to the AS.

10. The AS runs an identical hash and checks to see if the response is correct. The AS will then send either a success or failure message back to the supplicant.

11. The authenticator forwards the AS message to the supplicant in an EAP-Success frame. The supplicant has now been authenticated.

12. The final step is the 4-Way Handshake negotiation between the authenticator and the supplicant. This is a complex process used to generate dynamic encryption keys. This process is discussed in great detail in Chapter 5.

13. Once the supplicant has completed Layer 2 EAP authentication and created dynamic encryption keys, the controlled port is unblocked. The supplicant is then authorized to use network resources. If using IP, the next step the supplicant will take is obtain an IP address using DHCP.

You should notice that in step 4, the supplicant’s username is seen in clear text. This might be considered a security risk. You should also notice that in steps 6–9, the supplicant’s password credentials are validated using a weak challenge/hash response. This frame exchange can be captured using a WLAN protocol analyzer such as Wireshark. This is a security risk because the hash algorithms have been cracked and they are susceptible to offline dictionary attacks. In other words, the presentation of supplicant identity and validation of supplicant credentials is a security risk. Wouldn’t it be better if steps 4–9 were protected in an encrypted tunnel? Since its original adoption, a number of weaknesses were discovered with some EAP authentication methods. The most secure EAP methods used today employ tunneled authentication to pass identity credentials (usernames and passwords) similar to what you find with web-based e-commerce transactions. We will now discuss the major EAP protocols, including the ones that use tunneled authentication.

Weak EAP Protocols

Older legacy EAP protocols exist that are highly susceptible to a variety of attacks, including social engineering and offline dictionary attacks. These authentication protocols had their day in the sun, but they should be viewed as absolutely unacceptable solutions in enterprise WLANs now that more secure EAP protocols are available. We will now discuss two legacy protocols called EAP-MD5 and EAP-LEAP.

EAP-MD5

EAP-Message Digest5 (EAP-MD5) is a fairly simple EAP type and is conceptually similar to the generic EAP method described in the previous section. EAP-MD5 was for a long time used for port authentication on wired networks and therefore was one of the very first EAP types used with WLANs. Many organizations were already using EAP-MD5, and it was a logical progression to leverage it for WLANs because RADIUS servers already supported it. However, EAP-MD5 has several major weaknesses:

One-Way Authentication Only the supplicant is validated; the server is not validated. Mutual authentication is needed to create dynamic encryption keys. If EAP-MD5 is the chosen authentication method, the encryption method is static WEP or no encryption at all.

Username in Clear Text The supplicant’s username is always seen in clear text, as illustrated in Figure 4.25 earlier. If a hacker knows the identity of the user, the hacker can attempt to get the password using social engineering techniques. Therefore, EAP-MD5 is vulnerable to social engineering attacks.

Weak MD5 Hash The supplicant password is hashed using the MD5 hash function, which was once considered secure enough for its intended use in PPP networks. MD5 was never designed to be used over a wireless medium, and it is easily broken using a variety of hacker tools available today. Therefore, EAP-MD5 is highly susceptible to offline dictionary attacks.

Because of these three major weaknesses, EAP-MD5 should never be used in an enterprise WLAN environment now that stronger EAP protocols exist.

EAP-LEAP

EAP-Lightweight Extensible Authentication Protocol (EAP-LEAP), also known simply as LEAP, was a hugely successful EAP type used in the enterprise for many years. LEAP was easy to deploy using the same identity credentials to which end users were already intimately accustomed—that is, usernames and passwords. Furthermore, it was introduced in 2000 when security weaknesses were discovered with static WEP encryption. LEAP was also used to generate dynamic WEP keys, as described in Chapter 5. Dynamic WEP was a predecessor to TKIP/RC4 and CCMP/AES dynamic encryption. LEAP was a big step forward in security at the time.

Unlike EAP-MD5, LEAP does perform a type of pseudo-mutual authentication. Most documentation claims that LEAP supports mutual authentication. The password hash comparison algorithm used with MS-CHAP and MS-CHAPv2 validates that each side has the same password using a mutual authentication process. This is not the same mutual authentication that we’ve discussed where the supplicant validates the authentication server identity.

LEAP is not a TLS tunneled authentication method and is not an open standard; it must be licensed from Cisco. Figure 4.26 depicts the entire EAP-LEAP authentication process.

LEAP has several major weaknesses:

Username in Clear Text The supplicant’s username is always seen in clear text in the initial EAP-Response frame sent by the supplicant to the authentication server. If a hacker knows the identity of the user, the hacker can attempt to get the password using social engineering techniques. Therefore EAP-LEAP is vulnerable to social engineering attacks.

Weak MS-CHAPv2 Hash The supplicant password is hashed using the MS-CHAPv2 hash function. MS-CHAPv2 has also been found to be vulnerable. A widely available program called ASLEAP, developed by Joshua Wright, can perform an offline dictionary attack on the hash function and easily obtain the password. Therefore, EAP-LEAP is highly susceptible to offline dictionary attacks.

FIGURE 4.26 EAP-LEAP

Pseudo-Mutual Authentication There has been some confusion with LEAP over the years with respect to mutual authentication. Since LEAP uses MS-CHAPv2, the MS-CHAPv2 protocol itself supports a form of mutual authentication. With respect to the grand scheme of WLAN security and what a WLAN security professional should look for in a security protocol, this form of mutual authentication buys very little.

The biggest problem with both EAP-MD5 and LEAP is that the prize is absolutely huge to a hacker—a username and password. The username and password is likely the same username and password used for Windows Active Directory or whatever network operating system might be installed. With a high-gain antenna sitting from quite far away, an attacker can pick up this exchange and gain full access credentials for WLAN users in mass. Combine this with a little knowledge of who the IT administrator is, and an attacker can have the keys to the kingdom in very short order. Or what about the CEO? That username and password just might give an attacker access to the CEO’s email account. What’s more, there is no way this attack can be detected because it can be performed completely passively and offline.

The success of an offline dictionary attack is only as strong as the size of the offline dictionary file. The use of strong and complex passwords might defeat this attack, but the bulk of the end-user population does not use passwords anywhere near strong enough to defeat the offline attack. Furthermore, enforcing strong password policies comes with significant end-user challenges.

LEAP is a Cisco proprietary protocol, and despite claims of mutual authentication, the authentication server in reality is never authenticated. LEAP relies on the mutual authentication properties of MS-CHAPv2, which is simply the peer challenge and response.

When configuring a supplicant for LEAP, put simply, you only provide a username and password. There is no configuration for validating a server-side certificate or any information about the AS. An authentication server can easily be impersonated when a supplicant participates in a LEAP authentication. A rogue access point configured for a different authentication server—perhaps one that records usernames and passwords to a log file—would result in a supplicant merrily sending along its user credentials, unaware that the credentials are being intercepted.

As a WLAN security professional, you should never deploy LEAP within a modern-day WLAN given the options available to you today. If your organization is currently running LEAP, provide a quick migration path for your organization to a WPA/WPA2-based, TLS-tunneled EAP method.

Strong EAP Protocols

It should be clear at this point that the key to enterprise wireless security is leveraging 802.1X/EAP. The service provided by 802.1X, as you have also already learned, blocks traffic until a successful authentication transaction occurs. 802.1X is simply a vehicle that enables port blocking and provides the framework for the authentication transaction to occur. The stronger methods of EAP use TLS-based authentication and/or TLS-tunneled authentication. We have already referenced tunneled EAP authentication types earlier in this chapter. In this section, we are going to explore the most common of these types and their inner workings in detail.

Unlike EAP-MD5 and EAP-LEAP, which have only one supplicant identity, EAP methods that use tunneled authentication have two supplicant identities. These two supplicant identities are often called the outer identity and the inner identity. The outer identity is effectively a bogus username, and the inner identity is the true identity of the supplicant. The outer identity is seen in clear text outside the encrypted TLS tunnel, whereas the inner identity is protected within the TLS tunnel.

As you can see in Figure 4.27, the original EAP standard requires that there always be a clear-text value in the initial EAP-Response frame sent by the supplicant to the authentication server. This clear-text value is the outer identity that travels outside the TLS tunnel. The default value used by most supplicants is “anonymous.”

FIGURE 4.27 Outer identity

Although the default value used by many supplicants for the outer identity is “anonymous,” the outer identity is usually a configurable setting. Keep in mind that this is not the real username. Some WLAN administrators use funny names such as Donald Duck or Mickey Mouse. Other WLAN administrators use a facility code identifying a group of supplicants. The facility code could be used for troubleshooting efforts of 802.1X/EAP supplicant failures and can help you quickly narrow down the facility where the problem was occurring. Other WLAN administrators use the outer identity as a social engineering honeypot. It should be noted that the default setting for the outer identity in some supplicants is the real username. In other words, the real username is used for both the inner and the outer identity. Some WLAN administrators do not necessarily view this as a security risk because company naming conventions are very easy to guess. The TLS tunnel will always encrypt the inner identity, but more importantly the TLS tunnel is used to protect the password challenge and response that is susceptible to offline dictionary attacks. Do not confuse the encryption used by the TLS tunnel with Layer 2 encryption that is used to protect the payload of 802.11 data frames. The encrypted TLS tunnel is created and exists only for a few milliseconds. The whole purpose of tunneled authentication is to provide a secure channel to protect the username/password identity credentials. The username/password credentials are encrypted inside the TLS tunnel. The TLS tunnel is not used to encrypt 802.11 data frames. We will now discuss versions of EAP that support tunneled authentication.

EAP-PEAP

EAP-Protected Extensible Authentication Protocol (EAP-PEAP), also known simply as PEAP, creates an encrypted TLS tunnel within which the supplicant’s inner identity is validated. Thus the term “protected” is used because the supplicant’s identity and credentials are always encrypted inside the TLS tunnel that is established.

PEAP is probably the most common and most widely supported EAP method used in WLAN security. That is, it is the most popular EAP type that is considered highly secure. The confusion regarding PEAP usually revolves around the fact that there are multiple flavors of PEAP, including these three major versions:

• EAP-PEAPv0 (EAP-MSCHAPv2)

• EAP-PEAPv0 (EAP-TLS)

• EAP-PEAPv1 (EAP-GTC)

PEAP is often referred to as “EAP inside EAP” authentication because the inner authentication protocol used inside the TLS tunnel is also another type of EAP. PEAPv0 and PEAPv1 both refer to the outer authentication method and are the mechanisms that create the secure TLS tunnel to protect subsequent authentication transactions. The EAP protocol enclosed within parentheses is the inner EAP protocol used with each of these three flavors of EAP-PEAP. The main difference between these three major flavors of EAP is simply the inner EAP protocol that is used within the TLS tunnel.

We will discuss the differences between these three versions of PEAP later in this section. First, let’s discuss how all flavors of PEAP operate. A key point is that in order to establish the TLS tunnel, a server-side certificate is required for all flavors of PEAP. As shown in Figure 4.28, the EAP-PEAP process involves two phases. Please refer to the figure as we discuss the two phases of EAP-PEAP. Please note that the steps are summarized and do not match the numbers in Figure 4.28. Although there are three major types of PEAP, we will use EAP-PEAPv0 (EAP-MSCHAPv2) as the example in Figure 4.28.

Phase 1

1. The authenticator sends an EAP frame requesting the identity of the supplicant.

2. The supplicant responds with an EAP response frame with the clear-text outer identity that is not the real username and is a bogus username.

3. At this point, the uncontrolled port opens on the authenticator to allow EAP traffic through. All other traffic remains blocked by the controlled port. The authenticator forwards the outer identity response to the AS.

4. The outer identity response cannot inform the AS about the actual identity of the supplicant. It simply informs the AS that a supplicant wants to be validated.

5. The AS sends the server certificate down to the supplicant. The supplicant uses the root-CA certificate to validate the server-side certificate and therefore authenticates the authentication server.

6. An encrypted point-to-point TLS tunnel is created between the supplicant and the authentication server. Once the TLS tunnel is established, Phase 2 can begin.

FIGURE 4.28 EAP-PEAP process

Phase 2

1. The AS requests the real identity of the supplicant.

2. The supplicant responds with the inner identity, which is the real username. The real username is now hidden because it is encrypted inside the TLS tunnel.

3. The remaining steps in Phase 2 involve a password challenge from the AS and a hashed response from the supplicant using an authentication protocol within the tunnel. The supplicant username/password credentials are validated by the authentication server. The entire exchange is encrypted within the TLS tunnel.

The whole point of Phase 2 is to validate the supplicant username/password credentials while encrypted within the TLS tunnel. The inner identity, or real username, is protected and therefore hidden. The password challenge and response exchange is also encrypted and protected. Whatever authentication method that is used inside the tunnel is also protected; therefore, any offline dictionary attacks are ineffective in obtaining the password.

PEAP has an interesting history. It began as a joint proposal by Cisco, Microsoft, and RSA Security. It is reported that Microsoft and Cisco didn’t completely agree on every detail and subsequently Microsoft implemented PEAPv0 using MS-CHAPv2 as the inner authentication method. MS-CHAPv2 is Microsoft’s own version of CHAP. Because Microsoft is the dominant player in both client and server operating systems providing built-in support, this has led to the success of EAP-PEAPv0 (EAP-MS-CHAPv2). Cisco split from the original specification, PEAPv1, which predominantly uses EAP-GTC as the inner authentication method. Supplicants and RADIUS servers may support all three type of PEAP; however, Microsoft’s EAP-PEAPv0 (EAP-MS-CHAPv2) is the most widely supported, including supplicants that are native to other operating systems such as Mac OS X, iOS, and Android OS.

We will now discuss the differences between the various versions of PEAP. As mentioned earlier, PEAP is often referred to as “EAP inside EAP” authentication because the inner authentication protocol used inside the TLS tunnel is also another type of EAP. The only real difference is the inner EAP protocol that is used within the TLS tunnel. PEAPv0 and PEAPv1 both refer to the outer authentication method and are the mechanisms that create the secure TLS tunnel to protect subsequent authentication transactions. PEAPv0 supports inner EAP methods of EAP-MSCHAPv2 and EAP-TLS whereas PEAPv1 supports the inner EAP method of EAP-GTC. All versions of PEAP require a server-side certificate, and all versions of PEAP operate using the two phases described earlier.

EAP-PEAPv0 (EAP-MSCHAPv2)

As mentioned earlier, Microsoft’s EAP-PEAPv0 (EAP-MSCHAPv2) is the most common form of PEAP. The protocol used for authentication inside the tunnel is EAP-MSCHAPv2. What is the difference between the normal MS-CHAPv2 protocol and the EAP-MSCHAPv2 protocol? For all practical purposes, they basically operate in the same manner and use the same hash algorithm. However, it should be noted that EAP-MSCHAPv2 is considered a separate protocol. The credentials used for this version of PEAP are usernames and passwords. Client-side certificates are not used and are not supported.

EAP-PEAPv0 (EAP-TLS)

This is another type of PEAP from Microsoft. EAP-PEAPv0 (EAP-TLS) uses the EAP-TLS protocol for the inner-tunnel authentication method. EAP-TLS requires the use of a client-side certificate. The client-side certificate is validated inside the TLS tunnel. No username is required for validation because the client-side certificate serves as the user credentials. This flavor of EAP is rarely used because the standards-based EAP-TLS is the usual choice when client-side certificates are also deployed.

EAP-PEAPv1 (EAP-GTC)

Cisco’s version of PEAP uses yet another different type of EAP for the inner tunnel authentication. EAP-PEAPv1 (EAP-GTC) uses EAP-Generic Token Card (EAP-GTC) for the inner-tunnel authentication protocol. EAP-GTC is defined in the IETF RFC 3748 and was developed to provide interoperability with existing security token device systems that use one-time passwords (OTP) such as RSA’s SecurID solution. The EAP-GTC method is intended for use with security token devices, but the credentials can also be a clear-text username and password. In other words, when EAP-GTC is used within a PEAPv1 tunnel, normally the credentials are a simple clear-text username and password.

Other versions of PEAP also exist. Other EAP protocols, such as EAP-POTP, can also be used for the inner-tunnel authentication method. EAP-POTP will be discussed later in this chapter.

Initially there were numerous compatibility issues because of the different types of PEAP. However, in practice you will be hard-pressed to find a case where you need to consider what PEAP version you are using anymore. Most RADIUS server vendors now support all versions of PEAP. Likewise, some supplicants will support multiple versions of PEAP. As stated earlier, almost all supplicants support EAP-PEAPv0 (EAP-MSCHAPv2) as the default version of PEAP.

EAP-TTLS

EAP-Tunneled Transport Layer Security (EAP-TTLS) was originally designed by Certicom and Funk Software (which is now owned by Juniper Networks) and is defined in RFC 5281. As with PEAP, it also uses a TLS tunnel to protect less-secure inner authentication methods. As shown in Figure 4.29, EAP-TTLS also uses two phases of operation very similar to EAP-PEAP.

The differences between EAP-TTLS and EAP-PEAP are fairly minor when analyzing them from a high level. The biggest difference is that EAP-TTLS supports more inner authentication methods, such as the legacy methods of PAP, CHAP, MS-CHAP, and MS-CHAPv2. EAP-TTLS also supports the use of EAP protocols as the inner authentication method. Figure 4.29 shows EAP-MSCHAPv2 being used for inner authentication; however, multiple authentication methods are supported within the TLS tunnel.

Remember that EAP-PEAP only supports EAP protocols for inner authentication whereas EAP-TTLS supports just about anything for inner authentication. Server-side certificates are required with EAP-TTLS to create the TLS tunnel, and client-side certificates are optional. Depending on the type of inner authentication method used, client-side certificates can be used as the protected supplicant credentials within the tunnel. Normally, however, the supplicant credentials are usernames and passwords because they are far easier to implement.

EAP-TTLS has been widely deployed, and it is likely to be encountered in many enterprise WLANs. While EAP-TTLS is almost identical to EAP-PEAP, it may not have the same native support in the operating systems of some supplicant devices. All major enterprise RADIUS servers seem to have built-in support for EAP-TTLS.

FIGURE 4.29 EAP-TTLS process

EAP-TLS

EAP Transport Layer Security (EAP-TLS) is defined in RFC 5216 and is a widely used security protocol. It is largely considered one of the most secure EAP methods used in WLANs today. This, however, comes at a cost.

EAP-TLS requires the use of client-side certificates in addition to a server certificate. Implementing a server-side certificate is not much of a burden, and EAP-TLS has the same server-side certificate requirement as EAP-PEAP and EAP-TTLS. The problem is that having a unique digital client certificate for each client requires a great deal of planning, infrastructure, and staff time relative to all the other EAP methods.

The biggest factor when deciding to implement EAP-TLS is whether an enterprise PKI infrastructure is already in place. This would usually, and optimally, include separate servers in a high-availability server cluster. Furthermore, access to these servers is critically important and must be guarded just like a master password list. Quite literally, these servers will have the certificate store, which includes the private keys for the entire PKI infrastructure. Therefore, even though EAP-TLS is widely considered secure, it can only be as secure as the certificate store.

Most enterprises consider managing, securing, and maintaining a PKI to be an unwanted burden. Therefore, unless one was already in place, EAP-TLS would not likely be a WLAN security professional’s first recommendation. EAP-TLS is often used in verticals such as the banking industry where the cost and time for providing proper security is an afterthought. Figure 4.30 depicts the EAP-TLS process.

FIGURE 4.30 EAP-TLS process

There are a few noteworthy points about the EAP-TLS protocol. From this process, you will notice that the AS presents its server-side certificate to the client first. If this certificate is not from a source that the client trusts, the supplicant can end the conversation immediately. The same goes for the AS. If the AS does not like the identity of the client-side certificate, it will reject the authentication attempt after the client has been given the first right of refusal.

An AS configured for EAP-TLS will typically allow validation of the client-side certificate by comparing one or more of the following in the user certificate:

• Certificate Subject Alternative Name (SAN)

• Certificate Subject Common Name (CN)

• Certificate Binary—a binary comparison to what’s included with the user object in LDAP or Active Directory database to what the supplicant presents

Also, there isn’t necessarily a tunnel where an inner authentication takes place like with the other TLS tunnel-based EAP types. However, there is an optional privacy mode where a TLS handshake can be established before the client identity is passed. When privacy mode is established, a typical TLS tunnel is also created as in PEAP and EAP-TTLS. However, the privacy method is generally not implemented by vendors.

Using client certificates is optional with EAP-TTLS and some flavors of EAP-PEAP that also use tunneled authentication. However, using a tunnel for a client certificate is not necessary. It is typically recommended to deploy EAP-TLS when using client-side certificates because of the wide support for the protocol.

An important point to mention is Microsoft’s implementation of Certificate Autoenrollment. Microsoft built a feature into their Active Directory solution when using their Certificate Authority (CA) product (free with Windows Server products) to auto-publish client certificates. This means that the biggest problem with EAP-TLS—deploying certificates to each end-user device—has been mostly automated with Microsoft end-user devices. Keep in mind that only domain objects will be applicable for this feature and the client-side certificate will have to be installed manually with other non-Microsoft WLAN clients.

EAP-FAST

Cisco initially developed the EAP-Flexible Authentication via Secure Tunneling (EAP-FAST) protocol, and it has been a proprietary protocol until fairly recently. No, “FAST” doesn’t mean that it is necessarily faster than other EAP types. IETF RFC 4851 was meant to define a standard for EAP-FAST, and the protocol is also recognized as part of the Wi-Fi Alliance WPA2 interoperability certification.

EAP-FAST is clearly stated in public documents by Cisco that it was designed to be a convenient, easy-to-implement replacement for LEAP. When it was discovered that LEAP can be easily cracked, something had to be done quickly. The whole point of EAP-FAST was to create a secure method of EAP authentication that would be resilient against offline dictionary attacks, yet not require the use of certificates. EAP-FAST provides for both mutual authentication and tunneled authentication just like EAP-PEAP and EAP-TTLS. However, EAP-FAST does not use standards-based X.509 digital certificates to create the TLS tunnel. Instead, EAP-FAST uses PACs.

PACs

A Protected Access Credential (PAC) is a cousin of a digital certificate. Actually, it is a shared secret. Since EAP-FAST is the only EAP type that uses PACs, it is prudent to discuss a bit of the EAP-FAST process with respect to how it is used in authentication server identity validation for the supplicant.

A PAC can consist of three components:

Shared Secret—The PAC-Key A preshared key between the client and the authentication server.

Opaque Element—The PAC-Opaque A variable-length data element sent during tunnel establishment where the AS can decode the required information to validate the client’s identity.

Other Information—PAC-Info A variable-length data element that minimally provides the authority identity of the PAC issuer (usually the master RADIUS server, which would be the PAC Authority). May also contain the PAC-Key lifetime.

As shown in Figure 4.31, EAP-FAST operates in three phases:

Phase 0 This phase is used for automatic PAC provisioning. Each supplicant is automatically sent a unique client PAC using an anonymous Diffie-Hellman exchange. After each client station initially receives a PAC, clients will skip Phase 0 in subsequent logins. Phase 0 is an optional phase, and all PACs can also be installed on the clients manually.

Phase 1 During this phase, the supplicant sends the outer bogus identity to let the AS know that a client seeks validation. The client and the AS negotiate using symmetric key encryption from the PAC shared secret (PAC-Opaque). The result of this negotiation is the establishment of an encrypted TLS tunnel.

Phase 2 The supplicant is then validated within the encrypted tunnel. EAP-FAST supports several inner authentication methods, including client-side certificates, just as EAP-TLS does. The authentication protocol normally used inside the tunnel is EAP-GTC when username and passwords serve as the client identity information. A token-based solution is also a possibility.

Let’s discuss manual and automatic PAC provisioning in a little more detail. The client PACs referenced earlier are created on the RADIUS server using a server-side master key and are unique to each client identity. After they have been created, they must be installed on each supplicant much like a client-side certificate is done. The client PACs can be manually installed by the WLAN administrator on each separate machine, and there will be no need for the optional Phase 0. Clients that already have a PAC file would proceed directly to Phase 1. However, if the WLAN administrator enables automatic PAC provisioning in Phase 0, the client PACs are installed automatically.

FIGURE 4.31 EAP-FAST process

Auto-provisioning might sound great, but the problem is, how does the client know that it is talking to a valid RADIUS server? If you use EAP-FAST with auto-provisioned PAC files, you are allowing your clients to auto-provision from an unknown and perhaps untrusted server.

Automatic PAC provisioning is performed using an anonymous Diffie-Hellman exchange whereby the client simply has to trust the person providing the PAC. This subjects EAP-FAST to man-in-the-middle attacks during Phase 0. Despite the risks of Phase 0, most organizations using EAP-FAST typically deploy using automatic PAC provisioning because they are seeking the convenience provided by EAP-FAST. Auto-provisioning is a configurable option on the RADIUS server. However, the problem is that most client supplicants do not have any administrative control over enforcing this, even if the RADIUS server did not allow automatic PAC provisioning.

As mentioned earlier, if EAP-FAST is deployed without the optional phase 0, the IT administrator will have to deploy PAC files manually to each machine. Doing this sacrifices the convenience of EAP-FAST. If you were to do all of that, why would you not just use a more standardized and much more widely acceptable protocol like EAP-TLS or EAP-PEAP? The amount of effort and coordination involved to accomplish this is ridiculous. It would be far easier and logical to use EAP-PEAP, EAP-TTLS, or EAP-TLS. Furthermore, an EAP-FAST supplicant must use the appropriate PAC file from its PAC file storage for the appropriate user identity. Since PAC files are based on user identities, a different client identity cannot use the same PAC file or authentication will fail. Even though EAP-FAST is not proprietary, it is normally deployed in enterprise environments that use a Cisco infrastructure.

Some organizations will use Phase 0 and automatic PAC provisioning during the initial installation of the WLAN and then disable automatic PAC provisioning. However, it should be noted that the only way EAP-FAST can be considered relatively secure is if, and only if, each PAC was deployed manually and automatic PAC provisioning was disabled.

There is another point to mention about EAP-FAST. A key component of this protocol revolves around PACs and distributing them to clients. What is truly unique about EAP-FAST is that the PAC file contains a shared secret instead of a certificate. When using a PKI, asymmetric encryption must be used to decrypt the client identity response. In other words, the AS will use its private key, that only it has, to decrypt the supplicant’s response that is encrypted using the AS public certificate. The computational overhead involved in this asymmetric encryption process is expensive. EAP-FAST uses a symmetric encryption algorithm based on the shared secret of each client’s unique PAC. Therefore, there is technically a minor performance advantage to using EAP-FAST.

Despite the fact that EAP-FAST can now be considered a mature protocol, it has not really caught on outside of Cisco-specific deployments. There is not a lot of widespread support for the EAP-FAST protocol in supplicants that instead support the EAP protocols that use certificates. EAP-PEAPv0 (EAP-MSCHAPv2) remains the most widely used protocol for 802.1X WLAN security when server-side certificates are the only requirement. If client-side certificates are also mandated, EAP-TLS is usually the chosen Layer 2 authentication protocol used within an 802.1X authorization framework.

	EAP-MD5	EAP-LEAP	EAP-TLS	EAP-TTLS	PEAPv0 (EAP-MSCHAPv2)	PEAPv0 (EAP-TLS)	PEAPv1 (EAP-GTC)	EAP-FAST
Security Solution	RFC-3748	Cisco proprietary	RFC-5216	RFC 5281	IETF draft	IETF draft	IETF draft	RFC 4851
Digital Certificates—Client	No	No	Yes	Optional	No	Yes	Optional	No
Digital Certificates—Server	No	No	Yes	Yes	Yes	Yes	Yes	No
Client Password Authentication	Yes	Yes	N/A	Yes	Yes	No	Yes	Yes
PACs—Client	No	No	No	No	No	No	No	Yes
PACs—Server	No	No	No	No	No	No	No	Yes
Credential Security	Weak	Weak (depends on password strength)	Strong	Strong	Strong	Strong	Strong	Strong (if Phase 0 is secure)
Encryption Key Management	No	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Mutual Authentication	No	Debatable	Yes	Yes	Yes	Yes	Yes	Yes
Tunneled Authentication	No	No	Optional	Yes	Yes	Yes	Yes	Yes
Wi-Fi Alliance Supported	No	No	Yes	Yes	Yes	No	Yes	Yes

Miscellaneous EAP Protocols

Many other flavors of EAP also exist. For example, there are proprietary protocols such as AirFortress EAP and Cogent Systems Biometrics Authentication EAP. We mentioned earlier that PEAPv1-EAP-GTC can be used with one-time password (OTP) token devices. IETF RFC 4793 defines EAP-Protected One-Time Password Protocol (EAP-POTP), which is another EAP method suitable for use with OTP token devices. EAP-POTP may be used as a better alternative for an internal authentication method inside the TLS tunnel of other protocols such as EAP-PEAP or EAP-TTLS.

Some EAP protocols are intended for use in the mobile phone industry. In the sections that follow, we will discuss two EAP methods that are intended for use with cellular networks.

EAP-SIM

EAP-Subscriber Identity Module (EAP-SIM) was primarily developed for the mobile phone industry and more specifically for second-generation (2G) mobile networks. Many of us who have mobile phones are familiar with the concept of a Subscriber Identity Module (SIM) card. A SIM card is an embedded identification and storage device very similar to a smart card. SIM cards are smaller and fit into small mobile devices like cellular or mobile phones with a 1:1 relationship to a device at any given time. The Global System for Mobile Communications (GSM) is a second-generation mobile network standard. EAP-SIM is outlined in the IETF RFC 4186, and it specifies an EAP mechanism that is based on 2G mobile network GSM authentication and key agreement primitives. For mobile phone carriers, this is a valuable piece of information that can be utilized for authentication. EAP-SIM does not offer mutual authentication, and key lengths are much shorter than the third-generation mechanisms used in third-generation (3G) mobile networks.

EAP-AKA

EAP-Authentication and Key Agreement (EAP-AKA) is an EAP type primarily developed for the mobile phone industry and more specifically for 3G mobile networks. EAP-AKA is outlined in the IETF RFC 4187, and it defines the use of the authentication and key agreement mechanisms already being used by the two types of 3G mobile networks. The 3G mobile networks include the Universal Mobile Telecommunications System (UTMS) and CDMA2000. AKA typically runs in a SIM module. The SIM module may also be referred to as a User Subscriber Identity Module (USIM) or Removable User Identity Module (R-UIM), which, as discussed earlier, is very similar to a smart card.

AKA is based on challenge-response mechanisms and symmetric cryptography and runs in the USIM or RUIM module. Key lengths can be substantially longer, and mutual authentication has now been included.

As WLANs are used more and more for voice communications, a protocol that can extend from the mobile network carriers into an enterprise WLAN can provide some advantages. Fixed Mobile Convergence (FMC) is a growing market segment targeted at large enterprises whereby dual-mode mobile phones (Wi-Fi-enabled mobile phones) can roam from a mobile network carrier to a WLAN and maintain a call session state. The promise is that with EAP-AKA being standardized in 802.11-based networks, a single user identifier would authenticate the device for both networks.

In mid-2009, the Wi-Fi Alliance announced the inclusion of EAP-AKA into the WPA2 interoperability suite. Both EAP-SIM and EAP-AKA are protocols that can be used with cellular devices.

A growing trend with public access networks is the use of 802.1X/EAP with Hotspot 2.0. Hotspot 2.0 is a Wi-Fi Alliance technical specification that is supported by the Passpoint certification program. With Hotspot 2.0, the client device is equipped by an authentication provider with one or more credentials, such as a SIM card, username/password pair, or X.509 certificate. Passpoint devices can query the network prior to connecting in order to identify potential authentication providers that are available on that network. Both EAP-SIM and EAP-AKA are protocols that can be used with cellular devices.

As WLANs are used more and more for voice communications, a protocol that can extend from the mobile network carriers into an enterprise WLAN can provide some advantages. Fixed Mobile Convergence (FMC) is a growing market segment targeted at large enterprises whereby dual-mode mobile phones (Wi-Fi-enabled mobile phones) can roam from a mobile network carrier to a WLAN and maintain a call session state. It is still early for enterprise WLANs to support FMC, and it will be interesting to see how EAP-AKA will play a role with these devices. The promise is that with EAP-AKA being standardized in 802.11-based networks, a single user identifier would authenticate the device for both networks.

EAP-TEAP

A more recent specification of EAP was defined in RFC-7170 for Tunneled Extensible Authentication Protocol (TEAP). This protocol is an enhanced version of EAP-FAST that uses PACs for credentials. TEAP also uses tunneled authentication, and multiple inner authentication protocols are supported within the TLS tunnel. TEAP allows for multiple credentials to be authenticated within a single EAP transaction. TEAP has the ability to link the credentials of the machine and the user together in a process known as EAP chaining. For example, EAP-TLS could be run twice as an inner authentication method, first using machine credentials then with user credentials.

Summary

802.1X/EAP enterprise methods currently exist that allow for secure WLAN communication. Hopefully, enough information was presented in this chapter to create more awareness regarding 802.1X framework and Layer 2 EAP authentication methods.

As a WLAN security professional, your ability to understand the complexities of the many protocols involved in WLAN security is paramount. Each protocol has its advantages and drawbacks, which must be mapped to the requirements of each implementation. Furthermore, a proper deployment of each security type must be performed. Simply using a strong EAP type doesn’t mean security is achieved.

The key thing to keep in mind is that you need to employ the most secure method possible for your organization based on the abilities of the client devices, end users, and systems being deployed.

Exam Essentials

Explain the concept of credentials. Understand the differences between something you are, something you have, and something you know. Explain the importance of multifactor authentication.

Understand the concept of AAA. Explain in detail how authentication is used to validate identity, authorization is used to grant access, and accounting is used for a paper trail.

Describe the 802.1X framework. Explain the roles of the 802.1X components of the supplicant, authenticator, and authentication server. Understand the concept of controlled and uncontrolled virtual ports.

Define the various types of supplicant identity credentials. Describe the many different types of credentials that can be used by a supplicant. This includes username/passwords, client certificates, machine credentials, and many more.

Describe the role of server-side and root CA certificates. Understand how a server-side certificate is used to validate the authentication server. Understand that the other purpose of the server-side certificate is to create an encrypted TLS tunnel.

Describe the role of client-side and root CA certificates. Understand that client-side certificates can be used with some versions of EAP as a client credential during the authentication process. Realize that EAP-TLS is the most common protocol deployed when client certificates are mandated.

Explain all the Layer 2 EAP methods. Be able to explain all the capabilities of each EAP method as well as the differences. Understand why different EAP methods may be used in different situations.

Review Questions

1. Which of these types of EAP use tunneled authentication? (Choose all that apply.)

A. EAP-LEAP

B. EAP-PEAPv0 (EAP-MSCHAPv2)

C. EAP-PEAPv1 (EAP-GTC)

D. EAP-FAST

E. EAP-TLS (privacy mode)

2. Which of these types of EAP require a client-side X.509 digital certificate to be used as the supplicant credentials? (Choose all that apply.)

A. EAP-TTLS

B. EAP-PEAPv0 (EAP-MSCHAPv2)

C. EAP-PEAPv0 (EAP-TLS)

D. EAP-FAST

E. EAP-TLS (privacy mode)

F. EAP-TLS (nonprivacy mode)

3. Which of these types of EAP use three phases of operation? (Choose all that apply.)

A. EAP-TTLS

B. EAP-PEAPv0 (EAP-MSCHAPv2)

C. EAP-PEAPv0 (EAP-TLS)

D. EAP-FAST

E. EAP-TLS (privacy mode)

F. EAP-TLS (nonprivacy mode)

4. Which of these types of EAP require a server-side certificate to create an encrypted TLS tunnel?

A. EAP-TTLS

B. EAP-PEAPv0 (EAP-MSCHAPv2)

C. EAP-PEAPv0 (EAP-TLS)

D. EAP-FAST

E. EAP-PEAPv1 (EAP-GTC)

F. EAP-LEAP

5. Which of these types of EAP are susceptible to offline dictionary attacks? (Choose all that apply.)

A. EAP-SIM

B. EAP-MD5

C. EAP-PEAPv0 (EAP-TLS)

D. EAP-FAST

E. EAP-PEAPv1 (EAP-GTC)

F. EAP-LEAP

6. What is the difference between the inner and outer identity?

A. Only the authentication server provides its credentials in the outer identity response.

B. The inner identity is only for authentication server credentials provided to the supplicant.

C. The inner identity must correspond to the outer identity for realm-based authentications.

D. The outer identity is in plain text; the inner identity is securely transmitted inside a TLS tunnel.

E. The outer identity is only for authentication server credentials provided to the supplicant.

7. How does a RADIUS server communicate with an authenticator? (Choose all that apply.)

A. UDP ports 1812 and 1813

B. TCP ports 1645 and 1646

C. Encrypted TLS tunnel

D. Encrypted IPsec tunnel

E. RADIUS IP packets

F. EAPOL frames

8. In a point-to-point bridge environment where 802.1X/EAP is used for bridge authentication, what device in the network acts as the 802.1X supplicant?

A. Nonroot bridge

B. WLAN controller

C. Root bridge

D. RADIUS server

E. Layer 3 core switch

9. Which Layer 2 protocol is used for authentication in an 802.1X framework?

A. PAP

B. MS-CHAPv2

C. EAP

D. CHAP

E. MS-CHAP

10. Which of these types of EAP offers support for legacy authentication protocols within the inner TLS tunnel to validate supplicant credentials?

A. EAP-TLS

B. EAP-TTLS

C. EAP-FAST

D. EAP-PEAPv0

E. EAP-PEAPv1

11. When you are using an 802.11 wireless controller solution, which device would you consider the authenticator?

A. Access point

B. RADIUS database

C. LDAP

D. WLAN controller

E. VLAN

12. For an 802.1X/EAP solution to work properly, which two components must both support the same type of EAP? (Choose two.)

A. Supplicant

B. Authorizer

C. Authenticator

D. Authentication server

13. What does 802.1X/EAP provide when implemented for WLAN security? (Choose all that apply.)

A. Access to network resources

B. Verification of access point credentials

C. Dynamic authentication

D. Dynamic encryption-key generation

E. Verification of user credentials

14. Chris has been hired as a consultant to secure the Harkins Corporation’s WLAN infrastructure. Management has asked him to choose a WLAN authentication solution that will best protect the company’s network resources from unauthorized users. The company is also looking for a strong dynamic encryption solution for data privacy reasons. Management is also looking for the cheapest solution as well as a solution that is easy to administer. Which of these WLAN security solutions does Chris decide meets all of the objectives required by management? (Choose the best answer.)

A. EAP-TLS and TKIP/RC4 encryption

B. EAP-TLS and CCMP/AES encryption

C. EAP-PEAPv0 (MSCHAPv2) and CCMP/AES encryption

D. EAP-PEAPv0 (EAP-TLS) and CCMP/AES encryption

E. EAP-FAST/manual provisioning and CCMP/AES encryption

F. EAP-MD5 and CCMP/AES encryption

15. What type of credential is used by the authenticator and authentication server to validate each other?

A. Server-side X.509 digital certificate

B. PAC

C. Client-side X.509 digital certificate

D. Username and password

E. Security token

F. Shared secret

16. Which of these types of EAP is designed for a Fixed Mobile Convergence (FMC) authentication solution over an 802.11 WLAN and a 3G cellular telephone network?

A. EAP-SIM

B. EAP-GTC

C. EAP-PEAPv0 (EAP-TLS)

D. EAP-AKA

E. EAP-Fortress

F. EAP-TTLS

17. What are some of the supplicant credentials that could be validated by an authentication server? (Choose all that apply.)

A. Server-side X.509 digital certificate

B. PAC

C. Client-side X.509 digital certificate

D. Username and password

E. Security token

F. Smart card

18. When 802.1X/EAP is properly deployed, which of these external databases can a RADIUS server query for proxy authentication?

A. Active Directory

B. E-Directory

C. Open Directory

D. All of the above

19. Which of these inner authentication EAP types is intended to be used with an 802.1X framework that uses security token devices as the supplicant credentials? (Choose all that apply.)

A. EAP-GTC

B. EAP-MSCHAPv2

C. EAP-POTP

D. EAP-LEAP

E. EAP-PEAP

F. EAP-TTLS

20. WLAN administrator Tammy O’Connell has been tasked with securing the corporate WLAN with 802.1X/EAP security. She has chosen to use the EAP-PEAPv0 (MSCHAPv2) protocol on the RADIUS servers and supplicants. Tammy created a root certificate using the company’s internal private Certificate Authority (CA) solution. She also created a server certificate, which was signed by the internal private CA. The wireless clients connecting to the WLAN include a mixture of corporate Windows laptops. Employees will also be connecting with personal devices such as Android phones and tablets. What other steps must Tammy take to ensure full functionality with 802.1X/EAP security? (Choose all that apply.)

A. Install the server certificate on the RADIUS server.

B. Distribute and install the server certificate to Windows laptops with GPO.

C. Distribute and install the root CA certificate to Windows laptops with GPO.

D. Distribute and install the server certificate to employee devices with GPO.

E. Distribute and install the root CA certificate to employee devices with GPO.

F. Distribute and install the server certificate to employee devices with MDM.

G. Distribute and install the root CA certificate to employee devices with MDM.