Re: [WIRELESS-LAN] eduroam ssid

[Philippe Hanset]

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
www.eduroam.us


> On Jun 20, 2016, at 8:03 PM, Curtis K. Larsen  
> 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 
>> 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:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K.
>>> Larsen
 Sent: Monday, June 20, 2016 5:19 PM
 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
 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 [neil-john...@uiowa.edu]
 Sent: Monday, June 20, 2016 2:52 PM
 To: Curtis K. Larsen
 Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
 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: neil-john...@uiowa.edu
 
 
 
> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen
  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 

RE: 802.11b data rates disabled?

[Osborne, Bruce W (Network Services)]

Add Visio TV to that list. Some of them need 1 & 2  to connect, even though 
they can do 802.11n.

​We are setting our minimum rates to 12 this summer. We had to setup a 
special ap-specific SSID for the manager’s Visio TV ☹

Bruce Osborne
Wireless Engineer
IT Network Services - Wireless

(434) 592-4229

LIBERTY UNIVERSITY
Training Champions for Christ since 1971

From: Samuel Clements [mailto:scleme...@gmail.com]
Sent: Monday, June 20, 2016 11:56 AM
Subject: Re: 802.11b data rates disabled?

I think we've arrived at a point where most 802.11b devices are flat out 
deprecated. I also believe that you're going to run into far more 802.11g 
devices that don't like 1 & 2 being disabled (most notably the Nintendo Wii) 
than you are people that actually expect an 802.11b device to still function. 
Between that, and the significant positive impact to CU that you'll undoubtedly 
get, it's a very timely conversation to be having. Unfortunately, you can't 
rely on your NMS platforms reporting of 802.11b devices since many .11g clients 
will stick further out than what's reasonable using CCK modulation (and showing 
.11b clients). In all instances in recent memory (say, 2 years), I've had the 
number of complaints by disabling .11b data rates be so low as to be background 
noise. Couple the ethernet adapter for the Wii into the equation, and the 
problems are practically nonexistent except in the most corner of cases.
  -Sam

On Mon, Jun 20, 2016 at 10:49 AM, Todd M. Hall 
mailto:t...@msstate.edu>> wrote:
Do you have all of the 802.11b data rates disabled?  If so, how long have they 
been disabled?  Did you have many complaints when you disabled them?  Were 
there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old 
rates. Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

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

RE: 802.11b data rates disabled?

[Osborne, Bruce W (Network Services)]

Really?

Nintendo dropped Wii & DS support & closed the online store in 2014.

​
 
Bruce Osborne
Wireless Engineer
IT Network Services - Wireless
 
(434) 592-4229
 
LIBERTY UNIVERSITY
Training Champions for Christ since 1971


-Original Message-
From: Kanan E Simpson [mailto:kesim...@valdosta.edu] 
Sent: Monday, June 20, 2016 12:03 PM
Subject: Re: 802.11b data rates disabled?

We disabled the 11b rates last summer. For the most part, we didn't have too 
many complaints. The complaints that we received was from the students that own 
the legacy Wii. All though the devices support 11g, it must see the SSID 
broadcasted at a 11b (1mbps) rate in order to connect.  This was the only 
complaint. We no longer support the original Wii.

We also have institutional devices at that are older and only support 11b. For 
these devices, we simply left the 11b rates on for the APs in the area they 
connect. Thankfully, it's only one building. 


Thanks,

Kanan Simpson, CWNA, JNCIA
Network Services Specialist
Information Technology Division
Valdosta State University

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
Sent: Monday, June 20, 2016 11:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] 802.11b data rates disabled?

Do you have all of the 802.11b data rates disabled?  If so, how long have they 
been disabled?  Did you have many complaints when you disabled them?  Were 
there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old 
rates. 
Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

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

RE: [WIRELESS-LAN] Aruba education (was "Aruba Controller code recommendations")

[Chuck Enfield]

Q: Obviously the Controllers have code that gets updated.  Do the AP's also 
get flashed?   Do they get flashed based on the controller code level?

