Re: Radius certificate length vs. onboarding opinions

[Richard Nedwich]

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.

RE: Radius certificate length vs. onboarding opinions

[Osborne, Bruce W (Network Operations)]

We currently use Option 3, but the clients only trust the certificate CHAIN, 
not the server certificate itself. This lets us replace the server certificate 
providing the chain remains the same. This worked fine for us for several years 
with a 1 year server certificate. Unfortunately, we have changed chains twice 
in the past year and will likely change chains again in January. ☹ Some of the 
clients we onboarded at the start of this semester have our “best guess” for 
the new certificate chain too.

We will be moving some clients to Option 4, though.


Bruce Osborne
Senior Network Engineer
Network Operations - Wireless
 (434) 592-4229
LIBERTY UNIVERSITY
Training Champions for Christ since 1971

From: Craig Simons [mailto:craigsim...@sfu.ca]
Sent: Monday, October 30, 2017 2:22 PM
Subject: Radius certificate length vs. onboarding opinions

All,

I know the subject has been broached on the list a few times before, but I’m 
looking for informal opinions/survey about how you are deploying your Radius 
EAP certificates for PEAP/TTLS users (non-TLS). We use Cloudpath to onboard 
users, but recently went through a difficult renewal period to replace our 
expiring certificate. As we had configured all of our clients to “verify the 
server certificate” (as you should from a security perspective), we found that 
iOS/MacOS and Android clients did not take kindly to a new certificate being 
presented. This resulted in quite a few disgruntled users who couldn’t connect 
to WiFi as well as a shell-shocked Service Desk. To help prevent this in the 
future (and because we are moving to a new Radius infrastructure), what is the 
consensus on the following strategies:

Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard with 
"verify server certificate" enabled

Option 2: Removing all traces of “verify server certificate” from OnBoard 
configuration and use 2-year certs from CAs

Option 3: Use 2-year CA certificates, enable “verify server certificates” and 
educate/prepare every two years for connection issues.

Option 4 (probably the best long-term answer): Move to private PKI and EAP-TLS.

Opinions?

Craig Simons
Network Operations Manager

Simon Fraser University | Strand Hall
 University Dr., Burnaby, B.C. V5A 1S6
T: 778.782.8036 | M: 604.649.7977 | 
www.sfu.ca/itservices

[http://www.sfu.ca/content/dam/sfu/creative-studio/images/email/sfu-horizontal.png]

** 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.