This chapter is reprinted with permission from the book Cisco Wireless LAN Security by Krishna Sankar, Sri Sundaralingam, Darrin Miller, and Andrew Balinsky, published by Cisco Press. The book is from Cisco Press' Networking Technology Series.
The EAP, a flexible protocol used to carry arbitrary authentication information, is defined in RFC 2284. (Incidentally, RFC 2284 is only 16 pages long!) A set of RFCs also defines the various authentication processes over EAP, including TLS, TTLS, SmartCard, and SIM. The IETF EAP workgroup is working on a revision of the EAP RFC and has submitted the new document as RFC 3579 (was RFC 2284bis).
EAP has two major features. First, it separates the message exchange from the process of authentication by providing an independent exchange layer. By doing so, it achieves the second characteristic: orthogonal extensibility, meaning that the authentication processes can extend the functionality by adopting a newer mechanism without necessarily effecting a corresponding change in the EAP layer.
The basic EAP consists of a set of simple constructs: four message types, two message frames, and an extensible choreography.
The four message types are request, response, success, and failure. Figure 7-2 shows the EAP frame format.
As shown in Figure 7-3, EAP also defines a packet to negotiate the EAP protocol configuration. The EAP protocol is identified by C227 (Hex). This packet will be included in the data field of the EAP frame in Figure 7-2.
Figure 7-2: EAP Frame Format
Figure 7-3:EAP Configuration Negotiation Packet
Depending on the type, the request and response packets include the type field and data, as shown in Figure 7-4.
Figure 7-4: EAP Request/Response Frame
Note - The RFC assigns eight request/response types. The rest are assigned by the Internet Assigned Numbers Authority (IANA). The current assignments are shown in Table 7-2.
|
Type |
Description |
|
1–6 |
Assigned by RFC |
|
1 |
Identity |
|
2 |
Notification |
|
3 |
Nak (response only) |
|
4 |
MD5-Challenge |
|
5 |
One-Time Password (OTP) |
|
6 |
Generic Token Card (GTC) |
|
7 |
Not assigned |
|
8 |
Not assigned |
|
9 |
RSA Public Key Authentication |
|
10 |
DSS Unilateral |
|
11 |
KEA |
|
12 |
KEA-VALIDATE |
|
13 |
EAP-TLS |
|
14 |
Defender Token (AXENT) |
|
15 |
RSA Security SecurID EAP |
|
16 |
Arcot Systems EAP |
|
17 |
EAP-Cisco Wireless (LEAP) |
|
18 |
Nokia IP SmartCard authentication |
|
19 |
SRP-SHA1 Part 1 |
|
20 |
SRP-SHA1 Part 2 |
|
21 |
EAP-TTLS |
|
22 |
Remote Access Service |
|
23 |
UMTS Authentication and Key Agreement |
|
24 |
EAP-3Com Wireless |
|
25 |
PEAP |
|
26 |
MS-EAP-Authentication |
|
27 |
Mutual Authentication w/Key Exchange (MAKE) |
|
28 |
CRYPTOCard |
|
29 |
EAP-MSCHAP-V2 |
|
30 |
DynamID |
|
31 |
Rob EAP |
|
32 |
SecurID EAP |
|
33 |
EAP-TLV |
|
34 |
SentriNET |
|
35 |
EAP-Actiontec Wireless |
|
36 |
Cogent Systems Biometrics Authentication EAP |
|
37 |
AirFortress EAP |
|
38 |
EAP-HTTP Digest |
|
39 |
SecureSuite EAP |
|
40 |
DeviceConnect EAP |
|
41 |
EAP-SPEKE |
|
42 |
EAP-MOBAC |
|
43 |
EAP-FAST |
|
44–191 |
Not assigned; can be assigned by IANA on the advice of a designated expert |
|
192–253 |
Reserved; requires standards action |
|
254 |
Expanded types |
|
255 |
Experimental usage |
Note - The expanded type (254) frame includes a vendor ID; therefore, it is not deemed interoperable.