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 <j...@scrippscollege.edu> 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" 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Philippe Hanset 
> <phan...@anyroam.net>
> Reply-To: "wireless-lan@listserv.educause.edu" 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> Date: Friday, April 28, 2017 at 2:51 PM
> To: "wireless-lan@listserv.educause.edu" <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 <j...@scrippscollege.edu> 
> 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 

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" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
on behalf of Philippe Hanset <phan...@anyroam.net>
Reply-To: "wireless-lan@listserv.educause.edu" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Date: Friday, April 28, 2017 at 2:51 PM
To: "wireless-lan@listserv.educause.edu" <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 
<j...@scrippscollege.edu<mailto:j...@scrippscollege.edu>> 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<mailto:wireless-lan@listserv.educause.edu>" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@listserv.ed

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 <http://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 <curtis.k.lar...@utah.edu> 
> 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 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Hunter Fuller 
> <hf0...@uah.edu>
> 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 
> <curtis.k.lar...@utah.edu<mailto:curtis.k.lar...@utah.edu>> 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<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
>  on behalf of Hunter Fuller <hf0...@uah.edu<mailto:hf0...@uah.edu>>
> Sent: Friday, April 28, 2017 8:51 AM
> To: 
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto: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 ru

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

[Philippe Hanset]

> On Apr 28, 2017, at 3:49 PM, Jeffrey D. Sessler <j...@scrippscollege.edu> 
> 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 
> <mailto:wireless-lan@listserv.educause.edu>" 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> <mailto:WIRELESS-LAN@listserv.educause.edu>> on behalf of Philippe Hanset 
> <phan...@anyroam.net <mailto:phan...@anyroam.net>>
> Reply-To: "wireless-lan@listserv.educause.edu 
> <mailto:wireless-lan@listserv.educause.edu>" 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> <mailto:WIRELESS-LAN@listserv.educause.edu>>
> Date: Friday, April 28, 2017 at 11:14 AM
> To: "wireless-lan@listserv.educause.edu 
> <mailto:wireless-lan@listserv.educause.edu>" 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> <mailto: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 infrastr

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 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Hunter Fuller <hf0...@uah.edu>
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 
<curtis.k.lar...@utah.edu<mailto:curtis.k.lar...@utah.edu>> 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<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Hunter Fuller <hf0...@uah.edu<mailto:hf0...@uah.edu>>
Sent: Friday, April 28, 2017 8:51 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto: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 
<curtis.k.lar...@utah.edu<mailto:curtis.k.lar...@utah.edu><mailto:curtis.k.lar...@utah.edu<mailto:curtis.k.lar...@utah.edu>>>
 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<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU><mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>>
 on behalf of Cappalli, Tim (Aruba Security) 
<t...@hpe.com<mailto:t...@hpe.com><mailto:t...@hpe.com<mailto:t...@hpe.com>>>
Sent: Friday, April 28, 2017 3:54 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU><mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSE

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 <curtis.k.lar...@utah.edu>
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 <curtis.k.lar...@utah.edu
> <mailto:curtis.k.lar...@utah.edu>> 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) <t...@hpe.com<mailto:t...@hpe.com>>
> 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
> <mailto: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 

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

[Philippe Hanset]

carriers might be an issue, but we suffer the same 
with our Cellphones already.
Privacy and Net Neutrality is at stake every day.

Hope this helps,

Philippe

Philippe Hanset, CEO
www.anyroam.net
www.eduroam.us
+1 (865) 236-0770

GPG key id: 0xF2636F9C







> Jeff
>  
>  
> From: "wireless-lan@listserv.educause.edu 
> <mailto:wireless-lan@listserv.educause.edu>" 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> <mailto:WIRELESS-LAN@listserv.educause.edu>> on behalf of Marcelo Maraboli 
> <marcelo.marab...@uc.cl <mailto:marcelo.marab...@uc.cl>>
> Organization: UC
> Reply-To: "wireless-lan@listserv.educause.edu 
> <mailto:wireless-lan@listserv.educause.edu>" 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> <mailto:WIRELESS-LAN@listserv.educause.edu>>
> Date: Thursday, April 20, 2017 at 2:16 PM
> To: "wireless-lan@listserv.educause.edu 
> <mailto:wireless-lan@listserv.educause.edu>" 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> <mailto: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/ <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 
> athttp://www.educause.edu/discuss <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 <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]

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<mailto: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<mailto:wireless-lan@listserv.educause.edu>" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Marcelo Maraboli 
<marcelo.marab...@uc.cl<mailto:marcelo.marab...@uc.cl>>
Organization: UC
Reply-To: 
"wireless-lan@listserv.educause.edu<mailto:wireless-lan@listserv.educause.edu>" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Thursday, April 20, 2017 at 2:16 PM
To: 
"wireless-lan@listserv.educause.edu<mailto:wireless-lan@listserv.educause.edu>" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto: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 th

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" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
on behalf of Marcelo Maraboli <marcelo.marab...@uc.cl>
Organization: UC
Reply-To: "wireless-lan@listserv.educause.edu" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Date: Thursday, April 20, 2017 at 2:16 PM
To: "wireless-lan@listserv.educause.edu" <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<mailto: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 
<curtis.k.lar...@utah.edu<mailto:curtis.k.lar...@utah.edu>> 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<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Cappalli, Tim (Aruba Security) <t...@hpe.com<mailto:t...@hpe.com>>
Sent: Friday, April 28, 2017 3:54 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto: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<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
on behalf of curtis.k.lar...@utah.edu<mailto: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 g

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 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Hunter Fuller <hf0...@uah.edu>
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 
<curtis.k.lar...@utah.edu<mailto:curtis.k.lar...@utah.edu>> 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<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Cappalli, Tim (Aruba Security) <t...@hpe.com<mailto:t...@hpe.com>>
Sent: Friday, April 28, 2017 3:54 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto: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<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
on behalf of curtis.k.lar...@utah.edu<mailto: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: 

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 
<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 
<curtis.k.lar...@utah.edu<mailto:curtis.k.lar...@utah.edu>> 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<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Cappalli, Tim (Aruba Security) <t...@hpe.com<mailto:t...@hpe.com>>
Sent: Friday, April 28, 2017 3:54 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto: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<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
on behalf of curtis.k.lar...@utah.edu<mailto: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<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Les Ridgley 
<les.ridg...@newcastle.edu.au<mailto:les.ridg...@newcastle.edu.au>>
Sent: Thursday, April 27, 2017 10:10 PM
    To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto: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 f

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 <curtis.k.lar...@utah.edu>
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) <t...@hpe.com>
> 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

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 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Cappalli, Tim (Aruba 
Security) <t...@hpe.com>
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 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 j

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" <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 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 Heartle

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

[Curtis K. Larsen]

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 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 1:52 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Hello Brian.  SLU-users has more direct access to internal services like file 
and print services that we didn't want to provide to eduroam users.  If we were 
ever to lock down SLU-users more to require VPN access to all internal 
resources, I think we'd recommend re-evaluating our SSIDs.

On Mon, Apr 24, 2017 at 8:14 AM, Brian Helman 
<bhel...@salemstate.edu<mailto:bhel...@salemstate.edu>> wrote:
John,

Do

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

[Les Ridgley]

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 1:52 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Hello Brian.  SLU-users has more direct access to internal services like file 
and print services that we didn't want to provide to eduroam users.  If we were 
ever to lock down SLU-users more to require VPN access to all internal 
resources, I think we'd recommend re-evaluating our SSIDs.

On Mon, Apr 24, 2017 at 8:14 AM, Brian Helman 
<bhel...@salemstate.edu<mailto:bhel...@salemstate.edu>> wrote:
John,

