Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Philippe Hanset]

At least with carriers you will know for sure that you have not expectation of 
privacy. 

> http://clark.com/technology/how-opt-out-verizons-super-cookie-tracking/



>  Apr 28, 2017, at 8:12 PM, Jeffrey D. Sessler  wrote:
> 
> Philippe,
>  
> This statement, “each user that uses eduroam has a verified affiliation with 
> a University/College somewhere in the world” while sort of true, is also 
> meaningless. They are numerous universities out there that grant identities 
> to anyone in their local community for the sake of services like the library 
> and wireless.  There is certainly a loose affiliation, but that in no way 
> means the university has vetted that person or would attest to anything more 
> than they filled out a form i.e. the fact that they have credentials doesn’t 
> in any way add to the “eduroam is vastly superior” claim.
>  
> Trust – Sure, we need to trust each other, and that’s why we have mechanisms 
> to do so such as federation. That’s only one part of the trust, and in the 
> case of eduroam, what requirements are there concerning how client data will 
> be handled as it terminates and transverses a participating college’s 
> network? A campus is free to record all activity, from DNS records, URLs, 
> flows, etc. And that’s the rub with eduroam. A member of my community has 
> knowledge of our AUP and what we collect as part of normal network operation. 
> When they auto-roam to another campus’ eduroam, there is no disclosure as to 
> how it operates. The user falsely assumes it’s the same as the home campus.
>  
> As for Passpoint/HT2.0, with its wider adoption, it will be interesting to 
> see if universities accomplish this via eduroam or/and via affiliations with 
> existing cellular or network providers, especially if there is a way to 
> monetize the university’s wifi network. I’d rather get paid by Verizon for 
> allowing a student’s Verizon cell phone access to our network, then to 
> provide that service for free via eduroam.
>  
> Jeff
>  
> From: "wireless-lan@listserv.educause.edu" 
>  on behalf of Philippe Hanset 
> 
> Reply-To: "wireless-lan@listserv.educause.edu" 
> 
> Date: Friday, April 28, 2017 at 2:51 PM
> To: "wireless-lan@listserv.educause.edu" 
> Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>  
>  
> On Apr 28, 2017, at 3:49 PM, Jeffrey D. Sessler  
> wrote:
>  
> Philippe,
>  
> I’m not arguing the “convenience factor” or OTA encryption, which eduroam 
> certainly provides, just that users (and universities advocating for it) 
> shouldn’t blindly trust it any more, or less, than any other guest network. 
>  
>  
> Jeff,
>  
> eduroam is authenticated and each user that uses eduroam has a verified 
> affiliation with a University/College somewhere in the world. Each NRO signs 
> an agreement, and each NRO makes
> each school agree to RADIUS logs holding and other privacy features. How is 
> this “little behind it”?
>  
> eduroam is vastly superior to other guest networks, unless you require direct 
> identification with an ID at the help desk to join Wi-Fi (and even IDs can be 
> very fake).
>  
> The same way that schools trust other directory services with Shibboleth or 
> even transcripts, at one point we have to rely on the fact that other members 
> of our community are on a acceptable standard
> that we can relate to make our lives easier and save time for all of us.
>  
> We do not ask schools to make it the primary SSID, most decide that it makes 
> more sense. It is simpler to make users be ready to travel and reduces SSID 
> confusion.
> As I mentioned earlier, users still need to me reminded that eduroam allows 
> them to connect around the world. Having eduroam as the main SSID is not 
> sufficient.
>  
> Having a local secure SSID is still very useful especially when there are 
> potential eduroam conflicts due to schools’ proximity.
> But this will soon be a moot point when Passpoint/HT2.0 becomes predominant.
> You will be able to welcome many roaming communities on your network and even 
> set your own preference for your clients to avoid
> "SSID conflicts" when same SSIDs advertised by different locations conflict 
> with each other (the client will always prefer the network from its own 
> school)
>  
> Philippe
>  
>  
>  
>  
>  
>  
>  
> 
> 
>  
> You touch on my concern with this statement, “Most Schools tend to give more 
> privileges/bandwidth to eduroam because it is acommunity of trust.” 
>  
> eduroam should in no way be considered “…a community of trust” as there is 
> little behind it to guarantee as such. In promoting it across EDUs, and 
> making it the primary SSID, universities are certainly making it appear as if 
> it is to those using it, but it’s an illusion. No matter how it’s painted, at 
> the end of the day it’s 

Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Jeffrey D. Sessler]

Philippe,

This statement, “each user that uses eduroam has a verified affiliation with a 
University/College somewhere in the world” while sort of true, is also 
meaningless. They are numerous universities out there that grant identities to 
anyone in their local community for the sake of services like the library and 
wireless.  There is certainly a loose affiliation, but that in no way means the 
university has vetted that person or would attest to anything more than they 
filled out a form i.e. the fact that they have credentials doesn’t in any way 
add to the “eduroam is vastly superior” claim.

Trust – Sure, we need to trust each other, and that’s why we have mechanisms to 
do so such as federation. That’s only one part of the trust, and in the case of 
eduroam, what requirements are there concerning how client data will be handled 
as it terminates and transverses a participating college’s network? A campus is 
free to record all activity, from DNS records, URLs, flows, etc. And that’s the 
rub with eduroam. A member of my community has knowledge of our AUP and what we 
collect as part of normal network operation. When they auto-roam to another 
campus’ eduroam, there is no disclosure as to how it operates. The user falsely 
assumes it’s the same as the home campus.

As for Passpoint/HT2.0, with its wider adoption, it will be interesting to see 
if universities accomplish this via eduroam or/and via affiliations with 
existing cellular or network providers, especially if there is a way to 
monetize the university’s wifi network. I’d rather get paid by Verizon for 
allowing a student’s Verizon cell phone access to our network, then to provide 
that service for free via eduroam.

Jeff

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

Date: Friday, April 28, 2017 at 2:51 PM
To: "wireless-lan@listserv.educause.edu" 
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)


On Apr 28, 2017, at 3:49 PM, Jeffrey D. Sessler 
> wrote:

Philippe,

I’m not arguing the “convenience factor” or OTA encryption, which eduroam 
certainly provides, just that users (and universities advocating for it) 
shouldn’t blindly trust it any more, or less, than any other guest network.


Jeff,

eduroam is authenticated and each user that uses eduroam has a verified 
affiliation with a University/College somewhere in the world. Each NRO signs an 
agreement, and each NRO makes
each school agree to RADIUS logs holding and other privacy features. How is 
this “little behind it”?

eduroam is vastly superior to other guest networks, unless you require direct 
identification with an ID at the help desk to join Wi-Fi (and even IDs can be 
very fake).

The same way that schools trust other directory services with Shibboleth or 
even transcripts, at one point we have to rely on the fact that other members 
of our community are on a acceptable standard
that we can relate to make our lives easier and save time for all of us.

We do not ask schools to make it the primary SSID, most decide that it makes 
more sense. It is simpler to make users be ready to travel and reduces SSID 
confusion.
As I mentioned earlier, users still need to me reminded that eduroam allows 
them to connect around the world. Having eduroam as the main SSID is not 
sufficient.

