We just went option 1, did a self-signed 20 year CA, then generated radius certs off that. Only role/function of that CA is for RADIUS. (PEAP-MSCHAPv2). For the most part, things went well, we use SecureW2 for onboarding if clients choose to do so, which installs the CA and sets the verification check, with a wildcard against the domain so any number of radius server changes could be in play.. (*.network.<your domain>).
Only issues so far with this: 1 - Windows 7 will not trust the cert unless you onboard / install the CA, just joining the network doesn't work. 2 - We've had about a dozen Windows 10 clients fail to connect out of 1,000's. Appears to be a software/patching issue, chasing with Microsoft now. If we boot the problem machine from a clean windows 10 boot disk, works fine. I doubt we will get 20 years out of it. Sometime before hand we will probably need to update due to encryption levels, exploits, new methods, etc. But at least we won't be changing simply because the timer ran out. :) I look forward to option 4 in the near future, although it doesn't fully solve the issue, but since folks need to onboard, makes things easier to manage. Carl Oakes California State University Sacramento From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Chuck Enfield Sent: Monday, October 30, 2017 2:24 PM To: [email protected] Subject: Re: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions Thanks Philippe. Hadn’t thought about fragmentation coming from the internet. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Philippe Hanset Sent: Monday, October 30, 2017 5:08 PM To: [email protected] Subject: Re: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions All, We love option 4 but it has its issues...and on that note let me share (with his permission) a tidbit from Curtis Larsen from University of Utah sent to the eduroam-admins list about EAP-TLS and firewalls/load balancer. Make a mental note for the future ;-), it took us a while to discover that problem: Fragmentation, fragmentation, fragmentation. Best, Philippe Philippe Hanset www.anyroam.net<http://www.anyroam.net> ------------------ From Curtis: We resolved this today working with our Firewall team but I wanted to thank Chad with Anyroam support for helping with the pcaps and suggesting a look at fragmentation initially. It turns out our problem had to do with how fragmented packets are handled by our border firewalls and our chosen load-balancing method on the respective port-channel interfaces. The key is that we needed to balance these RADIUS sessions/transactions on source/dest. IP alone instead of including the TCP/UDP port as well. The problem did not occur with PEAP MSCHAPv2 tests because the packets never fragmented and thus all had the same UDP port number and all got marked as the same session/transaction and sent out the same interface. Sometimes we got lucky and all EAP-TLS packets needed for a single authentication went the same way and it worked but often packets went different ways and the fragments were not able to be marked as part of the same session/transaction and that is when my server got half of the packets. Curtis K. Larsen Senior Wi-Fi Network Engineer University of Utah IT/CIS Office 801-587-1313 ------------------ On Oct 30, 2017, at 4:19 PM, Mike Atkins <[email protected]<mailto:[email protected]>> wrote: We are option 3 with 3 year certs. We were in the same boat as Craig just over a year ago. We moved to a different onboarding utility and different CA. It is a long story so feel free to hit me up offline. That said, in the future we will likely end up using both options 3 & 4 to be flexible with device/owner/use. Mike Atkins Network Engineer Office of Information Technology University of Notre Dame Phone: 574-631-7210 ---- .__o ----- _-\_<, --- (*)/'(*) From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Craig Simons Sent: Monday, October 30, 2017 2:22 PM To: [email protected]<mailto:[email protected]> Subject: [WIRELESS-LAN] 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 8888 University Dr., Burnaby, B.C. V5A 1S6 T: 778.782.8036 | M: 604.649.7977 | www.sfu.ca/itservices<http://www.sfu.ca/itservices> [Image removed by sender.] ********** 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. ********** 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. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