Do you know what the thought process was behind maintaining both an EDUROAM 
SSID as well as your SLU-users?  I'm just firing up our SSID for EDUROAM 
university-wide this week, so it would be the summer before our legacy SSID 
would go away.  If there is a compelling reason that we haven't discovered for 
keeping the legacy SSID, I certainly don't want to get rid of it.

-Brian

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>]
 On Behalf Of John Heartlein
Sent: Friday, April 21, 2017 5:08 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Saint Louis University deployed eduroam in late 2015.  Besides eduroam we have 
an 802.1x SSID SLU-users for our students, faculty, and staff.  We also have 
SLUguest for guests and legacy devices.  Here's a link to more information:

https://www.slu.edu/its/services-and-products/internet-and-network-services/wireless-networks-at-slu

On Fri, Apr 21, 2017 at 12:30 PM, Brian Helman 
<bhel...@salemstate.edu<mailto:bhel...@salemstate.edu>> wrote:
We have moved into the "testing" phase of our EDUROAM connectivity.  I'm hoping 
to fire up the EDUROAM SSID university-wide next week.  Currently, we have a 
.1x SSID that will stay through the summer.  Once EDUROAM is fully pushed, 
we'll start our advertisement campaign to get people to log in to it.  I would 
have waited until the summer to fire up EDUROAM so it is just available when 
everyone returns in the fall, but there's such a strong benefit for our 
students,

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

[Brian Helman]

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 1:52 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Hello Brian.  SLU-users has more direct access to internal services like file 
and print services that we didn't want to provide to eduroam users.  If we were 
ever to lock down SLU-users more to require VPN access to all internal 
resources, I think we'd recommend re-evaluating our SSIDs.

On Mon, Apr 24, 2017 at 8:14 AM, Brian Helman 
<bhel...@salemstate.edu<mailto:bhel...@salemstate.edu>> wrote:
John,

Do you know what the thought process was behind maintaining both an EDUROAM 
SSID as well as your SLU-users?  I’m just firing up our SSID for EDUROAM 
university-wide this week, so it would be the summer before our legacy SSID 
would go away.  If there is a compelling reason that we haven’t discovered for 
keeping the legacy SSID, I certainly don’t want to get rid of it.

-Brian

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>]
 On Behalf Of John Heartlein
Sent: Friday, April 21, 2017 5:08 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Saint Louis University deployed eduroam in late 2015.  Besides eduroam we have 
an 802.1x SSID SLU-users for our students, faculty, and staff.  We also have 
SLUguest for guests and legacy devices.  Here's a link to more information:

https://www.slu.edu/its/services-and-products/internet-and-network-services/wireless-networks-at-slu

On Fri, Apr 21, 2017 at 12:30 PM, Brian Helman 
<bhel...@salemstate.edu<mailto:bhel...@salemstate.edu>> wrote:
We have moved into the “testing” phase of our EDUROAM connectivity.  I’m hoping 
to fire up the EDUROAM SSID university-wide next week.  Currently, we have a 
.1x SSID that will stay through the summer.  Once EDUROAM is fully pushed, 
we’ll start our advertisement campaign to get people to log in to it.  I would 
have waited until the summer to fire up EDUROAM so it is just available when 
everyone returns in the fall, but there’s such a strong benefit for our 
students, staff and faculty if they are traveling over the summer that I want 
to get it to them.

There will be no “force move”, but the old .1x SSID won’t be available in the 
fall, so it benefits them to change their config now.   One note, we don’t 
currently support devices that do not support WPA/2 Enterprise (.1x) on our 
wireless network.  Essentially, we’re talking about gaming consoles (whether 
they support .1x or not), smart tv’s and media devices.  Students are told 
those devices need to be Ethernet-capable.  I suspect we’re at least another 
year away from supporting non-WPA/2 Ent devices on our wireless network.

>From what I have seen and it my discussions with our peers at other 
>institutions, unless there is a marketing reason the .1x auths are via EDUROAM 
>and the branded SSID’s are either specialized or they go away.

-Brian

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.E

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

[Luke Jenkins]

