Deep dive into how authentication with 802.1x works

Dec 12, 2024

By Jonas Hammarbäck

General

Some time ago I gave a talk about how authentication works and talked about both 802.1x and MAC authentication and what distinguishes different 802.1x authentication methods such as EAP-TLS, EAP-TEAP and EAP-PEAP. Here is a brief summary of the content.

Authentication takes place in several steps and the image below describes the overall steps. Initially, the client is blocked from accessing the network and authentication is performed before the port is opened to network traffic.

An important point to remember when troubleshooting clients that do not work in the network is to check whether the client has successfully authenticated in the RADIUS server. If this has not been done, the flow will stop, the port will not open and the client cannot get an IP address.

It is not uncommon for troubleshooting to focus on “the computer is not getting an IP address”, when instead it may be an expired certificate on the computer that is preventing it from being recognized.

Accounting Start and Interim Accounting are not actually parts of the authentication process, but it is the switch that reports back to the RADIUS server that it has activated the client with Accounting Start. After that, Interim Accounting messages are sent continuously, indicating how much data the client is sending and receiving.

MAC authentication

In MAC authentication, it is not the client itself that communicates with the RADIUS server, but it is the switch that contacts the RADIUS server on behalf of the client. MAC authentication is a weak authentication mechanism and should be avoided if possible because it is easy to send any MAC address.

The RADIUS server either has a registry of allowed MAC addresses or uses profiling information that allows the RADIUS server to identify the type of client connecting. For example, access point or video conferencing system.

If 802.1x is configured on the switch port, in most cases the switch will start by sending three Identity Request packets to the client. This is to initiate an 802.1x authentication. If the client does not respond to these, it continues to do a MAC authentication.

This means that MAC authentication usually takes longer because of the wait for 802.1x.

These parameters can be configured differently but are for most manufacturers standard.

During MAC authentication, the RADIUS server will check that the MAC address is valid. Either by checking against an internal database or list or by passing the question to another system that has the information. Using a RADIUS server like Aruba ClearPass that can use profiling information, the device type can be identified and rules can be set up to allow all devices of a type from a given manufacturer, for example.

802.1x authentication

In 802.1x authentication, the client communicates directly with the RADIUS server where the communication between client and switch is the EAP protocol and the switch repackages this into RADIUS which is sent to the RADIUS server. 802.1x supports several different authentication methods where EAP-TLS, which is certificate-based, is one of the most common. In the past, EAP-PEAP was also commonly used, but this method is no longer recommended because the algorithms used in this method are older and weaker and the authentication is based on passwords.

EAP-TLS uses certificates instead, which increases security and simplifies for the user. A new authentication method developed by Microsoft is EAP-TEAP. It is unique to Windows but worth looking at in environments where you want to authenticate both computer and user. This is because both authentications take place in parallel.

802.1x can be perceived by many as complicated and difficult to understand, partly because certificates are used which is an area where many technicians feel they would need a deeper knowledge to understand.

Under 802.1x, first the server and then the client will send their respective certificates to the peer, which will then perform a validation. When the client receives the RADIUS server’s certificate, it does not have an IP address and therefore cannot perform a normal revocation check of the server certificate. Instead, the client is pre-configured with which certificate should be authorized to perform EAP.

If the client does not accept the RADIUS server’s certificate, for example if the client is not configured correctly, it will not continue the process and send its certificate to the RADIUS server. This will cause the RADIUS server to timeout, which will be visible in the log.

If the client trusts the RADIUS server’s certificate, the client certificate is sent and the RADIUS server validates the certificate. In addition to validating the certificate, the client is often authorized by searching for the identity in the certificate in Active Directory, Entra ID, Intune or some other source of information about the device or user. Information that can be retrieved is account status, group membership, etc. This additional information is then used in the RADIUS server rules to determine if the client should be granted access and what access should be granted.

Recording of the webinar

In the recorded talk I also go through a bit about MPSK, how the client configuration should be done for 802.1x and some of the different steps that take place on the switch if Downloadable User Roles are sent from ClearPass to the switch. The talk is recorded and available at this link: