EAPOL (Extensible Authentication Protocol over LAN)

IEEE 802.1X is an IEEE standard for port-based Network Access Control (PNAC). Devices wanting to access the network must authenticate themselves before accessing it. It’s commonly used in corporate networks where we require user or device authentication.

802.1X uses Extensible Authentication Protocol (EAP) to exchange authentication messages. EAP is not a protocol but an authentication framework as defined in RFC 3748.

EAP offers different authentication methods called EAP methods. Depending on the EAP method, you can use authentication methods such as passwords, token cards, smart cards, certificates, etc. Examples of EAP methods are EAP-MD5, EAP-TLS, EAP-TTLS, or PEAP.

EAP is always carried by another protocol. EAP was originally an authentication option for the point-to-point protocol (PPP). To transport EAP messages, we need to encapsulate them. EAPOL (Extensible Authentication Protocol over Local Area Network) encapsulates EAP packets within Ethernet frames.

The first version of EAPOL was designed for IEEE 802.3 Ethernet wired networks in 802.1X-2001 but has been modified for other network types, such as IEEE 802.11 wireless in 802.1X-2004, where we encapsulate EAPOL messages in 802.11 frames.

EAPOL was updated again in the 802.1X-2010 revision to incorporate support for MACsec, as defined in IEEE 802.1AE, and for Secure Device Identity (DevID) under IEEE 802.1AR.

802.1X has three main components:

• Supplicant (client device)
• Authenticator (network devices such as a switch or wireless access point)
• Authentication server (typically RADIUS server)

Here is an example of where it is used:

We use EAPOL between the supplicant and the authenticator. Between the authenticator and authentication server, we use something else, usually a RADIUS server.

EAPOL is considered secure, but the security of EAPOL depends on the EAP method you use. For example, EAP-TLS provides strong security by using certificates where older methods, such as EAP-MP5, that only use a challenge are considered weak and vulnerable to attacks.

I’ll give you an overview of all EAPOL packets, messages and an explanation of its operation. We will also look at packet captures so you can see it in action.

802.1X Port Status

802.1X has two logical port entities for an authenticated port:

• Uncontrolled port: always open to send and receive authentication packets.
• Controlled port: blocks packets depending on the port state:
  • Authorized state: the controlled port is in the authorized state when the supplicant has passed authentication.
  • Unauthorized state: the controlled port is in the unauthorized state by default or when the supplicant has failed authentication.

The 802.1X Port Access Entity (PAE) uses the uncontrolled port to send and receive EAPOL packets. EAP also modifies the controlled port state. It can move from the unauthorized to the authorized state or vice versa. Here’s how to visualize this:

EAPOL Packets

EAPOL uses several different packets. Here is an overview:

• EAPOL-Start
• EAPOL-EAP
• EAPOL-Key
• EAPOL-Logoff
• EAPOL-Encapsulated-ASF-Alert
• EAPOL-MKA

Let’s go through them.

EAPOL-Start

The supplicant sends this packet when it wants to start the authentication process. When the authenticator receives this packet, it will transmit EAP-Request Identity messages to the supplicant.

EAPOL-EAP

This packet type transports EAP packets between the supplicant and the authenticator. It encapsulates EAP messages such as EAP-Request and EAP-Response messages.

EAPOL-Key

This packet is used to transport encryption keys and related data. You’ll see it when you use EAP methods that use encryption or in the Wi-Fi Protected Access (WPA) four-way handshake.

EAPOL-Logoff

Sent by the supplicant to the authenticator to terminate the authentication session. Once the authenticator receives an EAPOL-Logoff message, it will change the port state to unauthorized and discard the keys associated with that supplicant.

EAPOL-Encapsulated-ASF-Alert

This is not a common packet to see, but this packet is used to encapsulate ASF (Alert Standard Format) alerts. ASF is used for remote monitoring and control of systems. This packet can be used to encapsulate these packets over EAPOL.

EAPOL-MKA