Having a local secure SSID is still very useful especially when there are 
potential eduroam conflicts due to schools’ proximity.
But this will soon be a moot point when Passpoint/HT2.0 becomes predominant.
You will be able to welcome many roaming communities on your network and even 
set your own preference for your clients to avoid
"SSID conflicts" when same SSIDs advertised by different locations conflict 
with each other (the client will always prefer the network from its own school)

Philippe










You touch on my concern with this statement, “Most Schools tend to give more 
privileges/bandwidth to eduroam because it is acommunity of trust.”

eduroam should in no way be considered “…a community of trust” as there is 
little behind it to guarantee as such. In promoting it across EDUs, and making 
it the primary SSID, universities are certainly making it appear as if it is to 
those using it, but it’s an illusion. No matter how it’s painted, at the end of 
the day it’s still an unregulated, multi-ISP, guest network.

I’m not arguing against broadcasting eduroam (which my campus does), or its 
convenience for guests, just don’t hold it up as something it’s not.

Jeff


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

Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Philippe Hanset]

Curtis et al.,

You can mitigate the PEAP/EAP-TTLS password issue by using an installer.

In the case of CAT (cat.eduroam.org , free to eduroam 
connectors), a profile will be created that will lock the infrastructure 
certificate.
If a user is presented with a fake eduroam SSID, nothing will happen, no 
certificate option will be presented.

You can push the privacy and security one step further by enforcing the outer 
identity as anonymous@domain (an option in the CAT installer).
Then in your RADIUS only accept outer identities of the form anonymous@domain 
for your school (probably only available in FreeRADIUS and RADIATOR). This will 
give privacy for your users when they travel
and also prevent them from entering manually their own credentials, unless they 
can manually configure their 802.1X supplicant with the outer identity of 
anonymous@domain.
At this point, it is a user trying to be hacked ;-)

Also, even EAP-TLS doesn’t prevent a user from manually selecting an evil twin 
SSID.
If a user from a school is not configured for an SSID at all on an EAP-TLS 
campus and decides to manually select an SSID,
that user will be prompted for username and password. If that SSID is an evil 
twin, credentials will be captured. 
We have seen at UTK all kinds of passwords coming by on our valid 
WPA2-enterprise SSIDs, including  Google and others.
Check your RADIUS logs, it’s amazing!

Even with EAP-TLS, a good amount of education, every year, is still the best!

Philippe





> On Apr 28, 2017, at 4:16 PM, Curtis K. Larsen  
> wrote:
> 
> It matters to your PEAP user that might lose his credentials while connecting 
> to our network on our property even though he was told it was a "secure" 
> connection.  I'm talking about preventing the attack to the degree possible 
> by not providing a service that incorporates the vulnerable component in the 
> first place.  
> 
> I'm simply saying that before we added eduroam to our collection of ESSID's - 
> we did not have to worry about that specific issue because we controlled the 
> whole service end-to-end.  We've been running eduroam for like 5-6 years but 
> with that eduroam ESSID - there are additional ramifications.  Yes an EAP-TLS 
> issue could arise but if/when it does I can change all of the service 
> (including the EAP type used) for my own ESSID where my reach only extends so 
> far with eduroam.
> 
> Also, 5-6 years ago I was not aware of a non-eduroam method to allow guests 
> to quickly provision for EAP-TLS, but now I am.  It is easy to provision 
> guests off the street with EAP-TLS connections today and I can reach a much 
> larger portion of the population than has eduroam credentials (at least so 
> far).
> 
> Thanks,
> 
> Curtis
> 
> 
> 
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
>  on behalf of Hunter Fuller 
> 
> Sent: Friday, April 28, 2017 12:39 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
> 
> Curtis,
> 
> That makes sense. But, if a user set up an evil twin on your campus, it would 
> not matter, because you are using EAP-TLS, right? So you're not vulnerable to 
> the attack where a user's credentials might be exposed.
> 
> If they wanted to exploit some other flaw that can be exploited via evil 
> twin, they could still do it to your branded network.
> 
> It is also possible that I am totally misinformed on this, because we run 
> PEAP, so it's a totally different beast with different mitigations.
> 
> On Fri, Apr 28, 2017 at 10:17 AM Curtis K. Larsen 
> > wrote:
> I guess it boils down to an attacker being less likely to setup a fake 
> AP/evil twin on the property of an institution that does not support PEAP vs. 
> one that does.
> 
> -Curtis
> 
> 
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> >
>  on behalf of Hunter Fuller >
> Sent: Friday, April 28, 2017 8:51 AM
> To: 
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
> 
> I'm still not sure I follow.
> 
> It sounds like, in your current config, you have your constituents use 
> EAP-TLS, and cannot use PEAP. Meanwhile your visitors use whatever their home 
> institution offers.
> 
> If you ran with only the eduroam ESSID, you could run with the same config. 
> Your constituents are unable to use PEAP, and must use EAP-TLS home and 
> abroad. At the same time, your visitors continue to use whatever their home 
> institution offers. This is a viable config.
> 
> I understand keeping two ESSIDs for branding though of course. 

Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Philippe Hanset]

> On Apr 28, 2017, at 3:49 PM, Jeffrey D. Sessler  
> wrote:
> 
> Philippe,
>  
> I’m not arguing the “convenience factor” or OTA encryption, which eduroam 
> certainly provides, just that users (and universities advocating for it) 
> shouldn’t blindly trust it any more, or less, than any other guest network. 


Jeff,

eduroam is authenticated and each user that uses eduroam has a verified 
affiliation with a University/College somewhere in the world. Each NRO signs an 
agreement, and each NRO makes
each school agree to RADIUS logs holding and other privacy features. How is 
this “little behind it”?

eduroam is vastly superior to other guest networks, unless you require direct 
identification with an ID at the help desk to join Wi-Fi (and even IDs can be 
very fake).

The same way that schools trust other directory services with Shibboleth or 
even transcripts, at one point we have to rely on the fact that other members 
of our community are on a acceptable standard
that we can relate to make our lives easier and save time for all of us.

We do not ask schools to make it the primary SSID, most decide that it makes 
more sense. It is simpler to make users be ready to travel and reduces SSID 
confusion.
As I mentioned earlier, users still need to me reminded that eduroam allows 
them to connect around the world. Having eduroam as the main SSID is not 
sufficient.

Having a local secure SSID is still very useful especially when there are 
potential eduroam conflicts due to schools’ proximity.
But this will soon be a moot point when Passpoint/HT2.0 becomes predominant.
You will be able to welcome many roaming communities on your network and even 
set your own preference for your clients to avoid
"SSID conflicts" when same SSIDs advertised by different locations conflict 
with each other (the client will always prefer the network from its own school)

Philippe