There is chatter on the eduroam development email list from time to time
about Passpoint / HS2.0, but I've not seen anyone mention having a full
blown production implementation (I'd love to be wrong about this).

The archies are available at
https://lists.eduroam.org/sympa/info/development , the most recent activity
on this topic was in 2017-03.

-Luke

On Wed, Apr 26, 2017 at 12:41 PM, Cappalli, Tim (Aruba Security) <
t...@hpe.com> wrote:

> Just curious. Is anyone using Passpoint / HS2 with eduroam?
>
>
>
> tim
>
>
>
> *From: *The EDUCAUSE Wireless Issues Constituent Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of "Sweetser, Frank E" <
> f...@wpi.edu>
> *Reply-To: *The EDUCAUSE Wireless Issues Constituent Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Date: *Wednesday, April 26, 2017 at 11:19 AM
> *To: *"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" <WIRELESS-LAN@LISTSERV.
> EDUCAUSE.EDU>
>
> *Subject: *Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>
>
>
> We rolled out eduroam a couple of years ago, and like most others appear
> to, we have it give identical service to our own users.  That said, we're
> planning on keeping both our branded network and eduroam, as there are two
> cases where we want to broadcast our branded SSID, but not eduroam:
>
>
>
>  - Aruba RAPs, installed in user's homes.  We don't want to inadvertently
> offer eduroam hotspot services off a user's home internet connection.
>
>  - High density environments where we're co-mingled with other entities
> offering eduroam.  This could easily lead to bad roaming performance, as
> clients end up accidentally migrating to a different network without
> realizing it.
>
>
>
> Frank Sweetser
> Director of Network Operations
> Worcester Polytechnic Institute
> "For every problem, there is a solution that is simple, elegant, and
> wrong." - HL Mencken
>
>
> --
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Walter Reynolds <
> wa...@umich.edu>
> *Sent:* Tuesday, April 25, 2017 3:33 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>
>
>
> We have been doing the attribute method for a while and have not really
> had any problems.  We use Freeradius with an LDAP check for the attributes.
>
>
>
>
> 
>
> Walter Reynolds
>
> Principal Systems Security Development Engineer
> Information and Technology Services
> University of Michigan
> (734) 615-9438
>
>
>
> On Tue, Apr 25, 2017 at 2:57 PM, Hunter Fuller <hf0...@uah.edu> wrote:
>
> Just like Brian mentioned, we sort users based on their attributes. If you
> are staff, and you connect to eduroam, you end up on the staff network.
>
>
>
> Those who didn't go that route, but instead kept the other ESSID for
> separation, what did you find were the shortcomings were with the
> attribute-based method? (Are we about to regret doing this, is really what
> I'm asking.)
>
>
>
> On Tue, Apr 25, 2017 at 1:10 PM Stephen Belcher <
> steve.belc...@mail.wvu.edu> wrote:
>
> That is the same situation with WVU. We maintain WVU.Encrypted for
> faculty, staff and students. We treat those users as “on campus”.
>
> We treat WVU.Guest and Eduroam as “off campus".
>
>
> -Original Message-
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Fligor, Debbie
> Sent: Monday, April 24, 2017 4:38 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>
> I can’t speak for the campuses you named, but we have not switched to
> eduroam as our main SSID, and we have no current plans to. I’m sure someone
> is happy about the branding somewhere, but it’s also for technical reasons.
> Eduroam, like our guest wireless, is routed outside our campus border
> firewall. When you are on our campus's IllinoisNet SSID you are on the
> campus side of the border firewall and have more access to campus resources
> than you do when you are on the eduroam SSID or our IllinoisNet_Guest
> SSID.  Our campus network design has very little internal firewalling - the
> majority of the protection for offices, labs, classrooms, wireless, and
> anything other than University-wide Admin applications is the border
> firewall. So putting guests on the outside, and faculty, staff and students
> on the inside is important.
>
> Additionally the firewall for the edur

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

[Sweetser, Frank E]

We rolled out eduroam a couple of years ago, and like most others appear to, we 
have it give identical service to our own users.  That said, we're planning on 
keeping both our branded network and eduroam, as there are two cases where we 
want to broadcast our branded SSID, but not eduroam:


 - Aruba RAPs, installed in user's homes.  We don't want to inadvertently offer 
eduroam hotspot services off a user's home internet connection.

 - High density environments where we're co-mingled with other entities 
offering eduroam.  This could easily lead to bad roaming performance, as 
clients end up accidentally migrating to a different network without realizing 
it.


Frank Sweetser
Director of Network Operations
Worcester Polytechnic Institute
"For every problem, there is a solution that is simple, elegant, and wrong." - 
HL Mencken



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Walter Reynolds 
<wa...@umich.edu>
Sent: Tuesday, April 25, 2017 3:33 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

We have been doing the attribute method for a while and have not really had any 
problems.  We use Freeradius with an LDAP check for the attributes.



Walter Reynolds
Principal Systems Security Development Engineer
Information and Technology Services
University of Michigan
(734) 615-9438

On Tue, Apr 25, 2017 at 2:57 PM, Hunter Fuller 
<hf0...@uah.edu<mailto:hf0...@uah.edu>> wrote:
Just like Brian mentioned, we sort users based on their attributes. If you are 
staff, and you connect to eduroam, you end up on the staff network.

Those who didn't go that route, but instead kept the other ESSID for 
separation, what did you find were the shortcomings were with the 
attribute-based method? (Are we about to regret doing this, is really what I'm 
asking.)

On Tue, Apr 25, 2017 at 1:10 PM Stephen Belcher 
<steve.belc...@mail.wvu.edu<mailto:steve.belc...@mail.wvu.edu>> wrote:
That is the same situation with WVU. We maintain WVU.Encrypted for faculty, 
staff and students. We treat those users as “on campus”.

We treat WVU.Guest and Eduroam as “off campus".


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>]
 On Behalf Of Fligor, Debbie
Sent: Monday, April 24, 2017 4:38 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

I can’t speak for the campuses you named, but we have not switched to eduroam 
as our main SSID, and we have no current plans to. I’m sure someone is happy 
about the branding somewhere, but it’s also for technical reasons. Eduroam, 
like our guest wireless, is routed outside our campus border firewall. When you 
are on our campus's IllinoisNet SSID you are on the campus side of the border 
firewall and have more access to campus resources than you do when you are on 
the eduroam SSID or our IllinoisNet_Guest SSID.  Our campus network design has 
very little internal firewalling - the majority of the protection for offices, 
labs, classrooms, wireless, and anything other than University-wide Admin 
applications is the border firewall. So putting guests on the outside, and 
faculty, staff and students on the inside is important.

Additionally the firewall for the eduroam network is set up to allow the 
minimum ports required by the eduroam agreement, so that when our faculty, 
staff and students test that something works on eduroam before they travel, 
they are reasonably well guaranteed it will work on any eduroam net anywhere. 
With our change from Meru/Radiator to Aruban/Clearpass last summer, it’s likely 
that it would be much simpler to drop eduroam users that are local onto a 
“different” version of eduroam that was on the campus side of the border 
firewall, but then the user experience on eduroam here would not be the same 
experience as if they were at a different site providing eduroam. Both in what 
ports were allowed in/out of the eduroam network and much more importantly how 
connections to campus resources function for networks off-campus. We want users 
to have a consistent experience with how eduroam works for their use cases, 
regardless of whether they are on our campus or somewhere else.


To answer the other questions, we currently have 3 non-eduroam SSIDs

our main SSID that is inside the campus board firewalls is 802.1x we have an 
open guest SSID that uses the Clearpass guest captive portal system we have a 
devices SSID that is MAC auth but I believe this one is being phased out in 
favor of using features in ClearPass to do something similar. This is mostly 
for gaming consoles and the things that re

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

[Walter Reynolds]

We have been doing the attribute method for a while and have not really had
any problems.  We use Freeradius with an LDAP check for the attributes.



Walter Reynolds
Principal Systems Security Development Engineer
Information and Technology Services
University of Michigan
(734) 615-9438

On Tue, Apr 25, 2017 at 2:57 PM, Hunter Fuller <hf0...@uah.edu> wrote:

> Just like Brian mentioned, we sort users based on their attributes. If you
> are staff, and you connect to eduroam, you end up on the staff network.
>
> Those who didn't go that route, but instead kept the other ESSID for
> separation, what did you find were the shortcomings were with the
> attribute-based method? (Are we about to regret doing this, is really what
> I'm asking.)
>
> On Tue, Apr 25, 2017 at 1:10 PM Stephen Belcher <
> steve.belc...@mail.wvu.edu> wrote:
>
>> That is the same situation with WVU. We maintain WVU.Encrypted for
>> faculty, staff and students. We treat those users as “on campus”.
>>
>> We treat WVU.Guest and Eduroam as “off campus".
>>
>>
>> -Original Message-
>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Fligor, Debbie
>> Sent: Monday, April 24, 2017 4:38 PM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>>
>> I can’t speak for the campuses you named, but we have not switched to
>> eduroam as our main SSID, and we have no current plans to. I’m sure someone
>> is happy about the branding somewhere, but it’s also for technical reasons.
>> Eduroam, like our guest wireless, is routed outside our campus border
>> firewall. When you are on our campus's IllinoisNet SSID you are on the
>> campus side of the border firewall and have more access to campus resources
>> than you do when you are on the eduroam SSID or our IllinoisNet_Guest
>> SSID.  Our campus network design has very little internal firewalling - the
>> majority of the protection for offices, labs, classrooms, wireless, and
>> anything other than University-wide Admin applications is the border
>> firewall. So putting guests on the outside, and faculty, staff and students
>> on the inside is important.
>>
>> Additionally the firewall for the eduroam network is set up to allow the
>> minimum ports required by the eduroam agreement, so that when our faculty,
>> staff and students test that something works on eduroam before they travel,
>> they are reasonably well guaranteed it will work on any eduroam net
>> anywhere. With our change from Meru/Radiator to Aruban/Clearpass last
>> summer, it’s likely that it would be much simpler to drop eduroam users
>> that are local onto a “different” version of eduroam that was on the campus
>> side of the border firewall, but then the user experience on eduroam here
>> would not be the same experience as if they were at a different site
>> providing eduroam. Both in what ports were allowed in/out of the eduroam
>> network and much more importantly how connections to campus resources
>> function for networks off-campus. We want users to have a consistent
>> experience with how eduroam works for their use cases, regardless of
>> whether they are on our campus or somewhere else.
>>
>>
>> To answer the other questions, we currently have 3 non-eduroam SSIDs
>>
>> our main SSID that is inside the campus board firewalls is 802.1x we have
>> an open guest SSID that uses the Clearpass guest captive portal system we
>> have a devices SSID that is MAC auth but I believe this one is being phased
>> out in favor of using features in ClearPass to do something similar. This
>> is mostly for gaming consoles and the things that really can’t do 802.1x.
>>
>>
>> It’s been quite a few years since I ran the wireless network on our
>> campus, but I believe I’ve got the current technical details correct, Chuck
>> can correct me if I got anything wrong.
>>
>>
>> --
>> -debbie
>> Debbie Fligor, n9dn   Lead Network Engineer @ Univ. of Il at
>> Urbana-Champaign
>> email: fli...@illinois.edu
>>
>>
>>
>> > On Apr 24, 2017, at 14:18, Marcelo Maraboli <marcelo.marab...@uc.cl>
>> wrote:
>> >
>> > I would like to thank all who responded.
>> >
>> > Everybody who responded is making EduRoam their main SSID
>> > deprecating their old SSID (MAC or .1x).
>> >
>> > I still wonder why Universities like MIT,Harvard,Stanford and Berkeley
>> > only use Eduroam as a secondary 

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

[Hunter Fuller]

Just like Brian mentioned, we sort users based on their attributes. If you
are staff, and you connect to eduroam, you end up on the staff network.

Those who didn't go that route, but instead kept the other ESSID for
separation, what did you find were the shortcomings were with the
attribute-based method? (Are we about to regret doing this, is really what
I'm asking.)

On Tue, Apr 25, 2017 at 1:10 PM Stephen Belcher <steve.belc...@mail.wvu.edu>
wrote:

> That is the same situation with WVU. We maintain WVU.Encrypted for
> faculty, staff and students. We treat those users as “on campus”.
>
> We treat WVU.Guest and Eduroam as “off campus".
>
>
> -Original Message-
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Fligor, Debbie
> Sent: Monday, April 24, 2017 4:38 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>
> I can’t speak for the campuses you named, but we have not switched to
> eduroam as our main SSID, and we have no current plans to. I’m sure someone
> is happy about the branding somewhere, but it’s also for technical reasons.
> Eduroam, like our guest wireless, is routed outside our campus border
> firewall. When you are on our campus's IllinoisNet SSID you are on the
> campus side of the border firewall and have more access to campus resources
> than you do when you are on the eduroam SSID or our IllinoisNet_Guest
> SSID.  Our campus network design has very little internal firewalling - the
> majority of the protection for offices, labs, classrooms, wireless, and
> anything other than University-wide Admin applications is the border
> firewall. So putting guests on the outside, and faculty, staff and students
> on the inside is important.
>
> Additionally the firewall for the eduroam network is set up to allow the
> minimum ports required by the eduroam agreement, so that when our faculty,
> staff and students test that something works on eduroam before they travel,
> they are reasonably well guaranteed it will work on any eduroam net
> anywhere. With our change from Meru/Radiator to Aruban/Clearpass last
> summer, it’s likely that it would be much simpler to drop eduroam users
> that are local onto a “different” version of eduroam that was on the campus
> side of the border firewall, but then the user experience on eduroam here
> would not be the same experience as if they were at a different site
> providing eduroam. Both in what ports were allowed in/out of the eduroam
> network and much more importantly how connections to campus resources
> function for networks off-campus. We want users to have a consistent
> experience with how eduroam works for their use cases, regardless of
> whether they are on our campus or somewhere else.
>
>
> To answer the other questions, we currently have 3 non-eduroam SSIDs
>
> our main SSID that is inside the campus board firewalls is 802.1x we have
> an open guest SSID that uses the Clearpass guest captive portal system we
> have a devices SSID that is MAC auth but I believe this one is being phased
> out in favor of using features in ClearPass to do something similar. This
> is mostly for gaming consoles and the things that really can’t do 802.1x.
>
>
> It’s been quite a few years since I ran the wireless network on our
> campus, but I believe I’ve got the current technical details correct, Chuck
> can correct me if I got anything wrong.
>
>
> --
> -debbie
> Debbie Fligor, n9dn   Lead Network Engineer @ Univ. of Il at
> Urbana-Champaign
> email: fli...@illinois.edu
>
>
>
> > On Apr 24, 2017, at 14:18, Marcelo Maraboli <marcelo.marab...@uc.cl>
> wrote:
> >
> > I would like to thank all who responded.
> >
> > Everybody who responded is making EduRoam their main SSID
> > deprecating their old SSID (MAC or .1x).
> >
> > I still wonder why Universities like MIT,Harvard,Stanford and Berkeley
> > only use Eduroam as a secondary SSID and still keep their main SSID.
> > The only thing I can think of is branding.
> >
> >
> >
> > thanks.
> >
> >
> > On 4/20/17 6:16 PM, Marcelo Maraboli wrote:
> >> 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

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

[Stephen Belcher]

That is the same situation with WVU. We maintain WVU.Encrypted for faculty, 
staff and students. We treat those users as “on campus”. 

We treat WVU.Guest and Eduroam as “off campus".


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Fligor, Debbie
Sent: Monday, April 24, 2017 4:38 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

I can’t speak for the campuses you named, but we have not switched to eduroam 
as our main SSID, and we have no current plans to. I’m sure someone is happy 
about the branding somewhere, but it’s also for technical reasons. Eduroam, 
like our guest wireless, is routed outside our campus border firewall. When you 
are on our campus's IllinoisNet SSID you are on the campus side of the border 
firewall and have more access to campus resources than you do when you are on 
the eduroam SSID or our IllinoisNet_Guest SSID.  Our campus network design has 
very little internal firewalling - the majority of the protection for offices, 
labs, classrooms, wireless, and anything other than University-wide Admin 
applications is the border firewall. So putting guests on the outside, and 
faculty, staff and students on the inside is important. 

Additionally the firewall for the eduroam network is set up to allow the 
minimum ports required by the eduroam agreement, so that when our faculty, 
staff and students test that something works on eduroam before they travel, 
they are reasonably well guaranteed it will work on any eduroam net anywhere. 
With our change from Meru/Radiator to Aruban/Clearpass last summer, it’s likely 
that it would be much simpler to drop eduroam users that are local onto a 
“different” version of eduroam that was on the campus side of the border 
firewall, but then the user experience on eduroam here would not be the same 
experience as if they were at a different site providing eduroam. Both in what 
ports were allowed in/out of the eduroam network and much more importantly how 
connections to campus resources function for networks off-campus. We want users 
to have a consistent experience with how eduroam works for their use cases, 
regardless of whether they are on our campus or somewhere else.


To answer the other questions, we currently have 3 non-eduroam SSIDs

our main SSID that is inside the campus board firewalls is 802.1x we have an 
open guest SSID that uses the Clearpass guest captive portal system we have a 
devices SSID that is MAC auth but I believe this one is being phased out in 
favor of using features in ClearPass to do something similar. This is mostly 
for gaming consoles and the things that really can’t do 802.1x.


It’s been quite a few years since I ran the wireless network on our campus, but 
I believe I’ve got the current technical details correct, Chuck can correct me 
if I got anything wrong.


-- 
-debbie
Debbie Fligor, n9dn   Lead Network Engineer @ Univ. of Il at 
Urbana-Champaign
email: fli...@illinois.edu 



> On Apr 24, 2017, at 14:18, Marcelo Maraboli <marcelo.marab...@uc.cl> wrote:
> 
> I would like to thank all who responded.
> 
> Everybody who responded is making EduRoam their main SSID
> deprecating their old SSID (MAC or .1x).
> 
> I still wonder why Universities like MIT,Harvard,Stanford and Berkeley
> only use Eduroam as a secondary SSID and still keep their main SSID.
> The only thing I can think of is branding.
> 
> 
> 
> thanks.
> 
> 
> On 4/20/17 6:16 PM, Marcelo Maraboli wrote:
>> 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 ? 
>> 
>> 












**
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)

[Brian Helman]

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 1:52 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Hello Brian.  SLU-users has more direct access to internal services like file 
and print services that we didn't want to provide to eduroam users.  If we were 
ever to lock down SLU-users more to require VPN access to all internal 
resources, I think we'd recommend re-evaluating our SSIDs.

On Mon, Apr 24, 2017 at 8:14 AM, Brian Helman 
<bhel...@salemstate.edu<mailto:bhel...@salemstate.edu>> wrote:
John,

Do you know what the thought process was behind maintaining both an EDUROAM 
SSID as well as your SLU-users?  I’m just firing up our SSID for EDUROAM 
university-wide this week, so it would be the summer before our legacy SSID 
would go away.  If there is a compelling reason that we haven’t discovered for 
keeping the legacy SSID, I certainly don’t want to get rid of it.

-Brian

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>]
 On Behalf Of John Heartlein
Sent: Friday, April 21, 2017 5:08 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Saint Louis University deployed eduroam in late 2015.  Besides eduroam we have 
an 802.1x SSID SLU-users for our students, faculty, and staff.  We also have 
SLUguest for guests and legacy devices.  Here's a link to more information:

https://www.slu.edu/its/services-and-products/internet-and-network-services/wireless-networks-at-slu

On Fri, Apr 21, 2017 at 12:30 PM, Brian Helman 
<bhel...@salemstate.edu<mailto:bhel...@salemstate.edu>> wrote:
We have moved into the “testing” phase of our EDUROAM connectivity.  I’m hoping 
to fire up the EDUROAM SSID university-wide next week.  Currently, we have a 
.1x SSID that will stay through the summer.  Once EDUROAM is fully pushed, 
we’ll start our advertisement campaign to get people to log in to it.  I would 
have waited until the summer to fire up EDUROAM so it is just available when 
everyone returns in the fall, but there’s such a strong benefit for our 
students, staff and faculty if they are traveling over the summer that I want 
to get it to them.

There will be no “force move”, but the old .1x SSID won’t be available in the 
fall, so it benefits them to change their config now.   One note, we don’t 
currently support devices that do not support WPA/2 Enterprise (.1x) on our 
wireless network.  Essentially, we’re talking about gaming consoles (whether 
they support .1x or not), smart tv’s and media devices.  Students are told 
those devices need to be Ethernet-capable.  I suspect we’re at least another 
year away from supporting non-WPA/2 Ent devices on our wireless network.

From what I have seen and it my discussions with our peers at other 
institutions, unless there is a marketing reason the .1x auths are via EDUROAM 
and the branded SSID’s are either specialized or they go away.

-Brian

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>]
 On Behalf Of Bucklaew, Jerry