A: Aruba has two roles for controllers.  Local controllers terminate AP 
connections and manage the data plane.  Master controllers provide some 
control plane and coordination functions when multiple local controllers 
cover overlapping or adjacent RF domains.  A master controller, it’s local 
controllers, and all the APs connected to those locals must run the same 
code version.  This is accomplished by upgrading the code on all of the 
controllers, from which the APs will automatically get a code upgrade.



Q: Do you ever get to a point where you cannot flash the controller because 
that code level is not/will not be supported by an older AP?

A: Yes.  We are at that point right now.  We cannot move to AOS 6.5 (just 
released for early deployment) until we replace a couple hundred AP-120’s 
still in our network.  I will point out, however, that AP-120’s came to 
market around 2009, so they’ve had a pretty good run for an AP.



Q: For those of you who have rolled out 5GHz deployments, since the Aruba 
AP's appear to have fixed radios (ie one 2.4GHz and one 5GHz, rather than 
the ability to go with two 5GHz), do you ever find yourself deploying more 
AP's than you'd otherwise like to get a great 5GHz density?

A: Yes, but not very often for now.  For the AP density at which we deploy, 
with the amount of 2.4GHz usage remaining, and for our strategy of getting 
clients onto 5GHz radios, it makes sense to leave 2.4GHz radios enabled on 
most of our APs.  Large auditoriums with overhead AP installations are 
really the only locations we would benefit from having APs with (2) 5GHz 
radios.  For us, that represents a tiny number of APs on a very large 
network.  That said, as 5 GHz spectrum grows and 2.4GHz usage declines this 
will become a greater disadvantage.



Chuck Enfield

Manager, Wireless Systems & Engineering

Telecommunications & Networking Services

The Pennsylvania State University

110H, USB2, UP, PA 16802

ph: 814.863.8715

fx: 814.865.3988



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Helman
Sent: Monday, June 20, 2016 7:54 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Aruba education (was "Aruba Controller code 
recommendations")



I'm going to fork this topic a little.  We are relatively happy with our 
current wireless vendor, but I've been asked to look around to see what else 
is out there.  At the NERCOMP Annual Conference a few months ago, I lead a 
joint NETMAN/WirelessLAN discussion.  I listed the wireless vendors to see 
who was using each.  I did this alphabetically, and was pretty much able to 
stop on the 2nd vendor .. Aruba.  Clearly, it's pretty popular in Higher 
Ed..



So, I have a few questions that I hope will be easy.  Obviously the 
Controllers have code that gets updated.  Do the AP's also get flashed?   Do 
they get flashed based on the controller code level?  Do you ever get to a 
point where you cannot flash the controller because that code level is 
not/will not be supported by an older AP (we've experienced this with our 
management platform, where we had to run 2 instances .. and old and a new .. 
to support older AP's and move forward in supporting new ones).



For those of you who have rolled out 5GHz deployments, since the Aruba AP's 
appear to have fixed radios (ie one 2.4GHz and one 5GHz, rather than the 
ability to go with two 5GHz), do you ever find yourself deploying more AP's 
than you'd otherwise like to get a great 5GHz density?



Thanks!



-Brian



VENDORS: PLEASE DO NOT CALL ME.  I'm gathering info.  I'll make the first 
contact if I decide to move forward.



  _

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Sidharth Nandury 
[nandu...@denison.edu]
Sent: Friday, June 17, 2016 8:28 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 

Subject: Re: [WIRELESS-LAN] Aruba Controller code recommendations

We are running v6.4.3.7 on the controller while running v8.2.0.2 here at 
Denison University. The controller has not had any issues with it and works 
great! While there are no compatibility issues with each other, Airwave has 
had problems recognizing Cisco equipment gear. We have Cisco 2960X and S 
series switches, both 24 and 48 port. Airwave recognizes these switches as 
stack switches and instead of the particular model of switches that they 
actually are. Also, there was the issue of duplicate devices, where when 
scanning the network for devices it would add the device according to the 
MAC address of the device and then also the devices according to the MAC 
address of the management VLAN of the switch.



The code upgrade form 8.2.0.1 to 8.2.0.2 solved the duplicate device issue, 
but we st

RE: 802.11b data rates disabled?

[Kanan E Simpson]

Yes, I know. We still had some students using the Wii to stream Netflix. Maybe 
this fall, they will have new updated devices. :)


Kanan Simpson, CWNA, JNCIA
Network Services Specialist
Information Technology Division
Valdosta State University


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Osborne, Bruce W 
(Network Services)
Sent: Tuesday, June 21, 2016 8:03 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

Really?

Nintendo dropped Wii & DS support & closed the online store in 2014.

​
 
Bruce Osborne
Wireless Engineer
IT Network Services - Wireless
 
(434) 592-4229
 
LIBERTY UNIVERSITY
Training Champions for Christ since 1971


-Original Message-
From: Kanan E Simpson [mailto:kesim...@valdosta.edu] 
Sent: Monday, June 20, 2016 12:03 PM
Subject: Re: 802.11b data rates disabled?

We disabled the 11b rates last summer. For the most part, we didn't have too 
many complaints. The complaints that we received was from the students that own 
the legacy Wii. All though the devices support 11g, it must see the SSID 
broadcasted at a 11b (1mbps) rate in order to connect.  This was the only 
complaint. We no longer support the original Wii.

We also have institutional devices at that are older and only support 11b. For 
these devices, we simply left the 11b rates on for the APs in the area they 
connect. Thankfully, it's only one building. 


Thanks,

Kanan Simpson, CWNA, JNCIA
Network Services Specialist
Information Technology Division
Valdosta State University

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
Sent: Monday, June 20, 2016 11:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] 802.11b data rates disabled?