>  
> You touch on my concern with this statement, “Most Schools tend to give more 
> privileges/bandwidth to eduroam because it is acommunity of trust.” 
>  
> eduroam should in no way be considered “…a community of trust” as there is 
> little behind it to guarantee as such. In promoting it across EDUs, and 
> making it the primary SSID, universities are certainly making it appear as if 
> it is to those using it, but it’s an illusion. No matter how it’s painted, at 
> the end of the day it’s still an unregulated, multi-ISP, guest network.
>  
> I’m not arguing against broadcasting eduroam (which my campus does), or its 
> convenience for guests, just don’t hold it up as something it’s not.
>  
> Jeff
>  
>  
> From: "wireless-lan@listserv.educause.edu 
> " 
>  > on behalf of Philippe Hanset 
> >
> Reply-To: "wireless-lan@listserv.educause.edu 
> " 
>  >
> Date: Friday, April 28, 2017 at 11:14 AM
> To: "wireless-lan@listserv.educause.edu 
> " 
>  >
> Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>  
>  
> Jeff,
> 
> 
>  
> Why do I say this?
> · Organization - A university can’t assume and/or guarantee that 
> “eduroam” is administered at another campus in the same way that it is at 
> home. There is no guarantee of privacy, be it the data collected during 
> authentication/authorization, or information being sent/received by the 
> client while traversing the other organization’s network. There is no 
> guarantee user data won’t be sold, studied, or otherwise used as the 
> organization terminating the client’s connection sees fit. eduroam is a name 
> only. 
> · User – Assumption that “eduroam” away from their home campus is the 
> same as “eduroam” at another organization. Assumption that there is the same 
> level of data security, privacy, or other safeguards/guarantees as provided 
> at home. Assumption that the same resources are available. Assumption 
> “eduroam’ out in the world is superior than connecting to an open network.
>  
>  
> Connecting to eduroam is superior to connecting to an open network for at 
> least 4 reasons:
> (other may add to the pile)
>  
> 1-No wasted time “hunting” for an SSID that who knows what it is in a list 
> that is larger every day (especially for Urban Campuses)
> 2 -If the network is accepting your RADIUS infrastructure certificate, you 
> know that you are on a trusted network part of a community
>(I will send another email to respond to the MiTM attack on PEAP and 
> EAP-TTLS…use the CAT tool to mitigate that, or EAP-TLS if you can afford it)
> 3-Encryption over the air as part of WPA2-enterprise for guests as a great 

Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Curtis K. Larsen]

It matters to your PEAP user that might lose his credentials while connecting 
to our network on our property even though he was told it was a "secure" 
connection.  I'm talking about preventing the attack to the degree possible by 
not providing a service that incorporates the vulnerable component in the first 
place.  

I'm simply saying that before we added eduroam to our collection of ESSID's - 
we did not have to worry about that specific issue because we controlled the 
whole service end-to-end.  We've been running eduroam for like 5-6 years but 
with that eduroam ESSID - there are additional ramifications.  Yes an EAP-TLS 
issue could arise but if/when it does I can change all of the service 
(including the EAP type used) for my own ESSID where my reach only extends so 
far with eduroam.

Also, 5-6 years ago I was not aware of a non-eduroam method to allow guests to 
quickly provision for EAP-TLS, but now I am.  It is easy to provision guests 
off the street with EAP-TLS connections today and I can reach a much larger 
portion of the population than has eduroam credentials (at least so far).

Thanks,

Curtis



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Hunter Fuller 
Sent: Friday, April 28, 2017 12:39 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Curtis,

That makes sense. But, if a user set up an evil twin on your campus, it would 
not matter, because you are using EAP-TLS, right? So you're not vulnerable to 
the attack where a user's credentials might be exposed.

If they wanted to exploit some other flaw that can be exploited via evil twin, 
they could still do it to your branded network.

It is also possible that I am totally misinformed on this, because we run PEAP, 
so it's a totally different beast with different mitigations.

On Fri, Apr 28, 2017 at 10:17 AM Curtis K. Larsen 
> wrote:
I guess it boils down to an attacker being less likely to setup a fake AP/evil 
twin on the property of an institution that does not support PEAP vs. one that 
does.

-Curtis


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> 
on behalf of Hunter Fuller >
Sent: Friday, April 28, 2017 8:51 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

I'm still not sure I follow.

It sounds like, in your current config, you have your constituents use EAP-TLS, 
and cannot use PEAP. Meanwhile your visitors use whatever their home 
institution offers.

If you ran with only the eduroam ESSID, you could run with the same config. 
Your constituents are unable to use PEAP, and must use EAP-TLS home and abroad. 
At the same time, your visitors continue to use whatever their home institution 
offers. This is a viable config.

I understand keeping two ESSIDs for branding though of course. We were lucky as 
we didn't have branded ESSIDs before eduroam either. So it was no loss to move 
to eduroam.

On Fri, Apr 28, 2017 at 09:41 Curtis K. Larsen 
>>
 wrote:
My point is not that eduroam mandates a given EAP type.  My point is that if a 
given EAP type presents a vulnerability to users that will come into my 
institution's property but I allow it anyway so that another institution's 
configuration will be compatible - then I have surrendered a better security 
stance to facilitate that compatibility.  This is because the SSID is the same.

On the other hand, if I have a unique university SSID - I can easily choose the 
EAP type and thus mitigate the vulnerability more fully - this is now easy to 
do with various onboarding tools.  With HS 2.0 the roaming agreements can still 
be in place and we don't care about the SSID.  To me that sounds like the best 
of both worlds.

-Curtis


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
>>
 on behalf of Cappalli, Tim (Aruba Security) 
>>
Sent: Friday, April 28, 2017 3:54 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Can you elaborate on this comment?

“whereas with eduroam we 

Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Hunter Fuller]

Curtis,

That makes sense. But, if a user set up an evil twin on your campus, it
would not matter, because you are using EAP-TLS, right? So you're not
vulnerable to the attack where a user's credentials might be exposed.

If they wanted to exploit some other flaw that can be exploited via evil
twin, they could still do it to your branded network.

It is also possible that I am totally misinformed on this, because we run
PEAP, so it's a totally different beast with different mitigations.

On Fri, Apr 28, 2017 at 10:17 AM Curtis K. Larsen 
wrote:

> I guess it boils down to an attacker being less likely to setup a fake
> AP/evil twin on the property of an institution that does not support PEAP
> vs. one that does.
>
> -Curtis
>
> 
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Hunter Fuller <
> hf0...@uah.edu>
> Sent: Friday, April 28, 2017 8:51 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>
> I'm still not sure I follow.
>
> It sounds like, in your current config, you have your constituents use
> EAP-TLS, and cannot use PEAP. Meanwhile your visitors use whatever their
> home institution offers.
>
> If you ran with only the eduroam ESSID, you could run with the same
> config. Your constituents are unable to use PEAP, and must use EAP-TLS home
> and abroad. At the same time, your visitors continue to use whatever their
> home institution offers. This is a viable config.
>
> I understand keeping two ESSIDs for branding though of course. We were
> lucky as we didn't have branded ESSIDs before eduroam either. So it was no
> loss to move to eduroam.
>
> On Fri, Apr 28, 2017 at 09:41 Curtis K. Larsen  > wrote:
> My point is not that eduroam mandates a given EAP type.  My point is that
> if a given EAP type presents a vulnerability to users that will come into
> my institution's property but I allow it anyway so that another
> institution's configuration will be compatible - then I have surrendered a
> better security stance to facilitate that compatibility.  This is because
> the SSID is the same.
>
> On the other hand, if I have a unique university SSID - I can easily
> choose the EAP type and thus mitigate the vulnerability more fully - this
> is now easy to do with various onboarding tools.  With HS 2.0 the roaming
> agreements can still be in place and we don't care about the SSID.  To me
> that sounds like the best of both worlds.
>
> -Curtis
>
> 
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> on behalf of Cappalli, Tim (Aruba
> Security) >
> Sent: Friday, April 28, 2017 3:54 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>
> Can you elaborate on this comment?
>
> “whereas with eduroam we were kind of locked-in to the PEAP model.”
>
> Eduroam is EAP agnostic.
>
>
>
>
> On 4/27/17, 10:57 PM, "The EDUCAUSE Wireless Issues Constituent Group
> Listserv on behalf of Curtis K. Larsen" <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of curtis.k.lar...@utah.edu
> > wrote:
>
> We also use eduroam and a university SSID and one benefit I've seen is
> that when our CISO decided to deprecate PEAP due to the "fake AP/MITM -
> exposed password" issue and favor EAP-TLS - we could easily control our own
> destiny with our own SSID whereas with eduroam we were kind of locked-in to
> the PEAP model.  Lesser security will often result when universal
> compatibility is the goal.  I mean we could force our own users to use
> EAP-TLS at home and abroad but in my opinion we could not truly say that
> we've done everything possible to mitigate the PEAP vulnerability while
> still propping up a PEAP SSID org-wide even if PEAP only ends up being used
> by visitors.
>
> We currently offer long-term EAP-TLS connections on our university
> SSID to any guest willing to provide an SMS number (Cloudpath Feature).  It
> turns out that the SMS-capable phone carrying population is much larger
> than those with eduroam credentials so far, and phone numbers are possibly
> more valuable to administrators than AD credentials of participating
> institutions in resolving issues.  In my opinion, as onboarding solutions
> mature the SSID becomes less important, and who knows maybe with Hotspot
> 2.0 completely irrelevant?  Something to consider at least when making that
> decision anyway.
>
> --
> Curtis K. Larsen
> Senior Network Engineer
> University of Utah IT/CIS
> Office 801-587-1313 <(801)%20587-1313>
>
> 

Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Philippe Hanset]

Jeff,

>  
> Why do I say this?
> · Organization - A university can’t assume and/or guarantee that 
> “eduroam” is administered at another campus in the same way that it is at 
> home. There is no guarantee of privacy, be it the data collected during 
> authentication/authorization, or information being sent/received by the 
> client while traversing the other organization’s network. There is no 
> guarantee user data won’t be sold, studied, or otherwise used as the 
> organization terminating the client’s connection sees fit. eduroam is a name 
> only. 
> · User – Assumption that “eduroam” away from their home campus is the 
> same as “eduroam” at another organization. Assumption that there is the same 
> level of data security, privacy, or other safeguards/guarantees as provided 
> at home. Assumption that the same resources are available. Assumption 
> “eduroam’ out in the world is superior than connecting to an open network.


Connecting to eduroam is superior to connecting to an open network for at least 
4 reasons:
(other may add to the pile)

1-No wasted time “hunting” for an SSID that who knows what it is in a list that 
is larger every day (especially for Urban Campuses)
2 -If the network is accepting your RADIUS infrastructure certificate, you know 
that you are on a trusted network part of a community
   (I will send another email to respond to the MiTM attack on PEAP and 
EAP-TTLS…use the CAT tool to mitigate that, or EAP-TLS if you can afford it)
3-Encryption over the air as part of WPA2-enterprise for guests as a great side 
effect
4-The local school knows that if needed, the user can be found (infected 
machine, abuse, DMCA, etc…)

I agree that all eduroam networks are not equal, but neither are Open Networks. 
It is in the end a guest experience.
I actually have the same with my cellular network… sometimes it is LTE or 4G, 
sometimes 3G with very little capacity, even though
it always references the same carrier and I pay the same!
It is our job as Network Operators to inform our users that there is no 
guarantee of service 

Most Schools tend to give more privileges/bandwidth to eduroam because it is a 
community of trust.
So, in most cases you will experience a better experience that classic Open 
Guest Networks.


>  
> Certainly, some of the data privacy pieces could be mitigated by using a 
> home-campus VPN while traveling, but now you are creating rules that the 
> end-user must remember. These rules become confusing when you are in an area 
> with multiple organizations all broadcasting “eduroam”, where to simplify the 
> user experience i.e. they can get to the same resources, the default becomes 
> using VPN all the time. Once you force the use of a VPN, then is “eduroam” 
> any different than using an open/suest networ
> I would prefer to see “eduroam” in the same light as say, using Facebook to 
> login to other applications i.e. The university advertises that the guest 
> wireless SSID supports the “eduroam” authentication service. The visiting 
> person connects to your branded guest SSID using their home college 
> credentials – understanding that they are bound to your AUP or other local 
> decisions on the use of their data. There is no confusion about who owns, 
> administers, or otherwise controls the network the client is connected to and 
> no assumptions about resource availability.
>  


So for every campus that you visit you have to suffer:
Hunting for the SSID
Trust that SSID
Read the AUP
Share your Social Identity (talk about big data here)
And as a network Operator you have to hope that the Social Identity is somewhat 
real!

Schools don’t have time to look at big data for their traveling users or their 
guests, and the only info is username@domain or if you want anonymous@domain.
You actually have the choice to anonymize yourself, it is not against any rule.

The same goes for NROs (National Roaming Operators for eduroam), we have all 
signed an agreement that we cannot use user data other than troubleshooting and 
monitoring unless required by law enforcement.
I doubt that Facebook or any other Social Provider can guarantee that…they make 
money out of your data!

Again, if you fear to be tracked on eduroam, definitely anonymize your 
outer-identity. It is accepted, and many do it (it can even be done 
automatically in the CAT tool).
In case of abuse or infection, a user can be found by contacting the campus of 
origin (so you let the IDP decide how to deal with Privacy for their users!).

Finally, there is a reason why the big carriers did a push for 
Hotspot2.0/Passpoint. Protocols like 802.1X/WPA2-enterprise are great for 
security and authentication (both of the infrastructure
and users), and the guest Wi-Fi industry is moving toward those standards. We 
all have done it with eduroam way ahead of the carriers. 
The privacy issue with large carriers might be an issue, but we suffer the same 
with our Cellphones already.
Privacy and Net 

RE: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Turner, Ryan H]

I thought about ways to respond to this, but figure simple is better…

Most of those concerns are either easily mitigated with user education, or are 
issues we haven’t experienced.  Since we’ve had eduroam as primary for 2 years 
with hundreds of thousands of devices onboarded and a lot of traveling from our 
international student base, I would figure I would have seen most issues.  The 
biggest issue that we get, and it is rare, is “I was at X university, and I 
couldn’t connect”.  Most of the time it is the other university’s fault, and I 
have to explain that after looking in our logs.

