Our campus isn't comfortable with an open ESSID without verifying the identity of the user, so that's the value of eduroam - identity.
On Tue, Aug 15, 2017 at 10:47 Jeffrey D. Sessler <[email protected]> wrote: > Couple of comments: > > > > - eduroam – using your point of “…most users can access what they want > off-campus…”, what long-term value is there to eduroam? IMHO – not at lot. > Back in the day, this would facilitate quick access for a visiting educator > who may be collaborating with someone locally and needing access to local > resources. Today, in age of cloud-based collaboration platforms and access > from anywhere, how important is eduroam over an open wifi network? With few > exceptions, all the visitor needs is Internet access. eduroam doesn’t add > value here, but does add complexity to manage. > - Location data – Yeah, this can have some value, but at least here, > our emergency management moved to mobile-based applications that allow the > user to opt-in to being tracked with the addition of panic-button-like > services. I tend to shy away from using location-based services within WiFi > where life-safety is involved. It can be a wonderful tool, until it doesn’t > work that one-time management believes it should. In other words, finding a > missing AV cart is different than a missing person. > > Jeff > > > > On 8/14/17, 7:23 PM, "The EDUCAUSE Wireless Issues Constituent Group > Listserv on behalf of Jason Cook" <[email protected] on > behalf of [email protected]> wrote: > > > > This is a good topic, we are slowly moving towards a preferred EAP-TLS > from PEAP-MChapv2 but not current date to force and perhaps never. The > points made about why do we bother at all though are pretty relevant, most > users can access what they want off-campus from whatever network they want, > and VPN for more restricted access. So a properly segmented internal > network providing appropriate access would be fine. *PSK/ open networks are > theoretically ok. > > > > At this point we are still confident that dot1x based auth is still > the best way to go for users accessing our wifi, though this discussion has > certainly opened my eyes a lot. > > > > > > There's a couple of other reasons though why dot1x (which ever method) > does have advantages to us. This may not be relevant to all, and there > maybe better/other ways. > > > > eduroam will break down via other methods, so you'll still need to > manage a dot1x service no matter what. Then you have still have calls to SD > because the service is now different when you want to use it, requires > special setup that's different to on-campus.We've had Cloudpath a while, > originally for PEAP config and now TLS. We do roll with a main SSID so our > onboarding will configure our network UofA and eduroam and users will just > work wherever they go once done. > > > > Occasionally for security reasons we use location data to track > missing people. This is possible without auth to network data but it's > better having that auth data. Same goes for identifying users acting > inappropriately online. User ID to IP mapping is also fed into our firewall > for web filtering exceptions (including group and personal) > > > > Originally we went with Cloudpath to help users get configured easier > which worked well (though this is less of requirement with auto-configs now > pretty good), as well as properly since auto-config on OS's doesn't get the > certificate right (so it ensure proper config). Configuring eduroam at the > same time for windows was problematic however with PEAP (can't remember > other OS's). As it would only save 1 SSID User info properly, so the second > SSID it wouldn't save user ID and users would get prompted and not add the @ > adelaide.edu.au .. TLS resolves that little windows issue. > > > > So for us one additional positive the EAP-TLS over PEAP but overall > user-auth has its value. > > > > > > > > -- > > Jason Cook > > Technology Services > > The University of Adelaide, AUSTRALIA 5005 > > Ph : +61 8 8313 4800 > > > > -----Original Message----- > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: > [email protected]] On Behalf Of Lee H Badman > > Sent: Tuesday, 15 August 2017 2:59 AM > > To: [email protected] > > Subject: Re: [WIRELESS-LAN] EAP-TLS > > > > One interesting trade-off: if I have good AD credentials and pop up a > new Mac or Windows machine without any kind of onboarding in play, I will > get on the network quickly one way or the other with PEAP/MS-CHAPv2. . > Maybe I'm prompted to accept the server, but I'll get on. This is good and > bad. I got on, but not the way that the Security and Network folks might > have wanted me to get on- because the cert stuff is optional with > PEAP/MS-CHAPv2 on non-AD machines that you don't control. That's arguably > bad. > > > > But... I got on. And I got authentication and encryption, without IT > intervention. From the user perspective, this is good. I didn't have to > onboard, I didn't need IT help. I wasn't stranded if I didn't understand > what the onboarding SSID is all about, etc. > > > > With TLS- you get properly onboarded, or you're sucking wind until you > do. But once you do, TLS' advantages kick in as described in this thread. > But that "easy on" thing is gone... no matter how simple you make TLS > onboarding, it still requires end users to comprehend it. So, to me, part > of going to TLS is with the understanding that occasionally someone will be > stranded by their own lack of understanding the process, that somebody may > be someone important and/or vocal, the stranding will occur at the worst > time of day and in the worst circumstance in accordance with Murphey's Law, > and there will be some increase in related trouble calls. > > > > None of this negates TLS' value, but at the same time you have to go > into it with your eyes open to the perspective of the BYOD crowd on campus > versus what they are currently accustomed to. > > > > One man's o-pinion. > > > > -Lee > > > > Lee Badman | Network Architect > > > > Certified Wireless Network Expert (#200) Information Technology > Services > > 206 Machinery Hall > > 120 Smith Drive > > Syracuse, New York 13244 > > t 315.443.3003 f 315.443.4325 e [email protected] w its.syr.edu > SYRACUSE UNIVERSITY syr.edu > > > > > > -----Original Message----- > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: > [email protected]] On Behalf Of Curtis K. Larsen > > Sent: Monday, August 14, 2017 1:11 PM > > To: [email protected] > > Subject: Re: [WIRELESS-LAN] EAP-TLS > > > > Excellent Point. We did some testing with LDAP group lookups, etc. > vs. checking for an attribute in a user certificate for authorization and > found the performance to be significantly better for the same number of > authentications when *not* having to wait for LDAP. Another benefit is not > having to worry about users that have trouble typing passwords/getting > their account locked out for failed attempts. > > > > > > -- > > Curtis K. Larsen > > Senior Network Engineer > > University of Utah IT/CIS > > > > > > ________________________________________ > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv < > [email protected]> on behalf of Curtis, Bruce < > [email protected]> > > Sent: Monday, August 14, 2017 10:56 AM > > To: [email protected] > > Subject: Re: [WIRELESS-LAN] EAP-TLS > > > > > On Aug 11, 2017, at 7:45 AM, Bucklaew, Jerry <[email protected]> > wrote: > > > > > > To ALL: > > > > > > > > > > > > > > > > > > I am going to amend my initial request to "does anyone have any > other reasons to switch to eap-tls besides the ones I list below"? I am > trying to build a case for switching and want to gather all the benefits. > > > > One other benefit that I haven't seen mentioned in the thread yet is > that EAP-TLS removes dependency on Active Directory or other identity box. > > So an outage or slowdown of Active Directory (or other external box) > does not affect RADIUS and wireless logins. > > > > > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > > > [mailto:[email protected]] On Behalf Of Bucklaew, > > > Jerry > > > Sent: Thursday, August 10, 2017 3:36 PM > > > To: [email protected] > > > Subject: Re: [WIRELESS-LAN] EAP-TLS > > > > > > > > > > > > Lee, > > > > > > > > > > > > I want to state first that I am not, by any means, an expert on > all of the authentication standards and protocols. I was hoping someone > would have a document that would help better articulate the goals and > benefits. > > > > > > > > > > > > We have been a eap-peap shop for years and I have always been told > that eap-tls (cert based authentication) is more secure and you should do > that. I never had the time to deal with it and putting up a cert based > infrastructure just seemed daunting. I finally have some time and have > started to play with it. We are an Aruba shop and the clearpass Onboard > system seems pretty simple to implement and get EAP-TLS working. > > > > > > > > > > > > Now to the why. It seems that the ability to separate > username/password from network authentication has some benefits. If a > user changes his username/password it no longer affects his network > connectivity. If we want to blacklist a device it will be easy as each > device will have its own cert. So we can blacklist one device and let the > rest still on. We could do those things today but it is just a little > harder to do with eap-peap. We can also get users out of storing their > usernames and passwords, because everyone does it with eap-peap. The > thought process went, if you are going to run an on-board process anyway, > why not onboard with eap-tls. On the wireless side that is really all I > have. I have always been told it is more secure so have always thought I > should try and get there. > > > > > > > > > > > > Now, we are also moving to wired authentication on every port. We > are supporting both mac auth and 802.1x (eap-peap). We did this to get the > project moving and get all ports to some type of authentication. Now > 802.1x on the wired side is just plain difficult. Nothing except macs are > setup for it out of the box. You need admin rights on the machine to set > it up (which many people on the wired side don't have) and you almost have > to run through some type of onboard process to do it in mass. You have to > deal with stuff like network logons and mounting drives before > authentication. We also don't want the users storing usernames and password > and everyone will because no one wants to type it in every time. I am > back to the if you are going to run through an onboard process anyway, will > certs make it a little easier. It gives you the username/password > separation. The ability to revoke per device, and once onboarded, never > have to be bothered again (until the cert expires). > > > > > > > > > > > > I am not really concerned about peap being deprecated, it will be > around forever. I am not really concerned about usernames and passwords > being stolen because of eap-peap, there are so many easier ways to do > that. It guess it is really the username/password separation and the > "thought" that it is the most secure method. > > > > > > > > > > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > > > [mailto:[email protected]] On Behalf Of Lee H > Badman > > > Sent: Thursday, August 10, 2017 3:00 PM > > > To: [email protected] > > > Subject: Re: [WIRELESS-LAN] EAP-TLS > > > > > > > > > > > > Jerry, > > > > > > Am curious your reasons for TLS, like if anything beyond "it's > better". Concern for PEAP being deprecated, etc? > > > > > > Lee > > > > > > -----Original Message----- > > > From: Bucklaew, Jerry [[email protected]] > > > Received: Thursday, 10 Aug 2017, 14:42 > > > To: [email protected] > > > [[email protected]] > > > Subject: Re: [WIRELESS-LAN] EAP-TLS > > > > > > To ALL: > > > > > > > > > > > > > > > > > > We currently do mac auth and EAP-PEAP authentication on our > wireless network. I am trying to put together a proposal to move to cert > based authentication and I was wondering if anyone has a proposal or > justification already written as to why you should move to cert based > auth? Just trying to save myself some typing. > > > > > > ********** Participation and subscription information for this > EDUCAUSE Constituent Group discussion list can be found at > http://www.educause.edu/discuss. > > > > > > ********** Participation and subscription information for this > EDUCAUSE Constituent Group discussion list can be found at > http://www.educause.edu/discuss. > > > > > > ********** Participation and subscription information for this > EDUCAUSE Constituent Group discussion list can be found at > http://www.educause.edu/discuss. > > > > > > ********** Participation and subscription information for this > EDUCAUSE Constituent Group discussion list can be found at > http://www.educause.edu/discuss. > > > > > > ********** Participation and subscription information for this > EDUCAUSE Constituent Group discussion list can be found at > http://www.educause.edu/discuss. > > > > > > > --- > > Bruce Curtis [email protected] > > Certified NetAnalyst II 701-231-8527 > > North Dakota State University > > > > > > ********** > > Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/discuss. > > > > ********** > > Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/discuss. > > > > ********** > > Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/discuss. > > > > ********** > > Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/discuss. > > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/discuss. > > -- -- Hunter Fuller Network Engineer VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Systems and Infrastructure ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