MKA stands for “MACsec Key Agreement” and is part of the IEEE 802.1AE standard for providing MAC-layer encryption over wired networks. EAPOL-MKA packets distribute key material and manage encryption keys for MACsec-enabled devices. This protocol is used to secure communication on the LAN between supported devices.

EAP Messages

EAP messages are the actual contents or data within the EAPOL-EAP packets. These are the messages used for the authentication process. Here is a list of general EAP messages that are commonly used:

• EAP-Request/Identity
• EAP-Response/Identity
• EAP-Request/Challenge
• EAP-Response/Challenge
• EAP-Success
• EAP-Failure

Keep in mind that these are general EAP messages. You’ll see some of these or customized messages depending on your EAP method. Here’s what these messages are used for:

EAP-Request/Identity

Sent by the authenticator to request the identity of the supplicant.

EAP-Response/Identity

Sent by the supplicant as a response to the EAP-Request/Identity message. Includes the identity of the supplicant.

EAP-Request/Challenge

Sent by the authenticator to the supplicant. This message includes a challenge when you use a challenge-response-based authentication EAP method such as EAP-MD5.

EAP-Response/Challenge

Sent by the supplicant, which includes a response to the challenge in the EAP Request/Challenge message.

EAP-Success

Sent by the authenticator to tell the supplicant that the authentication process is successful and that the supplicant is authenticated.

EAP-Failure

Sent by the authenticator when the authentication process fails.

Operation Overview

Here is a general overview of how EAPOL (and RADIUS) packets are exchanged. This operation and the actual messages exchanged depend on the EAP method you use. Let’s have a look:

As you can see, we use EAPOL between the supplicant and the authentication server only. Let me walk you through this diagram:

• The switch interface that connects to the supplicant is in an unauthorized state. All packets are denied except for EAPOL packets.
• When the supplicant wants to access the network, it has to authenticate itself. It sends an EAPOL-Start packet to tell the authenticator it wants to authenticate.
• The authentication server replies with an EAP packet containing a Request/Identity message, asking for the identity of the supplicant.
• The supplicant replies with an EAP packet with a Response/Identity message containing its identity.
• The authenticator forwards the supplicant’s identity to the authentication server in a RADIUS Access-Request packet.
• The authentication server sends a challenge to the authenticator in a RADIUS Access-Challenge packet.
• The authenticator forwards the challenge to the supplicant in an EAP packet containing the EAP-Request/Challenge message.
• The supplicant includes its response to the challenge in an EAP packet in the Response/Challenge message.
• The authenticator forwards the response to the authentication server in a RADIUS Access-Request packet.
• The authentication server replies with a RADIUS Access-Accept packet.
• The authenticator sends an EAP-success packet to the supplicant and sets the port to the authorized state.
• When the supplicant wants to end the session, it sends an EAP-Logoff packet, and the authenticator resets the port to the unauthorized state.

Packet Capture

Capturing EAPOL packets is a good idea because you’ll be able to see the actual EAP messages in action.

Here is the topology I’ll use:

I’ll use the EAP-MD5 method because it’s one of the simplest EAP methods to set up. It’s insecure, so you shouldn’t use it in production anymore. EAP-MD only uses a challenge and response. Here are the devices I use:

• The host is a Ubuntu machine. I like to use Ubuntu because it has 802.1X support and still supports EAP-MD5.
• The switch is a Cisco catalyst 3850 running Cisco IOS Software, IOS-XE Software, Catalyst L3 Switch Software (CAT3K_CAA-UNIVERSALK9-M), Version 03.07.05.E RELEASE SOFTWARE (fc1).
• The RADIUS server is a freeradius server. You can use my Alpine freeradius image. It is simple to set up, and it supports many EAP methods.

Setting up 802.1X on Ubuntu is straightforward. Under network settings, you only have to enable 802.1X and specify the EAP method and credentials.Here it is:

hostname SW1
!
username admin privilege 15 secret 5 $1$YVOP$xaZpE.nA.FwvKwXxtvzTw1
aaa new-model
!
aaa authentication dot1x default group radius
!
aaa session-id common
!
ip dhcp pool VLAN10
 network 192.168.10.0 255.255.255.0