You are putting a lot of weight into ‘theoretical’ concerns, when it is almost 
a guarantee that if a student or faculty member travels to another university, 
they will have to connect to the ‘Guest’ open SSID, of which they will have no 
protection at all.  We have seen it from neighboring institutions, which 
despite running eduroam, have an extremely low adoption rate because people 
just won’t bother to onboard if it isn’t necessary.


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



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey D. Sessler
Sent: Friday, April 28, 2017 1:18 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

No matter what direction I come at it, “eduroam” is fundamentally a guest 
network with very little intrinsic value, but with many downsides. As such, I 
would be reluctant to make it our default SSID, and I caution those that use it 
as such to explore its shortcomings.

Why do I say this?

  *   Organization - A university can’t assume and/or guarantee that “eduroam” 
is administered at another campus in the same way that it is at home. There is 
no guarantee of privacy, be it the data collected during 
authentication/authorization, or information being sent/received by the client 
while traversing the other organization’s network. There is no guarantee user 
data won’t be sold, studied, or otherwise used as the organization terminating 
the client’s connection sees fit. eduroam is a name only.
  *   User – Assumption that “eduroam” away from their home campus is the same 
as “eduroam” at another organization. Assumption that there is the same level 
of data security, privacy, or other safeguards/guarantees as provided at home. 
Assumption that the same resources are available. Assumption “eduroam’ out in 
the world is superior than connecting to an open network.

Certainly, some of the data privacy pieces could be mitigated by using a 
home-campus VPN while traveling, but now you are creating rules that the 
end-user must remember. These rules become confusing when you are in an area 
with multiple organizations all broadcasting “eduroam”, where to simplify the 
user experience i.e. they can get to the same resources, the default becomes 
using VPN all the time. Once you force the use of a VPN, then is “eduroam” any 
different than using an open/suest network?

I would prefer to see “eduroam” in the same light as say, using Facebook to 
login to other applications i.e. The university advertises that the guest 
wireless SSID supports the “eduroam” authentication service. The visiting 
person connects to your branded guest SSID using their home college credentials 
– understanding that they are bound to your AUP or other local decisions on the 
use of their data. There is no confusion about who owns, administers, or 
otherwise controls the network the client is connected to and no assumptions 
about resource availability.

Jeff


From: 
"wireless-lan@listserv.educause.edu" 
> 
on behalf of Marcelo Maraboli 
>
Organization: UC
Reply-To: 
"wireless-lan@listserv.educause.edu" 
>
Date: Thursday, April 20, 2017 at 2:16 PM
To: 
"wireless-lan@listserv.educause.edu" 
>
Subject: [WIRELESS-LAN] Eduroam adoption (and migration process)

Hello everyone.

We are finally adopting EduROAM in our University and we currently have one
SSID with MAC-based authentication, so moving to EduROAM is also a 802.1x 
upgrade
for us as well.

Would you be so kind to respond a couple of questions?:


If you adopted EduROAM as your primary SSID:
- Did you leave an SSID for legacy devices ? (What AUTH mechanism for this 
SSID?)
- How did you "force-move" your users to EdoROAM from your old SSID ?

If you added EduROAM as 

Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Jeffrey D. Sessler]

No matter what direction I come at it, “eduroam” is fundamentally a guest 
network with very little intrinsic value, but with many downsides. As such, I 
would be reluctant to make it our default SSID, and I caution those that use it 
as such to explore its shortcomings.

Why do I say this?

· Organization - A university can’t assume and/or guarantee that 
“eduroam” is administered at another campus in the same way that it is at home. 
There is no guarantee of privacy, be it the data collected during 
authentication/authorization, or information being sent/received by the client 
while traversing the other organization’s network. There is no guarantee user 
data won’t be sold, studied, or otherwise used as the organization terminating 
the client’s connection sees fit. eduroam is a name only.

· User – Assumption that “eduroam” away from their home campus is the 
same as “eduroam” at another organization. Assumption that there is the same 
level of data security, privacy, or other safeguards/guarantees as provided at 
home. Assumption that the same resources are available. Assumption “eduroam’ 
out in the world is superior than connecting to an open network.

Certainly, some of the data privacy pieces could be mitigated by using a 
home-campus VPN while traveling, but now you are creating rules that the 
end-user must remember. These rules become confusing when you are in an area 
with multiple organizations all broadcasting “eduroam”, where to simplify the 
user experience i.e. they can get to the same resources, the default becomes 
using VPN all the time. Once you force the use of a VPN, then is “eduroam” any 
different than using an open/suest network?

I would prefer to see “eduroam” in the same light as say, using Facebook to 
login to other applications i.e. The university advertises that the guest 
wireless SSID supports the “eduroam” authentication service. The visiting 
person connects to your branded guest SSID using their home college credentials 
– understanding that they are bound to your AUP or other local decisions on the 
use of their data. There is no confusion about who owns, administers, or 
otherwise controls the network the client is connected to and no assumptions 
about resource availability.

Jeff


From: "wireless-lan@listserv.educause.edu"  
on behalf of Marcelo Maraboli 
Organization: UC
Reply-To: "wireless-lan@listserv.educause.edu" 

Date: Thursday, April 20, 2017 at 2:16 PM
To: "wireless-lan@listserv.educause.edu" 
Subject: [WIRELESS-LAN] Eduroam adoption (and migration process)

Hello everyone.

We are finally adopting EduROAM in our University and we currently have one
SSID with MAC-based authentication, so moving to EduROAM is also a 802.1x 
upgrade
for us as well.

Would you be so kind to respond a couple of questions?:


If you adopted EduROAM as your primary SSID:
- Did you leave an SSID for legacy devices ? (What AUTH mechanism for this 
SSID?)
- How did you "force-move" your users to EdoROAM from your old SSID ?

If you added EduROAM as just another SSID:
- why not adopt EduROAM as your primary SSID ?  (Branding or no interest? )
- Is your primary SSID also 802.1x o MAC-based ?
- if 802.1x, why have 2 SSIDs with 802.1x ?


thank you all,
--
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.

RE: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Turner, Ryan H]

Me, too.  You can absolutely require your local users to require EAP-TLS while 
supporting other institutions ability to support whatever EAP type they like.  
And when your users are abroad, those requirements are still in force.

We only run eduroam as our 802.1x using EAP-TLS and force non supported devices 
to a ‘branded’ PSK network.  Personally, unless you are in a dense urban area 
where the possibilities exist that you’ll connect to another institutions 
eduroam, I never saw the benefit to branding…

In our case, we have a satellite pharmacy school located at another campus that 
isn’t ours (UNC Chapel Hill pharmacy school located at UNC Asheville campus).  
We actually disconnected our access points, allowed UNC Asheville to install 
their access points in our building (that also had UNC Asheville departments), 
and we bridged our two networks L2 VLANs.  If you are a UNC Asheville person, 
you stay on their network.  If your username ends with @unc.edu, they actually 
tunnel the user into our campus vlan that is connected through a copper 
connection in a closet that contains both institutions equipment.  Really odd 
setup that can lead to some interesting troubleshooting issues, but I have a 
philosophy of solving problems rather than avoiding some complications.


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



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hunter Fuller
Sent: Friday, April 28, 2017 10:52 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

I'm still not sure I follow.

It sounds like, in your current config, you have your constituents use EAP-TLS, 
and cannot use PEAP. Meanwhile your visitors use whatever their home 
institution offers.

