Not to mention, these are still authentication AND encryption mechanisms, not just encryption. I think the original poster was wanting just an encryption method without the authentication. This doesn't really solve that.
Ryan H Turner Senior Network Engineer The University of North Carolina at Chapel Hill CB 1150 Chapel Hill, NC 27599 +1 919 445 0113 Office +1 919 274 7926 Mobile -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Turner, Ryan H Sent: Wednesday, November 20, 2013 3:16 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] 802.1x vs web-portal My problem with these approaches is their proprietary nature. I wonder how this has been addressed/discussed in the IEEE groups... Ryan H Turner Senior Network Engineer The University of North Carolina at Chapel Hill CB 1150 Chapel Hill, NC 27599 +1 919 445 0113 Office +1 919 274 7926 Mobile -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis, Bruce Sent: Wednesday, November 20, 2013 3:05 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] 802.1x vs web-portal On Nov 20, 2013, at 10:46 AM, Curtis K. Larsen (UIT-Network) <curtis.k.lar...@utah.edu> wrote: > I wonder if this might be closer to what you are looking for: > > http://theruckusroom.typepad.com/files/dynamic-psk-fs.pdf > > It definitely looks interesting. > > -Curtis Larsen Aerohive also has something that does not require an 802.1x supplicant but allows a unique password on each device. http://www.aerohive.com/solutions/technology-behind-solution/simplified-strong-authentication > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Coehoorn, Joel > [jcoeho...@york.edu] > Sent: Wednesday, November 20, 2013 9:24 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] 802.1x vs web-portal > > <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 > jcoeho...@york.edu > > > 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 <i...@st-andrews.ac.uk> 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: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > 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:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jason Cook > Sent: Wednesday, November 20, 2013 1:30 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > 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:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hanset, > Philippe C > Sent: Wednesday, 20 November 2013 9:56 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > 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 <jeff-k...@utc.edu> 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 athttp://www.educause.edu/groups/. > > > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found athttp://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found athttp://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found athttp://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found athttp://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 > athttp://www.educause.edu/groups/. --- Bruce Curtis bruce.cur...@ndsu.edu 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/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/.
