I am glad this conversation has come up. We adopted TLS several years ago as our EAP method, and I often get blank stares from people when I espouse the evils of using a username/password in any EAP method. Especially for folks that use TTLS. We've seen first place how easy it is to play man in the middle and collect usernames and passwords from improperly configured clients. Really dangerous, especially at a conference like educause that may run the eduroam SSID and have a lot of higher ranking officials running around with improperly configured devices (that don't verify servers or check certs).
Ryan Turner Manager of Network Operations ITS Communication Technologies The University of North Carolina at Chapel Hill [email protected] +1 919 445 0113 Office +1 919 274 7926 Mobile -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Curtis K. Larsen Sent: Tuesday, June 21, 2016 11:49 AM To: [email protected] Subject: Re: [WIRELESS-LAN] eduroam ssid Philippe, I agree with you that EAP-TLS is by far the best way to avoid Evil Twin attacks. I also think your suggestion here is a very clever improvement for PEAP for many eduroam admins. Since eduroam is almost synonymous with the "secure wireless network" at most institutions, I think whomever maintains the compliance document (from 2011) you referred to earlier should be careful to gradually update the security recommendations, and at some point turn them into best practices. The one you just mentioned would be a great start. I think there are too many users out there connecting to the "secure" wireless network not realizing it could be the most likely place for their username and password to be stolen. Thanks, Curtis On Tue, June 21, 2016 4:25 am, Philippe Hanset wrote: > Curtis, > > Your comments made me think of a work around to make PEAP a little better > with CAT! > > Indeed EAP-TLS is by far the best way to avoid MiTM attacks, but for > institutions not willing to deal with EAP-TLS (cost of installer > etc…), Here is what one can do with CAT to promote the usage of the installer: > > In the CAT installer you can specify a fixed outer-identity (same for > everyone) either of anonymous@realm or *****@realm (***** being a long > string…but be careful some OSes do not accept this, but they all > accept anonymous) You can then configure your home RADIUS server to > only accept requests of the form anonymous@realm or *****@realm and not > accept username@realm. > > Users trying to configure manually will not succeed and will have to > use the CAT tool and be configured properly with a locked infrastructure > certificate. > > Some crafty people might end up guessing the outer identity (by > sniffing packets), but hopefully those ones are smart enough to know not to > accept evil twins RADIUS certs. > > This is not 100%, but it can definitely help! > > Philippe > https://na01.safelinks.protection.outlook.com/?url=www.eduroam.us&data > =01%7c01%7crhturner%40email.unc.edu%7cc02cbbfb497c4001aca108d399ebc263 > %7c58b3d54f16c942d3af081fcabd095666%7c1&sdata=jfL6Ox%2f0z0mc1Y%2b%2fR6 > gIj4HT0MEvxWYEWyIq7NkPovA%3d > > >> On Jun 20, 2016, at 8:03 PM, Curtis K. Larsen <[email protected]> >> wrote: >> >> The PEAP vulnerability is only mitigated by requiring EAP-TLS and >> disabling PEAP. (It may help a little to recommend the CAT tool or >> similar, but not much) We've recommended similar tools for >> 9 >> years - I know the take rates - they aren't great. Why? Because it is >> optional. >> >> All I am pointing out is that one cannot say that they have >> completely mitigated 100% the PEAP vulnerability while still running >> eduroam. I can say that for my primary SSID. >> >> Thanks, >> >> Curtis >> >> >> On Mon, June 20, 2016 5:19 pm, Jeremy Mooney wrote: >>> How would you plan to mitigate for your users at remote institutions >>> if they're not verifying the certificate? It seems you can only >>> prevent at at the IdP side of your radius infrastructure, and your >>> clients can only trust they're talking to that server by verifying >>> the certificate. If they don't verify the certificate, anyone can >>> claim to be your server and just allow PEAP without you ever seeing >>> the traffic. Technically that's also the case locally (someone else >>> stands up an AP) and you could at most maybe see it happened but not >>> block it (at least without going into the legal minefield of active rogue >>> mitigation). >>> >>> I'd think that the best you can hope for (without solving the >>> problem of users falling for phishing/MitM in general) is just only >>> allowing EAP-TLS so any client with a working config for your >>> institution won't use PEAP, but that doesn't require blocking PEAP on the >>> SP side. >>> >>> >>> On Mon, Jun 20, 2016 at 5:00 PM, Curtis K. Larsen >>> <[email protected]> >>> wrote: >>> >>>> It's done on the RADIUS server, that's kind of my point. You have >>>> a service in your environment that may pose risk to some and you >>>> can't control it. >>>> >>>> I can mitigate the PEAP vulnerability for our users on campus, and >>>> our users at remote institutions, but I cannot mitigate that same >>>> vulnerability for another institutions' users on my campus. >>>> >>>> -Curtis >>>> >>>> >>>> On Mon, June 20, 2016 3:50 pm, Chuck Enfield wrote: >>>>> How would you disable PEAP on the eduroam SSID? I've never >>>>> noticed a setting for that. >>>>> >>>>> -----Original Message----- >>>>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv >>>>> [mailto:[email protected]] On Behalf Of Curtis K. >>>> Larsen >>>>> Sent: Monday, June 20, 2016 5:19 PM >>>>> To: [email protected] >>>>> Subject: Re: [WIRELESS-LAN] eduroam ssid >>>>> >>>>> Yes it does work. That's the problem - PEAP is vulnerable to Evil >>>>> Twin attacks so we are disabling PEAP. Doing that on eduroam >>>>> would break all institutions that still offer it. Leaving it >>>>> enabled exposes users at >>>> our >>>>> institution. >>>>> >>>>> -Curtis >>>>> >>>>> ________________________________________ >>>>> From: Johnson, Neil M [[email protected]] >>>>> Sent: Monday, June 20, 2016 2:52 PM >>>>> To: Curtis K. Larsen >>>>> Cc: [email protected] >>>>> Subject: Re: [WIRELESS-LAN] eduroam ssid >>>>> >>>>> eduroam should work with just about any authentication method that >>>>> uses EAP (PEAP,TLS,TTLS) etc. >>>>> >>>>> So if your are say moving to TLS (Client certificates) it should >>>>> still just work. >>>>> >>>>> -Neil >>>>> >>>>> -- >>>>> Neil Johnson >>>>> Network Engineer >>>>> The University of Iowa >>>>> Phone: 319 384-0938 >>>>> Fax: 319 335-2951 >>>>> E-Mail: [email protected] >>>>> >>>>> >>>>> >>>>>> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen >>>>> <[email protected]> wrote: >>>>>> >>>>>> We're beginning to run into this problem as well. Luckily, >>>>>> eduroam is not our primary SSID so at least the critical business >>>>>> functions continue to work fine on a separate SSID. My guess is >>>>>> that we'll end up >>>>> turning eduroam off at those remote locations if problems get reported. >>>>>> >>>>>> In talking with the eduroam admin from the other institution they >>>>>> mentioned that when this occurs in Europe the solution has been >>>>>> to change the name of the SSID. Is this really allowed? If so, >>>>>> I'm sold! Then we can start using our primary SSID with eduroam >>>>>> credentials! This is what I always thought eduroam should have been. >>>>>> To me the value was always in the universal credential >>>>>> *NOT* the SSID name. That was always a drawback for me >>>>>> especially as supplicants become easier to configure. >>>>>> >>>>>> The other problem that we're going to run into soon is that we >>>>>> will be phasing out PEAP on our main SSID to mitigate against the >>>>>> evil twin vulnerability, but what do we do with eduroam? I mean >>>>>> I guess you could say it is the remote institution's problem, or >>>>>> the user's problem if they connect to an evil twin on your campus >>>>>> because they're not validating the server. But if the evil twin >>>>>> is on your campus it >>>>> seems you have at least some responsibility in the matter. But as >>>>> it stands, eduroam will leave a bit of a gaping security hole for us. >>>>>> >>>>>> -- >>>>>> Curtis K. Larsen >>>>>> Senior Network Engineer >>>>>> University of Utah IT/CIS >>>>>> >>>>>> >>>>>> >>>>>> On Fri, June 17, 2016 7:35 am, Turner, Ryan H wrote: >>>>>>> Yes. We have a satellite school at UNC Asheville. Up until >>>>>>> recently, UNC Asheville was not running eduroam, and UNC Chapel >>>>>>> Hill >>>>> was the only occupant of a couple of buildings on campus. >>>>>>> UNC Asheville adopted eduroam and wanted to move into adjoining spaces. >>>>> So we were going to have >>>>>>> the situation where UNC Chapel Hill folks might attach to the >>>>>>> wrong institution's eduroam and vice versa. We ended up >>>>>>> bridging the two networks together through a single link, and >>>>>>> based on realm, UNC Asheville will terminate UNC Chapel Hill >>>>>>> folks directly to our network (through trunked vlans). It is >>>>>>> nice, because now anywhere on UNC Asheville campus, UNC Chapel >>>>>>> Hill folks have UNC Chapel Hill IP >>>>> space. Because it made sense, we actually turned off our access >>>>> points and allowed UNC Asheville to provide wireless in our areas >>>>> (so we >>>> wouldn't >>>>> have competing wireless). >>>>>>> >>>>>>> >>>>>>> Ryan Turner >>>>>>> Manager of Network Operations >>>>>>> ITS Communication Technologies >>>>>>> The University of North Carolina at Chapel Hill >>>>>>> >>>>>>> [email protected]<mailto:[email protected]> >>>>>>> +1 919 445 0113 Office >>>>>>> +1 919 274 7926 Mobile >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv >>>>>>> [mailto:[email protected]] On Behalf Of Becker, >>>>>>> Jason >>>>>>> Sent: Thursday, June 16, 2016 11:45 PM >>>>>>> To: [email protected] >>>>>>> Subject: [WIRELESS-LAN] eduroam ssid >>>>>>> >>>>>>> Has anyone ran into this situation. >>>>>>> >>>>>>> We are an eduroam participating school and have multiple >>>>>>> buildings that are either across the road or sometimes sidewalk >>>>>>> that another University owns. The other school is wanting to >>>>>>> join eduroam so my issue is when we are both broadcasting the >>>>>>> same ssid in possibly the same airspace. I have a felling this >>>>>>> is going to cause many problems >>>>> as clients could bounce back and forth between systems. >>>>>>> >>>>>>> If you had to deal with this I like to hear your thoughts on it. >>>>>>> >>>>>>> -- >>>>>>> Thanks, >>>>>>> Jason Becker >>>>>>> Network Systems Engineer >>>>>>> Washington University in St. Louis >>>>>>> [email protected]<mailto:[email protected]> >>>>>>> 314-935-5006 >>>>>>> ********** Participation and subscription information for this >>>>>>> EDUCAUSE Constituent Group discussion list can be found at >>>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fww >>>>> w.educause.edu%2fgroups%2f&data=01%7c01%7crhturner%40email.unc.edu >>>>> %7cc02cbbfb497c4001aca108d399ebc263%7c58b3d54f16c942d3af081fcabd09 >>>>> 5666%7c1&sdata=RB2AK7q%2f3LVSyaILYvzTBfzaKcMWCs%2f9PVD3OdX7Zcs%3d< >>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fna01.safelinks.protection.outlook&data=01%7c01%7crhturner%40email.unc.edu%7cc02cbbfb497c4001aca108d399ebc263%7c58b3d54f16c942d3af081fcabd095666%7c1&sdata=Hy8cfZN4ZZv%2fiQMMBn85V9Qcjy8UwNZBhP5uoHP25pQ%3d. >>>>> com/?url=http%3a%2f%2fwww.educause.edu >>>> %2fgroups%2f&data=01%7c01%7crhturner >>>>> %40email.unc.edu >>>> %7ccb70500b292d4427293208d39661db4b%7c58b3d54f16c942d3af08 >>>>> 1fcabd095666%7c1&sdata=qGNRUEHsNMv7sMBIsc4xSekkNTdOESCI%2fPCz87RzRZY%3d>. >>>>>>> >>>>>>> ********** >>>>>>> Participation and subscription information for this EDUCAUSE >>>>>>> Constituent Group discussion list can be found at >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.educause.edu%2fgroups%2f&data=01%7c01%7crhturner%40email.unc.edu%7cc02cbbfb497c4001aca108d399ebc263%7c58b3d54f16c942d3af081fcabd095666%7c1&sdata=RB2AK7q%2f3LVSyaILYvzTBfzaKcMWCs%2f9PVD3OdX7Zcs%3d. >>>>>>> >>>>>>> >>>>>> >>>>>> ********** >>>>>> Participation and subscription information for this EDUCAUSE >>>>>> Constituent >>>>> Group discussion list can be found at >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.educause.edu%2fgroups%2f&data=01%7c01%7crhturner%40email.unc.edu%7cc02cbbfb497c4001aca108d399ebc263%7c58b3d54f16c942d3af081fcabd095666%7c1&sdata=RB2AK7q%2f3LVSyaILYvzTBfzaKcMWCs%2f9PVD3OdX7Zcs%3d. >>>>> >>>>> >>>>> ********** >>>>> Participation and subscription information for this EDUCAUSE >>>>> Constituent Group discussion list can be found at >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.educause.edu%2fgroups%2f&data=01%7c01%7crhturner%40email.unc.edu%7cc02cbbfb497c4001aca108d399ebc263%7c58b3d54f16c942d3af081fcabd095666%7c1&sdata=RB2AK7q%2f3LVSyaILYvzTBfzaKcMWCs%2f9PVD3OdX7Zcs%3d. >>>>> >>>>> ********** >>>>> Participation and subscription information for this EDUCAUSE >>>>> Constituent >>>> Group discussion list can >>>>> be found at >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.educause.edu%2fgroups%2f&data=01%7c01%7crhturner%40email.unc.edu%7cc02cbbfb497c4001aca108d399ebc263%7c58b3d54f16c942d3af081fcabd095666%7c1&sdata=RB2AK7q%2f3LVSyaILYvzTBfzaKcMWCs%2f9PVD3OdX7Zcs%3d. >>>>> >>>> >>>> ********** >>>> Participation and subscription information for this EDUCAUSE >>>> Constituent Group discussion list can be found at >>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.educause.edu%2fgroups%2f&data=01%7c01%7crhturner%40email.unc.edu%7cc02cbbfb497c4001aca108d399ebc263%7c58b3d54f16c942d3af081fcabd095666%7c1&sdata=RB2AK7q%2f3LVSyaILYvzTBfzaKcMWCs%2f9PVD3OdX7Zcs%3d. >>>> >>> >>> >>> >>> -- >>> Jeremy Mooney >>> ITS - Bethel University >>> >> >> ********** >> Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found at >> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.educause.edu%2fgroups%2f&data=01%7c01%7crhturner%40email.unc.edu%7cc02cbbfb497c4001aca108d399ebc263%7c58b3d54f16c942d3af081fcabd095666%7c1&sdata=RB2AK7q%2f3LVSyaILYvzTBfzaKcMWCs%2f9PVD3OdX7Zcs%3d. > > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.educause.edu%2fgroups%2f&data=01%7c01%7crhturner%40email.unc.edu%7cc02cbbfb497c4001aca108d399ebc263%7c58b3d54f16c942d3af081fcabd095666%7c1&sdata=RB2AK7q%2f3LVSyaILYvzTBfzaKcMWCs%2f9PVD3OdX7Zcs%3d. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
