EAP-FAST joins 43 other Extensible Authenticate Protocol (EAP) types now being defined for use with IEEE 802.1X Port Access Control. 802.1X lets an Ethernet switch or wireless Access Point permit or deny access to a LAN based on a station's authenticated identity. EAP is the payload carried by 802.1X that lets the station authenticate itself to a RADIUS server. To learn more about 802.1X and other EAP types, read this Wi-Fi Planet Tutorial.
Like EAP-TLS (Transport Layer Security), EAP-FAST authenticates the server by certificate. Like PEAP and EAP-TTLS, EAP-FAST authenticates the station using legacy methods (I.E. username/password, tokens) over an encrypted TLS tunnel. So why propose a new EAP type?
As the name suggests, EAP-FAST is designed to speed re-authentication when a station roams from one AP to another. Repeating an EAP-TLS or PEAP authentication requires public key cryptography and many messages exchanged between the station and server. This takes a few seconds when stations roam and are must authenticate themselves again. That delay might not be a big deal for transaction-based applications, or even session-based applications that can survive lost packets. However, applications like voice over IP really require less than 30 milliseconds of latency.
EAP-FAST uses shared secret keys to speed up 802.1X re-authentication. Public key crypto is convenient because two parties can authenticate each other without knowing each other in advance. For example, public key crypto is used when you access a secure Web site over SSL. Secret key crypto is faster than public key crypto, but requires both sides to have the same secret key in advance. EAP-FAST uses secret keys that can be pre-shared (configured in advance) or dynamic (assigned during an initial, longer public key authentication).
To learn more about EAP-FAST, its design goals, and its security implications, read the Internet Draft. Keep in mind this proposal is a first draft that has not yet been widely endorsed by vendors. Some Internet Drafts never become standards, and others change quite a bit before becoming an RFC.
This was first published in February 2004