If you ran with only the eduroam ESSID, you could run with the same config. 
Your constituents are unable to use PEAP, and must use EAP-TLS home and abroad. 
At the same time, your visitors continue to use whatever their home institution 
offers. This is a viable config.

I understand keeping two ESSIDs for branding though of course. We were lucky as 
we didn't have branded ESSIDs before eduroam either. So it was no loss to move 
to eduroam.

On Fri, Apr 28, 2017 at 09:41 Curtis K. Larsen 
> wrote:
My point is not that eduroam mandates a given EAP type.  My point is that if a 
given EAP type presents a vulnerability to users that will come into my 
institution's property but I allow it anyway so that another institution's 
configuration will be compatible - then I have surrendered a better security 
stance to facilitate that compatibility.  This is because the SSID is the same.

On the other hand, if I have a unique university SSID - I can easily choose the 
EAP type and thus mitigate the vulnerability more fully - this is now easy to 
do with various onboarding tools.  With HS 2.0 the roaming agreements can still 
be in place and we don't care about the SSID.  To me that sounds like the best 
of both worlds.

-Curtis


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> 
on behalf of Cappalli, Tim (Aruba Security) >
Sent: Friday, April 28, 2017 3:54 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Can you elaborate on this comment?

“whereas with eduroam we were kind of locked-in to the PEAP model.”

Eduroam is EAP agnostic.




On 4/27/17, 10:57 PM, "The EDUCAUSE Wireless Issues Constituent Group Listserv 
on behalf of Curtis K. Larsen" 
 
on behalf of curtis.k.lar...@utah.edu> wrote:

We also use eduroam and a university SSID and one benefit I've seen is that 
when our CISO decided to deprecate PEAP due to the "fake AP/MITM - exposed 
password" issue and favor EAP-TLS - we could easily control our own destiny 
with our own SSID whereas with eduroam we were kind of locked-in to the PEAP 
model.  Lesser security will often result when universal compatibility is the 
goal.  I mean we could force our own users to use EAP-TLS at home and abroad 
but in my opinion we could not truly say that we've done everything possible to 
mitigate the PEAP vulnerability while still propping up a PEAP SSID org-wide 
even if PEAP only ends up being used by visitors.

We currently offer long-term EAP-TLS connections on our university SSID to 
any guest willing to provide an SMS number (Cloudpath Feature).  It turns out 
that the 

Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Dennis Xu]

I think there is one problem with just using eduroam SSID  that your users 
could have problem connecting to eduroam at other institutions, depends on your 
username policy. If you can force all your users to use u...@yourdomain.xxx as 
username, you don't have this issue. But if you allow a variety of username 
formats such as host/xxx for machine authentications, domain\xxx for Windows 
users domain login over wireless, these devices will not be able to connect at 
other institutions, and there is no easy fix for them if this happens. They 
will have to 'forget' the existing eduroam configuration and reconfigure it, 
which could result in lots of support calls.


Dennis Xu
University of Guelph
519-824-4120 Ext 56217
d...@uoguelph.ca
www.uoguelph.ca/ccs



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Hunter Fuller 
Sent: Friday, April 28, 2017 10:51:51 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

I'm still not sure I follow.

It sounds like, in your current config, you have your constituents use EAP-TLS, 
and cannot use PEAP. Meanwhile your visitors use whatever their home 
institution offers.

If you ran with only the eduroam ESSID, you could run with the same config. 
Your constituents are unable to use PEAP, and must use EAP-TLS home and abroad. 
At the same time, your visitors continue to use whatever their home institution 
offers. This is a viable config.

I understand keeping two ESSIDs for branding though of course. We were lucky as 
we didn't have branded ESSIDs before eduroam either. So it was no loss to move 
to eduroam.

On Fri, Apr 28, 2017 at 09:41 Curtis K. Larsen 
> wrote:
My point is not that eduroam mandates a given EAP type.  My point is that if a 
given EAP type presents a vulnerability to users that will come into my 
institution's property but I allow it anyway so that another institution's 
configuration will be compatible - then I have surrendered a better security 
stance to facilitate that compatibility.  This is because the SSID is the same.

On the other hand, if I have a unique university SSID - I can easily choose the 
EAP type and thus mitigate the vulnerability more fully - this is now easy to 
do with various onboarding tools.  With HS 2.0 the roaming agreements can still 
be in place and we don't care about the SSID.  To me that sounds like the best 
of both worlds.

-Curtis


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> 
on behalf of Cappalli, Tim (Aruba Security) >
Sent: Friday, April 28, 2017 3:54 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Can you elaborate on this comment?

“whereas with eduroam we were kind of locked-in to the PEAP model.”

Eduroam is EAP agnostic.




On 4/27/17, 10:57 PM, "The EDUCAUSE Wireless Issues Constituent Group Listserv 
on behalf of Curtis K. Larsen" 
 
on behalf of curtis.k.lar...@utah.edu> wrote:

We also use eduroam and a university SSID and one benefit I've seen is that 
when our CISO decided to deprecate PEAP due to the "fake AP/MITM - exposed 
password" issue and favor EAP-TLS - we could easily control our own destiny 
with our own SSID whereas with eduroam we were kind of locked-in to the PEAP 
model.  Lesser security will often result when universal compatibility is the 
goal.  I mean we could force our own users to use EAP-TLS at home and abroad 
but in my opinion we could not truly say that we've done everything possible to 
mitigate the PEAP vulnerability while still propping up a PEAP SSID org-wide 
even if PEAP only ends up being used by visitors.

We currently offer long-term EAP-TLS connections on our university SSID to 
any guest willing to provide an SMS number (Cloudpath Feature).  It turns out 
that the SMS-capable phone carrying population is much larger than those with 
eduroam credentials so far, and phone numbers are possibly more valuable to 
administrators than AD credentials of participating institutions in resolving 
issues.  In my opinion, as onboarding solutions mature the SSID becomes less 
important, and who knows maybe with Hotspot 2.0 completely irrelevant?  
Something to consider at least when making that decision anyway.

--
Curtis K. Larsen
Senior Network Engineer
University of Utah IT/CIS
Office 801-587-1313

___
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 

Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Curtis K. Larsen]

I guess it boils down to an attacker being less likely to setup a fake AP/evil 
twin on the property of an institution that does not support PEAP vs. one that 
does.

-Curtis


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Hunter Fuller 
Sent: Friday, April 28, 2017 8:51 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

I'm still not sure I follow.

It sounds like, in your current config, you have your constituents use EAP-TLS, 
and cannot use PEAP. Meanwhile your visitors use whatever their home 
institution offers.

If you ran with only the eduroam ESSID, you could run with the same config. 
Your constituents are unable to use PEAP, and must use EAP-TLS home and abroad. 
At the same time, your visitors continue to use whatever their home institution 
offers. This is a viable config.

I understand keeping two ESSIDs for branding though of course. We were lucky as 
we didn't have branded ESSIDs before eduroam either. So it was no loss to move 
to eduroam.

On Fri, Apr 28, 2017 at 09:41 Curtis K. Larsen 
> wrote:
My point is not that eduroam mandates a given EAP type.  My point is that if a 
given EAP type presents a vulnerability to users that will come into my 
institution's property but I allow it anyway so that another institution's 
configuration will be compatible - then I have surrendered a better security 
stance to facilitate that compatibility.  This is because the SSID is the same.

On the other hand, if I have a unique university SSID - I can easily choose the 
EAP type and thus mitigate the vulnerability more fully - this is now easy to 
do with various onboarding tools.  With HS 2.0 the roaming agreements can still 
be in place and we don't care about the SSID.  To me that sounds like the best 
of both worlds.

-Curtis


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> 
on behalf of Cappalli, Tim (Aruba Security) >
Sent: Friday, April 28, 2017 3:54 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Can you elaborate on this comment?

“whereas with eduroam we were kind of locked-in to the PEAP model.”

Eduroam is EAP agnostic.




On 4/27/17, 10:57 PM, "The EDUCAUSE Wireless Issues Constituent Group Listserv 
on behalf of Curtis K. Larsen" 
 
on behalf of curtis.k.lar...@utah.edu> wrote:

We also use eduroam and a university SSID and one benefit I've seen is that 
when our CISO decided to deprecate PEAP due to the "fake AP/MITM - exposed 
password" issue and favor EAP-TLS - we could easily control our own destiny 
with our own SSID whereas with eduroam we were kind of locked-in to the PEAP 
model.  Lesser security will often result when universal compatibility is the 
goal.  I mean we could force our own users to use EAP-TLS at home and abroad 
but in my opinion we could not truly say that we've done everything possible to 
mitigate the PEAP vulnerability while still propping up a PEAP SSID org-wide 
even if PEAP only ends up being used by visitors.

We currently offer long-term EAP-TLS connections on our university SSID to 
any guest willing to provide an SMS number (Cloudpath Feature).  It turns out 
that the SMS-capable phone carrying population is much larger than those with 
eduroam credentials so far, and phone numbers are possibly more valuable to 
administrators than AD credentials of participating institutions in resolving 
issues.  In my opinion, as onboarding solutions mature the SSID becomes less 
important, and who knows maybe with Hotspot 2.0 completely irrelevant?  
Something to consider at least when making that decision anyway.

--
Curtis K. Larsen
Senior Network Engineer
University of Utah IT/CIS
Office 801-587-1313

___
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> 
on behalf of Les Ridgley 
>
Sent: Thursday, April 27, 2017 10:10 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

We retained both the eduroam SSID and the university one for the reasons of 
branding and more importantly for us, to ensure that our users on a site that 
has multiple institutions broadcasting the eduroam SSID we could guarantee 

Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Hunter Fuller]

I'm still not sure I follow.

It sounds like, in your current config, you have your constituents use
EAP-TLS, and cannot use PEAP. Meanwhile your visitors use whatever their
home institution offers.

If you ran with only the eduroam ESSID, you could run with the same config.
Your constituents are unable to use PEAP, and must use EAP-TLS home and
abroad. At the same time, your visitors continue to use whatever their home
institution offers. This is a viable config.

I understand keeping two ESSIDs for branding though of course. We were
lucky as we didn't have branded ESSIDs before eduroam either. So it was no
loss to move to eduroam.

On Fri, Apr 28, 2017 at 09:41 Curtis K. Larsen 
wrote:

> My point is not that eduroam mandates a given EAP type.  My point is that
> if a given EAP type presents a vulnerability to users that will come into
> my institution's property but I allow it anyway so that another
> institution's configuration will be compatible - then I have surrendered a
> better security stance to facilitate that compatibility.  This is because
> the SSID is the same.
>
> On the other hand, if I have a unique university SSID - I can easily
> choose the EAP type and thus mitigate the vulnerability more fully - this
> is now easy to do with various onboarding tools.  With HS 2.0 the roaming
> agreements can still be in place and we don't care about the SSID.  To me
> that sounds like the best of both worlds.
>
> -Curtis
>
> 
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Cappalli, Tim (Aruba
> Security) 
> Sent: Friday, April 28, 2017 3:54 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>
> Can you elaborate on this comment?
>
> “whereas with eduroam we were kind of locked-in to the PEAP model.”
>
> Eduroam is EAP agnostic.
>
>
>
>
> On 4/27/17, 10:57 PM, "The EDUCAUSE Wireless Issues Constituent Group
> Listserv on behalf of Curtis K. Larsen" <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU on behalf of curtis.k.lar...@utah.edu>
> wrote:
>
> We also use eduroam and a university SSID and one benefit I've seen is
> that when our CISO decided to deprecate PEAP due to the "fake AP/MITM -
> exposed password" issue and favor EAP-TLS - we could easily control our own
> destiny with our own SSID whereas with eduroam we were kind of locked-in to
> the PEAP model.  Lesser security will often result when universal
> compatibility is the goal.  I mean we could force our own users to use
> EAP-TLS at home and abroad but in my opinion we could not truly say that
> we've done everything possible to mitigate the PEAP vulnerability while
> still propping up a PEAP SSID org-wide even if PEAP only ends up being used
> by visitors.
>
> We currently offer long-term EAP-TLS connections on our university
> SSID to any guest willing to provide an SMS number (Cloudpath Feature).  It
> turns out that the SMS-capable phone carrying population is much larger
> than those with eduroam credentials so far, and phone numbers are possibly
> more valuable to administrators than AD credentials of participating
> institutions in resolving issues.  In my opinion, as onboarding solutions
> mature the SSID becomes less important, and who knows maybe with Hotspot
> 2.0 completely irrelevant?  Something to consider at least when making that
> decision anyway.
>
> --
> Curtis K. Larsen
> Senior Network Engineer
> University of Utah IT/CIS
> Office 801-587-1313
>
> ___
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Les Ridgley <
> les.ridg...@newcastle.edu.au>
> Sent: Thursday, April 27, 2017 10:10 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>
> We retained both the eduroam SSID and the university one for the
> reasons of branding and more importantly for us, to ensure that our users
> on a site that has multiple institutions broadcasting the eduroam SSID we
> could guarantee connection to our network by using the university SSID.
>
> Had we only broadcast the eduroam SSID there was the possibility that
> the user could unknowingly connect to another institutions eduroam SSID and
> then not have the same access to system resources that they would
> experience had they connected to our SSID.
>
> We have not experienced significant support difficulties and allow the
> users to use either SSID at their own discretion.
>
> HTH,
> Les.
>
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Helman
> Sent: Friday, 28 April 2017 1:26 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Eduroam 

Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Curtis K. Larsen]

My point is not that eduroam mandates a given EAP type.  My point is that if a 
given EAP type presents a vulnerability to users that will come into my 
institution's property but I allow it anyway so that another institution's 
configuration will be compatible - then I have surrendered a better security 
stance to facilitate that compatibility.  This is because the SSID is the same.

On the other hand, if I have a unique university SSID - I can easily choose the 
EAP type and thus mitigate the vulnerability more fully - this is now easy to 
do with various onboarding tools.  With HS 2.0 the roaming agreements can still 
be in place and we don't care about the SSID.  To me that sounds like the best 
of both worlds.

