Organizations with ten or more employees should use 802.1X port-based authentication to control network access using individual credentials rather than pre-shared keys.

Control Type: Technical

Control Function: Preventive

The classic method for clients to connect to a network is with either a pre-shared key for wireless connections, or directly to the wired network with a patch cable. However, larger enterprise networks need a more secure way to control how clients connect. 802.1X requires users or devices to authenticate to the network individually, validating their credentials against an authentication server and blocking unauthorized access. 802.1X is an open standard that accomplishes just this. It is an IEEE standard and uses port-based network access control to provide access to networks.

802.1X uses three concepts to break down the concept of network authentication:

  1. Supplicant: a client device that wants to connect to the network.
  2. Authenticator: the network device that controls access to the network.
  3. Authentication Server: a central system that validates authentication credentials against a database or identity store to decide whether access should be granted.

Now, instead of simply using a single pre-shared key to access a wireless network or providing plug-and-play access to the wired infrastructure, enterprises can require users or devices to authenticate before being granted network access. In many cases, these credentials are integrated with another identity store, such as the organization's Active Directory. This way, a universal set of credentials can be used to authenticate to multiple resources.

There are generally two different protocols involved in the 802.1X framework. The first is the Extensible Authentication Protocol (EAP), which provides a framework for negotiating how a client authenticates to the authentication server. Then, Remote Authentication Dial-In User Service (RADIUS) is commonly used to transport the authentication messages between the authenticator and the authentication server. TACACS+ can also provide AAA services for network devices, but it is generally not used to implement 802.1X port-based network access control.

The EAP protocol is not inherently bound to whether a supplicant is connecting via WiFi or a wired link. EAP can also be used by other authentication frameworks, including some VPN implementations. In an 802.1X deployment, EAP is carried between the supplicant and authenticator using EAP over LAN (EAPOL), while the authenticator commonly encapsulates the EAP messages in RADIUS when communicating with the authentication server.

  1. Supplicant connects to the network infrastructure and requests access.
  2. Authenticator requests the supplicant to provide authentication information.
  3. Supplicant responds with its authentication information (username and password, certificate, etc.).
  4. Authenticator forwards the EAP authentication messages to the authentication server, commonly using RADIUS.
  5. Authentication server and supplicant communicate to negotiate and complete the authentication process.
  6. Supplicant is either granted access or denied access.

The interesting thing about EAP is that it is broken down into multiple types, each with varying levels of security. Some of the most common are:

  1. EAP-MSCHAPv2: Uses a challenge-response method with usernames and passwords. It is an older method of using EAP and is commonly used inside PEAP for authentication in Windows AD environments. However, MSCHAPv2 is less secure than certificate-based methods such as EAP-TLS, and captured authentication exchanges can potentially be subjected to offline password-cracking attacks.
  2. PEAP: Uses a TLS tunnel to protect the inner authentication method from outside sniffing. It is commonly paired with EAP-MSCHAPv2 to transport password-based authentication securely. However, PEAP with MSCHAPv2 still relies on passwords and is generally considered less robust than certificate-based authentication such as EAP-TLS.
  3. EAP-PSK: Uses a pre-shared key for authentication and does not require certificates. It is designed for environments where pre-shared keys are appropriate and is not generally the preferred method for large enterprise 802.1X deployments where individual device or user identity is required.
  4. EAP-MD5: A client proves that it knows a password by answering an MD5 challenge-response. This method is now considered obsolete and insecure. It does not provide mutual authentication or adequate protection against credential attacks, and thus should not be used in enterprise environments.
  5. EAP-LEAP: This is a Cisco proprietary version of EAP that uses challenge-response methods to authenticate clients. While historically used, it is now considered insecure and obsolete and should not be used in modern environments.
  6. EAP-SIM: Uses SIM credentials to authenticate devices. This makes it useful for environments involving cellular network authentication. However, it has limited applicability to typical enterprise wired and wireless network authentication.
  7. EAP-IKEv2: Uses the IKEv2 protocol found in IPsec, providing strong cryptographic protection and supporting multiple authentication methods. However, it is more complex than commonly deployed enterprise EAP methods and is not typically the first choice for a basic enterprise wireless network.
  8. EAP-FAST: Uses a protected TLS tunnel and a Protected Access Credential (PAC) to allow authentication inside the tunnel. This method was designed in part to avoid some of the certificate-management requirements of other EAP methods. However, it is more complex and is not commonly used in modern enterprise deployments.
  9. EAP-TEAP: Uses a TLS tunnel and allows multiple authentication methods within the tunnel. This method supports authentication chaining, allowing organizations to authenticate both the device and the user. It is useful for enterprise environments but is more complicated to deploy and requires compatible infrastructure.
  10. EAP-TTLS: Uses a server certificate to create an encrypted TLS tunnel, then allows an inner authentication method, typically involving a username and password, inside the tunnel. This can provide strong protection for password-based authentication, although EAP-TLS is generally preferred when an organization has the PKI and certificate-management infrastructure necessary to support it.
  11. EAP-TLS: Probably the most established EAP method for enterprise certificate-based authentication. It authenticates the client and server using X.509 certificates handled through a PKI. This provides strong mutual authentication and can be used to authenticate devices as well as users. EAP-TLS is highly useful for environments pursuing a zero-trust approach to user and device security. EAP-TLS does require a PKI and stable certificate management, which can put it out of scope for smaller businesses.

As these brief explanations demonstrate, EAP is used as a framework for negotiating and performing authentication between the supplicant and authentication server, with the authenticator acting as the intermediary. However, what are the specific details of RADIUS and TACACS+?

RADIUS is an older protocol originally intended for dial-up networks. However, it is still widely used today. RADIUS provides authentication, authorization, and accounting (AAA) services. In an 802.1X deployment, the authenticator forwards EAP authentication messages to the RADIUS server, which validates the authentication request and provides a response to the authenticator indicating whether access should be granted or denied. The authorization portion of RADIUS can also provide the authenticator with additional network-access information, such as VLAN assignments, ACL assignments, and QoS profiles. The accounting functionality allows organizations to record information about authentication sessions and network usage.

On the other hand, TACACS+ is a Cisco-developed AAA protocol that offers a few beneficial features. While traditional RADIUS encrypts the user's password field rather than the entire RADIUS packet, TACACS+ encrypts the body of its packets. RADIUS also traditionally combines authentication and authorization into a single exchange, while TACACS+ separates authentication, authorization, and accounting, allowing administrators to have more granular control over network-device access. However, the biggest difference between RADIUS and TACACS+ comes with what they are used for. TACACS+ is primarily used for authentication and authorization of administrators accessing network devices for management tasks, such as configuring Cisco network devices. It is not generally used for 802.1X port-based network access control. RADIUS, on the other hand, is widely used for port-based network access control, which is why it is much more common in 802.1X deployments.

Organizations can implement an 802.1X authentication server through a variety of proprietary and open-source means. Windows Server provides a Network Policy Server (NPS), which can be used as a RADIUS server for authentication and authorization. This is useful in environments that already have a dominant Windows architecture. NPS can use the same user accounts and passwords that exist in an organization's Active Directory. For open-source options, FreeRADIUS is a free RADIUS server that can be deployed and customized by network administrators to the organization's liking. PacketFence is another open-source software platform that can use FreeRADIUS but also expands its functionality into a full-fledged Network Access Control (NAC) solution. Not only does it support 802.1X authentication, but it also allows Layer 2 isolation, device profiling, VLAN assignment, and integration with vulnerability scanners and IDS/IPS systems.