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
>> >>>
>> > 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/.

Reply via email to