Sent: Friday, April 21, 2017 8:35 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

We are currently moving to eduraom as the primary ssid.   We are doing a 
communication campaign and will retire the old 802.1x ssid at some point.  We 
do have a non802.1x ssid for “other” devices.  It is a “start here” ssid that 
will also configure you for 802.1x.

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Marcelo Maraboli
Sent: Thursday, April 20, 2017 5:17 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto: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

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

[John Heartlein]

Hello Brian.  SLU-users has more direct access to internal services like
file and print services that we didn't want to provide to eduroam users.
If we were ever to lock down SLU-users more to require VPN access to all
internal resources, I think we'd recommend re-evaluating our SSIDs.

On Mon, Apr 24, 2017 at 8:14 AM, Brian Helman <bhel...@salemstate.edu>
wrote:

> John,
>
>
>
> Do you know what the thought process was behind maintaining both an
> EDUROAM SSID as well as your SLU-users?  I’m just firing up our SSID for
> EDUROAM university-wide this week, so it would be the summer before our
> legacy SSID would go away.  If there is a compelling reason that we haven’t
> discovered for keeping the legacy SSID, I certainly don’t want to get rid
> of it.
>
>
>
> -Brian
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *John Heartlein
> *Sent:* Friday, April 21, 2017 5:08 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>
>
>
> Saint Louis University deployed eduroam in late 2015.  Besides eduroam we
> have an 802.1x SSID SLU-users for our students, faculty, and staff.  We
> also have SLUguest for guests and legacy devices.  Here's a link to more
> information:
>
>
>
> https://www.slu.edu/its/services-and-products/
> internet-and-network-services/wireless-networks-at-slu
>
>
>
> On Fri, Apr 21, 2017 at 12:30 PM, Brian Helman <bhel...@salemstate.edu>
> wrote:
>
> We have moved into the “testing” phase of our EDUROAM connectivity.  I’m
> hoping to fire up the EDUROAM SSID university-wide next week.  Currently,
> we have a .1x SSID that will stay through the summer.  Once EDUROAM is
> fully pushed, we’ll start our advertisement campaign to get people to log
> in to it.  I would have waited until the summer to fire up EDUROAM so it is
> just available when everyone returns in the fall, but there’s such a strong
> benefit for our students, staff and faculty if they are traveling over the
> summer that I want to get it to them.
>
>
>
> There will be no “force move”, but the old .1x SSID won’t be available in
> the fall, so it benefits them to change their config now.   One note, we
> don’t currently support devices that do not support WPA/2 Enterprise (.1x)
> on our wireless network.  Essentially, we’re talking about gaming consoles
> (whether they support .1x or not), smart tv’s and media devices.  Students
> are told those devices need to be Ethernet-capable.  I suspect we’re at
> least another year away from supporting non-WPA/2 Ent devices on our
> wireless network.
>
>
>
> From what I have seen and it my discussions with our peers at other
> institutions, unless there is a marketing reason the .1x auths are via
> EDUROAM and the branded SSID’s are either specialized or they go away.
>
>
>
> -Brian
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Bucklaew, Jerry
> *Sent:* Friday, April 21, 2017 8:35 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>
>
>
> We are currently moving to eduraom as the primary ssid.   We are doing a
> communication campaign and will retire the old 802.1x ssid at some point.
> We do have a non802.1x ssid for “other” devices.  It is a “start here” ssid
> that will also configure you for 802.1x.
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] *On Behalf Of *Marcelo Maraboli
> *Sent:* Thursday, April 20, 2017 5:17 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 

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

