Rich, Thank you for your detailed response. I should state that our certificate challenges were in fact due to the issuer chain changing (SHA-1 to SHA-2). Perhaps in the near-term, another certificate in the same chain would not be a repeat of last time. Still, with >60% of our mobile devices being Mac OSX/iOS based, I’m nervous that Apple will do something we don’t expect. In the end, any OnBoarding tool can only manipulate the APIs presented by the OS and each flavour of OS may have a different outcome.
I have taken your analysis to heart and it would appear that option 3 is probably the best way forward and we just need to ensure our support resources are set up to handle potential issues. Option 4 is a good long-term strategy, but for different reasons other than simply avoiding short term certificates. Thanks, Craig > On Oct 31, 2017, at 2:53 PM, Richard Nedwich <[email protected]> wrote: > > 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. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
