The Extensible Authentication Protocol

802.1X is based on EAP. Recent work in wireless networking required an update to the standard, which is now found in RFC 3748. Back in the early 1990s, when PPP was first introduced, there were two protocols available to authenticate users, each of which required the use of a PPP protocol number. Authentication is not a "one size fits all" problem, and it was an active area of research at the time. Rather than burn up PPP protocol numbers for authentication protocols that might become obsolete, the IETF standardized EAP. EAP used a single PPP protocol number while supporting a wide variety of authentication mechanisms. EAP is a simple encapsulation that can run over any link layer, but it has been most widely deployed on PPP links. Figure 6-1 shows the basic EAP architecture, which is designed to run over any link layer and use any number of authentication methods.

Figure 6-1. EAP architecture

 

EAP Packet Format

Figure 6-2 shows the format of an EAP packet. When used on PPP links, EAP is carried in PPP frames with a protocol number of 0xC227. There is no strict requirement that EAP run on PPP; the packet shown in Figure 6-2 can be carried in any type of frame. The fields in an EAP packet are:

Code

The Code field, the first field in the packet, is one byte long and identifies the type of EAP packet. It is used to interpret the Data field of the packet.

Identifier

The Identifier field is one byte long. It contains an unsigned integer used to match requests with responses to them. Retransmissions reuse the same identifier numbers, but new transmissions use new identifier numbers.

Length

The Length field is two bytes long. It is the number of bytes in the entire packet, which includes the Code, Identifier, Length, and Data fields. On some link layer protocols, padding may be required. EAP assumes that any data in excess of the Length field is link-layer padding and can be ignored.

Data

The last field is the variable-length Data field. Depending on the type of packet, the Data field may be zero bytes long. Interpretation of the Data field is based on the value of the Code field.

Figure 6-2. EAP packet format

 

EAP Requests and Responses

EAP exchanges are composed of requests and responses. The authenticator sends requests to the system seeking access, and based on the responses, access may be granted or denied. Client systems only send response packets when there is an outstanding request to send. There is no such thing as an unsolicited packet from the system seeking authentication. The format of request and response packets is shown in Figure 6-3.

Figure 6-3. EAP Request and EAP Response packets

The Code field is set to 1 for requests and 2 for responses. The Identifier and Length fields are used as described in the previous section on the generic format. The Data field carries the data used in requests and responses. Each Data field carries one type of data, broken down into a type identifier code and the associated data:

Type

The Type field is a one-byte field that indicates the type of request or response. Only one type is used in each packet. With one exception, the Type field of the response matches the corresponding request. That exception is that when a request is unacceptable, the peer may send a NAK to suggest an alternative type. Types greater than or equal to 4 indicate authentication methods.

Type-Data

The Type-Data field is a variable field that must be interpreted according to the rules for each type, as described in the following sections.

Type code 1: Identity

The authenticator generally uses the Identity type as the initial request, which is often written as EAP-Request/Identity, or simply Request/Identity to indicate that the authenticator is attempting to establish some sort of username to authenticate. Frequently, the EAP Identity is the user identifier, possibly with routing information. Some technologies work by submitting an EAP Identity that may correspond to the machine. In the initial Request/Identity packet, if any information is present in the Type-Data field, it is used to prompt the user, though this is relatively uncommon. If the Type-Data field is present and contains a prompt string, its length is inferred from the length of the EAP packet, rather than having a separate delimiter.

Many EAP implementations are capable of prompting the (human) user for input to determine the user identity, though it is not required. For greater usability, most EAP implementations also allow the identity to be statically configured. Once the user name has been determined, the EAP client will respond with a Response/Identity packet. In Response/Identity packets, the Type-Data field contains the username. It may be a "bare" username, such as mgast, or it may be qualified with an Internet-style domain ([e-mail]), or a Windows-style domain name (DOMAINmgast).

Some EAP implementations may attempt to look up the user identity in a Response even before issuing the authentication challenge. If the user does not exist, the authentication can fail without further processing. Most implementations automatically reissue the identity request to give the user an opportunity to correct typos.

Type code 2: Notification

