Steps 1,2 and 3 – Establish layer one and two
The wireless client associates with the AP and seSupplicantional EAPOL start frame.
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.
Step 4b (identity response) From the Client to the WLC
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).
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.
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.
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
Step 7 (RADIUS success)
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