How 8021x Works
Extensible Authentication Protocol (EAP) is the transport mechanism used in 802.1x to authenticate supplicants against a back-end data store, typically a RADIUS server. EAP was initially defined in RFC 2284 as a general authentication framework running over Layer 2 PPP. In RFC 3748, the EAP definition has been updated to include IEEE 802 as a link layer. The IEEE 802 encapsulation of EAP does not involve PPP, and IEEE 802.1X does not include support for link or network layer negotiations. As a result, within IEEE 802.1X, it is not possible to negotiate non-EAP authentication mechanisms, such as Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP). EAP does not select a specific authentication mechanism during the link layer phase but rather postpones it until the authentication phase. Figure 17-2 depicts the EAP frame format.
Figure 17-2. EAP Frame Format
|
Elhernet Header |
802,1x Header |
EAP Payload |
||
|
Code |
ID |
Length |
Data |
|
1 Byte |
1 Byte |
2 Bytes |
0+ Bytes |
The field descriptions are as follows:
• Code The Code field is 1 octet and identifies the type of EAP packet. Table 17-2 shows the assigned EAP Codes.
Table 17-2.
Assigned EAP Codes
|
Code |
Description |
|
1 |
Request |
|
2 |
Response |
|
3 |
Success |
|
4 |
Failure |
EAP only defines codes 1 through 4. Any EAP packets with other codes are silently discarded.
• Identifier The Identifier field is 1 octet and aids in matching Responses with Requests.
• Length The Length field is 2 octets and indicates the length, in octets, of the EAP packet including the Code, Identifier, Length, and Data fields. Octets outside the range of the Length field should be treated as data link layer padding and will be ignored upon reception. A message with the Length field set to a value larger than the number of received octets will be silently discarded.
• Data The Data field is 0 or more octets. The Code field determines the format of the Data field.
On LAN media, the supplicant and the authenticator communicate using an encapsulation technique known as EAP over LANs
(EAPOL). EAPOL supports various media types, such as Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), and WLANs.
EAPOL is encapsulated EAP messages that can be handled directly by a LAN MAC service. Figure 17-3 shows the EAPOL frame format.
Figure 17-3. EAPOL Frame Format
[View full size imagel
Pratoosl VsisiafT t fjyle
UéilirMtlO" MAC e Syle-n.
SOWiM MAC
eßylea
|
EttiarType |
Body |
||
|
CchM |
Langm |
PacKsi Body |
|
|
2 Bytes |
2Byles |
The Packet Type field is 1 octet in length, taken to represent an unsigned binary number. Its value determines the type of packet being transmitted. The following types are defined: • EAP-Packet A value of 0 indicates that the frame carries an EAP packet. • EAPOL-Start A value of 1 indicates that the frame is an EAPOL-Start frame. • EAPOL-Logoff A value of 2 indicates that the frame is an explicit EAPOL-Logoff request frame. • EAPOL-Key A value of 3 indicates that the frame is an EAPOL-Key frame. • EAPOL-Encapsulated-ASF-Alert A value of 4 indicates that the frame carries an EAPOL-Encapsulated-ASF-Alert. There are a number of modes of operation for 802.1x authentication. Figure 17-4 depicts a generic message exchange between a client and the authentication server: Figure 17-4. 802.1x Message Exchange [View full size imagel 
1. The authenticator sends an EAP-Request/Identity packet to the supplicant as soon as it detects that the link is active (for example, the client has connected to a switch port). 2. The supplicant sends an EAP-Response/Identity packet to the authenticator, which is then passed on to the authentication (RADIUS) server. Communications between the supplicant and authentication server also leverage the RADIUS protocol carried over standard User Datagram Protocol (UDP). 3. The authentication server sends back a challenge to the authenticator, such as with a token password system. The authenticator unpacks this from IP and repackages it into EAPOL and sends it to the supplicant. Different authentication methods will vary this message and the total number of messages. EAP supports client-only authentication and strong mutual authentication. Only strong mutual authentication is considered appropriate in a wireless environment. 4. The supplicant responds to the challenge via the authenticator and passes the response on to the authentication server. 5. If the supplicant provides proper identity, the authentication server responds with a success message, which is then passed on to the supplicant. The authenticator now allows access to the LAN, possibly restricted based on attributes that came back from the authentication server. For example, the authenticator might switch the supplicant to a particular VLAN or install a set of access control rules. Port StateIf IEEE 802.1x is configured on a switch port, the port starts in the unauthorized state. The port does not allow any traffic through except for IEEE 802.1x, STP, and CDP packets. When the supplicant successfully authenticates, the port changes to authorized state and allows through traffic from the client to network resources. If the client does not support IEEE 802.1x, the switch cannot authenticate the client unless a guest VLAN is preconfigured to provide some level of necessary network access. In the scenario in which the switch port is an unauthorized port even though the client is 802.1x compatible, the client sends an authentication request to the switch using an EAPOL-Start frame. The client attempts the request a fixed number of times. Because no response is received from an unauthorized port, the client continues sending frames as if the port is in authorized state. For more information about controlling the port state, visit Cisco.com. |
Continue reading here: Selecting EAP
Was this article helpful?