The problem with this statement:
EAP-PEAP/EAP-TTLS, if properly onboarded, are very secure. But the
problem is ‘properly onboarded’.
… is that even having PEAP or EAP-TTLS enabled on the network exposes you to
risk regardless of the supplicant configuration as anyone can attempt to
connect using PEAP, putting their creds at risk.
Secure solution = EAP-TLS only.
Also, did you mean EAP-TTLS here? > any institution that is running EAP-TLS
with PAP
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
<[email protected]> on behalf of "Turner, Ryan H"
<[email protected]>
Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv
<[email protected]>
Date: Tuesday, July 25, 2017 at 11:53 AM
To: "[email protected]" <[email protected]>
Subject: Re: [WIRELESS-LAN] EAP-PEAP risk/benefit assessment
There are flaws with every mechanism. We are a long time EAP-TLS shop.
In a university environment, access is rarely as difficult thing. There are
many buildings and methods for motivated individuals to get access. Most of us
actually provide some level of access to guests, already. In short, university
defenses for network access are weak, often by design. For us, the issue
really isn’t about access to the network. It is, however, about access to
credentials. With all other ‘normal’ widely adopted methods out there, you are
setting individuals up to expose their credentials to MitM. With TLS, even if
someone exports a cert, all that next person has is network access. They don’t
have credentials.
Put another way, any institution that is running EAP-TLS with PAP (using this
configuration because it is the easiest), I would be willing to make a large
bet that I could drive to your campus, sit outside your main administrative
building, and I could have some tasty usernames and passwords in short order.
It requires no hacking (because I’m not a hacker). Other methods like PEAP are
definitely much more difficult, but not outside of the range of a hacker IF the
client didn’t onboard their device properly. And many people won’t onboard
properly with a username/password method because it is easier just to punch
those in upon connection.
EAP-PEAP/EAP-TTLS, if properly onboarded, are very secure. But the problem is
‘properly onboarded’.
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 Thomas Carter
Sent: Wednesday, July 12, 2017 1:20 PM
To: [email protected]
Subject: Re: [WIRELESS-LAN] EAP-PEAP risk/benefit assessment
Depending on the setup and purpose, the certs could be exported and shared to
people/devices not intended; it may be assumed that will not happen.
Thomas Carter
Network & Operations Manager / IT
Austin College
900 North Grand Avenue
Sherman, TX 75090
Phone: 903-813-2564
www.austincollege.edu<http://www.austincollege.edu/>
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:[email protected]] On Behalf Of Cappalli, Tim (Aruba
Security)
Sent: Wednesday, July 12, 2017 10:33 AM
To:
[email protected]<mailto:[email protected]>
Subject: Re: [WIRELESS-LAN] EAP-PEAP risk/benefit assessment
I’m curious about “…certs may give a false sense of security and identity”. Can
you elaborate on that?
Tim
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
<[email protected]<mailto:[email protected]>>
on behalf of Thomas Carter
<[email protected]<mailto:[email protected]>>
Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv
<[email protected]<mailto:[email protected]>>
Date: Wednesday, July 12, 2017 at 11:22 AM
To:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: Re: [WIRELESS-LAN] EAP-PEAP risk/benefit assessment
We use mac address auth (using Packetfence) for this reason. On-boarding is
easy (there’s even a mac self-registration portal for devices that don’t
understand the captive portal on connecting) through a captive portal, and the
kids are used to captive portals at Starbucks/Target/McDonalds already . We
formerly used Bradford Networks (long story, but we had some major issues with
them) using a certificate based solution, and our opening of school support has
gone from lines out the door of IT to almost nothing. While mac spoofing is a
thing, EAP/PEAP/certs may give a false sense of security and identity. In a
past life in the corporate world we did a PEAP solution with locked down
certificates, but we tightly controlled all the end-points as well (only
corporate owned devices allowed on the corp network).
Thomas Carter
Network & Operations Manager / IT
Austin College
900 North Grand Avenue
Sherman, TX 75090
Phone: 903-813-2564
www.austincollege.edu<http://www.austincollege.edu/>
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:[email protected]] On Behalf Of Tim Tyler
Sent: Tuesday, July 11, 2017 10:17 AM
To:
[email protected]<mailto:[email protected]>
Subject: Re: [WIRELESS-LAN] EAP-PEAP risk/benefit assessment
I think this is an excellent topic that has made me wonder. Given that so many
users don’t secure their radius client profile, I have often thought mac
address authentication might be a better option, but it would require a
convenient registration method. If someone uses a man in the middle attack
against a mac address, the consequences are minimal. If someone does it
against usernames and password, they likely will have access to their other
accounts as well. If people can on-board a full PEAP with certificate lock
down solution, then it is the best. But if many of your clients are not
getting the cert loaded and the client dependent on it, then it makes me wonder
if mac address authentication isn’t better in the bigger picture of things.
I am still using PEAP, but I am constantly thinking about mac address
authentication.
Tim
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Jonathan Waldrep
Sent: Tuesday, July 11, 2017 9:58 AM
To:
[email protected]<mailto:[email protected]>
Subject: Re: [WIRELESS-LAN] EAP-PEAP risk/benefit assessment
We acknowledged that many users are going to connect without using an
on-boarding tool, and almost no one is going to secure their wireless profile
manually. This leaves these users (on *all* platforms) open to a radius
impersonation attack. Given this, we require a different password for network
access.
It's worth making a note of our security and business models (slightly over
simplified, but sufficient for this topic). We treat ourselves as an ISP to our
users. Everyone gets online with the same level of access. Our systems are
secured at the server level. Guests self-register to access the network for a
limited time.
All this means that getting someone's network credentials means very little. If
someone were doing something especially nefarious, using someone else's
credentials would make it more difficult for us to find them. However, the
attacker doesn't gain access to the compromised user's financial records,
email, or anything else.
--
Jonathan Waldrep
Network Engineer
Network Infrastructure and Services
Virginia Tech
On Mon, Jul 10, 2017 at 8:24 PM, Mike King
<[email protected]<mailto:[email protected]>> wrote:
Marcelo,
If windows 7 is just 4%, what is your highest percentage? Windows 10, or
something else?
On Mon, Jul 10, 2017 at 5:36 PM, Marcelo Maraboli
<[email protected]<mailto:[email protected]>> wrote:
Hello David
we did this last month and "secured" PEAP by minimizing the risk in Windows 7
clients.
We used this guide and it worked very well.
http://www.defenceindepth.net/2010/05/attacking-and-securing-peap.html
We did not use "step 4" because it didn't leave the user ID in our AAA,
they were all "anonymous".
We also studied every operating system that connected to our WIFI and
found out that Windows-7 is just 4%, so we hope this problem will die on
it's own. Windows 10 can use PAP-TTLS, even though that is another deal.
hope it helps.
best regards,
On 7/10/17 3:55 PM, LaPorte, David wrote:
I was wondering if anyone has done a risk/benefit assessment of using EAP-PEAP
in your environment. If so, would you be willing to share? We have a solid
understanding of the security/usability tradeoffs that come with PEAP, but were
hoping to not re-invent the wheel :)
Thanks,
Dave
David LaPorte
[email protected]<mailto:[email protected]>
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/discuss.
--
Marcelo Maraboli Rosselott
Subdirector de Redes y Seguridad
Dirección de Informática
Pontificia Universidad Católica de Chile
http://informatica.uc.cl/
--
Campus San Joaquín, Av. Vicuña Mackenna 4860, Macul
Santiago, Chile
Teléfono: (56) 22354 1341
********** Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/discuss.
********** Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/discuss.
********** Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/discuss.
********** Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/discuss.
********** Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/discuss.
********** Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/discuss.
********** Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/discuss.
********** Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/discuss.
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/discuss.
