Simple Explanation of the 802.1x Authentication process

[FAQ_User]

Article ID: 5532

Protocols/Features
RADIUS
PEAP
EAP
EAPOL
MD5
TLS
TTLS

Standards
802.1x

Goals
802.1x authentication process
802.1x authentication method support

Symptoms
"Invalid EAP type"

Solution
Generally, the 802.1x authentication process is as follows:

1. When a user (802.1x supplicant) connects to a switch port, depending upon the supplicant software it may send out an EAPOL (EAP over LAN) start packet, and the switch (802.1x client) sends it (either in responds to the start packet; or on a scheduled basis - typically every 5 seconds - while no supplicant is authenticated on the port) an EAPOL identity request.
2. The supplicant provides its identity, such as a user name, in an EAPOL response to the switch.
3. The client switch forwards the information to the RADIUS server. Note that all client <-> supplicant intercommunication uses the EAPOL protocol, and all server <-> client intercommunication uses the RADIUS protocol.
4. The RADIUS server verifies the supplicant identity and sends an access challenge back to the supplicant via the switch. The RADIUS packet from the server contains not only the challenge, but the authentication method to be used. As relayed by the switch, the supplicant can reject the authentication method and request another, depending on the configuration of the client software and the RADIUS server. The authentication method can be PEAP (Protected Extensible Authentication Protocol), MD5 (Message Digest 5), TLS (Transport Layer Security), TTLS (Tunneled Transport Layer Security), or another similar method.
5. The supplicant responds to the appropriate method with its credentials, such as a password or certificate.
6. The RADIUS server verifies the client credentials and responds with an accept or reject packet. Included in the access accept may be a FilterID (5199) defining both management access to the switch and/or a pre-defined Secure Networks policy; and/or Tunnel attributes potentially specifying the user's new RFC3580 VLAN Assignment.
7. If authentication is successful, the switch allows the client to access the network using the defined access permissions. Otherwise...
   • if the device is operating in "802.1x Strict" mode, then network access is denied and the port remains blocked.
   • if the device is operating in "802.1x non-Strict" mode - currently only possible for the DFE (via 'multiauth mode multi'), SecureStacks (via 'multiauth mode multi'), and Matrix E1 (via 'policy invalid action default-policy') - then the prior assignments remains in effect. This would be a machine authentication policy if applicable, or otherwise the port's default policy if applicable, or otherwise the port's PVID and Egress permissions.
   This process is such that the authentication method is essentially a pass-through parameter to the switch. Our 802.1x-capable switches thus effectively support all 802.1x authentication methods.
   
   See also: 6750.