On Fri, Oct 10, 2003 at 04:21:05PM -0700, Jonn Martell wrote: : > >Question: with the 802.1x-capable network, what do you use to encrypt the > > data? As I understand it, 802.1x is used for access control > > only. Am I missing something? > > Right, on top of 802.1x, you need an EAP (extensible authentication > protocol) methods which are still in development for wireless.
That's for auth. I'm thinking about encrypting the actual flows following the authentication so that the user data is protected and to prevent connection hijacking. That's why I like the VPN solution as an option. Not only does it require authentication, it also brings the encrypted tunnel into the core of my network. Encryption is something of an end-to-end problem, as I see it. I can imagine users running SSH on top of a VPN connection on top of WEP or WPA or 802.11i... That's a lot of layers. I like the VPN solution as a sort of middle ground, since it requires auth, provides packet encryption, and can be brought deep into the core of our network before the packets fall out in the clear. I have talked to deparments that have critical data (HIPPA, etc.) about poking additional holes in the firewall so that they can run their own VPN servers with connections to the sensitive applications. Doing that protects the data end-to-end. > We are planning to use WPA-TKIP (Wi-Fi Protected Access and Temporal Key > Integrity Protocol which replaces WEP). Provides dynamic keys (on a per > user basis) with encryption key rotation. Much like the proprietary > Agere AS2000 and Cisco LEAP without the headaches of supporting an odd > client with limited support. ...once all of the clients also support those protocols, yes. Again, the problem I have with this scenario is that it only protects the wireless space. The packets fall out of the encrypted covering at the back end, and are then in the clear. Granted, that gives you wire equivalent protection, but given the concerns I've been fielding I'm not sure that's what's really wanted. Also, as mentioned, this is an end-to-end problem. Users concerned about data security will also be running VPN tunnels or SSH or SSL... If they're not, then their data may be exposed on the wired side anyway. Finally, placing all of that security stuff on the AP means more complexity at the AP end. It's a gut reaction at this point (which I admit is becoming a knee-jerk reaction) is to eschew complexity at the edge. So, all in all, I have my doubts. I'm still watching, though. There's a lot going on out there and getting a clear picture of it is going to be a requirement for me. > There are still some issues in security with WPA which will get > partially resolved with IEEE 802.11i (and better AES-based encryption). > The IEEE working group dealing with this (TGi) is behind schedule in > releasing this and it's pushed back, yet again, to 2004. IEEE 802.11i > (and WPA which is based on draft 3 of 802.11i) rides on top of 802.1x to > provide the encryption via key rotation. Sounds good. I'm just not willing to be on the bleeding edge with it. > Looking into my crystal ball, I would say that Cisco (as the leader in > both enterprise and home wireless with the Linksys purchase) will be the > one to watch. Even the much awaited 802.11i doesn't solve some > fundamental problems like fast roaming and interoperability; but Cisco > will because the customer base is asking. So expect a lot of vendors to > certify with the "Cisco Compatible" program CCX2. CCX provides a great > way to centrally manage a reliable network by having clients assist in > rogue AP and inteference detection. I expect that CCX2 will become an > "industry standard" with people like HP, Apple and Palm support it (but > that is just a wild guess :) I have been asking Cisco for a variety of features for a while (years). Some have appeared, some not. Cisco, like all the others, make products to meet their own needs. Often that matches the customer's needs but, surprisingly, sometimes not. > Let's just say that I'm glad we have deployed the Cisco AP1200s ... I > still don't see much competition in the enterprise space... > > >>In the near to long term, the 802.1x SSID/VLAN is absolutely strategic > >>for us in providing a safe and scalable wireless network and we will > >>push people as soon as it's fully deployable (hint: as soon as we get > >>multiple BSSID support to make the 802.1x SSID/VLAN "plug and play" with > >>Windows).We are reay to deploy it if our primary network comes under > >>attack but with all the WPA and IEEE 802.11i delays, I prefer to wait a > >>little bit more. > > > > > >See, I'm just not convinced that 802.1x is a complete and practical > >solution. You're only talking about Windows. I have a lot of other OSes > >out there. Honestly, if I were to block a set of OSes from joining my > >network, all of the recent attacks would make blocking Windows tempting. > >That won't fly, of course, and neither will blocking PalmOS. I have had > >people call me with AmigaOS support questions... (The scary thing was > >that I was able to answer.) > > And you are right, large EDUs are in a difficult position because unlike > an enterprise we can't mandate a client platform. We've seen everything > on our network... I'm rather glad we don't try to mandate a client platform. Computers are tools, and different tools do different jobs. I wouldn't want to mandate OpenBSD laptops for people doing spreadsheets any more than I would want to mandate Macintosh desktops for the Inventory folk. When I worked in business (banking...ouch) we used all sorts of systems. Vaxen and their ilk for some jobs, Mainframes for others, etc. There were some mandates that came down for, eg., desktop systems. That created a support headache. Imagine a TSO user being handed a Windows box. Ouch. > That is why we will always need two wireless networks: an open network > with "wireless authenticaion gateway"/vpn authentication type > authentication for the lowest common denominator and a much better/safer > 802.1x network where the authentication/encryption is done at the edge. > > I don't see any other way to service our users. If anyone does, let me > know! ;-) We're just sticking with the former for now. The latter is interesting as an experiment, but... > In most EDU environments, we will need to broadcast both networks (hence > the need for multiple BSSID support). > > We actually want to be able to broadcast more than two SSIDs in order to > provide true support for "virtual departmental wireless networks". That > allows us to meet individual departmental needs without having to enter > into a nightmare RF channel and power management scenario. We're looking at that feature too. Being able to create departmental workgroups on top of existing infrastructure is quite a nifty feature. > 802.1x is not Windows only, Macs and Linux are building 802.1x support. > Those wanting to do mission critical work will use an OS with 802.1x > support on the more secure, 802.1x network. Those who don't care but > want wireless connectivity will use the "open" (WG/VPN protected) network. Well, I still don't see 802.1x as "more secure". How is it more secure than a VPN solution? : > >Going back to the "wireless transceiver", I would really prefer it if APs > >would act as transceivers instead of hubs. If all AP traffic were sent up > >the wire then the back-end device could handle all authentication and > >authorization. It could also filter all flows, which would also be nifty. > >The end product would also be less expensive. > > > >Adding some extra processing power and memory to a transceiver style AP > >would result in an AP like the ones we have today, so it would be a > >no-brainer for a willing vendor. I am hoping that someone will do this > >with the new Atheros chips. > > With this architecture, I'm almost convinced that you would be > vulnerable to ARP attacks. If you are open to ARP attacks, it doesn't > sell for enterprises and you won't see vendors creating highly > specialised products just for EDUs. It was a good idea though - but with > the ARP insecurity issues on the LAN, you do have a problem. Can you give me an example? I've heard the ARP attack concern raised before but, to be quite honest, I don't get it. Which part of the network would be vulnerable to the ARP attack? Sure, on current equipment without WEP someone could hijack a MAC/IP pair. That's why it's worth-while to have some sort of encryption-based client verification. It needs to be something ongoing, however. Just authenticating the client at session startup isn't enough. You have to continue to verify that the client is the same client during the entire session. That's why NoCat runs an applet that periodically re-authenticates with the server. VPN solutions do the same. Anyway, a client spoofing a MAC/IP pair--though a real concern--seems to me to be unrelated to the architecture I've described. Again, I could clueless here. > >>We also feel that segmentation by "campus wide" VLANs is the way to > >>provide seamless campus wide roaming and the required longer term > >>scalability. That means APs that properly understand VLANs. > > > > > >With a transceiver-type AP, the back-end device could handle the vLANs. > >:) > > > >Okay, one feature that would be nice on a transceiver type AP would be GRE > >tunneling. That way, it doesn't matter where you deploy the AP. It > >would tunnel all packets to either an intermediate device or directly to a > >central controller. > > Check the blackhat.com presentations on GRE attacks. The only way I see > this working is if you uses highly specialised (and proprietary) > switches. That stuff doesn't sell as well as far as I'm concerned. I'm looking up those blackhat.com presentations now. Hmmm... Thanks! Chris -)----- -- Christopher R. Hertel -)----- University of Minnesota [EMAIL PROTECTED] Networking and Telecommunications Services "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/cg/.