!
dot1x system-auth-control
!
interface GigabitEthernet1/0/11
 switchport access vlan 10
 switchport mode access
 authentication host-mode multi-auth
 authentication port-control auto
 dot1x pae authenticator
 spanning-tree portfast
!
interface GigabitEthernet1/0/12
 switchport access vlan 10
 switchport mode access
 spanning-tree portfast
!
interface Vlan10
 ip address 192.168.10.100 255.255.255.0
!
radius server FREERADIUS
 address ipv4 192.168.10.200 auth-port 1812 acct-port 1813
 key CISCO

version: '2'
services:
 freeradius:
  image: networklessons/docker-alpine-freeradius:1
  ports:
   - 1812:1812/udp
   - 1813:1813/udp
  volumes:
   - "./clients.conf:/etc/raddb/clients.conf"
   - "./users:/etc/raddb/users"
   - "./eap:/etc/raddb/mods-enabled/eap"

client CISCO {
  ipaddr                = 0.0.0.0/0
  secret                = CISCO 
  }

eap {
        default_eap_type = md5
        timer_expire = 60
        ignore_unknown_eap_types = no
        cisco_accounting_username_bug = no
        max_sessions = ${max_requests}

        md5 {
        }
}

ubuntu          Cleartext-Password := "ubuntu"

I’ll show you all the packets from both sides: EAPOL and RADIUS.

EAPOL

Let’s start with the EAPOL packets. If you want to see them for yourself, you can download them here:

802.1X EAP-MD5 EAPOL

EAPOL-Start

The EAPOL-Start packet is the first one and is sent from the supplicant to the authenticator:

Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface -, id 0
Ethernet II, Src: Solarfla_25:11:f0 (00:0f:53:25:11:f0), Dst: Nearest-non-TPMR-bridge (01:80:c2:00:00:03)
    Destination: Nearest-non-TPMR-bridge (01:80:c2:00:00:03)
    Source: Solarfla_25:11:f0 (00:0f:53:25:11:f0)
    Type: 802.1X Authentication (0x888e)
    Padding: 000000000000000000000000000000000000000000000000000000000000000000000000…
802.1X Authentication
    Version: 802.1X-2001 (1)
    Type: Start (1)
    Length: 0

Here’s what we see:

• The packet is destined for the Ethernet multicast address 0180:c200:0003.
• The Ethertype is 0x888E.
• The version is set to 802.1X-2001.
• The type is “Start”.

EAP-Request/Identity

The authenticator sends the EAP-Request/Identity packet to the supplicant:

Frame 2: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface -, id 0
Ethernet II, Src: Cisco_6f:77:8b (bc:c4:93:6f:77:8b), Dst: Solarfla_25:11:f0 (00:0f:53:25:11:f0)
    Destination: Solarfla_25:11:f0 (00:0f:53:25:11:f0)
    Source: Cisco_6f:77:8b (bc:c4:93:6f:77:8b)
    Type: 802.1X Authentication (0x888e)
    Padding: 000000000000000000000000000000000000000000000000000000000000000000000000…
802.1X Authentication
    Version: 802.1X-2010 (3)
    Type: EAP Packet (0)
    Length: 5
Extensible Authentication Protocol
    Code: Request (1)
    Id: 9
    Length: 5
    Type: Identity (1)

The output above shows that the version is set to 802.1X-2010, and the type is an EAP packet. The EAP message shows that the code is set to request, and the type is identity.

EAP-Response/Identity

The supplicant replies with the EAP-Response/Identity packet:

Frame 3: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface -, id 0
Ethernet II, Src: Solarfla_25:11:f0 (00:0f:53:25:11:f0), Dst: Nearest-non-TPMR-bridge (01:80:c2:00:00:03)
    Destination: Nearest-non-TPMR-bridge (01:80:c2:00:00:03)
    Source: Solarfla_25:11:f0 (00:0f:53:25:11:f0)
    Type: 802.1X Authentication (0x888e)
    Padding: 00000000000000000000000000000000000000000000000000000000000000
