Exactly. Once you've done that, you've effectively mitigated the attack on properly setup clients.
On Mon, Jun 20, 2016 at 6:42 PM, Philippe Hanset <[email protected]> wrote: > Jeremy, > > > You can still help your users with PEAP (and that will help at remote > locations or on campus as well) by forcing them to on-board their original > eduroam config via an installer (e.g. CAT or a commercial one). > With Operating Systems using profiles you can lock the config so that > users won’t be able to authenticate if the RADIUS infrastructure > certificate is incorrect (case of MiTM attacks). > Now, if the user has the ability to delete the installed profile and to > manually join eduroam there is nothing to prevent that. > > This “locking” mechanism of the infrastructure certificate is a feature > of automatic installers that network operators tend to overlook. > We often have eduroam operators telling us that they don’t need to use CAT > (cat.eduroam.org, it’s free!) since OSes are doing such a good job at > prompting users > for credentials. True, but those same OSes are not good at preventing MiTM > attacks. > > Philippe > www.eduroam.us > > > > On Jun 20, 2016, at 7:19 PM, Jeremy Mooney <[email protected] > <[email protected]>> 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 >> >>> >> > http://www.educause.edu/groups/< >> https://na01.safelinks.protection.outlook. >> > 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 >> > http://www.educause.edu/groups/. >> >>> >> >>> >> >> >> >> ********** >> >> Participation and subscription information for this EDUCAUSE >> Constituent >> > Group discussion list can be found at http://www.educause.edu/groups/. >> > >> > >> > ********** >> > Participation and subscription information for this EDUCAUSE Constituent >> > Group discussion list can be found at http://www.educause.edu/groups/. >> > >> > ********** >> > Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can >> > be found at http://www.educause.edu/groups/. >> > >> >> ********** >> Participation and subscription information for this EDUCAUSE Constituent >> Group discussion list can be found at http://www.educause.edu/groups/. >> > > > > -- > Jeremy Mooney > ITS - Bethel University > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > -- Jeremy Mooney ITS - Bethel University ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
