I never thought we'd get to EAP-FAST - meaning, I specifcally thought that LEAP would suffice for low-level security conscious customers, PEAP would sit happily in the good-enough-for-the-vast majority middle, and EAP-TLS would be the protocol of choice for the ultimate security conscious customers. Well, I was wrong.
First off, LEAP vulnerabilities became very well published and promoted, and drove a lot of customers off of LEAP, even for rather low-security connections (e.g. scanners tracking bar codes with no $$$ or sensitive data). Secondly, even though PEAP only requires certificate(s) on the RADIUS server(s), some customers expressed a desire to not use certs or require certificate at all. So, EAP-FAST came about really at the intersection of those two drivers:
- the need for something "lightweight" in implementation without certs or heavywieght RSA PKI operations (for embedded devices primarily)
and
- the need for something secure and not easily attackable.
The key advantages of EAP-FAST are mostly off-the-desktop in processor or memory constrained environments. Specifically, you don't need any certicate or RSA code, and as such, you don't need to support as much memory or processor footprint required for PEAP. With that said, we do see some very large enterprise customers also deploying EAP-FAST, primarily because regardless of the number of certs, they don't want to use certificates or anything PKI in their IT rollouts.
From a security standpoint, you are not really "loosing" anything with PEAP, and if you are authenticating desktop users with username/pwds and/or OTP, PEAP is probably the easiest way to go from a deployment, client-side support and requirements standpoint.