802.1X Authentication
    Version: 802.1X-2001 (1)
    Type: EAP Packet (0)
    Length: 11
Extensible Authentication Protocol
    Code: Response (2)
    Id: 9
    Length: 11
    Type: Identity (1)
    Identity: ubuntu

Above, we see that the code is set to response, and the type is identity. The identity shows “ubuntu”, the username I configured on my desktop.

EAP-Request/Challenge

The authenticator will forward the challenge from the RADIUS server to the supplicant in the EAP-Request/Challenge packet:

Frame 4: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface -, id 0
Ethernet II, Src: Cisco_6f:77:8b (bc:c4:93:6f:77:8b), Dst: Solarfla_25:11:f0 (00:0f:53:25:11:f0)
    Destination: Solarfla_25:11:f0 (00:0f:53:25:11:f0)
    Source: Cisco_6f:77:8b (bc:c4:93:6f:77:8b)
    Type: 802.1X Authentication (0x888e)
    Padding: 0000000000000000000000000000000000000000
802.1X Authentication
    Version: 802.1X-2010 (3)
    Type: EAP Packet (0)
    Length: 22
Extensible Authentication Protocol
    Code: Request (1)
    Id: 10
    Length: 22
    Type: MD5-Challenge EAP (EAP-MD5-CHALLENGE) (4)
        [Expert Info (Warning/Security): Vulnerable to MITM attacks. If possible, change EAP type.]
            [Vulnerable to MITM attacks. If possible, change EAP type.]
            [Severity level: Warning]
            [Group: Security]
    EAP-MD5 Value-Size: 16
    EAP-MD5 Value: 07132be14ba1bfea95cfe460094a23fb

This output shows that the code is set to request, and the type is MD5-Challenge EAP. The challenge is included under the EAP-MD5 Value.

EAP-Response/Challenge

The supplicant will reply with the EAP-Response/Challenge packet:

Frame 5: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface -, id 0
Ethernet II, Src: Solarfla_25:11:f0 (00:0f:53:25:11:f0), Dst: Nearest-non-TPMR-bridge (01:80:c2:00:00:03)
    Destination: Nearest-non-TPMR-bridge (01:80:c2:00:00:03)
    Source: Solarfla_25:11:f0 (00:0f:53:25:11:f0)
    Type: 802.1X Authentication (0x888e)
    Padding: 0000000000000000000000000000000000000000
802.1X Authentication
    Version: 802.1X-2001 (1)
    Type: EAP Packet (0)
    Length: 22
Extensible Authentication Protocol
    Code: Response (2)
    Id: 10
    Length: 22
    Type: MD5-Challenge EAP (EAP-MD5-CHALLENGE) (4)
        [Expert Info (Warning/Security): Vulnerable to MITM attacks. If possible, change EAP type.]
            [Vulnerable to MITM attacks. If possible, change EAP type.]
            [Severity level: Warning]
            [Group: Security]
    EAP-MD5 Value-Size: 16
    EAP-MD5 Value: 6492f6ebd6ce9b437643ea37ac9b24c5

The code is set to response. The type is MD5-Challenge EAP. It also includes the response under EAP-MD5 Value.

EAP-Success

Finally, the supplicant receives the EAP-Success packet from the authenticator:

Frame 6: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface -, id 0
Ethernet II, Src: Cisco_6f:77:8b (bc:c4:93:6f:77:8b), Dst: Solarfla_25:11:f0 (00:0f:53:25:11:f0)
    Destination: Solarfla_25:11:f0 (00:0f:53:25:11:f0)
    Source: Cisco_6f:77:8b (bc:c4:93:6f:77:8b)
    Type: 802.1X Authentication (0x888e)
    Padding: 000000000000000000000000000000000000000000000000000000000000000000000000…
802.1X Authentication
    Version: 802.1X-2010 (3)
    Type: EAP Packet (0)
    Length: 4
Extensible Authentication Protocol
    Code: Success (3)
    Id: 10
    Length: 4

The code is set to Success.

RADIUS

While we are at it, let’s also look at the RADIUS packets. You can take a look for yourself here: