1X on Wireless LANs

X on Wireless LANs

802.1X provides a framework for user authentication over any LANs, including wireless. For the purposes of this book, the "port" in 802.1X on wireless is an association between a wireless device and its access point. The successful exchange of Association Request and Association Response frames is reported to the 802.1X state engine as the link layer becoming active. Once associated, a station can exchange 802.1X frames in an attempt to become authorized. The completion of the 802.1X authentication exchange, including key distribution, is reported to the user as the interface coming up.

Sample 802.1X Exchange on 802.11

EAPOL exchanges look almost exactly like EAP exchanges. The main difference is that supplicants can issue EAPOL-Start frames to trigger the EAP exchange, and they can use EAPOL-Logoff messages to deauthorize the port when the station is done using the network. The examples in this section assume that a RADIUS server is used as the back-end authentication server, and therefore they show the authenticator performing translation from EAP on the front end to RADIUS on the back end. EAP authentication in RADIUS packets is specified in RFC 2869.

This example exchange also shows the use of EAPOL-Key frames to distribute key information for link layer security protocols. Figure 6-8 shows a sample EAPOL exchange on an 802.11 network. The figure shows a successful authentication, whose steps are:

1. The supplicant associates with the 802.11 network. Association is a simple two-frame exchange which nearly always succeeds.
2. The supplicant starts the 802.1X exchange with an EAPOL-Start message. This step is optional. Not all supplicants send EAPOL-Start messages, so this step may not be present.
3. The "normal" EAP exchange begins. The authenticator (access point) issues an EAP-Request/Identity frame. Request/Identity frames may be sent without first having an EAPOL-Start if the access point only forwards frames for authenticated sessions. Unsolicited Request/Identity frames indicate to the supplicant that 802.1X authentication is required.
4. The supplicant replies with an EAP-Response/Identity frame, which is passed on to the RADIUS server as a Radius-Access-Request packet.
5. The RADIUS server determines the type of authentication that is required, and sends an EAP-Request for the method type. The EAP-Request is encapsulated in a Radius-Access-Challenge packet to the AP. When it reaches the AP, the EAP-Request is passed on to the supplicant. EAP Requests are are often denoted EAP-Request/Method, where the Method refers to the EAP method in use. If PEAP is in use, the return packet will be written as EAP-Request/PEAP.
6. The supplicant gathers the reply from the user and sends an EAP-Response in return. The response is translated by the authenticator into a Radius-Access-Request with the response to the challenge as a data field.

   Steps five and six repeat as many times as is necessary to complete the authentication. If it is an EAP method that requires certificate exchange, multiple steps are almost certainly required. Many EAP exchanges can require 10-20 round trips between the client and RADIUS server.

7. The RADIUS server grants access with a Radius-Access-Accept packet, so the authenticator issues an EAP-Success frame and authorizes the port. Authorization may depend on parameters passed back from the RADIUS server.
8. Immediately following receipt of the Access-Accept packet, the access point distributes keys to the supplicant using EAPOL-Key messages. Key distribution is discussed in the next chapter.
9. Once keys are installed in the supplicant, it can begin sending data frames to access the network. It is quite common at this point for DHCP configuration to take place.
10. When the supplicant is done accessing the network, it sends an EAPOL-Logoff message to put the port back into an unauthorized state.

Figure 6-8. Typical 802.1X exchange on 802.11

Exchanges similar to Figure 6-8 may be used at any point. It is not necessary for the user to begin an EAPOL exchange with the EAPOL-Start message. At any point, the authenticator can begin an EAPOL exchange by issuing an EAP-Request/Identity frame to refresh the authentication data. Re-authentications are often triggered by session timeout values to refresh keys.

Dynamic keying

The EAPOL-Key frame allows keys to be sent from the access point to the client and vice versa. Key exchange frames are sent only if the authentication succeeds; this prevents the compromise of key information. EAPOL-Key frames can be used periodically to update keys dynamically as well. Several of the weaknesses in WEP stem from the long lifetime of the keys. When it is difficult to rekey every station on the network, keys tend to be used for long periods of time. Several experts have recommended changing WEP keys on a regular basis, but no practical mechanism to do so existed until the development of 802.1X.