[Fligor, Debbie]

I can’t speak for the campuses you named, but we have not switched to eduroam 
as our main SSID, and we have no current plans to. I’m sure someone is happy 
about the branding somewhere, but it’s also for technical reasons. Eduroam, 
like our guest wireless, is routed outside our campus border firewall. When you 
are on our campus's IllinoisNet SSID you are on the campus side of the border 
firewall and have more access to campus resources than you do when you are on 
the eduroam SSID or our IllinoisNet_Guest SSID.  Our campus network design has 
very little internal firewalling - the majority of the protection for offices, 
labs, classrooms, wireless, and anything other than University-wide Admin 
applications is the border firewall. So putting guests on the outside, and 
faculty, staff and students on the inside is important. 

Additionally the firewall for the eduroam network is set up to allow the 
minimum ports required by the eduroam agreement, so that when our faculty, 
staff and students test that something works on eduroam before they travel, 
they are reasonably well guaranteed it will work on any eduroam net anywhere. 
With our change from Meru/Radiator to Aruban/Clearpass last summer, it’s likely 
that it would be much simpler to drop eduroam users that are local onto a 
“different” version of eduroam that was on the campus side of the border 
firewall, but then the user experience on eduroam here would not be the same 
experience as if they were at a different site providing eduroam. Both in what 
ports were allowed in/out of the eduroam network and much more importantly how 
connections to campus resources function for networks off-campus. We want users 
to have a consistent experience with how eduroam works for their use cases, 
regardless of whether they are on our campus or somewhere else.


To answer the other questions, we currently have 3 non-eduroam SSIDs

our main SSID that is inside the campus board firewalls is 802.1x 
we have an open guest SSID that uses the Clearpass guest captive portal system
we have a devices SSID that is MAC auth but I believe this one is being phased 
out in favor of using features in ClearPass to do something similar. This is 
mostly for gaming consoles and the things that really can’t do 802.1x.


It’s been quite a few years since I ran the wireless network on our campus, but 
I believe I’ve got the current technical details correct, Chuck can correct me 
if I got anything wrong.


-- 
-debbie
Debbie Fligor, n9dn   Lead Network Engineer @ Univ. of Il at 
Urbana-Champaign
email: fli...@illinois.edu 