Do you have all of the 802.11b data rates disabled?  If so, how long have they 
been disabled?  Did you have many complaints when you disabled them?  Were 
there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old 
rates. 
Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

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

Re: [WIRELESS-LAN] eduroam ssid

[Jeffrey D. Sessler]

The decision about the EAP method must be made above and beyond just the 
engineering staff. Just as with other security-related challenges, risk 
management (and an institutions appetite for risk) must be considered. Even 
with the PEAP evil twin, there are a number of mitigation techniques which can 
help, and with those in place, does it still make financial sense to move to 
another EAP in an attempt to mitigate a now low probability exploit? Is their 
evidence of this exploit at your institution? Would an attacker hang out on 
your campus, where the users are mostly low value targets (students), or will 
an attacker hang out at the local Starbucks/Panera or sports arena, where it’s 
far easier to gather information from open guest networks?

Said another way, if moving to say EAP-TLS costs the institution $130,000 a 
year (software, hardware, and staff FTE), what’s the risk exposure over five 
years? Is the $650,000 investment in institution funds to mitigate the PEAP 
problem worth it? Does the change impact user experience for the positive or 
negative? Is it more/less work for user services?

In my opinion, the biggest risk factor we have today is the end-user. MiTM 
attacks are a real possibility, but I’d argue that there is a bigger threat of 
users clicking on “Cats on pianos” malware links…

Jeff

From: "wireless-lan@listserv.educause.edu"  
on behalf of Philippe Hanset 
Reply-To: "wireless-lan@listserv.educause.edu" 

Date: Monday, June 20, 2016 at 6:20 PM
To: "wireless-lan@listserv.educause.edu" 
Subject: Re: [WIRELESS-LAN] eduroam ssid

David,

To clarify,
eduroam is not a standard, but a trust fabric to roam between research and 
education institutions. eduroam requires  IEEE 802.1X (which is a well used 
standard at many institutions for WLAN and sometimes LAN security) to operate 
which in turn can run on multiple different EAP methods. EAP-TTLS, PEAP, 
EAP-TLS, EAP-PWD,… can all be used with eduroam.  All these methods have their 
issues and schools pick them based on what suits them best for their 
requirements and their environment.

Hope this helps,

Philippe
www.eduroam.us


