![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/image-24.png)
Steps 1,2 and 3 – Establish layer one and two
The wireless client associates with the AP and seSupplicantional EAPOL start frame.
![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/image-25-1024x57.png)
Step 4a (identity request) From the WLC to the Wireless Client
The supplicant requests the authenticator’s identity to ensure it sends the client certificate to the correct place.
![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/image-27-1024x398.png)
Step 4b (identity response) From the Client to the WLC
![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/image-29-1024x440.png)
Step 5 (RADIUS access-request) from the WLC to the RADIUS Server
Access-Request packets are sent to a RADIUS server and convey information used to determine whether a user is allowed access to a specific NAS and any special services requested for that user. An implementation wishing to authenticate a user MUST transmit a RADIUS packet with the Code field set to 1 (Access-Request).
![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/image-30-1024x350.png)
Step 5a (mutual authentication) – Server response proxied to the client via the WLC
The server (RADIUS) first presents its server-side certificate to the client. The supplicant can end the conversation immediately if this certificate is not from a client’s trusted source. The same goes for the AS. If the AS does not like the identity of the client-side certificate, it will reject the authentication attempt after the client has been given the Supplicantright of refusal.
![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/image-31-1024x437.png)
![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/image-32-1024x216.png)
Step 5b (mutual authentication) – Client response to the authenticator
The supplicant validates the identity of the authentication server certificate. After validation, the supplicant sends its client certificate.
![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/5b-1024x477.jpg)
![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/image-33-1024x396.png)
![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/image-34-1024x366.png)
Step 6 (RADIUS success or reject)
Access-Accept packets are sent by the RADIUS server and provide specific configuration information necessary to begin service delivery to the user. If all Attribute values received in an Access-Request are acceptable, then the RADIUS implementation MUST transmit a packet with the Code field set to 2 (Access-Accept). The access-accept frame will contain the VLAN assignment based on the user’s group. For use in VLAN assignment, the following tunnel attributes are used:
Tunnel-Type=VLAN (13)
Tunnel-Medium-Type=802
Tunnel-Private-Group-ID=VLANID
![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/image-35-1024x220.png)
Step 7 (RADIUS success)
![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/7-1024x154.jpg)
Steps 8 – 11 (4-way handshake)
RSNA defines a protocol using EAPOL-Keyframes called the 4-way handshake. The handshake completes the IEEE 802.1X authentication process. The information flow of the 4-way handshake is as follows:
Message 1: Authenticator Supplicant: EAPOL-Key
Message 2: Supplicant Authenticator: EAPOL-Key
Message 3: Authenticator Supplicant: EAPOL-Key
Message 4: Supplicant Authenticator: EAPOL-Key
![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/image-36-1024x204.png)
Step 12 (Encrypted channel) 802.1X controlled port allows encrypted data traffic.
![](https://www.netprojnetworks.com/wp-content/uploads/2022/10/image-37-1024x359.png)