First things first. It’s 802.1X, not 802.1x or 802.11x. Now that we have that straight, let’s move on. 802.1X is an Institute of Electrical and Electronics Engineers (IEEE) standard for port based network access control. 802.1X provides a framework for authentication and authorization as well as dynamic encryption key management for over the air encryption. With 802.1X, all traffic with the exception of authentication traffic is blocked at the port until successful authentication. Upon successful authentication, normal traffic is able to pass through the port and the user or device is authorized to access network resources. Originally designed for use in wired networks, 802.1X has been adapted for use in Wireless Local Area Networks (WLANs). In a WLAN, the port is a virtual port or port entity.

The 802.1X authentication and authorization framework involves three main parties, each with a specific function. These three parties work in conjunction with each other to ensure only successfully authenticated 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 and devices. EAP will be discussed further below. The three major parties of the 802.1X framework are the supplicant, authenticator, and authentication server.

Supplicant, authenticator, and authentication server.

Supplicant
The supplicant is a host with software, a client side device such as a laptop, tablet, or handheld that is requesting authentication and authorization to the WLAN using credentials such as username/password or certificate. The supplicant sends EAP authentication messages to the authentication server at Layer 2 using EAP over LAN (EAPOL) encapsulation as all other traffic is blocked until successful authentication.

The term supplicant is often used interchangeably to refer to the software running on the client. The supplicant can be built into the operating system such as the Microsoft Windows, can be provided by the WLAN client adapter vendor such as the Intel PROSet Utility, or can be purchased from a 3rd Party such as the Juniper Networks’ Odyssey Access Client (OAC) (now owned and supported by Pulse Secure, LLC). For best practice, you should standardize on one supplicant type per device, for example use the built in supplicant on all your Microsoft Windows devices. 

Authenticator
The authenticator is a network device, such as an access point, that blocks all traffic through its port entity with the exception of EAP authentication traffic until successful authentication. The authenticator encapsulates the EAP authentication messages sent from the supplicant into the RADIUS protocol and forwards them on to the authentication server. The authenticator plays the role of the intermediary, passing authentication messages between the supplicant and authentication server. The authenticator maintains two virtual ports; an uncontrolled port and a controlled port. The uncontrolled port allows EAP authentication traffic to pass through, while the controlled port blocks all other traffic until successful authentication.

As the authenticator, the access point or WLAN controller must be configured to point to the IP address of one or more authentication/RADIUS servers, must be configured with the appropriate UDP ports being used by the RADIUS server (1645/1812 for authentication; 1646/1813 for accounting), and must be configured with a shared secret. A shared secret exists between the authenticator and authentication server so that they can validate each other.

Authentication Server
The authentication server is a server that validates the credentials of the supplicant that is requesting authentication and authorization to the WLAN. The authentication server is typically a RADIUS server that maintains a user data base or may proxy to another external database such as Microsoft Active Directory (AD)/LDAP. Upon successful authentication, the authentication server sends a RADIUS accept packet to the supplicant. The authenticator forwards the message to the supplicant in an EAP success frame, a 4-Way Handshake negotiation is completed to generate dynamic encryption keys for over the air encryption, the controlled port of the authenticator is unblocked, and the supplicant is authorized to access network resources. The next step the supplicant would take would typically be to obtain an IP address using DHCP.

Generic 802.1X/EAP exchange

RADIUS Client
When configuring the authentication server you must create a RADIUS client with the IP address and a shared secret for each access point or WLAN controller depending on the vendor. Alternatively you may be able to configure a RADIUS client in the RADIUS server with a range of IP addresses. Microsoft Windows Server Enterprise and Network Policy Server (NPS) for example allow you to configure a range of IP addresses in the address field by using Classless Inter-Domain Routing (CIDR) notation. For example if the access points were all on the 192.168.1.0/255.255.255.0 network, you could type 192.168.1.0/24 in the address field. Please beware however that Microsoft Windows Server Standard NPS does not support configuring a RADIUS Client with a range of IP addresses and you are limited to a maximum of 50 RADIUS clients. Again a shared secret exists between the authenticator and authentication server so that they can validate each other.

NPS configuration examples depicting a RADIUS client for a single AP and a RADIUS client for an entire subnet of APs using CIDR notation respectively.

Extensible Authentication Protocol (EAP)
The Extensible Authentication Protocol (EAP), as defined in IETF RFC 3748, and later updated in RFC 5247, supports multiple authentication methods. EAP was originally adopted for use with PPP but has since been redefined for use with 802.1X port based network access control. EAP is layer 2 protocol used within the 802.1X framework to validate users and devices. EAP is very flexible in that there are many different flavors of EAP or EAP methods available. Some are proprietary such as Cisco LEAP while others are standards-based such as EAP-TLS. Some provide mutual authentication while others do not. Some require both server and client side certificates, while some require just server side certificates; others don’t require certificates at all. Some use usernames and passwords, others use tokens. Some support machine or computer authentication while others don’t. Some send credentials inside an encrypted tunnel resulting in stronger security while others do not.

Let’s take a closer look at EAP-PEAP.