On Jun 20, 2016, at 8:59 PM, Schuette, David 
mailto:schue...@msudenver.edu>> wrote:

Reading everyone comments about edu-roam has me believing it is an old standard 
which needs to be updated for today's security needs.



Sent from my Verizon 4G LTE smartphone


 Original message 
From: "Curtis K. Larsen" 
mailto:curtis.k.lar...@utah.edu>>
Date: 6/20/16 6:04 PM (GMT-07:00)
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] eduroam ssid
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 
> mailto:curtis.k.lar...@utah.edu>>
> 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:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K.
>> Larsen
>> > Sent: Monday, June 20, 2016 

Re: [WIRELESS-LAN] eduroam ssid

[Jeremy Mooney]

How does certificate locking not mitigate the PEAP issue?

Why make CAT optional? A couple well-placed configuration points (private
CA, requiring anonymous outer identity) can effectively make it necessary
to setup for most users. Yes they may still try, but they could do that
with PEAP totally disabled too. In either case, if they can't connect and
are pushed to the proper setup.

Although whether eduroam or SchoolSSID, turning off PEAP on the
infrastructure doesn't seem to address the vulnerability. The whole issue
is someone setting up an alternate AP, and that AP isn't going to disable
PEAP just because your infrastructure does.


On Mon, Jun 20, 2016 at 7:03 PM, Curtis K. Larsen 
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 <
> curtis.k.lar...@utah.edu>
> > 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:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K.
> >> Larsen
> >> > Sent: Monday, June 20, 2016 5:19 PM
> >> > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> >> > 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 [neil-john...@uiowa.edu]
> >> > Sent: Monday, June 20, 2016 2:52 PM
> >> > To: Curtis K. Larsen
> >> > Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> >> > 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: neil-john...@uiowa.edu
> >> >
> >> >
> >> >
> >> >> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen
> >> >  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 t

Re: [WIRELESS-LAN] eduroam ssid

[Jeremy Mooney]

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 
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  > 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 <
> curtis.k.lar...@utah.edu> 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:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K.
>> Larsen
>> > Sent: Monday, June 20, 2016 5:19 PM
>> > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> > 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 [neil-john...@uiowa.edu]
>> > Sent: Monday, June 20, 2016 2:52 PM
>> > To: Curtis K. Larsen
>> > Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> > 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: neil-john...@uiowa.edu
>> >
>> >
>> >
>> >> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen
>> >  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 g

Re: [WIRELESS-LAN] eduroam ssid

[Jeremy Mooney]

This is actually the config we use. We also pair it with a private CA to
work around the OSes where CAT can only set a CA trust rather than CA and
hostname pair.

There are a couple minor issues we've worked around:
1. A phone wouldn't send a separate outer identity. We also allowed a
username@share-identity. outer identity to workaround. On the third
RMA of the hardware it started using the outer identity properly, so I'm
thinking this is actually some weird bug.
2. Windows uses the same @realm for inner and outer identity. Just be aware
of this when picking the outer identity and documenting for users (our CAT
page lists to use @domain.edu for the Windows downloads).

