<rant>What I really want to provide is an HTTPS-like experience for my users that just works: an SSL layer that doesn't care who you are, but still provides meaningful encryption for the last 50 meters where your traffic is moving through the air for anyone nearby to snoop.
I'm annoyed that so many encryption solutions are coupled to authentication. The two don't need to be linked. You don't have to log into an https site to get encrypted traffic, and you shouldn't have to log into a wifi network to get encryption either. My ideal scenario is that someday I'll be able to install the same wildcard ssl certificate that we purchase for our web sites to each access point or at a controller, change a setting for an SSID to use this certificate for encryption, and as long the certificate is from a well-known/reputable vendor, user devices will just work. I include guest devices in this category. I want someone -- anyone, but especially visiting admissions candidates --- to be able to turn on their device for the first time and have the experience be easy: no capture, no guest registration, no prompt to agree to terms of service, just choose the SSID and they're online. Sure, I could use a shared key scenario and just publish the key, but that's not the same thing. If anyone knows the key, anyone can decrypt the traffic, and it still requires an extra step to get online. I honestly couldn't care less about the authentication part of this. I don't need to know right away that it was Jane Smith's computer committing whatever nefarious deed. The immediate reaction to that kind of thing is the same regardless of the name of the person behind it. As long as I can target a MAC address or have reasonably static IP addresses (I do), I'm happy enough using a captive portal rule on a specific machine after the fact to identify a user for those times when enforcement issues come up. College-owned machines here do log user names all the time, so it's just student-owned devices where this is necessary. Sadly, I don't believe this kind of wifi exists today. Certificate-based 1x comes close, but the need to install/configure devices with a supplicant breaks it. I would settle for 1x, if I could count on it working for my students. Personally, I place blame on the WiFi Alliance, certifying devices that don't work for this feature as well as they should. Currently, we're working to provide two WiFi options: one that's completely open (and I mean completely), and one that uses 1x and prompts for a user's Active Directory login. Anyone can walk on campus and get online at a basic level. Really. I don't care. Guest (and even neighbor) use is a drop in the bucket compared to what our regular students demand. But if you need encryption you'd better hope the site or service supports https. We encourage students to use the 1x SSID whenever they can, and try to educate about the importance of encryption. *Most don't care*, and choose the open network, but at least the option is open to them.</rant> Joel Coehoorn Director of Information Technology York College, Nebraska 402.363.5603 [email protected] *The mission of York College is to transform lives through Christ-centered education and to equip students for lifelong service to God, family, and society* On Wed, Nov 20, 2013 at 8:54 AM, Ian McDonald <[email protected]> wrote: > Isn't that really a client supplicant issue though? You can send back a > reason for authfailure, and then the client could prompt for a replacement > password. > > -- > ian > -----Original Message----- > From: Fleming, Tony > Sent: 20-11-2013, 14:22 > To: [email protected] > Subject: Re: [WIRELESS-LAN] 802.1x vs web-portal > > I can tell you we use dot1x here with AD credentials and it doesn't lend > itself to a good end-user experience. Our security policy requires password > expiration after 60 days. When a student's password expires we see an > increase of wireless related complaints (typically blaming the > performance/signal of the wireless network) not realizing their password > has expired and new credentials need to be applied in their wireless > profile. > The other AD credential issue we have is related to lock-out. If a student > mistypes his/her password to lock-out their account all of their devices > stop connecting to the wireless network. > > Having said that, we are eyeing certificate based 802.1x. Not having a lot > of experience with PKI we are trying to gauge the effort level of > deployment. > Not trying to highjack the thread here - but I am curious if anyone has > some real world experience spinning-up a PKI (from scratch) using CloudPath > with certificates. What is the effort level? > > Tony > > -----Original Message----- > From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: > [email protected]] On Behalf Of Jason Cook > Sent: Wednesday, November 20, 2013 1:30 AM > To: [email protected] > Subject: Re: [WIRELESS-LAN] 802.1x vs web-portal > > List seems to sum it up pretty well. > > I think user wise dot1x is better ....... "once setup". So while it may be > more of a pain to configure for some users, once configured the experience > is much better as they walk on to campus and are connected. > > Having a captive portal is probably a good option for those that can't get > dot1x working . > > I'm interested in the 10% though, do you get them all connected in the > end? 10% seems quite a high percentage > > -- > 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 Hanset, Philippe C > Sent: Wednesday, 20 November 2013 9:56 AM > To: [email protected] > Subject: Re: [WIRELESS-LAN] 802.1x vs web-portal > > from the top of my head... > > ###What's bad for the user: > > -Captive portal: no encryption over the air, pesky re-authentication and > timeouts, no authentication of the infrastructure (yes, when you accept > that SSL Cert from RADIUS you actually authenticate the infrastructure) > > -802.1X: finicky supplicants, and, without a good installer, long config > instructions. Strongly authenticated (can't escape the system ;-) > > ###What's bad for the network engineer (and user stuff as well...): > > -Captive portal: CPU capacity of portal (802.11ac!!!), clients taking IP > addresses and air time even if not authenticated, authentication can be > defeated > > -802.1X: bugs from various vendors. A pain the troubleshoot when not > working. Certificate Expiration and help desk calls resulting from it > > add yours! > > Philippe > > Philippe Hanset > www.eduroam.us > > > On Nov 19, 2013, at 2:10 PM, Jeff Kell <[email protected]> wrote: > > > On 11/19/2013 4:05 PM, Peter P Morrissey wrote: > >> Can anyone name an application that does not have strong encryption? > >> > >> I'm not arguing against 802.1x, because it works very well for us as > users don't have to authenticate constantly on a portal, and we seem to do > a very good job getting them on initially, but I am having a hard time > understanding the encryption benefits lately. > > > > Does FireSheep or Ettercap ring any bells? > > > > Jeff > > > > ********** > > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > > > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