> On Apr 24, 2017, at 14:18, Marcelo Maraboli  wrote:
> 
> I would like to thank all who responded.
> 
> Everybody who responded is making EduRoam their main SSID
> deprecating their old SSID (MAC or .1x).
> 
> I still wonder why Universities like MIT,Harvard,Stanford and Berkeley
> only use Eduroam as a secondary SSID and still keep their main SSID.
> The only thing I can think of is branding.
> 
> 
> 
> thanks.
> 
> 
> On 4/20/17 6:16 PM, Marcelo Maraboli wrote:
>> 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 ? 
>> 
>> 












**
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)

[John Kristoff]

On Mon, 24 Apr 2017 19:18:51 +
Marcelo Maraboli  wrote:

> I still wonder why Universities like MIT,Harvard,Stanford and Berkeley
> only use Eduroam as a secondary SSID and still keep their main SSID.
> The only thing I can think of is branding.

Branding and inertia of the installed base may preclude an easy change.
I've also heard it suggested that in dense areas, if you connect to the
"wrong" eduroam, not being on the network you expect to be on may cause
some access-related problems for those that use them based on SSID or
assignment wireless network address/id.

John

**
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)

[Marcelo Maraboli]

I would like to thank all who responded.

Everybody who responded is making EduRoam their main SSID
deprecating their old SSID (MAC or .1x).

I still wonder why Universities like MIT,Harvard,Stanford and Berkeley
only use Eduroam as a secondary SSID and still keep their main SSID.
The only thing I can think of is branding.



thanks.


On 4/20/17 6:16 PM, Marcelo Maraboli wrote:

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.




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

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

[Marcelo Maraboli]

Hello Jason

thank you for you thorough response.

You should maybe check Radiator instead of Freeradius, since
it makes life much easier with 802.1x and all the complexities
you mentioned.

We will deploy Eduroam/802.1x with Radiator since we too have
some complexities and Freeradius is a painin programmability.


best regards,


On 4/24/17 1:11 PM, Trinklein, Jason R wrote:


We are in the process of migrating to eduroam as our primary SSID 
also. We introduced eduroam to our campus in August 2016. Our original 
college-branded secure wireless network was already 802.1x, so we 
don’t need to worry about supporting legacy devices by holding back a 
legacy SSID. We did some advertising in multiple school publications 
when eduroam was first turned on, but we still only saw 1-2% of our 
users on eduroam.


We are migrating from our college-branded SSID to eduroam for a few 
reasons:


- The two networks are functionally identical since we are using 
dynamic VLAN assignment


- We can clean up wireless SSID broadcast packets by reducing the SSID 
count


- Migration to a single eduroam SSID seems to be the trend in higher 
education


- Ensures that the college community is in a position to take 
advantage of eduroam, since without its wide adoption in this manner, 
few people would know it was there.


We have a 9 step approach for migrating to eduroam:

1.Notify IT personnel and helpdesk about the change

2.Update onboarding tools to onboard to eduroam instead of 
college-branded SSID


3.Creation of eduroam informational website, videos, and tutorials

4.Campus-wide poster advertisement campaign

5.Campus-wide email advertisement campaign

6.Captive portal on college-branded SSID notifying users of upcoming 
change


7.Stop broadcast of college-branded SSID

8.Captive portal on college-branded SSID with no internet access, 
notifying users they must switch to eduroam


9.Disable the college-branded SSID

We expect to reach step 9 by December-January, so it’s a 10 month 
transitional plan. Hopefully it introduces the least amount of 
confusion and interruption to wireless service and experience.


Our current challenges are supporting Active-Directory member 
computers on eduroam, since the domain username doesn’t comply with 
eduroam username formatting requirements (with the appended 
@domain.edu). First, the FreeRADIUS server dumps any authentications 
without @domain.edu, and domain systems’ machine accounts authenticate 
with a host/systemname format. I introduced conditionals in the 
FreeRADIUS configuration to allow authentication if the username 
begins with host/. This allows uncached user logins from Windows by 
allowing the machine to associate with eduroam, pre-login. Presently, 
we’re working on getting Mac domain-joined systems to work correctly, 
since they try to join the wireless network with the same username of 
the person who logged in, which often lacks the @domain.edu appendage. 
We are investigating script options to programmatically remediate the 
issue instead of relying on workforce re-education on login procedure.


--

*Jason Trinklein*

/Wireless Engineering Manager/

College of Charleston

81 St. Philip Street | Office 311D | Charleston, SC 29403

trinkle...@cofc.edu <mailto:trinkle...@cofc.edu> | (843) 300–8009

*From: *The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Marcelo Maraboli 
<marcelo.marab...@uc.cl>

*Organization: *UC
*Reply-To: *The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>

*Date: *Thursday, April 20, 2017 at 5:16 PM
*To: *"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
<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/ 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__informatica.uc.cl_=DwMDaQ=7MSSWy9Bs2yocjNQzurxOQ=AuveJXIorHW4s-aGSHEbnQZt5LubWGCZik-5HxxaRqU=mwgRV4dz51nmKO4n7zUvVkBMW8jqu0eV6qmsDi8Wfp8=KPJNn9_5O7gqyGZHvcRp87kqBmeDRJHVETfPPcgJwbY=>

--
Campus San Joaquín, Av. Vicuña Mackenna 4860, Macul
Santiago, C

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

[Hunter Fuller]

On Thu, Apr 20, 2017 at 4:30 PM Marcelo Maraboli 
wrote:

> - Did you leave an SSID for legacy devices ? (What AUTH mechanism for this
> SSID?)
>

Our "UAH Get Connected" ESSID is wide open, and will assist users with
connecting to eduroam. It also doubles as our legacy/gaming/streaming
device ESSID.


> - How did you "force-move" your users to EdoROAM from your old SSID ?
>

We are in the process of doing this. We've publicly given warning about
moving to eduroam for about a year via email and usual advertisement
channels. Later this year, our legacy ESSIDs will be turned off.

**
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)

[Philippe Hanset]

All,

I recently did a presentation to the business school at University of 
Tennessee. UT uses eduroam as the only secure SSID. They all knew about 
eduroam. And when I asked the audience of 60 or so students how many knew that 
it works seamlessly around the world, only 3 students raised their hands! 
Professors knew about it but not students. In your outreach campaign/material 
please  make sure to emphasize the roaming aspect. It is seems to be easily 
forgotten over time.

Thanks,

Philippe

Philippe Hanset
www.anyroam.net
www.eduroam.us

