Hi Craig, I'm not sure if anyone from Cloudpath already advised you, but I did forward your question to Kevin Koster, Cloudpath Founder and Chief Architect, for his opinion of the pros/cons of these options. I thought I would share them, in case this forum found it useful.
Best, Rich -=-=-=-=-=-=-= Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard with "verify server certificate" enabled Pros: You control the issuing CA, so you control if/when you change the issuing CA. Client will validate the RADIUS server certificate, thereby protecting the user’s password and prevent device from connecting to man-in-the-middle. Cons: Need to generate the private CA (ie need CA tool or openssl skills). Need to install private CA on end-user devices (ie need onboarding tool). Option 2: Removing all traces of “verify server certificate” from OnBoard configuration and use 2-year certs from CAs Pros: “It just works.” Cons. This disables all security built into WPA2-Enterprise. Device will give the password to any network, real or fake. Device will join evil twins. Commentary: With validation disabled, credentials are so at-risk that the network’s attempt to authenticate wifi users becomes moot. If you use this model, you would do less damage to your end-users by using PSK (or even better, Dynamic PSK) or having everyone use a static password (like “password”). Option 3: Use 2-year CA certificates, enable “verify server certificates” and educate/prepare every two years for connection issues. Commentary: This is essentially “use a public CA and be prepared to deal with issues when issuer chain changes”. This normally occurs when protocols become obsolete (1024 to 2048, SHA-1 to SHA-2, etc), but can potentially occur anytime. For 802.1X, these changes are impactful to (properly configured) end-users. Unfortunately, most revenue for public CAs is from web server certificates (which are not affected by issuing CA changes), so they don’t always see chain changes as something to be avoided. Pros: Like #1, credentials are protected. Cons: Requires client configuration. If CA changes its chain, the network will break for the device. Work-Around: The impact of this can be reduced by buying 2-year certificates every 12 months. Then, if the chain does change, you have a 12 month window to transition. This doesn’t change the need to transition, but it does provide a window to make life easier. Option 4 (probably the best long-term answer): Move to private PKI and EAP-TLS. Commentary: While EAP-TLS has benefits beyond this particular issue, EAP-TLS does not change this particular issue. The following scenarios with EAP-TLS would map to 1-3 above: - Using EAP-TLS with a RADIUS cert from private CA would be similar to #1. - Using EAP-TLS with a RADIUS cert from public CA would be similar to #3. - Using EAP-TLS with server cert validation disabled would be similar to #2 (user would be still exposed to connecting to evil twins but the cleartext password wouldn’t be leaked). ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
