Would you please elaborate on an apparent contradiction on EAP FAST?

Would you please elaborate on an apparent contradiction on EAP FAST?

In this ATE answer, you indicate that Cisco's EAP FAST makes use of, or requires, server side certificates, but Cisco's Web site says EAP-FAST does not require any server-side certificates. Would you please elaborate on this apparent contradiction?

    Requires Free Membership to View

    By submitting your registration information to SearchNetworking.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchNetworking.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Good question. EAP-FAST allows for, but does not require, server side certificates.

Cisco's EAP-FAST Internet Draft includes two options for establishing a TLS tunnel through which to conduct phase 2 authentication: one uses server side certificates; the other does not. As described in section 7, EAP-FAST Provisioning, an encrypted unauthenticated tunnel can be established using TLS_DH_anon_WITH_AES_128_CBC_SHA, or an encrypted server authenticated tunnel can be established using TLS_DHE_RSA_WITH_AES_128_CBC_SHA.

Using an RSA-based Diffie-Hellman (DH) exchange in phase 1 authenticates at least the server by certificate during TLS tunnel establishment. Using anonymous Diffie-Hellman skips phase 1 authentication during tunnel establishment, deferring mutual authentication to phase 2. As noted in the draft, "This cipher suite [TLS_DH_anon_WITH_AES_128_CBC_SHA ] is used at the cost of some security strength to enable the minimization of deployment requirements" -- specifically, avoiding server side certificates. Known security risks are further explained in the Internet draft, along with techniques suggested to minimize those risks (e.g., one-time secrets used only for provisioning).

In short, if you find the risk acceptable, you can avoid server certificates entirely by using only preshared secrets. If you don't think that risk is worth the benefit, you can use a server certificate for secure-but-dynamic provisioning of shared secrets. In either case, you can use shared secrets after the first connection for faster mutual authentication based on symmetric instead of public key crypto.

This was first published in April 2004