> On Apr 24, 2017, at 12:11 PM, Trinklein, Jason R <trinkle...@cofc.edu> wrote:
> 
> We are in the process of migrating to eduroam as our primary SSID also. We 
> introduced eduroam to our campus in August 2016. Our original college-branded 
> secure wireless network was already 802.1x, so we don’t need to worry about 
> supporting legacy devices by holding back a legacy SSID. We did some 
> advertising in multiple school publications when eduroam was first turned on, 
> but we still only saw 1-2% of our users on eduroam.
>  
> We are migrating from our college-branded SSID to eduroam for a few reasons:
> - The two networks are functionally identical since we are using dynamic VLAN 
> assignment
> - We can clean up wireless SSID broadcast packets by reducing the SSID count
> - Migration to a single eduroam SSID seems to be the trend in higher education
> - Ensures that the college community is in a position to take advantage of 
> eduroam, since without its wide adoption in this manner, few people would 
> know it was there.
>  
> We have a 9 step approach for migrating to eduroam:
> 1.   Notify IT personnel and helpdesk about the change
> 2.   Update onboarding tools to onboard to eduroam instead of 
> college-branded SSID
> 3.   Creation of eduroam informational website, videos, and tutorials
> 4.   Campus-wide poster advertisement campaign
> 5.   Campus-wide email advertisement campaign
> 6.   Captive portal on college-branded SSID notifying users of upcoming 
> change
> 7.   Stop broadcast of college-branded SSID
> 8.   Captive portal on college-branded SSID with no internet access, 
> notifying users they must switch to eduroam
> 9.   Disable the college-branded SSID
>  
> We expect to reach step 9 by December-January, so it’s a 10 month 
> transitional plan. Hopefully it introduces the least amount of confusion and 
> interruption to wireless service and experience.
>  
> Our current challenges are supporting Active-Directory member computers on 
> eduroam, since the domain username doesn’t comply with eduroam username 
> formatting requirements (with the appended @domain.edu). First, the 
> FreeRADIUS server dumps any authentications without @domain.edu, and domain 
> systems’ machine accounts authenticate with a host/systemname format. I 
> introduced conditionals in the FreeRADIUS configuration to allow 
> authentication if the username begins with host/. This allows uncached user 
> logins from Windows by allowing the machine to associate with eduroam, 
> pre-login. Presently, we’re working on getting Mac domain-joined systems to 
> work correctly, since they try to join the wireless network with the same 
> username of the person who logged in, which often lacks the @domain.edu 
> appendage. We are investigating script options to programmatically remediate 
> the issue instead of relying on workforce re-education on login procedure.
>  
> -- 
> Jason Trinklein
> Wireless Engineering Manager
> College of Charleston
> 81 St. Philip Street | Office 311D | Charleston, SC 29403
> trinkle...@cofc.edu | (843) 300–8009
>  
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Marcelo Maraboli 
> <marcelo.marab...@uc.cl>
> Organization: UC
> Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> Date: Thursday, April 20, 2017 at 5:16 PM
> To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" <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 n

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

[Trinklein, Jason R]

We are in the process of migrating to eduroam as our primary SSID also. We 
introduced eduroam to our campus in August 2016. Our original college-branded 
secure wireless network was already 802.1x, so we don’t need to worry about 
supporting legacy devices by holding back a legacy SSID. We did some 
advertising in multiple school publications when eduroam was first turned on, 
but we still only saw 1-2% of our users on eduroam.

We are migrating from our college-branded SSID to eduroam for a few reasons:
- The two networks are functionally identical since we are using dynamic VLAN 
assignment
- We can clean up wireless SSID broadcast packets by reducing the SSID count
- Migration to a single eduroam SSID seems to be the trend in higher education
- Ensures that the college community is in a position to take advantage of 
eduroam, since without its wide adoption in this manner, few people would know 
it was there.

We have a 9 step approach for migrating to eduroam:

1.   Notify IT personnel and helpdesk about the change

2.   Update onboarding tools to onboard to eduroam instead of 
college-branded SSID

3.   Creation of eduroam informational website, videos, and tutorials

4.   Campus-wide poster advertisement campaign

5.   Campus-wide email advertisement campaign

6.   Captive portal on college-branded SSID notifying users of upcoming 
change

7.   Stop broadcast of college-branded SSID

8.   Captive portal on college-branded SSID with no internet access, 
notifying users they must switch to eduroam

9.   Disable the college-branded SSID

We expect to reach step 9 by December-January, so it’s a 10 month transitional 
plan. Hopefully it introduces the least amount of confusion and interruption to 
wireless service and experience.

Our current challenges are supporting Active-Directory member computers on 
eduroam, since the domain username doesn’t comply with eduroam username 
formatting requirements (with the appended @domain.edu). First, the FreeRADIUS 
server dumps any authentications without @domain.edu, and domain systems’ 
machine accounts authenticate with a host/systemname format. I introduced 
conditionals in the FreeRADIUS configuration to allow authentication if the 
username begins with host/. This allows uncached user logins from Windows by 
allowing the machine to associate with eduroam, pre-login. Presently, we’re 
working on getting Mac domain-joined systems to work correctly, since they try 
to join the wireless network with the same username of the person who logged 
in, which often lacks the @domain.edu appendage. We are investigating script 
options to programmatically remediate the issue instead of relying on workforce 
re-education on login procedure.

--
Jason Trinklein
Wireless Engineering Manager
College of Charleston
81 St. Philip Street | Office 311D | Charleston, SC 29403
trinkle...@cofc.edu<mailto:trinkle...@cofc.edu> | (843) 300–8009

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Marcelo Maraboli 
<marcelo.marab...@uc.cl>
Organization: UC
Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Date: Thursday, April 20, 2017 at 5:16 PM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" <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/<https://urldefense.proofpoint.com/v2/url?u=http-3A__informatica.uc.cl_=DwMDaQ=7MSSWy9Bs2yocjNQzurxOQ=AuveJXIorHW4s-aGSHEbnQZt5LubWGCZik-5HxxaRqU=mwgRV4dz51nmKO4n7zUvVkBMW8jqu0eV6qmsDi8Wfp8=KPJNn9_5O7gqyGZHvcRp87kqBmeDRJHVETfPPcgJwbY=>
--
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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.educause.edu_discuss=DwMDaQ=7MSSWy9Bs2yocjNQzurxOQ=AuveJXIorHW4s-aGSHEbnQZt5LubWGCZik-5HxxaRqU=mwgRV4dz51nmKO4n7zUvVkBMW8jq

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

[Brian Helman]

John,

Do you know what the thought process was behind maintaining both an EDUROAM 
SSID as well as your SLU-users?  I’m just firing up our SSID for EDUROAM 
university-wide this week, so it would be the summer before our legacy SSID 
would go away.  If there is a compelling reason that we haven’t discovered for 
keeping the legacy SSID, I certainly don’t want to get rid of it.

-Brian

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of John Heartlein
Sent: Friday, April 21, 2017 5:08 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

Saint Louis University deployed eduroam in late 2015.  Besides eduroam we have 
an 802.1x SSID SLU-users for our students, faculty, and staff.  We also have 
SLUguest for guests and legacy devices.  Here's a link to more information:

https://www.slu.edu/its/services-and-products/internet-and-network-services/wireless-networks-at-slu

On Fri, Apr 21, 2017 at 12:30 PM, Brian Helman 
<bhel...@salemstate.edu<mailto:bhel...@salemstate.edu>> wrote:
We have moved into the “testing” phase of our EDUROAM connectivity.  I’m hoping 
to fire up the EDUROAM SSID university-wide next week.  Currently, we have a 
.1x SSID that will stay through the summer.  Once EDUROAM is fully pushed, 
we’ll start our advertisement campaign to get people to log in to it.  I would 
have waited until the summer to fire up EDUROAM so it is just available when 
everyone returns in the fall, but there’s such a strong benefit for our 
students, staff and faculty if they are traveling over the summer that I want 
to get it to them.

There will be no “force move”, but the old .1x SSID won’t be available in the 
fall, so it benefits them to change their config now.   One note, we don’t 
currently support devices that do not support WPA/2 Enterprise (.1x) on our 
wireless network.  Essentially, we’re talking about gaming consoles (whether 
they support .1x or not), smart tv’s and media devices.  Students are told 
those devices need to be Ethernet-capable.  I suspect we’re at least another 
year away from supporting non-WPA/2 Ent devices on our wireless network.

From what I have seen and it my discussions with our peers at other 
institutions, unless there is a marketing reason the .1x auths are via EDUROAM 
and the branded SSID’s are either specialized or they go away.

-Brian

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>]
 On Behalf Of Bucklaew, Jerry
Sent: Friday, April 21, 2017 8:35 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

