EAP-FAST
Comparing the various methods, the EAP-FAST mechanism is the most comprehensive and secure WLAN scheme. LEAP was proven to be susceptible to dictionary attacks, and EAP-FAST is preferable to LEAP. In short, EAP-FAST is hardened LEAP with better crypto protecting the challenge/response mechanism.
EAP-FAST not only mitigates risks from passive dictionary attacks and man-in-the-middle (MitM) attacks, it also enables secure authentication based on currently deployed infrastructure. In addition, EAP-FAST minimizes the hardware requirement; many of the mechanisms require computational burden at the edge devices for asymmetric cryptography and certificate validation. As you have seen from your experience, secure-but-difficult-to-deploy mechanisms would not be popular; hence, EAP-FAST's features (such as flexible deployment model, support for secure provisioning, and efficiency) make it attractive for deployments.
To bootstrap the process securely, EAP-FAST establishes a shared secret (between the client and the authentication server) referred to as the Protected Access Credential Key (PAC-Key). The PAC consists of the PAC-Key (32 bytes), an opaque field cached by the server, and PAC info (metadata about the PAC). The PAC is used to establish a tunnel that is then used to perform authentication. The three-phase EAP-FAST protocol is shown in Table 7-3.
Table 7-3 EAP-FAST Phases
|
Phase |
Function |
Description |
Purpose |
|
Phase 0 |
In-band provisioning—provide the peer with a shared secret to be used in secure phase 1 conversation |
Uses Authenticated Diffie-Hellman Protocol (ADHP) This phase is independent of other phases; hence, any other scheme (in-band or out-of-band) can be used in the future. |
Eliminate the requirement in the client to establish a master secret every time a client requires network access |
|
Phase 1 |
Tunnel establishment |
Authenticates using the PAC and establishes a tunnel key |
Key establishment to provide confidentiality and integrity during the authentication process in phase 2 |
|
Phase 2 |
Authentication |
Authenticates the peer |
Multiple tunneled, secure authentication mechanisms |
Figure 7-18 shows the functional entities involved in an EAP-FAST exchange. Of course, more than one function can be embedded in one server or software layer.
)
Figure
7-18 EAP-FAST Functional Entities
EAP-FAST Frame Format
As shown in Figure 7-19, the EAP-FAST frame format is similar to the TLS format for phase 1.
)
Figure
7-19 EAP-FAST Frame Format
The major contribution by EAP-FAST to the frame format is the PAC fields and associated information in the phase 0 and subsequent conversations. Figure 7-20shows the PAC-TLV.
Table 7-4 describes some of the salient fields.
EAP-FAST Choreography
The EAP-FAST choreography is a combination of multiple conversations. Figure 7-21 shows an overview of the EAP-FAST choreography.
)
Figure
7-20 PAC TLV Frame Format
Table 7-4 Salient Fields in EAP-FAST
|
Name |
Description |
Relevance |
|
A-ID |
Authority identifier. This field would be in the EAP-FAST start frame. |
A unique name identifying the authentication server. Will be used by the client/peer to index into the PAC and other context information. |
|
I-ID |
Initiator identifier. |
A unique name identifying the peer/client. |
|
CRED-LIFETIME |
Expiration time of the credential. |
This field will be in the PAC key info and used to validate a PAC key set. |
)
Figure
7-21 EAP-FAST Choreography Overview
|
Step 1 |
Step 1, of course, is to have connectivity between the client/peer and AP, in addition to secure connections between the AP, EAP-FAST server, and authentication server. |
|
Step 2 |
To bootstrap a secure channel, the EAP phase 0 provisioning needs to be performed. This is done once per client setup. This phase itself is an EAP-TLS exchange, with the Diffie-Hellman key exchange and fields embedded in the TLS choreography. At the end of phase 0, the PAC between the peer/client and the authentication server is established. |
|
Step 3 |
This is similar to the EAP identity exchange. |
|
Step 4 |
This is the EAP-FAST start message, which includes the authenticator ID. |
|
Steps 5, 6, and 7 |
TLS exchanges over EAP-FAST to authenticate the peer and the server. The client sends the PAC-opaque to the server in Step 5. |
|
Step 8 |
Step 8, the inner authentication method, is where the actual authentication happens. The message exchange is implemented via EAP-TLV over EAP-FAST between the peer and the EAP server and most probably RADIUS between the EAP server and the authentication server. It is also possible that the same software in one computer performs both server functions. The phase 2 inner authentication method over EAP-TLV can be EAP-SIM, EAP-OTP, EAP-GTC, or MSCHAPv2. |
|
Step 9 |
This is the mandatory EAP success message required by EAP. |
|
Step 10 |
You can now use the key materials and contexts established by the three phases to use WPA methods to exchange information, thereby achieving confidentiality and integrity. |