Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
I've watched this thread with interest, but it went on rather a divergent course so I'll just reply to this initial one (somewhat belatedly). So Andrew's original below is about https://support.apple.com/en-gb/HT211025, and true enough that's applicable for pre-installed root CAs, so those using commercial CAs for their Radius server cert need to pay attention as per the rest of this discussion. The recommendations, such as I've always understood them, and I think have come out during this thread, are: 1. create a private CA root cert with a very long life (lots of years) 2. use that to sign a server cert for your radius server with a shorter life (some handful number of years) 3. as a consequence, therefore, you don't obtain a cert from a commercial CA 4. use an onboarding tool (we use CAT) to enforce server-name pinning in the eduroam config and to deliver the private CA root cert to device 5. once the private CA root cert is installed on the client, we can change the radius server cert seamlessly at will, just so long as its subject is the pinned server-name and it is signed by the same installed private root cert [in theory] This is the arrangement we've had for nearly 5 years, a ~30 year private CA root cert, which issued a 5 year radius server cert. That expires at the start of next year so I am looking at changing now. Here's a good set of certificate recommendations from Geant: https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations, and while reviewing those I noticed something new at the end since the previous time I'd looked, which references this article: https://support.apple.com/en-us/HT210176 This claims that in iOS13/macOS 10.15, "all TLS certs (various conditions about 2048 bits, SHA-2, subject alt name) ... TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).". Which seems to suggest that even certs issued by a private CA root also fall under this restriction, and hence "Connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail". Here's the curious bit. After my enquiries about that, engineers at JISC tried some experiments by setting the clock forward etc to see how these operating systems behaved, and couldn't discern any evidence that they would fail to auth even with a long certificate expiry. So now for the new radius cert I need to issue, I need to decide if I go with another 5 year one, with the possibility that an iOS upgrade might start to reject it at some point in the future, or stick with 2 years and the (relatively minor, if point 5 above holds) pain of changing the cert every other summer? You can probably read the whole discussion here: https://www.jiscmail.ac.uk/cgi-bin/wa-jisc.exe?A2=ind2007=EDUROAM-UK=D=835 Interested to see if anyone has any further insight, apologies if I missed it in the thread or elsewhere. Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . 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. From: The EDUCAUSE Wireless Issues Community Group Listserv on behalf of Andrew Gallo Sent: Wednesday, August 19, 2020 14:28 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Does anyone know if the new, shorter certificate expiration for TLS that Apple announced (and Google is following) will affect 802.1X authentication? Thanks -- Andrew Gallo The George Washington University ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
On 20/8/20 1:01 am, Smith, Todd wrote: > If I come onto your institution then I would have to accept your > certificate chain to be granted access. Why should I trust your chain > over a major CA provider? Obviously, you have the control and authority > to insist on whatever access conditions that you find acceptable, but in > my case I don’t and I use third-party certs since they are acceptable by > practically every device. The risk is not about the initial trust, the risk is that with a public CA, an attacker can obtain a certificate signed by the same CA, and spoof your SSID and obtain PEAP credentials with their validly-signed RADIUS server. Since most clients won't be configured with the specific RADIUS server names and will trust any server signed by the same CA, they will connect to this spoofed SSID without prompting the user. And then, given the way PEAP works, they'll have a password-equivalent secret for the user. If you have a private CA for your RADIUS servers, nobody else can obtain a certificate signed by it (well unless they hack your servers). This is a marginal but not insignificant risk to poorly configured clients. I definitely agree that vendors (both client and wifi infrastructure) should make EAP-TLS easier to deploy. -- James Andrewartha Network & Projects Engineer Christ Church Grammar School Claremont, Western Australia Ph. (08) 9442 1757 Mob. 0424 160 877 ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
MFA is common place at the cohorts I interface with, and was driven by a mix of the financial aid security requirements (GLBA) finally being enforced (Dear Colleague Letter in 2014), and Internet2 Net+ collaborations starting with DUO in 2012. If you're an organization with everything behind SSO, then MFA is a pretty simple add. If your organization has a Office365 tenant, MFA comes along for free as does their federation service. Other than apathy, the barrier to adoption is pretty low. That said, when we talk about risk, you don't necessarily have to mitigate everything to be successful i.e. every resource behind MFA. You simply need enough of the primary services enabled where a bad actor simply moves on to an easier target. If the Employee HR portal (where direct deposit info can be changed) and email are behind SSO + MFA with other primary apps, you're risk becomes significantly smaller. Jeff From: The EDUCAUSE Wireless Issues Community Group Listserv On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 2:01 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? I was saying there are very few organizations that truly have every resource, where the primary password is used, enabled for MFA. From: The EDUCAUSE Wireless Issues Community Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> on behalf of Scott Bertilson <01d368c4bbc6-dmarc-requ...@listserv.educause.edu<mailto:01d368c4bbc6-dmarc-requ...@listserv.educause.edu>> Sent: Wednesday, August 19, 2020 4:45:27 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Tim commented: ...I highly doubt a majority of organizations have every single non-Wi-Fi resource protected with strong MFA at this point in time. In our case, we use PEAP and use the same PW for WiFi as for everything else, but most of everything else (and growing) requires MFA. I hope that's what he meant or else I'm missing something about how you make MFA work for WiFi in any large installation. ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C9017b6bf7ed84dae2cfe08d84480d90a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637334667477262286=mvBwerz%2FDEVShRIIxKtFZe5BAt8Jh%2BPTKBGAp6HEBV0%3D=0> ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
Wow, apologies. I misread your comment, even after I copied it. Ouch. On Wed, Aug 19, 2020 at 4:01 PM Tim Cappalli < 0194c9ecac40-dmarc-requ...@listserv.educause.edu> wrote: > I was saying there are very few organizations that truly have every > resource, where the primary password is used, enabled for MFA. > > -- > *From:* The EDUCAUSE Wireless Issues Community Group Listserv < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Scott Bertilson < > 01d368c4bbc6-dmarc-requ...@listserv.educause.edu> > *Sent:* Wednesday, August 19, 2020 4:45:27 PM > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > *Subject:* Re: [WIRELESS-LAN] New certificate expiration for certificates > affecting 802.1X? > > Tim commented: > ...I highly doubt a majority of organizations have every single non-Wi-Fi > resource protected with strong MFA at this point in time. > > In our case, we use PEAP and use the same PW for WiFi as for everything > else, but most of everything else (and growing) requires MFA. I hope > that's what he meant or else I'm missing something about how you make MFA > work for WiFi in any large installation. > > ** > Replies to EDUCAUSE Community Group emails are sent to the entire > community list. If you want to reply only to the person who sent the > message, copy and paste their email address and forward the email reply. > Additional participation and subscription information can be found at > https://www.educause.edu/community > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C9017b6bf7ed84dae2cfe08d84480d90a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637334667477262286=mvBwerz%2FDEVShRIIxKtFZe5BAt8Jh%2BPTKBGAp6HEBV0%3D=0> > > ** > Replies to EDUCAUSE Community Group emails are sent to the entire > community list. If you want to reply only to the person who sent the > message, copy and paste their email address and forward the email reply. > Additional participation and subscription information can be found at > https://www.educause.edu/community > ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
I was saying there are very few organizations that truly have every resource, where the primary password is used, enabled for MFA. From: The EDUCAUSE Wireless Issues Community Group Listserv on behalf of Scott Bertilson <01d368c4bbc6-dmarc-requ...@listserv.educause.edu> Sent: Wednesday, August 19, 2020 4:45:27 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Tim commented: ...I highly doubt a majority of organizations have every single non-Wi-Fi resource protected with strong MFA at this point in time. In our case, we use PEAP and use the same PW for WiFi as for everything else, but most of everything else (and growing) requires MFA. I hope that's what he meant or else I'm missing something about how you make MFA work for WiFi in any large installation. ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C9017b6bf7ed84dae2cfe08d84480d90a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637334667477262286=mvBwerz%2FDEVShRIIxKtFZe5BAt8Jh%2BPTKBGAp6HEBV0%3D=0> ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
Tim commented: ...I highly doubt a majority of organizations have every single non-Wi-Fi resource protected with strong MFA at this point in time. In our case, we use PEAP and use the same PW for WiFi as for everything else, but most of everything else (and growing) requires MFA. I hope that's what he meant or else I'm missing something about how you make MFA work for WiFi in any large installation. ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
As Tim mentioned, PEAP is fine and actually in my opinion the most OS friendly EAP method (I define friendly as no complicated installer required and no EAP fragmentation issues) as long as you use a non sensitive password. But who does that ? and that is what hurts PEAP. There are now Wifi hacking kits designed to collect passwords for WPA enterprise .Canada has been pushing for their eduroam partners to use CAT to mitigate the problem since CAT enforces the certificate pinning and prevents users from accepting « anything » when presented with a fake certificate. We implemented campus wide WEP at University of Tennessee back in 2000. Worst idea ever. Our CiO absolutely wanted security and we got the Lucent per user per session encryption. OS support fell apart. Worst idea ever. We then did MAC address registration using our home grown netreg... that worked flawlessly for more than 10 years. We tried in the meantime 802.1X with the Odyssey client (from Funk back then). Thank goodness we kept it as a pilot within the IT department! Then slowly but surely OSes started to get their act together with EAP-TTLS (not in Windows for quite a while if you remember). Now we finally have PEAP working fine everywhere but we screw it up by using sensitive passwords, and EAP-TLS is the golden standard but requires a heavy duty installer. Something tells me that it will eventually get better. (just wait 20 years :) Philippe Philippe Hanset, CEO ANYROAM LLC www.anyroam.net www.eduroam.us +1 (865) 236-0770 On Aug 19, 2020, at 1:38 PM, Jeffrey D. Sessler wrote: For a student population that will only be with the institution for 4 years, and then spend the next 60 years using WiFi options with lower barriers and potentially a little more risk, are EDU’s getting it wrong? Are we too focused on something with low risk while ignoring other higher risk issues? At the point one needs complicated provisioning tools, your userbase sees only barriers, and then wonders why the other 99% of places they frequent don’t require such inconveniences. The key is a _realistic_ risk assessment. There are plenty of examples outside of technology e.g. the lock on your doors, where it’s a given there are no silver bullets and we choose based on risk vs cost. Do you spend thousands of dollars to put Bowley locks on your doors, or accept that in most situations, the $20 kwickset locks are good enough? As a bad actor, why would I spend time trying to compromise a WiFi network, when it’s far easier to send your organization phishing emails? Phishing can be done remotely and exploit the greatest weakest (humans). A successful phish/compromise and I’m well past the front door, the expensive locks, and enjoying a beer from your refrigerator. According to by eduroam guest reports, PEAP still dominates everything else at 89.7% vs 8.3% for EAP-TLS and 1.97% for EAP-TTLS. I don’t know that I’d call that legacy, and while it does have weakness, how would one compare it to an institution that may not have the best security controls around their provisioning tools? A compromise of one’s provisioning tool, say because of admins using weak passwords and/or no MFA, may present a higher security risk than the use of PEAP. Jeff From: The EDUCAUSE Wireless Issues Community Group Listserv On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 9:43 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? My old colleagues likely won’t be happy with me saying this, but given the industry changes, I think you should collectively pressure NAC vendors to make device provisioning part of the core product without the need for additional licensing (at least for EDU). From: Tim Tyler Sent: Wednesday, August 19, 2020 12:39 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Yes, I always find this conversation to be interesting. There are many institutions that can’t afford an on-boarding solution. Hence, the certs usually get ignored since most configurations are manual or semi-automatic. And my thought is that mac address registration would eliminate the vulnerability of user’s credentials via network authentication. So this is something I keep thinking might be better than 802.1x if certs are going to get ignored anyways. But the recent conversation on mac addresses potentially becoming dynamic will make me strongly hesitate on this thought. Tim From: The EDUCAUSE Wireless Issues Community Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 11:27 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Correct, some versions of operating systems do not support a self-signed EAP
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
I’ll respond, but we’re drifting really far from the original tactical conversation/ask. This is a great conversation, but I think maybe a separate thread to discuss the points you brought up might be better as many are either forward looking (do we need identity for Wi-Fi) or comparing attack vectors. RE: compromised databases, yeah sure, but that assumes those credentials are there and still active. If I sit near University A and get 100 credentials, there’s a lot more guarantee I’m going to be able to do something malicious with very little work. RE: MFA, sure that’s a huge part of the conversation, but I highly doubt a majority of organizations have every single non-Wi-Fi resource protected with strong MFA at this point in time. tim From: Jeffrey D. Sessler<mailto:j...@scrippscollege.edu> Sent: Wednesday, August 19, 2020 14:28 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Tim, Isn’t it easier for a bad actor to pull user/passwords from the various online compromised credential databases, then collect them from WiFi scanning? It would be interesting to correlate wifi harvested credentials with the various compromised credential databases, looking for matches. One could then evaluate the effectiveness of the scanning over the alternative and less risky use of the database. It’s the economics of thievery, and I’m not convinced someone would go to the trouble of WiFi scanning given the alternative. And for those using password-based auth (primary credentials), then the easy defense is MFA, where the bad actor would be limited to only WiFi access. For those that treat WiFi as a hostile network and not as a permission to access resouces, at best this person gets free WiFi access. Jeff From: The EDUCAUSE Wireless Issues Community Group Listserv On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 10:43 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? The underlying protocols used with PEAP are legacy. Usage in the wild does not dictate whether a protocol is legacy or not. My one specific comment is to this: * As a bad actor, why would I spend time trying to compromise a WiFi network, when it’s far easier to send your organization phishing emails? It is incredibly easy. During non-COVID times, I can sit in downtown Boston and harvest hundreds of user credentials in an hour with software that can be configured in 10 minutes. This kind of passive “attack” is far worse than a phishing attempt. In closing (unless there are other direct technical questions), if you’re going to use password-based authentication, please do not use the user’s primary credential. Generate a network-specific credential that the user can use for Wi-Fi. If we can make this the baseline, many concerns would go away. tim From: Jeffrey D. Sessler<mailto:j...@scrippscollege.edu> Sent: Wednesday, August 19, 2020 13:38 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? For a student population that will only be with the institution for 4 years, and then spend the next 60 years using WiFi options with lower barriers and potentially a little more risk, are EDU’s getting it wrong? Are we too focused on something with low risk while ignoring other higher risk issues? At the point one needs complicated provisioning tools, your userbase sees only barriers, and then wonders why the other 99% of places they frequent don’t require such inconveniences. The key is a _realistic_ risk assessment. There are plenty of examples outside of technology e.g. the lock on your doors, where it’s a given there are no silver bullets and we choose based on risk vs cost. Do you spend thousands of dollars to put Bowley locks on your doors, or accept that in most situations, the $20 kwickset locks are good enough? As a bad actor, why would I spend time trying to compromise a WiFi network, when it’s far easier to send your organization phishing emails? Phishing can be done remotely and exploit the greatest weakest (humans). A successful phish/compromise and I’m well past the front door, the expensive locks, and enjoying a beer from your refrigerator. According to by eduroam guest reports, PEAP still dominates everything else at 89.7% vs 8.3% for EAP-TLS and 1.97% for EAP-TTLS. I don’t know that I’d call that legacy, and while it does have weakness, how would one compare it to an institution that may not have the best security controls around their provisioning tools? A compromise of one’s provisioning tool, say because of admins using weak passwords and/or no MFA, may present a higher security risk than the use of PEAP. Jeff Fro
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
The underlying protocols used with PEAP are legacy. Usage in the wild does not dictate whether a protocol is legacy or not. My one specific comment is to this: * As a bad actor, why would I spend time trying to compromise a WiFi network, when it’s far easier to send your organization phishing emails? It is incredibly easy. During non-COVID times, I can sit in downtown Boston and harvest hundreds of user credentials in an hour with software that can be configured in 10 minutes. This kind of passive “attack” is far worse than a phishing attempt. In closing (unless there are other direct technical questions), if you’re going to use password-based authentication, please do not use the user’s primary credential. Generate a network-specific credential that the user can use for Wi-Fi. If we can make this the baseline, many concerns would go away. tim From: Jeffrey D. Sessler<mailto:j...@scrippscollege.edu> Sent: Wednesday, August 19, 2020 13:38 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? For a student population that will only be with the institution for 4 years, and then spend the next 60 years using WiFi options with lower barriers and potentially a little more risk, are EDU’s getting it wrong? Are we too focused on something with low risk while ignoring other higher risk issues? At the point one needs complicated provisioning tools, your userbase sees only barriers, and then wonders why the other 99% of places they frequent don’t require such inconveniences. The key is a _realistic_ risk assessment. There are plenty of examples outside of technology e.g. the lock on your doors, where it’s a given there are no silver bullets and we choose based on risk vs cost. Do you spend thousands of dollars to put Bowley locks on your doors, or accept that in most situations, the $20 kwickset locks are good enough? As a bad actor, why would I spend time trying to compromise a WiFi network, when it’s far easier to send your organization phishing emails? Phishing can be done remotely and exploit the greatest weakest (humans). A successful phish/compromise and I’m well past the front door, the expensive locks, and enjoying a beer from your refrigerator. According to by eduroam guest reports, PEAP still dominates everything else at 89.7% vs 8.3% for EAP-TLS and 1.97% for EAP-TTLS. I don’t know that I’d call that legacy, and while it does have weakness, how would one compare it to an institution that may not have the best security controls around their provisioning tools? A compromise of one’s provisioning tool, say because of admins using weak passwords and/or no MFA, may present a higher security risk than the use of PEAP. Jeff From: The EDUCAUSE Wireless Issues Community Group Listserv On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 9:43 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? My old colleagues likely won’t be happy with me saying this, but given the industry changes, I think you should collectively pressure NAC vendors to make device provisioning part of the core product without the need for additional licensing (at least for EDU). From: Tim Tyler<mailto:ty...@beloit.edu> Sent: Wednesday, August 19, 2020 12:39 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Yes, I always find this conversation to be interesting. There are many institutions that can’t afford an on-boarding solution. Hence, the certs usually get ignored since most configurations are manual or semi-automatic. And my thought is that mac address registration would eliminate the vulnerability of user’s credentials via network authentication. So this is something I keep thinking might be better than 802.1x if certs are going to get ignored anyways. But the recent conversation on mac addresses potentially becoming dynamic will make me strongly hesitate on this thought. Tim From: The EDUCAUSE Wireless Issues Community Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 11:27 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Correct, some versions of operating systems do not support a self-signed EAP server certificates. It is also just a bad idea as you can’t renew it without re-onboarding devices. If you use at least 1 issuer, you can cycle the certificate without updating clients. PEAP (and EAP-TTLS) should never be used on unmanaged devices unless a securi
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
For a student population that will only be with the institution for 4 years, and then spend the next 60 years using WiFi options with lower barriers and potentially a little more risk, are EDU’s getting it wrong? Are we too focused on something with low risk while ignoring other higher risk issues? At the point one needs complicated provisioning tools, your userbase sees only barriers, and then wonders why the other 99% of places they frequent don’t require such inconveniences. The key is a _realistic_ risk assessment. There are plenty of examples outside of technology e.g. the lock on your doors, where it’s a given there are no silver bullets and we choose based on risk vs cost. Do you spend thousands of dollars to put Bowley locks on your doors, or accept that in most situations, the $20 kwickset locks are good enough? As a bad actor, why would I spend time trying to compromise a WiFi network, when it’s far easier to send your organization phishing emails? Phishing can be done remotely and exploit the greatest weakest (humans). A successful phish/compromise and I’m well past the front door, the expensive locks, and enjoying a beer from your refrigerator. According to by eduroam guest reports, PEAP still dominates everything else at 89.7% vs 8.3% for EAP-TLS and 1.97% for EAP-TTLS. I don’t know that I’d call that legacy, and while it does have weakness, how would one compare it to an institution that may not have the best security controls around their provisioning tools? A compromise of one’s provisioning tool, say because of admins using weak passwords and/or no MFA, may present a higher security risk than the use of PEAP. Jeff From: The EDUCAUSE Wireless Issues Community Group Listserv On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 9:43 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? My old colleagues likely won’t be happy with me saying this, but given the industry changes, I think you should collectively pressure NAC vendors to make device provisioning part of the core product without the need for additional licensing (at least for EDU). From: Tim Tyler<mailto:ty...@beloit.edu> Sent: Wednesday, August 19, 2020 12:39 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Yes, I always find this conversation to be interesting. There are many institutions that can’t afford an on-boarding solution. Hence, the certs usually get ignored since most configurations are manual or semi-automatic. And my thought is that mac address registration would eliminate the vulnerability of user’s credentials via network authentication. So this is something I keep thinking might be better than 802.1x if certs are going to get ignored anyways. But the recent conversation on mac addresses potentially becoming dynamic will make me strongly hesitate on this thought. Tim From: The EDUCAUSE Wireless Issues Community Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 11:27 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Correct, some versions of operating systems do not support a self-signed EAP server certificates. It is also just a bad idea as you can’t renew it without re-onboarding devices. If you use at least 1 issuer, you can cycle the certificate without updating clients. PEAP (and EAP-TTLS) should never be used on unmanaged devices unless a security assessment has been done and its been determined that credential exposure is an acceptable risk to the organization. I feel like this conversation surfaces multiple times per year. So here’s the summary: If able, EAP-TLS should be used for all user-centric device network access. This then implies an organizationally controlled PKI is used to issue the EAP server certificate. If EAP-TLS is not feasible and a legacy, known vulnerable EAP method like PEAP is going to be used, it is highly recommended that a supplicant provisioning wizard be used. This would also use an organizationally controlled PKI for the EAP server certificate. Your information security team should determine whether credential exposure is an acceptable risk for the organization. If EAP-TTLS/PAP or EAP-TTLS/MSCHAPv2 are used, a supplicant provisioning wizard is required for Apple operating systems. This would also use an organizationally controlled PKI for the EAP server certificate. Your information security team should determine whether credential exposure is an acceptable risk for the organization. If you decide to use an EAP server certificate from a pub
RE: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
Well, the prompt is nearly identical identical for private vs public CAs on Apple and Windows devices, and at least in my experience, users don’t read it, they just either complain to the help desk (or on Twitter) or click it. The core reason to use an internal PKI is so you can renew the server certificates without worrying about breaking changes for that impact users and require help desk calls and/or intervention. If we want to get super technical, using a web server certificate from a public CA for EAP is technically not allowed. The other thing to keep in mind is that you can use multiple EAP methods on the same SSID. You can use PEAP for your legacy organizationally owned devices, and even devices that are managed (ex: Windows devices with a machine credential) and use EAP-TLS or another option for unmanaged. tim From: Smith, Todd<mailto:todd.sm...@camc.org> Sent: Wednesday, August 19, 2020 13:23 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Tim, Thank you for your response. The issue that I see is that where it is a supplicant or a manual install; I am still required to trust your chain instead of a major CA. I use third-party certificates since I know that are supported and it is easier to trust an organization that has to be validated every couple of years then a random organization that may or may not protect its internal CA properly. I do run internal CA and they are harder to protect then most people believe. Much of the medical equipment that I work with can’t support EAP-TLS and getting 802.1x PEAP is sometimes a major challenge. In 2020, the number of wireless devices that I see that are at least 3 generations old is still unacceptably high. Todd Smith From: The EDUCAUSE Wireless Issues Community Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 1:12 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? The core difference is a user or device password cannot be compromised when modern authentication is used. Password-based authentication has been in the process of being deprecated for years. Unfortunately networks are one of the last parties stuck on passwords. * If I come onto your institution then I would have to accept your certificate chain to be granted access. Why should I trust your chain over a major CA provider? This should NEVER be happening. That’s the other major point. A properly configured supplicant will never prompt the user to accept a trust anchor, regardless of whether it’s a public CA or not. Tim From: Smith, Todd<mailto:todd.sm...@camc.org> Sent: Wednesday, August 19, 2020 13:01 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? This is all well and good and I accept that different institutions have different requirements. How is EAP-TLS which requires a client certificate any better than EAP-PEAP which while using username/password is in a Microsoft setting not worse than setting at your wired machine to login? Unless your organization requires client side certs on your wired machines; then I don’t see the difference? Your point is well founded in that not required server certificate validation does open up to MITM attacks for PEAP but to summarily declare EAP-TLS superior because it uses client certificates seems to miss the point. If I come onto your institution then I would have to accept your certificate chain to be granted access. Why should I trust your chain over a major CA provider? Obviously, you have the control and authority to insist on whatever access conditions that you find acceptable, but in my case I don’t and I use third-party certs since they are acceptable by practically every device. To change the question slightly, What are organizations using for large private PKI? Microsoft CA? OpenSSL? What are organizations doing to onboard non-owned devices to accept this foreign cert chain? Thank you in advance for a responses to a difficult and troubling subject Todd Smith ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C3c25ae2d96c342746f4808d84464a091%7C72f988bf8
RE: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
Tim, Thank you for your response. The issue that I see is that where it is a supplicant or a manual install; I am still required to trust your chain instead of a major CA. I use third-party certificates since I know that are supported and it is easier to trust an organization that has to be validated every couple of years then a random organization that may or may not protect its internal CA properly. I do run internal CA and they are harder to protect then most people believe. Much of the medical equipment that I work with can't support EAP-TLS and getting 802.1x PEAP is sometimes a major challenge. In 2020, the number of wireless devices that I see that are at least 3 generations old is still unacceptably high. Todd Smith From: The EDUCAUSE Wireless Issues Community Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 1:12 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? The core difference is a user or device password cannot be compromised when modern authentication is used. Password-based authentication has been in the process of being deprecated for years. Unfortunately networks are one of the last parties stuck on passwords. ? If I come onto your institution then I would have to accept your certificate chain to be granted access. Why should I trust your chain over a major CA provider? This should NEVER be happening. That's the other major point. A properly configured supplicant will never prompt the user to accept a trust anchor, regardless of whether it's a public CA or not. Tim From: Smith, Todd<mailto:todd.sm...@camc.org> Sent: Wednesday, August 19, 2020 13:01 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? This is all well and good and I accept that different institutions have different requirements. How is EAP-TLS which requires a client certificate any better than EAP-PEAP which while using username/password is in a Microsoft setting not worse than setting at your wired machine to login? Unless your organization requires client side certs on your wired machines; then I don't see the difference? Your point is well founded in that not required server certificate validation does open up to MITM attacks for PEAP but to summarily declare EAP-TLS superior because it uses client certificates seems to miss the point. If I come onto your institution then I would have to accept your certificate chain to be granted access. Why should I trust your chain over a major CA provider? Obviously, you have the control and authority to insist on whatever access conditions that you find acceptable, but in my case I don't and I use third-party certs since they are acceptable by practically every device. To change the question slightly, What are organizations using for large private PKI? Microsoft CA? OpenSSL? What are organizations doing to onboard non-owned devices to accept this foreign cert chain? Thank you in advance for a responses to a difficult and troubling subject Todd Smith ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
RE: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
The core difference is a user or device password cannot be compromised when modern authentication is used. Password-based authentication has been in the process of being deprecated for years. Unfortunately networks are one of the last parties stuck on passwords. * If I come onto your institution then I would have to accept your certificate chain to be granted access. Why should I trust your chain over a major CA provider? This should NEVER be happening. That’s the other major point. A properly configured supplicant will never prompt the user to accept a trust anchor, regardless of whether it’s a public CA or not. Tim From: Smith, Todd<mailto:todd.sm...@camc.org> Sent: Wednesday, August 19, 2020 13:01 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? This is all well and good and I accept that different institutions have different requirements. How is EAP-TLS which requires a client certificate any better than EAP-PEAP which while using username/password is in a Microsoft setting not worse than setting at your wired machine to login? Unless your organization requires client side certs on your wired machines; then I don’t see the difference? Your point is well founded in that not required server certificate validation does open up to MITM attacks for PEAP but to summarily declare EAP-TLS superior because it uses client certificates seems to miss the point. If I come onto your institution then I would have to accept your certificate chain to be granted access. Why should I trust your chain over a major CA provider? Obviously, you have the control and authority to insist on whatever access conditions that you find acceptable, but in my case I don’t and I use third-party certs since they are acceptable by practically every device. To change the question slightly, What are organizations using for large private PKI? Microsoft CA? OpenSSL? What are organizations doing to onboard non-owned devices to accept this foreign cert chain? Thank you in advance for a responses to a difficult and troubling subject Todd Smith From: The EDUCAUSE Wireless Issues Community Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 11:27 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Correct, some versions of operating systems do not support a self-signed EAP server certificates. It is also just a bad idea as you can’t renew it without re-onboarding devices. If you use at least 1 issuer, you can cycle the certificate without updating clients. PEAP (and EAP-TTLS) should never be used on unmanaged devices unless a security assessment has been done and its been determined that credential exposure is an acceptable risk to the organization. I feel like this conversation surfaces multiple times per year. So here’s the summary: If able, EAP-TLS should be used for all user-centric device network access. This then implies an organizationally controlled PKI is used to issue the EAP server certificate. If EAP-TLS is not feasible and a legacy, known vulnerable EAP method like PEAP is going to be used, it is highly recommended that a supplicant provisioning wizard be used. This would also use an organizationally controlled PKI for the EAP server certificate. Your information security team should determine whether credential exposure is an acceptable risk for the organization. If EAP-TTLS/PAP or EAP-TTLS/MSCHAPv2 are used, a supplicant provisioning wizard is required for Apple operating systems. This would also use an organizationally controlled PKI for the EAP server certificate. Your information security team should determine whether credential exposure is an acceptable risk for the organization. If you decide to use an EAP server certificate from a public CA, expect problems every year. General summary Always use a PKI in your control for the EAP server identity so you’re able to renew the server certificate without any risk of a chain change or enforcement of restrictions intended for browsers If you must use legacy password-based authentication, use a supplicant provisioning wizard (butrealize this does not remove all risk as you can’t force users to use it) If users configure their own supplicant for password-based authentication or blindly accept a certificate prompt, you should assume that their credentials have been comprised Also one quick update regarding Android: Android 11 will not restrict EAP server certificates to Chrome’s 1 year lifetime. tim From: Dennis Xu<mailto:d...@uoguelph.ca> Sent: Wednesday, Augus
RE: [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
This is all well and good and I accept that different institutions have different requirements. How is EAP-TLS which requires a client certificate any better than EAP-PEAP which while using username/password is in a Microsoft setting not worse than setting at your wired machine to login? Unless your organization requires client side certs on your wired machines; then I don’t see the difference? Your point is well founded in that not required server certificate validation does open up to MITM attacks for PEAP but to summarily declare EAP-TLS superior because it uses client certificates seems to miss the point. If I come onto your institution then I would have to accept your certificate chain to be granted access. Why should I trust your chain over a major CA provider? Obviously, you have the control and authority to insist on whatever access conditions that you find acceptable, but in my case I don’t and I use third-party certs since they are acceptable by practically every device. To change the question slightly, What are organizations using for large private PKI? Microsoft CA? OpenSSL? What are organizations doing to onboard non-owned devices to accept this foreign cert chain? Thank you in advance for a responses to a difficult and troubling subject Todd Smith From: The EDUCAUSE Wireless Issues Community Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 11:27 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Correct, some versions of operating systems do not support a self-signed EAP server certificates. It is also just a bad idea as you can’t renew it without re-onboarding devices. If you use at least 1 issuer, you can cycle the certificate without updating clients. PEAP (and EAP-TTLS) should never be used on unmanaged devices unless a security assessment has been done and its been determined that credential exposure is an acceptable risk to the organization. I feel like this conversation surfaces multiple times per year. So here’s the summary: If able, EAP-TLS should be used for all user-centric device network access. This then implies an organizationally controlled PKI is used to issue the EAP server certificate. If EAP-TLS is not feasible and a legacy, known vulnerable EAP method like PEAP is going to be used, it is highly recommended that a supplicant provisioning wizard be used. This would also use an organizationally controlled PKI for the EAP server certificate. Your information security team should determine whether credential exposure is an acceptable risk for the organization. If EAP-TTLS/PAP or EAP-TTLS/MSCHAPv2 are used, a supplicant provisioning wizard is required for Apple operating systems. This would also use an organizationally controlled PKI for the EAP server certificate. Your information security team should determine whether credential exposure is an acceptable risk for the organization. If you decide to use an EAP server certificate from a public CA, expect problems every year. General summary Always use a PKI in your control for the EAP server identity so you’re able to renew the server certificate without any risk of a chain change or enforcement of restrictions intended for browsers If you must use legacy password-based authentication, use a supplicant provisioning wizard (butrealize this does not remove all risk as you can’t force users to use it) If users configure their own supplicant for password-based authentication or blindly accept a certificate prompt, you should assume that their credentials have been comprised Also one quick update regarding Android: Android 11 will not restrict EAP server certificates to Chrome’s 1 year lifetime. tim From: Dennis Xu<mailto:d...@uoguelph.ca> Sent: Wednesday, August 19, 2020 12:12 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Hi Tim, Can you please further elaborate the issues with self-signed certs vs private CA signed certs besides the manageability stuffs? I understand some OSes cannot connect if using self-signed cert for PEAP authentication, unless using on-boarding solutions to configure them to trust the cert. I am not sure if the private CA signed cert makes any difference on this. Below is from the FreeRADIUS EAP configuration file: # Trusted Root CA list # # ALL of the CA's in this list will be trusted # to issue client certificates for authentication. # # In general, you should use self-signed # certificates for 802
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
My old colleagues likely won’t be happy with me saying this, but given the industry changes, I think you should collectively pressure NAC vendors to make device provisioning part of the core product without the need for additional licensing (at least for EDU). From: Tim Tyler<mailto:ty...@beloit.edu> Sent: Wednesday, August 19, 2020 12:39 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Yes, I always find this conversation to be interesting. There are many institutions that can’t afford an on-boarding solution. Hence, the certs usually get ignored since most configurations are manual or semi-automatic. And my thought is that mac address registration would eliminate the vulnerability of user’s credentials via network authentication. So this is something I keep thinking might be better than 802.1x if certs are going to get ignored anyways. But the recent conversation on mac addresses potentially becoming dynamic will make me strongly hesitate on this thought. Tim From: The EDUCAUSE Wireless Issues Community Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 11:27 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Correct, some versions of operating systems do not support a self-signed EAP server certificates. It is also just a bad idea as you can’t renew it without re-onboarding devices. If you use at least 1 issuer, you can cycle the certificate without updating clients. PEAP (and EAP-TTLS) should never be used on unmanaged devices unless a security assessment has been done and its been determined that credential exposure is an acceptable risk to the organization. I feel like this conversation surfaces multiple times per year. So here’s the summary: If able, EAP-TLS should be used for all user-centric device network access. This then implies an organizationally controlled PKI is used to issue the EAP server certificate. If EAP-TLS is not feasible and a legacy, known vulnerable EAP method like PEAP is going to be used, it is highly recommended that a supplicant provisioning wizard be used. This would also use an organizationally controlled PKI for the EAP server certificate. Your information security team should determine whether credential exposure is an acceptable risk for the organization. If EAP-TTLS/PAP or EAP-TTLS/MSCHAPv2 are used, a supplicant provisioning wizard is required for Apple operating systems. This would also use an organizationally controlled PKI for the EAP server certificate. Your information security team should determine whether credential exposure is an acceptable risk for the organization. If you decide to use an EAP server certificate from a public CA, expect problems every year. General summary Always use a PKI in your control for the EAP server identity so you’re able to renew the server certificate without any risk of a chain change or enforcement of restrictions intended for browsers If you must use legacy password-based authentication, use a supplicant provisioning wizard (butrealize this does not remove all risk as you can’t force users to use it) If users configure their own supplicant for password-based authentication or blindly accept a certificate prompt, you should assume that their credentials have been comprised Also one quick update regarding Android: Android 11 will not restrict EAP server certificates to Chrome’s 1 year lifetime. tim From: Dennis Xu<mailto:d...@uoguelph.ca> Sent: Wednesday, August 19, 2020 12:12 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Hi Tim, Can you please further elaborate the issues with self-signed certs vs private CA signed certs besides the manageability stuffs? I understand some OSes cannot connect if using self-signed cert for PEAP authentication, unless using on-boarding solutions to configure them to trust the cert. I am not sure if the private CA signed cert makes any difference on this. Below is from the FreeRADIUS EAP configuration file: # Trusted Root CA list # # ALL of the CA's in this list will be trusted # to issue client certificates for authentication. # # In general, you should use self-signed # certificates for 802.1x (EAP) authentication. # In that case, this CA file should contain # *one* CA certificate. Thanks, Dennis From: The EDUCAUSE Wire
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
Yes, I always find this conversation to be interesting. There are many institutions that can’t afford an on-boarding solution. Hence, the certs usually get ignored since most configurations are manual or semi-automatic. And my thought is that mac address registration would eliminate the vulnerability of user’s credentials via network authentication. So this is something I keep thinking might be better than 802.1x if certs are going to get ignored anyways. But the recent conversation on mac addresses potentially becoming dynamic will make me strongly hesitate on this thought. Tim *From:* The EDUCAUSE Wireless Issues Community Group Listserv [mailto: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Tim Cappalli *Sent:* Wednesday, August 19, 2020 11:27 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Correct, some versions of operating systems do not support a self-signed EAP server certificates. It is also just a bad idea as you can’t renew it without re-onboarding devices. If you use at least 1 issuer, you can cycle the certificate without updating clients. PEAP (and EAP-TTLS) should never be used on unmanaged devices unless a security assessment has been done and its been determined that credential exposure is an acceptable risk to the organization. I feel like this conversation surfaces multiple times per year. So here’s the summary: - If able, EAP-TLS should be used for all user-centric device network access. This then implies an organizationally controlled PKI is used to issue the EAP server certificate. - If EAP-TLS is not feasible and a legacy, known vulnerable EAP method like PEAP is going to be used, it is highly recommended that a supplicant provisioning wizard be used. This would also use an organizationally controlled PKI for the EAP server certificate. Your information security team should determine whether credential exposure is an acceptable risk for the organization. - If EAP-TTLS/PAP or EAP-TTLS/MSCHAPv2 are used, a supplicant provisioning wizard is required for Apple operating systems. This would also use an organizationally controlled PKI for the EAP server certificate. Your information security team should determine whether credential exposure is an acceptable risk for the organization. - If you decide to use an EAP server certificate from a public CA, expect problems every year. General summary Always use a PKI in your control for the EAP server identity so you’re able to renew the server certificate without any risk of a chain change or enforcement of restrictions intended for browsers If you must use legacy password-based authentication, use a supplicant provisioning wizard (butrealize this does not remove all risk as you can’t force users to use it) If users configure their own supplicant for password-based authentication or blindly accept a certificate prompt, you should assume that their credentials have been comprised *Also one quick update regarding Android: Android 11 will not restrict EAP server certificates to Chrome’s 1 year lifetime.* tim *From: *Dennis Xu *Sent: *Wednesday, August 19, 2020 12:12 *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject: *Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Hi Tim, Can you please further elaborate the issues with self-signed certs vs private CA signed certs besides the manageability stuffs? I understand some OSes cannot connect if using self-signed cert for PEAP authentication, unless using on-boarding solutions to configure them to trust the cert. I am not sure if the private CA signed cert makes any difference on this. Below is from the FreeRADIUS EAP configuration file: # Trusted Root CA list # # ALL of the CA's in this list will be trusted # to issue client certificates for authentication. # # In general, you should use self-signed # certificates for 802.1x (EAP) authentication. # In that case, this CA file should contain # *one* CA certificate. Thanks, Dennis *From:* The EDUCAUSE Wireless Issues Community Group Listserv < WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Mike Atkins *Sent:* Wednesday, August 19, 2020 11:51 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? *CAUTION:* This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca Good clarification, thanks. In previous discussions, our identity group mentioned using PKI that they use for other systems.
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
Correct, some versions of operating systems do not support a self-signed EAP server certificates. It is also just a bad idea as you can’t renew it without re-onboarding devices. If you use at least 1 issuer, you can cycle the certificate without updating clients. PEAP (and EAP-TTLS) should never be used on unmanaged devices unless a security assessment has been done and its been determined that credential exposure is an acceptable risk to the organization. I feel like this conversation surfaces multiple times per year. So here’s the summary: * If able, EAP-TLS should be used for all user-centric device network access. This then implies an organizationally controlled PKI is used to issue the EAP server certificate. * If EAP-TLS is not feasible and a legacy, known vulnerable EAP method like PEAP is going to be used, it is highly recommended that a supplicant provisioning wizard be used. This would also use an organizationally controlled PKI for the EAP server certificate. Your information security team should determine whether credential exposure is an acceptable risk for the organization. * If EAP-TTLS/PAP or EAP-TTLS/MSCHAPv2 are used, a supplicant provisioning wizard is required for Apple operating systems. This would also use an organizationally controlled PKI for the EAP server certificate. Your information security team should determine whether credential exposure is an acceptable risk for the organization. * If you decide to use an EAP server certificate from a public CA, expect problems every year. General summary Always use a PKI in your control for the EAP server identity so you’re able to renew the server certificate without any risk of a chain change or enforcement of restrictions intended for browsers If you must use legacy password-based authentication, use a supplicant provisioning wizard (butrealize this does not remove all risk as you can’t force users to use it) If users configure their own supplicant for password-based authentication or blindly accept a certificate prompt, you should assume that their credentials have been comprised Also one quick update regarding Android: Android 11 will not restrict EAP server certificates to Chrome’s 1 year lifetime. tim From: Dennis Xu<mailto:d...@uoguelph.ca> Sent: Wednesday, August 19, 2020 12:12 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Hi Tim, Can you please further elaborate the issues with self-signed certs vs private CA signed certs besides the manageability stuffs? I understand some OSes cannot connect if using self-signed cert for PEAP authentication, unless using on-boarding solutions to configure them to trust the cert. I am not sure if the private CA signed cert makes any difference on this. Below is from the FreeRADIUS EAP configuration file: # Trusted Root CA list # # ALL of the CA's in this list will be trusted # to issue client certificates for authentication. # # In general, you should use self-signed # certificates for 802.1x (EAP) authentication. # In that case, this CA file should contain # *one* CA certificate. Thanks, Dennis From: The EDUCAUSE Wireless Issues Community Group Listserv On Behalf Of Mike Atkins Sent: Wednesday, August 19, 2020 11:51 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca<mailto:ith...@uoguelph.ca> Good clarification, thanks. In previous discussions, our identity group mentioned using PKI that they use for other systems. Note to self, be careful what you ask for. Mike Atkins Network Engineer Office of Information Technology University of Notre Dame From: The EDUCAUSE Wireless Issues Community Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 11:34 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Got it. Just to clarify, a self-signed EAP server certificate should never be used. A server certificate issued by a PKI under your control is the best deployment practice (which is not the same as a self-signed certificate). tim From: Mike Atkins<mailto:matk...@nd.edu> Sent: Wednesday, August 19, 2020 11:31 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.E
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
Hi Tim, Can you please further elaborate the issues with self-signed certs vs private CA signed certs besides the manageability stuffs? I understand some OSes cannot connect if using self-signed cert for PEAP authentication, unless using on-boarding solutions to configure them to trust the cert. I am not sure if the private CA signed cert makes any difference on this. Below is from the FreeRADIUS EAP configuration file: # Trusted Root CA list # # ALL of the CA's in this list will be trusted # to issue client certificates for authentication. # # In general, you should use self-signed # certificates for 802.1x (EAP) authentication. # In that case, this CA file should contain # *one* CA certificate. Thanks, Dennis From: The EDUCAUSE Wireless Issues Community Group Listserv On Behalf Of Mike Atkins Sent: Wednesday, August 19, 2020 11:51 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca<mailto:ith...@uoguelph.ca> Good clarification, thanks. In previous discussions, our identity group mentioned using PKI that they use for other systems. Note to self, be careful what you ask for. Mike Atkins Network Engineer Office of Information Technology University of Notre Dame From: The EDUCAUSE Wireless Issues Community Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 11:34 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Got it. Just to clarify, a self-signed EAP server certificate should never be used. A server certificate issued by a PKI under your control is the best deployment practice (which is not the same as a self-signed certificate). tim From: Mike Atkins<mailto:matk...@nd.edu> Sent: Wednesday, August 19, 2020 11:31 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Tim, We use the public certificates for users that do not use our onboarding utility. We use a public root certificate that is in pretty much all operating systems. Fortunately or unfortuanately, some operating systems still want to walk the entire chain so we onboard with the root and intermediate. Our information security group had concerns about users just accepting security prompts for certificates. Using a self-signed cert that expires far into the future sounds better each day. Mike Atkins Network Engineer Office of Information Technology University of Notre Dame From: The EDUCAUSE Wireless Issues Community Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 10:38 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? If you’re already onboarding your users, why do you continue to use a public cert? A public EAP server cert should only be used when a “walk-up” enter your username/password experience is desired (of course that’s after your organization has decided that credential exposure is not a concern). Tim From: Mike Atkins<mailto:matk...@nd.edu> Sent: Wednesday, August 19, 2020 10:34 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? We were burnt last December by an updated cert with the same cert chain and still not trusted by some devices/operating systems. We learned documents that referenced changes to the default web browser on an operating system ended up with a modification in the operating system that matched the web browser's changed behavior. I think this is the same experience Christopher is referencing. We ended up having to re-onboard all of our devices at the very last minute. We spent more time than we should have to try to avoid onboarding devices mid-semester when our cert expired. (this happened right around finals of course) Our identity group is buying a cert to test with a month in advance. They then cancel/revoke that cert to get money back and then order the production cert. This is to best ensure we test with the right root/intermediate certificate authorities that will be on our production cert. We still lose about a w
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
Good clarification, thanks. In previous discussions, our identity group mentioned using PKI that they use for other systems. Note to self, be careful what you ask for. *Mike Atkins * Network Engineer Office of Information Technology University of Notre Dame *From:* The EDUCAUSE Wireless Issues Community Group Listserv < WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli *Sent:* Wednesday, August 19, 2020 11:34 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Got it. Just to clarify, a self-signed EAP server certificate should never be used. A server certificate issued by a PKI under your control is the best deployment practice (which is not the same as a self-signed certificate). tim *From: *Mike Atkins *Sent: *Wednesday, August 19, 2020 11:31 *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject: *Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Tim, We use the public certificates for users that do not use our onboarding utility. We use a public root certificate that is in pretty much all operating systems. Fortunately or unfortuanately, some operating systems still want to walk the entire chain so we onboard with the root and intermediate. Our information security group had concerns about users just accepting security prompts for certificates. Using a self-signed cert that expires far into the future sounds better each day. *Mike Atkins * Network Engineer Office of Information Technology University of Notre Dame *From:* The EDUCAUSE Wireless Issues Community Group Listserv < WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli *Sent:* Wednesday, August 19, 2020 10:38 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? If you’re already onboarding your users, why do you continue to use a public cert? A public EAP server cert should only be used when a “walk-up” enter your username/password experience is desired (of course that’s after your organization has decided that credential exposure is not a concern). Tim *From: *Mike Atkins *Sent: *Wednesday, August 19, 2020 10:34 *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject: *Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? We were burnt last December by an updated cert with the same cert chain and still not trusted by some devices/operating systems. We learned documents that referenced changes to the default web browser on an operating system ended up with a modification in the operating system that matched the web browser's changed behavior. I think this is the same experience Christopher is referencing. We ended up having to re-onboard all of our devices at the very last minute. We spent more time than we should have to try to avoid onboarding devices mid-semester when our cert expired. (this happened right around finals of course) Our identity group is buying a cert to test with a month in advance. They then cancel/revoke that cert to get money back and then order the production cert. This is to best ensure we test with the right root/intermediate certificate authorities that will be on our production cert. We still lose about a week on the production cert between testing and install. Ideally, we would keep the yearly cert installation during the summer but time is against us. Mike Atkins Network Engineer Office of Information Technology University of Notre Dame -Original Message- From: The EDUCAUSE Wireless Issues Community Group Listserv On Behalf Of Johnson, Christopher Sent: Wednesday, August 19, 2020 10:07 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? I think it's going to "depend" on each Operating System for the 802.1X authentications being affected. The information below is more of just an FYI on what I've observed (cause I imagine someone's going to say - If I'm going through the trouble of installing a public Root CA that already exists - then why not go ahead and use a Private CA). 1. Apple specifically states "This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS." - so that makes me wonder if you install a public Root CA via a mobile config for example for iOS - does that exempt it from the 1 year limitation then? 2. Chrome OS though (at least from the behavior I've seen) you can't install a public Root that already exists on to the OS. I don't think I would trust those "possible exceptions though". One of the annoying things I felt with Android and Chromebook for certificate management was If I go into the device and "Disable/Turn Off the certificates/Set to Not Use" - then
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
Got it. Just to clarify, a self-signed EAP server certificate should never be used. A server certificate issued by a PKI under your control is the best deployment practice (which is not the same as a self-signed certificate). tim From: Mike Atkins<mailto:matk...@nd.edu> Sent: Wednesday, August 19, 2020 11:31 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Tim, We use the public certificates for users that do not use our onboarding utility. We use a public root certificate that is in pretty much all operating systems. Fortunately or unfortuanately, some operating systems still want to walk the entire chain so we onboard with the root and intermediate. Our information security group had concerns about users just accepting security prompts for certificates. Using a self-signed cert that expires far into the future sounds better each day. Mike Atkins Network Engineer Office of Information Technology University of Notre Dame From: The EDUCAUSE Wireless Issues Community Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tim Cappalli Sent: Wednesday, August 19, 2020 10:38 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? If you’re already onboarding your users, why do you continue to use a public cert? A public EAP server cert should only be used when a “walk-up” enter your username/password experience is desired (of course that’s after your organization has decided that credential exposure is not a concern). Tim From: Mike Atkins<mailto:matk...@nd.edu> Sent: Wednesday, August 19, 2020 10:34 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? We were burnt last December by an updated cert with the same cert chain and still not trusted by some devices/operating systems. We learned documents that referenced changes to the default web browser on an operating system ended up with a modification in the operating system that matched the web browser's changed behavior. I think this is the same experience Christopher is referencing. We ended up having to re-onboard all of our devices at the very last minute. We spent more time than we should have to try to avoid onboarding devices mid-semester when our cert expired. (this happened right around finals of course) Our identity group is buying a cert to test with a month in advance. They then cancel/revoke that cert to get money back and then order the production cert. This is to best ensure we test with the right root/intermediate certificate authorities that will be on our production cert. We still lose about a week on the production cert between testing and install. Ideally, we would keep the yearly cert installation during the summer but time is against us. Mike Atkins Network Engineer Office of Information Technology University of Notre Dame -Original Message- From: The EDUCAUSE Wireless Issues Community Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Johnson, Christopher Sent: Wednesday, August 19, 2020 10:07 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? I think it's going to "depend" on each Operating System for the 802.1X authentications being affected. The information below is more of just an FYI on what I've observed (cause I imagine someone's going to say - If I'm going through the trouble of installing a public Root CA that already exists - then why not go ahead and use a Private CA). 1. Apple specifically states "This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS." - so that makes me wonder if you install a public Root CA via a mobile config for example for iOS - does that exempt it from the 1 year limitation then? 2. Chrome OS though (at least from the behavior I've seen) you can't install a public Root that already exists on to the OS. I don't think I would trust those "possible exceptions though". One of the annoying things I felt with Android and Chromebook for certificate management was If I go into the device and "Disable/Turn Off the certificates/Set to Not Use" - then all portions of the Operating System should not use those certificates regardless. However, from what I saw, even if I disable some of the Public CAs - the wireless supplicant still seems to trust them. Christopher Johnson Wireless Network Engineer Office of Technology Solutions | Illinois State University (309) 438-
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
Tim, We use the public certificates for users that do not use our onboarding utility. We use a public root certificate that is in pretty much all operating systems. Fortunately or unfortuanately, some operating systems still want to walk the entire chain so we onboard with the root and intermediate. Our information security group had concerns about users just accepting security prompts for certificates. Using a self-signed cert that expires far into the future sounds better each day. *Mike Atkins * Network Engineer Office of Information Technology University of Notre Dame *From:* The EDUCAUSE Wireless Issues Community Group Listserv < WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli *Sent:* Wednesday, August 19, 2020 10:38 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? If you’re already onboarding your users, why do you continue to use a public cert? A public EAP server cert should only be used when a “walk-up” enter your username/password experience is desired (of course that’s after your organization has decided that credential exposure is not a concern). Tim *From: *Mike Atkins *Sent: *Wednesday, August 19, 2020 10:34 *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject: *Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? We were burnt last December by an updated cert with the same cert chain and still not trusted by some devices/operating systems. We learned documents that referenced changes to the default web browser on an operating system ended up with a modification in the operating system that matched the web browser's changed behavior. I think this is the same experience Christopher is referencing. We ended up having to re-onboard all of our devices at the very last minute. We spent more time than we should have to try to avoid onboarding devices mid-semester when our cert expired. (this happened right around finals of course) Our identity group is buying a cert to test with a month in advance. They then cancel/revoke that cert to get money back and then order the production cert. This is to best ensure we test with the right root/intermediate certificate authorities that will be on our production cert. We still lose about a week on the production cert between testing and install. Ideally, we would keep the yearly cert installation during the summer but time is against us. Mike Atkins Network Engineer Office of Information Technology University of Notre Dame -Original Message- From: The EDUCAUSE Wireless Issues Community Group Listserv On Behalf Of Johnson, Christopher Sent: Wednesday, August 19, 2020 10:07 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? I think it's going to "depend" on each Operating System for the 802.1X authentications being affected. The information below is more of just an FYI on what I've observed (cause I imagine someone's going to say - If I'm going through the trouble of installing a public Root CA that already exists - then why not go ahead and use a Private CA). 1. Apple specifically states "This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS." - so that makes me wonder if you install a public Root CA via a mobile config for example for iOS - does that exempt it from the 1 year limitation then? 2. Chrome OS though (at least from the behavior I've seen) you can't install a public Root that already exists on to the OS. I don't think I would trust those "possible exceptions though". One of the annoying things I felt with Android and Chromebook for certificate management was If I go into the device and "Disable/Turn Off the certificates/Set to Not Use" - then all portions of the Operating System should not use those certificates regardless. However, from what I saw, even if I disable some of the Public CAs - the wireless supplicant still seems to trust them. Christopher Johnson Wireless Network Engineer Office of Technology Solutions | Illinois State University (309) 438-8444 Stay connected with ISU IT news and tips with @ISU IT Help on Facebook and Twitter -Original Message- From: The EDUCAUSE Wireless Issues Community Group Listserv On Behalf Of Tim Tyler Sent: Wednesday, August 19, 2020 8:45 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? [This message came from an external source. If suspicious, report to ab...@ilstu.edu<mailto:ab...@ilstu.edu >] I was told by Sertigo that all commercial certs would be affected. We just bought the last 2 year expirations we could get away with for both 802.1x and https. The reason I am told has to do with so many smaller esta
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
If you’re already onboarding your users, why do you continue to use a public cert? A public EAP server cert should only be used when a “walk-up” enter your username/password experience is desired (of course that’s after your organization has decided that credential exposure is not a concern). Tim From: Mike Atkins<mailto:matk...@nd.edu> Sent: Wednesday, August 19, 2020 10:34 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? We were burnt last December by an updated cert with the same cert chain and still not trusted by some devices/operating systems. We learned documents that referenced changes to the default web browser on an operating system ended up with a modification in the operating system that matched the web browser's changed behavior. I think this is the same experience Christopher is referencing. We ended up having to re-onboard all of our devices at the very last minute. We spent more time than we should have to try to avoid onboarding devices mid-semester when our cert expired. (this happened right around finals of course) Our identity group is buying a cert to test with a month in advance. They then cancel/revoke that cert to get money back and then order the production cert. This is to best ensure we test with the right root/intermediate certificate authorities that will be on our production cert. We still lose about a week on the production cert between testing and install. Ideally, we would keep the yearly cert installation during the summer but time is against us. Mike Atkins Network Engineer Office of Information Technology University of Notre Dame -Original Message- From: The EDUCAUSE Wireless Issues Community Group Listserv On Behalf Of Johnson, Christopher Sent: Wednesday, August 19, 2020 10:07 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? I think it's going to "depend" on each Operating System for the 802.1X authentications being affected. The information below is more of just an FYI on what I've observed (cause I imagine someone's going to say - If I'm going through the trouble of installing a public Root CA that already exists - then why not go ahead and use a Private CA). 1. Apple specifically states "This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS." - so that makes me wonder if you install a public Root CA via a mobile config for example for iOS - does that exempt it from the 1 year limitation then? 2. Chrome OS though (at least from the behavior I've seen) you can't install a public Root that already exists on to the OS. I don't think I would trust those "possible exceptions though". One of the annoying things I felt with Android and Chromebook for certificate management was If I go into the device and "Disable/Turn Off the certificates/Set to Not Use" - then all portions of the Operating System should not use those certificates regardless. However, from what I saw, even if I disable some of the Public CAs - the wireless supplicant still seems to trust them. Christopher Johnson Wireless Network Engineer Office of Technology Solutions | Illinois State University (309) 438-8444 Stay connected with ISU IT news and tips with @ISU IT Help on Facebook and Twitter -Original Message- From: The EDUCAUSE Wireless Issues Community Group Listserv On Behalf Of Tim Tyler Sent: Wednesday, August 19, 2020 8:45 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? [This message came from an external source. If suspicious, report to ab...@ilstu.edu<mailto:ab...@ilstu.edu>] I was told by Sertigo that all commercial certs would be affected. We just bought the last 2 year expirations we could get away with for both 802.1x and https. The reason I am told has to do with so many smaller establishments that go out of business before their cert expires leaving the cert as a security vulnerability for consumers. I just wish there was a way to allow for the longer certs for those of us that have a long history of existence and stability. Such a pain. And I am told they are debating quarterly cert replacements in the future. That would turn cert management into a much bigger responsibility if that were to happen. Hopefully that doesn’t happen. And yes, if you want to manage EAP with your own self cert, I believe you can use a longer expiration. Tim -Original Message- From: The EDUCAUSE Wireless Issues Community Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Andrew Gallo Sent: Wednesday, August 19, 2020 8:29 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] New certificate expir
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
I think it's going to "depend" on each Operating System for the 802.1X authentications being affected. The information below is more of just an FYI on what I've observed (cause I imagine someone's going to say - If I'm going through the trouble of installing a public Root CA that already exists - then why not go ahead and use a Private CA). 1. Apple specifically states "This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS." - so that makes me wonder if you install a public Root CA via a mobile config for example for iOS - does that exempt it from the 1 year limitation then? 2. Chrome OS though (at least from the behavior I've seen) you can't install a public Root that already exists on to the OS. I don't think I would trust those "possible exceptions though". One of the annoying things I felt with Android and Chromebook for certificate management was If I go into the device and "Disable/Turn Off the certificates/Set to Not Use" - then all portions of the Operating System should not use those certificates regardless. However, from what I saw, even if I disable some of the Public CAs - the wireless supplicant still seems to trust them. Christopher Johnson Wireless Network Engineer Office of Technology Solutions | Illinois State University (309) 438-8444 Stay connected with ISU IT news and tips with @ISU IT Help on Facebook and Twitter -Original Message- From: The EDUCAUSE Wireless Issues Community Group Listserv On Behalf Of Tim Tyler Sent: Wednesday, August 19, 2020 8:45 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? [This message came from an external source. If suspicious, report to ab...@ilstu.edu<mailto:ab...@ilstu.edu>] I was told by Sertigo that all commercial certs would be affected. We just bought the last 2 year expirations we could get away with for both 802.1x and https. The reason I am told has to do with so many smaller establishments that go out of business before their cert expires leaving the cert as a security vulnerability for consumers. I just wish there was a way to allow for the longer certs for those of us that have a long history of existence and stability. Such a pain. And I am told they are debating quarterly cert replacements in the future. That would turn cert management into a much bigger responsibility if that were to happen. Hopefully that doesn’t happen. And yes, if you want to manage EAP with your own self cert, I believe you can use a longer expiration. Tim -Original Message- From: The EDUCAUSE Wireless Issues Community Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Andrew Gallo Sent: Wednesday, August 19, 2020 8:29 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Does anyone know if the new, shorter certificate expiration for TLS that Apple announced (and Google is following) will affect 802.1X authentication? Thanks -- Andrew Gallo The George Washington University ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
Re: [External] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
Every day I am more and more thankful that we migrated off of InCommon for dot1X. We slid right under the door for all this Apple stuff. Life has never been better on our private CA. On Wed, Aug 19, 2020 at 08:42 Andrew Gallo < 01d1fb3cd70a-dmarc-requ...@listserv.educause.edu> wrote: > Thanks Tim- > > Good point on the non-public CA. > > For the record, here's Apple's announcement: > https://support.apple.com/en-us/HT211025 > > I'm also going to ask over on the InCommon cert-users list. > > Thanks > > > > > On 8/19/2020 9:33 AM, Tim Cappalli wrote: > > Google’s announcement was for Chrome so it is not clear whether there > will be a change in Android. > > > > Apple’s announcement is system-wide on macOS and iOS. > > > > But keep in mind it does not apply to non-public CAs, which are the only > trust chains that should be used for EAP. > > > > tim > > > > > > From: The EDUCAUSE Wireless Issues Community Group Listserv on behalf of > Andrew Gallo > > Sent: Wednesday, August 19, 2020 09:28 > > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > > Subject: [WIRELESS-LAN] New certificate expiration for certificates > affecting 802.1X? > > > > Does anyone know if the new, shorter certificate expiration for TLS that > > Apple announced (and Google is following) will affect 802.1X > authentication? > > > > Thanks > > -- > > > > Andrew Gallo > > The George Washington University > > > > > > ** > > Replies to EDUCAUSE Community Group emails are sent to the entire > community list. If you want to reply only to the person who sent the > message, copy and paste their email address and forward the email reply. > Additional participation and subscription information can be found at > https://www.educause.edu/community > > > > ** > > Replies to EDUCAUSE Community Group emails are sent to the entire > community list. If you want to reply only to the person who sent the > message, copy and paste their email address and forward the email reply. > Additional participation and subscription information can be found at > https://www.educause.edu/community > > > > -- > > Andrew Gallo > The George Washington University > > ** > Replies to EDUCAUSE Community Group emails are sent to the entire > community list. If you want to reply only to the person who sent the > message, copy and paste their email address and forward the email reply. > Additional participation and subscription information can be found at > https://www.educause.edu/community > -- -- Hunter Fuller (they) Router Jockey VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
RE: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
I was told by Sertigo that all commercial certs would be affected. We just bought the last 2 year expirations we could get away with for both 802.1x and https. The reason I am told has to do with so many smaller establishments that go out of business before their cert expires leaving the cert as a security vulnerability for consumers. I just wish there was a way to allow for the longer certs for those of us that have a long history of existence and stability. Such a pain. And I am told they are debating quarterly cert replacements in the future. That would turn cert management into a much bigger responsibility if that were to happen. Hopefully that doesn’t happen. And yes, if you want to manage EAP with your own self cert, I believe you can use a longer expiration. Tim -Original Message- From: The EDUCAUSE Wireless Issues Community Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Andrew Gallo Sent: Wednesday, August 19, 2020 8:29 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Does anyone know if the new, shorter certificate expiration for TLS that Apple announced (and Google is following) will affect 802.1X authentication? Thanks -- Andrew Gallo The George Washington University ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?
Google’s announcement was for Chrome so it is not clear whether there will be a change in Android. Apple’s announcement is system-wide on macOS and iOS. But keep in mind it does not apply to non-public CAs, which are the only trust chains that should be used for EAP. tim From: The EDUCAUSE Wireless Issues Community Group Listserv on behalf of Andrew Gallo Sent: Wednesday, August 19, 2020 09:28 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Does anyone know if the new, shorter certificate expiration for TLS that Apple announced (and Google is following) will affect 802.1X authentication? Thanks -- Andrew Gallo The George Washington University ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
