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.
Note
EAP-FAST started out as Tunneled EAP (TEAP), also known as LEAP V2. But as it evolves, it has become more than a LEAP replacement and is maturing. The final specification might be a little different from what is portrayed here, but the major concepts will not be different.
EAP-FAST is available as an informational Internet draft at http://www.ietf.org/internet-drafts/draft-cam-winget-eap-fast-00.txt.
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.
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) | 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.
Note
The separation of duties between an EAP-FAST server and the inner method server adds deployment flexibility and extensibility. An organization can use the current and available authentication infrastructure and then progressively move to any other infrastructure it chooses.
As shown in Figure 7-19, the EAP-FAST frame format is similar to the TLS format for phase 1.
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-20 shows the PAC-TLV.
Table 7-4 describes some of the salient fields.
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. |
The EAP-FAST choreography is a combination of multiple conversations. Figure 7-21 shows an overview of the EAP-FAST choreography.
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. |
Step 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. Note One of the built-in features in EAP-FAST is the PAC refresh, which can be done after successful authentication, at the end of Step 8. This functionality adds the secure update of the PAC as part of the EAP-FAST message exchange and infrastructure, thus making maintenance easier and more secure. |
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. |