We are currently moving to eduraom as the primary ssid.   We are doing a 
communication campaign and will retire the old 802.1x ssid at some point.  We 
do have a non802.1x ssid for “other” devices.  It is a “start here” ssid that 
will also configure you for 802.1x.

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Marcelo Maraboli
Sent: Thursday, April 20, 2017 5:17 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto: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/<https://urldefense.proofpoint.com/v2/url?u=http-3A__informatica.uc.cl_=DwMGaQ=Pk_HpaIpE_jAoEC9PLIWoQ=irT60-I-yL1W4SGW22eq3Q=b4OwnNC5GQ_5JzNqfo9xV_eIQpeNn1TLjXNDkysa6Ao=W7T1LWTYU_vQnYw0nOAnrzqdqHQLBeKLGDI_pknEjdU=>
--
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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.educause.edu_discuss=DwMGaQ=Pk_HpaIpE_jAoEC9PLIWoQ=irT60-I-yL1W4SGW22eq3Q=b4OwnNC5GQ_5JzNqfo9xV_eIQpeNn1TLjXNDkysa6Ao=rn0F6ESIotiVL131yKhw_PqTou4PLW1_SCuxJuNFGh8=>.
*

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

[John Heartlein]

Saint Louis University deployed eduroam in late 2015.  Besides eduroam we
have an 802.1x SSID SLU-users for our students, faculty, and staff.  We
also have SLUguest for guests and legacy devices.  Here's a link to more
information:

https://www.slu.edu/its/services-and-products/internet-and-network-services/wireless-networks-at-slu

On Fri, Apr 21, 2017 at 12:30 PM, Brian Helman <bhel...@salemstate.edu>
wrote:

> We have moved into the “testing” phase of our EDUROAM connectivity.  I’m
> hoping to fire up the EDUROAM SSID university-wide next week.  Currently,
> we have a .1x SSID that will stay through the summer.  Once EDUROAM is
> fully pushed, we’ll start our advertisement campaign to get people to log
> in to it.  I would have waited until the summer to fire up EDUROAM so it is
> just available when everyone returns in the fall, but there’s such a strong
> benefit for our students, staff and faculty if they are traveling over the
> summer that I want to get it to them.
>
>
>
> There will be no “force move”, but the old .1x SSID won’t be available in
> the fall, so it benefits them to change their config now.   One note, we
> don’t currently support devices that do not support WPA/2 Enterprise (.1x)
> on our wireless network.  Essentially, we’re talking about gaming consoles
> (whether they support .1x or not), smart tv’s and media devices.  Students
> are told those devices need to be Ethernet-capable.  I suspect we’re at
> least another year away from supporting non-WPA/2 Ent devices on our
> wireless network.
>
>
>
> From what I have seen and it my discussions with our peers at other
> institutions, unless there is a marketing reason the .1x auths are via
> EDUROAM and the branded SSID’s are either specialized or they go away.
>
>
>
> -Brian
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Bucklaew, Jerry
> *Sent:* Friday, April 21, 2017 8:35 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
>
>
>
> We are currently moving to eduraom as the primary ssid.   We are doing a
> communication campaign and will retire the old 802.1x ssid at some point.
> We do have a non802.1x ssid for “other” devices.  It is a “start here” ssid
> that will also configure you for 802.1x.
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] *On Behalf Of *Marcelo Maraboli
> *Sent:* Thursday, April 20, 2017 5:17 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/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__informatica.uc.cl_=DwMGaQ=Pk_HpaIpE_jAoEC9PLIWoQ=irT60-I-yL1W4SGW22eq3Q=b4OwnNC5GQ_5JzNqfo9xV_eIQpeNn1TLjXNDkysa6Ao=W7T1LWTYU_vQnYw0nOAnrzqdqHQLBeKLGDI_pknEjdU=>
> --
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.educause.edu_discuss=DwMGaQ=Pk_HpaIpE_jAoEC9PLIWoQ=irT60-I-yL1W4SGW22eq3Q=b4OwnNC5GQ_5JzNqfo9xV_eIQpeNn1TLjXNDkysa6Ao=rn0F6ESIotiVL131yKhw_PqTou4PLW1_SCuxJuNFGh8=>.
>
>
> ** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at http://www.educause.edu/
> discuss
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.educause.edu_discuss=DwMGaQ=Pk_HpaIpE_jAoEC9PLIWoQ=irT60-I-yL1W4SGW22eq3Q=b4OwnNC5GQ_5JzNqfo9xV_eIQpeNn1TLjXNDkysa6Ao=rn

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

[Brian Helman]

We have moved into the “testing” phase of our EDUROAM connectivity.  I’m hoping 
to fire up the EDUROAM SSID university-wide next week.  Currently, we have a 
.1x SSID that will stay through the summer.  Once EDUROAM is fully pushed, 
we’ll start our advertisement campaign to get people to log in to it.  I would 
have waited until the summer to fire up EDUROAM so it is just available when 
everyone returns in the fall, but there’s such a strong benefit for our 
students, staff and faculty if they are traveling over the summer that I want 
to get it to them.

There will be no “force move”, but the old .1x SSID won’t be available in the 
fall, so it benefits them to change their config now.   One note, we don’t 
currently support devices that do not support WPA/2 Enterprise (.1x) on our 
wireless network.  Essentially, we’re talking about gaming consoles (whether 
they support .1x or not), smart tv’s and media devices.  Students are told 
those devices need to be Ethernet-capable.  I suspect we’re at least another 
year away from supporting non-WPA/2 Ent devices on our wireless network.

From what I have seen and it my discussions with our peers at other 
institutions, unless there is a marketing reason the .1x auths are via EDUROAM 
and the branded SSID’s are either specialized or they go away.

-Brian

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Bucklaew, Jerry
Sent: Friday, April 21, 2017 8:35 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam adoption (and migration process)

We are currently moving to eduraom as the primary ssid.   We are doing a 
communication campaign and will retire the old 802.1x ssid at some point.  We 
do have a non802.1x ssid for “other” devices.  It is a “start here” ssid that 
will also configure you for 802.1x.

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Marcelo Maraboli
Sent: Thursday, April 20, 2017 5:17 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto: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.

**
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)

[Bucklaew, Jerry]

We are currently moving to eduraom as the primary ssid.   We are doing a 
communication campaign and will retire the old 802.1x ssid at some point.  We 
do have a non802.1x ssid for “other” devices.  It is a “start here” ssid that 
will also configure you for 802.1x.

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Marcelo Maraboli
Sent: Thursday, April 20, 2017 5:17 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)

[Manon Lessard]

Hi


Eduroam is our primary SSID: when we moved to it, we kept  an old 802.1x which 
we discontinued 1 month after the beginning of the school year. We  still kept 
an open SSID to allow legacy devices to access the network with a VPN 
authentication. We massively advertised and updated all the information 
available to people on campus to make it very clear they had to be on Eduroam.

Cheers!

Manon Lessard
Technicienne en développement de systèmes
CCNP, CWNA, CWDP
Direction des technologies de l'information
Pavillon Louis-Jacques-Casault
1055, avenue du Séminaire
Bureau 0403
Université Laval, Québec (Québec)
G1V 0A6, Canada

418 656-2131, poste 12853
Télécopieur : 418 656-7305
manon.less...@dti.ulaval.ca<mailto:manon.less...@dti.ulaval.ca>
www.dti.ulaval.ca<http://www.dti.ulaval.ca/>

Avis relatif à la confidentialité | Notice of 
Confidentiality<http://www.rec.ulaval.ca/lce/securite/confidentialite.htm>



[Description : Description : Description : Description : Description : 
Description : Description : Description : Description : Description : 
Description : Description : Description : Description : Description : 
Description : Description : Description : Description : Logo de l'Université 
Laval]



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Marcelo Maraboli
Sent: 20 avril 2017 17:17
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.