EAP-FAST
acronymnetworkingsecurityvendors & products
Stands for: Flexible Authentication via Secure Tunneling (RFC 4851, EAP Type 43)
Flexible Authentication via Secure Tunneling, Cisco's EAP Type 43 of RFC 4851: a TLS tunnel that can be established with a Protected Access Credential rather than a server certificate, with the real authentication carried as TLVs inside it.
RFC 4851 (Cam-Winget, McGrew, Salowey and Zhou of Cisco, May 2007, Informational) specifies EAP-FAST in two phases: a TLS tunnel, then an exchange of type-length-value objects inside it that carries the inner authentication. What distinguishes it is the Protected Access Credential, the PAC: a PAC-Key, a 32-octet secret shared between peer and server; a PAC-Opaque, a ticket the server can decode but the peer cannot; and PAC-Info, the authority's identity and the credential's lifetime. With a PAC the tunnel can be re-established without server-side state and without a certificate exchange, which was the point for constrained devices and for sites that did not run a PKI. The RFC lists the design goals as mutual authentication, immunity to passive dictionary attacks, protection against man-in-the-middle attacks, and efficiency for devices with limited resources. RFC 7170 records that EAP-FAST "has been widely adopted" and that the IETF's EMU working group took it as the basis for TEAP, the standards-track tunnel method. Its weak point in operation was always PAC provisioning: how the first PAC reaches a device safely is a deployment decision, not something the method can guarantee on its own.
EAP-FAST was Cisco's answer to a problem it had partly created. Password-based wireless authentication needed a tunnel, and the tunnelled methods of the day, PEAP and EAP-TTLS, anchored that tunnel in a server certificate, which meant a certificate authority, a trust anchor on every client and a validation setting that users could turn off. RFC 4851, published in May 2007 by Cam-Winget, McGrew, Salowey and Zhou, all of Cisco, as an Informational document, specifies Flexible Authentication via Secure Tunneling at EAP Type 43. Phase one establishes a TLS tunnel; phase two runs an exchange of TLVs, type-length-value objects, inside it, and the inner authentication, the result, and any additional data travel as TLVs. The structure is close to PEAP's, but the way the tunnel can be built is not.
The Protected Access Credential is the method's signature idea. The RFC defines a PAC in three parts: the PAC-Key, a 32-octet secret shared between the peer and the server; the PAC-Opaque, a ticket that the server created and only the server can interpret, which the peer stores and presents; and PAC-Info, which carries the identity of the authority that issued it and the credential's lifetime. A peer holding a PAC can re-establish the tunnel with it, without a certificate exchange and, in the RFC's words, without the server having to keep state for that peer, since everything the server needs is inside the opaque ticket it wrote. The design goals the RFC lists are mutual authentication, immunity to passive dictionary attacks, protection against man-in-the-middle attacks, and efficiency for devices with limited resources, and the PAC serves the last of those directly.
The PAC also created the method's characteristic operational problem. The first PAC has to get onto the device somehow, and however it is done, that first delivery is the moment the whole scheme's trust is established. Deployments provisioned PACs out of band, or allowed an in-band provisioning exchange whose security properties depended on the mode chosen, and the configuration of that step, on servers and on supplicants, became the thing engineers spent their time on. The method also remained a vendor specification: Informational status, Cisco authorship, and strongest support in Cisco's own clients and servers.
Its legacy is TEAP. RFC 7170, the Tunnel Extensible Authentication Protocol of May 2014 and a Standards Track document, says in its own text that EAP-FAST "has been widely adopted" and was "adopted by the EMU working group as the basis for the standard tunnel-based EAP method". TEAP keeps the TLS tunnel and the TLV structure, keeps PAC provisioning as one option beside certificate provisioning, adds a mandatory Crypto-Binding TLV, and allows several inner methods in sequence, which is how user and machine authentication can be chained in one conversation. A designer meeting EAP-FAST today is usually meeting an older Cisco estate, and the question is whether to move it to TEAP or, where clients can hold certificates, to EAP-TLS.
Also known as: protected access credential, eap-fast pac