The authenticator can use the Notification type to send a message to the user. The user's system can then display the message in the Request/Notification for the user's benefit. Notification messages are used to provide messages to the user from the authentication system, such as a password about to expire, or the reason for an account lockout. Notification messages are not commonly used with 802.1X; only a few vendors implement them. Responses must be sent in reply to Notification requests. However, Response/Notification packets serve as simple acknowledgments, and the Type-Data field has a zero length.

Type code 3: NAK

Null acknowledgments (NAKs) are used to suggest a new authentication method. The authenticator issues a challenge, encoded by a type code. Authentication types are numbered 4 and above. If the end user system does not support the authentication type of the challenge, it can issue a NAK. The Type-Data field of a NAK message includes a single byte corresponding to the suggested authentication type. Most 802.1X implementations do not actively negotiate, and will simply log an error message if the client attempts to use an unsupported type.

EAP Authentication Methods

In addition to flow-control messages and negotiation messages, EAP assigns type codes to authentication methods. EAP delegates the work of proving a user identity to a subsidary protocol, the EAP method, which is a set of rules for authenticating a user.

The advantage of using the method construction is that it frees EAP from any particular set of assumptions about what is necessary to authenticate a user. When requirements change, as they did with the popularity of wireless networks, new EAP methods can be developed to meet the challenge. Table 6-1 lists several EAP methods with their type codes. A more detailed description of the EAP methods commonly used on wireless LANs will follow later in this chapter.

Table 6-1. Common EAP methods for 802.1X authentication

Type code	Authentication protocol	Description
4	MD5 Challenge	CHAP-like authentication in EAP
6	GTC	Originally intended for use with token cards such as RSA SecurID
13	EAP-TLS	Mutual authentication with digital certificates
21	TTLS	Tunneled TLS; protects weaker authentication methods with TLS encryption
25	PEAP	Protected EAP; protects weaker EAP methods with TLS encryption
18	EAP-SIM	Authentication by mobile phone Subscriber Identity Module (SIM)
29	MS-CHAP-V2	Microsoft encrypted password authentication; compatible with Windows domains

 

EAP Success and Failure

At the conclusion of an EAP exchange, the user has either authenticated successfully or has failed to authenticate (Figure 6-4). Once the authenticator determines that the exchange is complete, it can issue an EAP-Success (code 3) or EAP-Failure (code 4) frame to end the EAP exchange. Implementations are allowed to send multiple requests before failing the authentication to allow a user to get the correct authentication data.

Figure 6-4. EAP Success and Failure frames

Success and Failure frames are not authenticated in any way. In the dial-up world, the telephone network provides a modicum of security that the sender is at the other end of the circuit. In wireless LANs, the lack of authentication on Success and Failure frames may require extra protocol design.

A Sample EAP Exchange

A sample EAP exchange is shown in Figure 6-5. It is not a "real" exchange that would be seen on a wireless network because it uses protocols that are not in wide deployment. It is intended only to give you a basic idea of how the protocol is supposed to work. The EAP exchange is a series of steps beginning with a request for identity and ending with a success or failure message. As a matter of notation, packets transmitted as part of an EAP method exchange are written Request/Method when they come from the authenticator, and Response/Method when they are sent in response.

1. The authenticator issues a Request/Identity packet to identify the user. Request/Identity packets serve two purposes. In addition to starting the exchange, they also serve notice to the client that the network is likely to drop any data traffic before authentication completes.
2. The end user system prompts for input, collects the user identifier, and sends the user identifier in a Response/Identity message.
3. With the user identified, the authenticator can issue authentication challenges. In step 3 in the figure, the authenticator issues an MD-5 Challenge to the user with a Request/MD-5 Challenge packet.
4. The user system is configured to use a token card for authentication, so it replies with a Response/NAK, suggesting the use of Generic Token Card authentication.
5. The authenticator issues a Request/Generic Token Card challenge, prompting for the numerical sequence on the card.
6. The user types a response, which is passed along in a Response/Generic Token Card.
7. If the user response is not correct, authentication is not possible. However, the authenticator EAP implementation allows for multiple authentication Requests, so a second Request/Generic Token Card is issued.
8. Once again, the user types a response, which is passed along in a Response/Generic Token Card.
9. On the second try, the response is correct, so the authenticator issues a Success message.

Figure 6-5. Sample EAP exchange