On Wed, 1 Nov 2017, James Andrewartha wrote: > One distinction about using a private CA is that you can have an > extremely long root CA, and then have shorter lived certificates signed > by that CA that are rotated. However, without onboarding to install the > CA for the SSID vs just trusting the certificate (which I know is what > macOS and iOS do) then it's not much of a distinction in practice. This > also means I have the same certificate installed on all RADIUS servers.
This is what we do. Very long CA, which the clients get in their onboarding (via CAT, and a local captive portal), and a less-long server cert with a fixed name applied to all the RADIUS servers. As long as replacement server certs use the same name, and are signed by the same root, changeovers should be pretty seamless. (Having gone through a previous root CA change, and a server name change along the way, when it came up again for renewal I wanted to try and make sure that we didn't have that pain any more in the future, at least so far as we can predict). Long term, I agree that cert auth would be better. But I have no real information on the management overhead or technologies to use for efficiently running a PKI for issuing thousands of client certs nor how good client support is. Also agree with the comments about IoT. It makes me deeply uncomfortable when I find out that some wireless device is using the wireless network with some researcher's personal credentials are stored in it so it can connect. We encourage the use of "role accounts" where this is necessary, but they usually would have to ask to find this out and they often just don't. To be fair, I'm usually surprised if a device can do 802.1X - usually means it is linux-based and you've good access to the innards. If you've got a device that can do 5G rather than 2.4G, and does WPA2-PSK, then you're doing well it seems ... I've learned to pleasantly surprised if you get that much and not expect anything more. It's clear we need a separate SSID for those purposes, but I guess to ensure it is only used by suitable devices of limited capabilities it needs to be MAC authenticated which isn't terrific, is a management overhead, and so on. And many of those devices still need Internet access to talk to their cloudy home. So that's NAT or proxying in an IPv4 world, unless you're gonna burn public IPs on them. Interested in how people are handling this too. Jethro. > > On EAP-TLS, we briefly tried enabling Windows Credential Guard last week > on a few IT laptops, and immediately had to turn it off as it breaks > MSCHAPv2 authentication: > https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-considerations > > I had a meeting with Microsoft yesterday and they said that certificate > auth is really the only secure answer. Since our devices are owned by > the school, we'll probably look at setting up a private Windows CA first > rather than going down the CloudPath or SecureW2 path. > > On 31/10/17 12:46, Craig Simons wrote: > > These are very helpful and thoughtful points to consider. I think of > > this issue using the angel and devil on the shoulder analogy. On one > > shoulder, as a security conscious engineer (and technophile) I see why > > shorter certificates (I believe the maximum is 39 months now?) with all > > allowances made for security are the necessary evil. On the other, we > > want the campus WiFi experience to be easy, simple and as painless for > > the user (and Service Desk people) as possible. In many ways, a good > > onboarding tool lets you have your cake and eat it too... but our recent > > experience has shown us that even this has it’s limits. > > > > I suppose the “correct” answer is the one that is supportable. This > > requires the Service Desk/Desktop Support people to be willing and able > > to handle the hordes when they arrive in the interests of security > > “tough love”. > > > > However, I still believe there is a large role to play for EAP-TLS in > > the future. In the IoT world, the willingness of users to put their > > personal credentials on low-end devices is a security threat before even > > getting to the certificate conversation. > > > > Thanks to all that replied! > > > > *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 > > > > ? ? > > SFU SIMON FRASER UNIVERSITY > > IT SERVICES > > > > > >> On Oct 30, 2017, at 1: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? > > -- > James Andrewartha > Network & Projects Engineer > Christ Church Grammar School > Claremont, Western Australia > Ph. (08) 9442 1757 > Mob. 0424 160 877 > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/discuss. > . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
