With the threat of ASLEAP looming, Cisco created their new Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) protocol and submitted it to the IETF. EAP-FAST as proclaimed by Cisco marketing would be “as secure as PEAP” and “as easy as LEAP”! EAP-FAST achieves this by creating the same secure encrypted tunnel used to protect user credentials during the authentication session as PEAP without the need for any kind of PKI on the client end or even the server end. Naturally, I immediately became skeptical of that claim. Of course there are other ways such as secret key cryptography of achieving a secure key exchange without PKI, but none are ever as elegant or as easy to deploy in large scale. Is EAP-FAST the exception?
EAP-FAST under normal operation is just like PEAP and has two phases. Phase 1 sets up a secure encrypted tunnel and Phase 2 is a MS-CHAPv2 session that verifies the client to the authentication server. Since MS-CHAPv2 is widely known to be very weak against dictionary attacks, the encrypted tunnels established in Phase 1 provides a safe environment for the MS-CHAPv2 session. The difference is that EAP-FAST uses a PAC (Protected Access Credentials) shared secret to set up the tunnel where as PEAP uses the server side digital certificate to set up a TLS tunnel (similar to how secure Web servers work). A unique user specific PAC file is generated from a single EAP-FAST Master Key on the authentication server for each and every user. Distributing the PAC can be achieved by an optional “Phase 0” (AKA automatic provisioning) or by other out-of-band methods such as sneaker net, protected admin-only file share, or user specific restricted directory.
Marketing vs. reality
After carefully reading through the IETF draft of the EAP-FAST protocol submitted by Cisco, it became fairly obvious that Cisco’s marketing claims were not entirely accurate. Although it was technically true that EAP-FAST “could” be as secure as PEAP and it “could” be as easy as LEAP, Cisco’s marketing left out the fine print and omitted the fact that you just couldn’t have both at the same time.
The fact of the matter is, in order for EAP-FAST to truly be as secure as PEAP, it would have to run in “server-side authentication Diffie-Hellman mode” in “Phase 0” which ironically requires a server side Digital Certificate. As you recall, the very need for a server side Digital Certificate was the very thing that scared people away from PEAP in the first place. Cisco says that you could resort to other “out-of-band” methods of PAC provisioning which doesn’t require a server side certificate but the practicality of manual PAC provisioning is rather dubious. The EAP-FAST PAC refresh mechanism on the other hand does automatically provision keys in a secure manner but it can only be used to maintain the PAC but does not address the need for initial PAC provisioning.
In order to be as easy as LEAP, EAP-FAST had to run “Phase 0” in anonymous Diffie-Hellman mode. An anonymous Diffie-Hellman key exchange by definition means that you can’t verify who is on the other end. In this case, a hacker can pose as your access-point and authentication server in Phase 0 and wait for an unsuspecting user to connect at phase 0 and wait for the clear text username and the hashed passwords. Since the server is obviously a fake, it would fail the server challenge and phase 0 would be aborted by the client. However, enough of the MS-CHAPv2 session has been captured to perform an offline ASLEAP attack. If the user’s password is not extremely complex which is usually the case, then game over and the hacker gains both user credentials and access to your wireless LAN.
According to the EAP-FAST IETF draft paper, if such a man in the middle exploit is attempted, the user is to immediately change their password. However, there is no indication that the EAP-FAST client will automatically warn the user and administrator or force the password change. At least running EAP-FAST with this convenient but weak form of automatic PAC provisioning is still significantly more secure than running LEAP for two reasons.
* First, PAC provisioning is only done once to set up the PAC secret between the server and client and all subsequent EAP-FAST sessions skip “Phase 0”. LEAP on the other hand is vulnerable each and every time a user authenticates with the radius server during the wireless LAN authentication.
* Second, even during a phase 0 anonymous DH session, the attack must be active which exposes the hacker to detection and is significantly more risky. A LEAP attacker on the other hand can perform the exploit with virtual impunity.
Even though this is a significant improvement over LEAP, EAP-FAST can never be as secure as EAP-TLS, EAP-TTLS, or PEAP while running in this mode. EAP-FAST does provide a faster authentication session because it uses symmetric cryptography instead of the asymmetric cryptography that EAP-TLS, EAP-TTLS, or PEAP uses but that’s hardly an advantage. I have even tried PEAP authentication on 266 MHz PDA devices which is the slowest platform you would run EAP on and I can’t see any significant delays with PEAP. I really doubt you will ever miss a few milliseconds on your notebook when authenticating with PEAP for wireless LAN access. Speed in deployment is what I’m concerned about and this is where EAP-FAST falls on its face.
EAP-FAST deployment troubles
The deployment of EAP-FAST is marketed “as easy as LEAP” but the reality is not so simple. According to Cisco’s own EAP-FAST deployment guide, you cannot completely rely on automatic provisioning of PAC files because it is susceptible to an active attack. The following is an excerpt from that deployment guide.
Note: Because transmission of PACs in phase zero is secured by MS-CHAPv2 authentication and MS-CHAPv2 is vulnerable to dictionary attacks, we recommend that you limit use of automatic provisioning to initial deployment of EAP-FAST. After a large EAP-FAST deployment, PAC provisioning should be performed manually to ensure the highest security for PACs. For more information about manual PAC provisioning, see Manual PAC Provisioning.
Source: Cisco EAP-FAST deployment guide
As you can see in the fine print, EAP-FAST deployment is not that straight forward. You must eventually resort to manual provisioning of user specific PAC secrets that must be deployed with the greatest secrecy and care. The secret must even be kept from other legitimate users or else the PAC is still compromised because you wouldn’t want multiple users knowing the same PAC.
After reading the Manual PAC Provisioning section from the same Cisco document, it became rather amusing to see the amount of work it takes to deploy EAP-FAST in a secure manner. Having plenty of experience in deploying EAP-TLS or PEAP, I can tell you right now that EAP-FAST manual PAC provisioning is the most labor intensive way of deploying secure authentication. In the case of PEAP, trust of the PEAP server’s digital certificate is inherent if the certificate was purchased from a public Certificate Authority.
Even if you didn’t want to spend the $300 a year to buy a digital certificate for your PEAP server, you could always build your own Certificate Authority or self sign a digital certificate which could be deployed automatically using Active Directory. If your company runs Windows NT domains or some other non-Microsoft user directory which doesn’t support automatic deployment of a Root Certificate, then the public certificate “.cer file” of the PEAP server could simply be posted on a public intranet page for users to manually install in their root CTL (Certificate Trust List). There is absolutely no fear of the public certificate falling in to the wrong hands because it only contains the 1024-bit public key portion of the certificate which is practically impossible to crack.
With EAP-FAST user specific PAC files, you literally have to generate and manage thousands (one for every user) of unique user-specific private keys where you can’t even afford a single compromise of a single key. You can forget about posting that on a public intranet server let alone automatically deploying it with Active Directory group policies. Each PAC is unique and must be manually imported in to the Cisco ACU (Aironet Client Utility) on each end user’s laptop. You can see why I chuckle when Cisco claims EAP-FAST is “easy as LEAP” because it isn’t even as easy as EAP-TLS in a managed environment.
More limitations on Cisco EAP-FAST
Cisco EAP-FAST requires the use of newer Cisco Wi-Fi adapters since the older cards don’t support it. Cisco EAP-FAST also requires the use of a very expensive authentication platform using Cisco ACS (Access Control Server) which ironically isn’t as flexible or easy to manage as Microsoft’s built in RADIUS server IAS (Internet Authentication Service) and this is speaking from a lot of experience dealing with both platforms. The Cisco client also doesn’t support “machine login” which is a way for a computer to log on to the network before the user signs on to Windows. For Enterprise deployments this is extremely important because of the need for logon scripts and group policies to function properly. Cisco’s own Website instructs users to use the Microsoft Wireless Client if they wish to implement machine logins.
The bottom line on EAP-FAST
So is Cisco’s EAP-FAST an exception to the rule where you can’t get away with no PKI to facilitate secure key exchange on a large scale? I think we can safely conclude no, it cannot. After reading through the deployment section, one really begins to wonder if EAP-FAST is really worth all that trouble just to avoid deploying a digital certificate on the authentication server because you don’t want to build a PKI Certificate Authority or because you don’t want to purchase a $300 digital certificate every year. If you were hoping that EAP-FAST was going to be your savior, it won’t happen since it can never be “as easy as LEAP” if it wants to be secure like PEAP. The best solution is to use PEAP authentication.