The only OSes we've seen as an issue have been the ones which can't support
PEAP securely (see https://wiki.geant.org/x/MAB_AQ). For those the config
fails anyways, and we recommend they use other options until they upgrade
to something more modern (the problematic ones are long past vendor support
at this point).


On Tue, Jun 21, 2016 at 5: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
> www.eduroam.us
>
>
> > On Jun 20, 2016, at 8:03 PM, Curtis K. Larsen 
> 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 <
> curtis.k.lar...@utah.edu>
> >> 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:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K.
> >>> Larsen
>  Sent: Monday, June 20, 2016 5:19 PM
>  To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>  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 ed

RE: 802.11b data rates disabled?

[Rick . Decaro]

Thanks for the info everyone.   We are going to keep our minimum at 54Mbps 
right now and see what happens.   We will do another quick survey to find any 
coverage gaps that may have cropped up as a result of the change.

The main reason for our change is to increase performance in our classrooms 
where we have 125 students in a small space.  We have 2 AP's in each of these 
rooms and so far the change to 54Mbps has helped from what we can tell.

Rick DeCaro
(636)230-1911
rick.dec...@logan.edu


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Anthony Croome
Sent: Monday, June 20, 2016 11:06 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

Exactly, use 24Mbs to avoid weird behaviour.

We looked at this a few years ago and found that XP could not handle management 
packets being sent at 48Mb/s or 54Mb/s despite the card connecting at 450Mb/s 
on 5GHz N or 144Mb/s on 2.4GHz N.

On 5GHz the laptop could get an IP address but could not ping it's gateway.
On 2.4GHz the laptop could get an IP, it could ping it's gateway, but it's 
performance was terrible.

What we saw from a 5GHz packet capture was the AP continuously sending RTS to 
the client but never getting any packets from the client.  On 2.4GHz it would 
reply but only after a random number of RTS were sent.  

Anthony
IT Networks
Queensland University of Australia

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jason Cook
Sent: Tuesday, 21 June 2016 11:20 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

Yeah my understanding is that as per the standard devices are 
required(mandatory) to support 6,12,24 rates for 802.11g. So to ensure all 
devices are happy then 24 would be the right minimum, therefore you may see 
some weird behaviour.  So devices need to support that to be compliant, I'm not 
sure it means you have to use it. I'd say if your running 54 and there's no 
complaints why change.  it will be interesting to see how things go. 


We disabled 802.11b rates about 3 months back with no issues reported. We've 
left it enabled in some of our remote campuses where we use lower rates to get 
distance. 



--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005 Ph    : +61 8 8313 4800

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Chuck Enfield
Sent: Tuesday, 21 June 2016 6:21 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

Rick,

If I were brave enough to do what you've done, here's what I would worry
about:

- 802.11a/g devices are getting scarce, but I've heard rumors that there were 
802.11g devices that required a basic rate of 6, 12, or 24 Mb/s.
It's possible that there are no such devices left, that driver updates have 
eliminated the limitation, or that no such devices ever existed.
- Many client device drivers do unexpected things when connected to networks 
with unconventional settings.  For example, will clients with a marginal MCS 7 
connection probe for their next AP before their retry rate goes through the 
roof?
- We use 40Mhz channels, so reliable comm at MCS 7 requires about 28 dB SNR.  
It could be very difficult to maintain that while moving.
- Even if clients roam successfully, you'll see an increase in roaming 
activity.  Moving clients may normally hit every second or third AP along the 
way, in your case they'll probably hit every AP.  This could increase the 
overhead consumed by authentication and/or stress your AAA infrastructure.  
That said, the AAA load could be more than offset by reduced authentication 
attempts to indoor APs from outdoor passers-by.

I'm not suggesting these are reasons not to do it.  They're just things I'd 
worry about.  I'd be interested in hearing how it works out for you if you find 
the time to follow up.  

Thanks,

Chuck

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Rick.Decaro
Sent: Monday, June 20, 2016 2:10 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

It sound like a lot of people have already disabled the 802.11b data
rates.   That being saidwhat minimum rate is everyone using?  

We just changed ours last week from a minimum of 1Mbps to 54Mbps.   So far
we have not heard of any issues.Does anyone know what if any problems
could arise from this being set to 54Mbps?   Is there a sweet spot in
between that is better? 

Thanks,

Rick DeCaro
(636)230-1911
rick.dec...@logan.edu


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent 

Re: [WIRELESS-LAN] eduroam ssid

[Curtis K. Larsen]

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
> www.eduroam.us
>
>
>> On Jun 20, 2016, at 8:03 PM, Curtis K. Larsen  
>> 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 
>>> 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:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K.
 Larsen
> Sent: Monday, June 20, 2016 5:19 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> 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 [neil-john...@uiowa.edu]
> Sent: Monday, June 20, 2016 2:52 PM
> To: Curtis K. Larsen
> Cc:

RE: [WIRELESS-LAN] eduroam ssid

[Turner, Ryan H]

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

r...@unc.edu
+1 919 445 0113 Office
+1 919 274 7926 Mobile



-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K. Larsen
Sent: Tuesday, June 21, 2016 11:49 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
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  
>> 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 
>>> 
>>> wrote:
>>>
 It's done on the RADIUS server

Re: [WIRELESS-LAN] eduroam ssid

[Curtis K. Larsen]

The key phrase there being ..."on properly setup clients".  Which implies that 
there exists
improperly setup clients.  In many cases there are more improperly setup than 
properly setup.

Thanks,

Curtis

On Tue, June 21, 2016 8:58 am, Jeremy Mooney wrote:
> 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 
> 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 > > 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 <
>> curtis.k.lar...@utah.edu> 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:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K.
>>> Larsen
>>> > Sent: Monday, June 20, 2016 5:19 PM
>>> > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>>> > 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 [neil-john...@uiowa.edu]
>>> > Sent: Monday, June 20, 2016 2:52 PM
>>> > To: Curtis K. Larsen
>>> > Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>>> > 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: neil-john...@uiowa.edu
>>> >
>>> >
>>> >
>>> >> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen
>>> >  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 allo

Re: [WIRELESS-LAN] 802.11b data rates disabled?

[Frank Sweetser]

Hey, I remember that bug! Or at least a very similar one.

There were a wide range of centrino chipsets with a driver bug.  Specifically, 
the driver would advertise 3 stream data rates, even though the hardware 
itself was only 2 stream.  This meant that the card could *usually* process 
broadcast packets, as they get sent at the greatest common denominator speed 
of all associated stations, so could get an IP address and ARP, but any 
unicast traffic would get sent at a data rate the client hardware couldn't 
decode and disappeared.  The fix was to get a new driver from Intel, as MS 
update was shipping buggy drivers for a very, very long time.


The fact that the client getting an IP address depended on the data rates of 
other clients on the same AP made troubleshooting nearly impossible, until we 
got lucky and Trapeze identified it as a known bug.


Frank Sweetser fs at wpi.edu|  For every problem, there is a solution that
Manager of Network Operations   |  is simple, elegant, and wrong.
Worcester Polytechnic Institute |   - HL Mencken

On 6/21/2016 12:06 AM, Anthony Croome wrote:

Exactly, use 24Mbs to avoid weird behaviour.

We looked at this a few years ago and found that XP could not handle management 
packets being sent at 48Mb/s or 54Mb/s despite the card connecting at 450Mb/s 
on 5GHz N or 144Mb/s on 2.4GHz N.

On 5GHz the laptop could get an IP address but could not ping it's gateway.
On 2.4GHz the laptop could get an IP, it could ping it's gateway, but it's 
performance was terrible.

What we saw from a 5GHz packet capture was the AP continuously sending RTS to 
the client but never getting any packets from the client.  On 2.4GHz it would 
reply but only after a random number of RTS were sent.

Anthony
IT Networks
Queensland University of Australia

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jason Cook
Sent: Tuesday, 21 June 2016 11:20 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

Yeah my understanding is that as per the standard devices are 
required(mandatory) to support 6,12,24 rates for 802.11g. So to ensure all 
devices are happy then 24 would be the right minimum, therefore you may see 
some weird behaviour.  So devices need to support that to be compliant, I'm not 
sure it means you have to use it. I'd say if your running 54 and there's no 
complaints why change.  it will be interesting to see how things go.


We disabled 802.11b rates about 3 months back with no issues reported. We've 
left it enabled in some of our remote campuses where we use lower rates to get 
distance.



--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Chuck Enfield
Sent: Tuesday, 21 June 2016 6:21 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

Rick,

If I were brave enough to do what you've done, here's what I would worry
about:

- 802.11a/g devices are getting scarce, but I've heard rumors that there were 
802.11g devices that required a basic rate of 6, 12, or 24 Mb/s.
It's possible that there are no such devices left, that driver updates have 
eliminated the limitation, or that no such devices ever existed.
- Many client device drivers do unexpected things when connected to networks 
with unconventional settings.  For example, will clients with a marginal MCS 7 
connection probe for their next AP before their retry rate goes through the 
roof?
- We use 40Mhz channels, so reliable comm at MCS 7 requires about 28 dB SNR.  
It could be very difficult to maintain that while moving.
- Even if clients roam successfully, you'll see an increase in roaming 
activity.  Moving clients may normally hit every second or third AP along the 
way, in your case they'll probably hit every AP.  This could increase the 
overhead consumed by authentication and/or stress your AAA infrastructure.  
That said, the AAA load could be more than offset by reduced authentication 
attempts to indoor APs from outdoor passers-by.

I'm not suggesting these are reasons not to do it.  They're just things I'd 
worry about.  I'd be interested in hearing how it works out for you if you find 
the time to follow up.

Thanks,

Chuck

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Rick.Decaro
Sent: Monday, June 20, 2016 2:10 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

It sound like a lot of people have already disabled the 802.11b data
rates.   That being saidwhat minimum rate is everyone using?

We just changed ours last week from a minimum of 1Mbps to 54Mbps.   So far
we

RE: [WIRELESS-LAN] Wi-Fiber experince

[Kent A Cummings]

Try wifiber.net


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jason Watts
Sent: Friday, June 17, 2016 6:17 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Wi-Fiber experince


So the spec sheet on that site mentions 2Gbps over 802.11N 2x2 MIMO.

Nope.

Unfortunately that looks like vaporware or a  site designed to look like a real 
product until you read it.

The WiFiber SmartSecurity paper talks about motion detecting IP cameras and the 
next bullet mentions his these same cameras can be used to share moments with 
family and friends.

It's like someone took data sheets from five different products that are not 
wireless backhaul and smooshed them together.

I wouldn't care if the in-person pitch was perfect, if I saw that website I 
would run away.

If it IS wireless backhaul you're shopping for then there are plenty of decent 
products including the aforementioned Airfiber from Ubiquiti.


Sent from my iPhone

On Jun 17, 2016, at 3:01 AM, Davidoff, Michel 
mailto:mdavid...@calstate.edu>> wrote:
How about Wi-Fiber 



Michel Davidoff
Director CyberInfrastructure
California State University, Chancellor's Office
Tel  562 951 8419
Cell 707 481 1084

It is amazing what we can achieve together when nobody cares who gets the credit



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
mailto:WIRELESS-LAN@listserv.educause.edu>> 
on behalf of Jeremy Gibbs mailto:jlgi...@utica.edu>>
Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv 
mailto:WIRELESS-LAN@listserv.educause.edu>>
Date: Thursday, June 16, 2016 at 6:51 PM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
mailto:WIRELESS-LAN@listserv.educause.edu>>
Subject: Re: [WIRELESS-LAN] Wi-Fiber experince

You know, I needed a laugh today and someone delivered, thanks!

In all seriousness, are you referring to Ubiquiti 
Airfiber?


--

Jeremy L. Gibbs
Sr. Network Engineer
Utica College IITS

T: (315) 223-2383
F: (315) 792-3814
E: jlgi...@utica.edu
http://www.utica.edu

On Thu, Jun 16, 2016 at 9:40 PM, Samuel Clements 
mailto:scleme...@gmail.com>> wrote:
802.11bh ?

This email sent from a mobile computing device. Please excuse typos and brevity.

On Jun 16, 2016, at 8:25 PM, Jeremy Gibbs 
mailto:jlgi...@utica.edu>> wrote:
Yup, googled it and came up with Wisconsin Sheep and Wool 
Festival.  I don't think that's 
right..


--

Jeremy L. Gibbs
Sr. Network Engineer
Utica College IITS

T: (315) 223-2383
F: (315) 792-3814
E: jlgi...@utica.edu
http://www.utica.edu

On Thu, Jun 16, 2016 at 6:36 PM, Jason Watts 
mailto:jwa...@pratt.edu>> wrote:

That doesn't appear to be a real website

On 6/16/2016 4:19 PM, Davidoff, Michel wrote:
I would like to know if you have heard or if you are using products from 
wi-fiber.com for inside or outside deployment.



Michel Davidoff
Director CyberInfrastructure
California State University, Chancellor's Office
Tel  562 951 8419
Cell 707 481 1084

We all work better when we work together!


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

Re: [WIRELESS-LAN] 802.11b data rates disabled?

[James Andrewartha]

On 21/06/16 12:06, Anthony Croome wrote:
> Exactly, use 24Mbs to avoid weird behaviour.
> 
> We looked at this a few years ago and found that XP could not handle 
> management packets being sent at 48Mb/s or 54Mb/s despite the card connecting 
> at 450Mb/s on 5GHz N or 144Mb/s on 2.4GHz N.
> 
> On 5GHz the laptop could get an IP address but could not ping it's gateway.
> On 2.4GHz the laptop could get an IP, it could ping it's gateway, but it's 
> performance was terrible.
> 
> What we saw from a 5GHz packet capture was the AP continuously sending RTS to 
> the client but never getting any packets from the client.  On 2.4GHz it would 
> reply but only after a random number of RTS were sent.  

I saw a similar situation recently, a new laptop with an Intel AC
chipset was sending continuous RTS at 2Mbps (on 2.4GHz), however the AP
was configured with an 11g protection rate of 11Mbps. Setting that to
2Mbps and the client could talk fine.

-- 
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

Re: [WIRELESS-LAN] 802.11b data rates disabled?

[Jake Snyder]

With mandatory rates, the higher you go the more issues you can see and the 
advantages of more airtime suffer diminishing returns.  Since the lowest 
mandatory is where control frames get sent, it can have some pretty serious 
impact.  Pushing higher than 24 should be done with some good airtime analysis 
that most controllers won't give you. When you watch Mac laptops spam control 
frames like RTS and BAR at 6Mbps and it go unack'd from the AP because of data 
rates, things can go sideways pretty fast.  For more resiliency, keeping lower 
OFDM rates enabled helps clients with poor supplicants have good experiences.

And most NMS and controllers can't see the issues because the AP isn't 
registering the frames sent at unsupported rates.  This leads to performance 
issues that you probably won't see and are hard to quantify.

Trimming DSSS and HR-DSSS rates (1,2,5.5,11) are a good idea if you can, but I 
would advise getting crazy trimming rates beyond that.

My general recommendation is 12Mbps as minimum in 2.4GHz and 6 as the minimum 
for 5GHz.  This is a reasonable starting place with good overall device 
compatibility.  Obviously in LPV and stadiums are exceptions to this advise.

Thanks
Jake Snyder


Sent from my iPhone

> On Jun 21, 2016, at 7:44 PM, James Andrewartha  
> wrote:
> 
>> On 21/06/16 12:06, Anthony Croome wrote:
>> Exactly, use 24Mbs to avoid weird behaviour.
>> 
>> We looked at this a few years ago and found that XP could not handle 
>> management packets being sent at 48Mb/s or 54Mb/s despite the card 
>> connecting at 450Mb/s on 5GHz N or 144Mb/s on 2.4GHz N.
>> 
>> On 5GHz the laptop could get an IP address but could not ping it's gateway.
>> On 2.4GHz the laptop could get an IP, it could ping it's gateway, but it's 
>> performance was terrible.
>> 
>> What we saw from a 5GHz packet capture was the AP continuously sending RTS 
>> to the client but never getting any packets from the client.  On 2.4GHz it 
>> would reply but only after a random number of RTS were sent.  
> 
> I saw a similar situation recently, a new laptop with an Intel AC
> chipset was sending continuous RTS at 2Mbps (on 2.4GHz), however the AP
> was configured with an 11g protection rate of 11Mbps. Setting that to
> 2Mbps and the client could talk fine.
> 
> -- 
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
> 
> **
> 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/.