-Curtis


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Cappalli, Tim (Aruba 
Security) 
Sent: Friday, April 28, 2017 3:54 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Can you elaborate on this comment?

“whereas with eduroam we were kind of locked-in to the PEAP model.”

Eduroam is EAP agnostic.




On 4/27/17, 10:57 PM, "The EDUCAUSE Wireless Issues Constituent Group Listserv 
on behalf of Curtis K. Larsen"  wrote:

We also use eduroam and a university SSID and one benefit I've seen is that 
when our CISO decided to deprecate PEAP due to the "fake AP/MITM - exposed 
password" issue and favor EAP-TLS - we could easily control our own destiny 
with our own SSID whereas with eduroam we were kind of locked-in to the PEAP 
model.  Lesser security will often result when universal compatibility is the 
goal.  I mean we could force our own users to use EAP-TLS at home and abroad 
but in my opinion we could not truly say that we've done everything possible to 
mitigate the PEAP vulnerability while still propping up a PEAP SSID org-wide 
even if PEAP only ends up being used by visitors.

We currently offer long-term EAP-TLS connections on our university SSID to 
any guest willing to provide an SMS number (Cloudpath Feature).  It turns out 
that the SMS-capable phone carrying population is much larger than those with 
eduroam credentials so far, and phone numbers are possibly more valuable to 
administrators than AD credentials of participating institutions in resolving 
issues.  In my opinion, as onboarding solutions mature the SSID becomes less 
important, and who knows maybe with Hotspot 2.0 completely irrelevant?  
Something to consider at least when making that decision anyway.

--
Curtis K. Larsen
Senior Network Engineer
University of Utah IT/CIS
Office 801-587-1313

___
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Les Ridgley 

Sent: Thursday, April 27, 2017 10:10 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

We retained both the eduroam SSID and the university one for the reasons of 
branding and more importantly for us, to ensure that our users on a site that 
has multiple institutions broadcasting the eduroam SSID we could guarantee 
connection to our network by using the university SSID.

Had we only broadcast the eduroam SSID there was the possibility that the 
user could unknowingly connect to another institutions eduroam SSID and then 
not have the same access to system resources that they would experience had 
they connected to our SSID.

We have not experienced significant support difficulties and allow the 
users to use either SSID at their own discretion.

HTH,
Les.

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Helman
Sent: Friday, 28 April 2017 1:26 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)


A related question came up today when discussing whether or not to get rid 
of our branded SSID or not once eduroam is up and running on our network.  
Specifically:

For those who decided to keep both the branded and eduroam SSID's (and 
assuming they are identical in terms of access for your institutional users) -- 
have there been any issues in doing so?  For example, does it cause confusion 
to users or doesn't it matter to them?  Any support issues either with the 
people directly supporting the users and/or managing the wireless network?  If 
you decided to keep both .. do you regret this decision or are you 
happy/neutral with it?

Conversely, if you DID decide to go with only the eduroam SSID, has anyone 
regretted this decision?

We're just trying to get a fuller understanding before we 

Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Matthew Newton]

On Fri, Apr 28, 2017 at 09:54:55AM +, Cappalli, Tim (Aruba Security) wrote:
> Can you elaborate on this comment?
> 
> “whereas with eduroam we were kind of locked-in to the PEAP model.”
> 
> Eduroam is EAP agnostic.

Quite - I was thinking the same thing.

There's no reason why you can't use EAP-TLS for your local users
on eduroam. Visitors can still use PEAP, or EAP-TTLS, or whatever
else they need to, but that's not something for you to have to
worry about.

Matthew


-- 
Matthew Newton, Ph.D. 

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, 

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

Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

[Cappalli, Tim (Aruba Security)]

Can you elaborate on this comment?

“whereas with eduroam we were kind of locked-in to the PEAP model.”

Eduroam is EAP agnostic.

 


On 4/27/17, 10:57 PM, "The EDUCAUSE Wireless Issues Constituent Group Listserv 
on behalf of Curtis K. Larsen"  wrote:

We also use eduroam and a university SSID and one benefit I've seen is that 
when our CISO decided to deprecate PEAP due to the "fake AP/MITM - exposed 
password" issue and favor EAP-TLS - we could easily control our own destiny 
with our own SSID whereas with eduroam we were kind of locked-in to the PEAP 
model.  Lesser security will often result when universal compatibility is the 
goal.  I mean we could force our own users to use EAP-TLS at home and abroad 
but in my opinion we could not truly say that we've done everything possible to 
mitigate the PEAP vulnerability while still propping up a PEAP SSID org-wide 
even if PEAP only ends up being used by visitors.

We currently offer long-term EAP-TLS connections on our university SSID to 
any guest willing to provide an SMS number (Cloudpath Feature).  It turns out 
that the SMS-capable phone carrying population is much larger than those with 
eduroam credentials so far, and phone numbers are possibly more valuable to 
administrators than AD credentials of participating institutions in resolving 
issues.  In my opinion, as onboarding solutions mature the SSID becomes less 
important, and who knows maybe with Hotspot 2.0 completely irrelevant?  
Something to consider at least when making that decision anyway.

--
Curtis K. Larsen
Senior Network Engineer
University of Utah IT/CIS
Office 801-587-1313

___
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Les Ridgley 

Sent: Thursday, April 27, 2017 10:10 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

We retained both the eduroam SSID and the university one for the reasons of 
branding and more importantly for us, to ensure that our users on a site that 
has multiple institutions broadcasting the eduroam SSID we could guarantee 
connection to our network by using the university SSID.

Had we only broadcast the eduroam SSID there was the possibility that the 
user could unknowingly connect to another institutions eduroam SSID and then 
not have the same access to system resources that they would experience had 
they connected to our SSID.

We have not experienced significant support difficulties and allow the 
users to use either SSID at their own discretion.

HTH,
Les.

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Helman
Sent: Friday, 28 April 2017 1:26 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)


A related question came up today when discussing whether or not to get rid 
of our branded SSID or not once eduroam is up and running on our network.  
Specifically:

For those who decided to keep both the branded and eduroam SSID's (and 
assuming they are identical in terms of access for your institutional users) -- 
have there been any issues in doing so?  For example, does it cause confusion 
to users or doesn't it matter to them?  Any support issues either with the 
people directly supporting the users and/or managing the wireless network?  If 
you decided to keep both .. do you regret this decision or are you 
happy/neutral with it?

Conversely, if you DID decide to go with only the eduroam SSID, has anyone 
regretted this decision?

We're just trying to get a fuller understanding before we decide to remove 
the branded SSID.  We do think that's what people will look for .. especially 
those not familiar with eduroam.

Thanks!

-Brian



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Brian Helman 
[bhel...@salemstate.edu]
Sent: Tuesday, April 25, 2017 1:57 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
Ahh, I see.  They are separate networks.  We are using a NAC to place users 
in their proper vlan, so there’s no differentiation between our current 
university ssid and eduroam.

By the way, I keep writing “EDUROAM”.  I know it’s “eduroam” .. it’s just 
habit from typing “EDUCAUSE”.

Thanks!

-Brian

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of John Heartlein
Sent: Tuesday, April 25, 2017