802.1X Security Overview 98
HJ Franzen writes "Ars Technica have what they call a wireless security blackpaper posted that's well worth a read. I wish this was available when I was spec'ing wireless VPN solutions for my campus. The article is pretty detailed and discusses the many ways in which companies are trying to address the fatal flaws in WEP."
For those of you who need some info on.... (Score:4, Informative)
http://www.tomshardware.com/network/02q3/020719
They've got some good information on why 64/40 and 128 bit encryption isn't enough; as well as why the current "consumer-level" equipment can't do enough to thwart drive-bys.
Re:SSID Security (Score:4, Informative)
My experience. . . (Score:3, Informative)
I haven't read the aforementioned article, but I will check it out. My experiences may just say the same thing as they say (or maybe not). So sorry if this is repeated.
WEP is a joke unless you keep rekeying connection, which depending on how many packets you throw across the connection may or may not be realistically possible. (In many cases I'd guess not)
Choosing a secure SSID as someone mention won't get you very far if you're running in infrastructure mode since it broadcasts that. And if someone knows you have an AP then they can scan channel by channel until tcpdump picks something up and then you really don't need an SSID.
IPSec is a widely accessible protocol that gives the ability to encrypt communications and do authentication (in much the same way that ssh does it). IPSec is available on many platforms: Linux, Windows 2k/XP, BSD, (I think Mac OSX does), and most of them support it natively (ie no slow userspace daemons to run).
Using the authentication you can allow only authorized clients to connect, by allowing only IPSec packets through your router and then let IPSec do the rest. IPSec also does rekeying for the encryption so it's much safer than WEP.
Patrik
Re:SSID Security (Score:2, Informative)
Can someone then explain to me what is the reason for choosing a secure SSID?
Well, if you name yours "company name" and you happen to work for Company Name then it's kind of obvious whose network you have. Now, this issue isn't so important when you have a large corporate campus and you have to be in the parking lot just to get reception "gee, I wonder whose network this is???" But it makes a lot of sense in a shared environment or in office space in urban environments. Chances are by doing some range poking you can narrow down the broadcast field where you're catching an SSID and possibly locate the physical location of the box, but it's just another layer to security. As is often promoted, layering security is better than just one this-had-better-hold form of security -- it often means you can detect intrusions at less vital areas and it often means those inside with proper access aren't working in some soft gooy center where it's easy to gain access throughout.
Good implementation more than just security (Score:3, Informative)
Security is only one issue that needs to be considered in implementing wireless networking. We identified three key issues in developing a wireless strategy: (1) security that was "good enough", (2) end-user simplicity, and (3) technical staff set-up and management.
We eventually decided to use Nathan Zorn's Authentication Gateway [musc.edu]. Wireless connections are blocked at the gateway until users connect via ssh. Clients need to have ssh and know the name of the gateway: everything else gets configured automatically. The system uses iptables, PAM, and ssh and the only admininstration required is to build accounts. The system might not scale well, but works well for an entity our size (one department).
I gave a presentation [umass.edu] about our conclusions.
Not bad, albeit a bit confused about RC4 (Score:3, Informative)
They claim the RC4 algorithm itself is broken, which it is to some degree, but there's lots of information on how to avoid these problems that was available prior to the design of WEP. I also dislike their implication that RC4 inherently uses a 24 bit IV, that was an IEEE decision, RC4 can use an IV that's as large as you want.
RC4 is reasonably secure when implemented correctly, but IEEE ignored the very well known and clearly stated fact that when using RC4, keys must not be re-used for the same data. And that's not surprising, block ciphers are greatly weakened by such things too, which is why anyone in their right mind uses a decent sized IV. RC4 is weaker to key reuse than block ciphers because of its design, but that was a well known fact prior to the design of WEP.
Weak keys are a genuine weakness in RC4. However, they too are well documented and can be easily detected and skipped prior to use. The fact that WEP uses a 24bit IV makes it particularly easy to create a table of IVs that weak, making this problem significantly worse. A great paper on RC4's weak keys, and how to avoid the problem, was posted to sci.crypt in 1995:
http://marcel.wanda.ch/Archive/WeakKeys.txt
So all the weaknesses in WEP that stem from the use of RC4 as an encryption algorithm were well documented, and methods of avoiding them resulting in weaknesses were well known, but the IEEE chose not to heed them. They were trying to make something "secure enough" and traded off things like using a short IV without consulting the cryptographic community about the implications.
Hindsight is 20-20, but I can't exactly call these RC4 flaws. I mean, if you had a power tool and you ignored the warnings printed in the manual, would you blame the tool when it fails?
Using a short IV is clearly an implementation flaw, the fault of WEP not RC4. IEEE wanted to save a few bytes of overhead and purposefuly chose a short IV. The weak keys are a flaw in RC4, but just generating a few bytes and discarding prior to using the key helps reduce the scope of this attack dramaticly. Even better is to detect and avoid the use of the weak keys in the first place, or do both. Since this was widely known when WEP was designed, I consider it to be a implementation flaw in WEP as well, albeit one that stems from a weakness in RC4.
Re:wep is a stupid idea (Score:3, Informative)
I'll pick on a few of the most obvious stupidities:
short of non-reversable encs like md5 it is basically impossible to protect data if you know the before enc and after enc data on a common packet.
1. MD5 isn't a cipher, it's a hash function.
2. Real cipher algorithms, e.g. AES-CBC, handles known plaintext attacks quite well.
a smart sniffer will realise that if he/she sends a standard packet with data to the ip hes trying to access that they can get the keys that way too. This changes the nature from a purely passive interception attack but none-the-less doesnt make it at all secure.
Yeah? That would be the well known ICMP-"g1mme your k3ye5"-request standard packet, or what?
its been well known in military tactics for decades that no matter how you encrypt your data it will always be broken when its exposed to scruitany.
True. Anybody with the slightest knowledge of security will tell you that any defense buys you time. No more, no less.
Hell pgp can even easily be broken if you know the source doc before encryption and thats supposed to be one of the most secure encryption devices out there.
Hmm, got a reference to back that up? No? Thought so.
Add to this that with tcpip you'll always know the source I cant see how you're gonna encrypt the packets short of changing the way tcpip works.
I can see just fine; IPsec - see RFC 2411 etc.
If you're going to use wireless dont expect absolute privacy. This should never have been a concern. If you want security fork out the bucks for wired systems.
Wired networks are not absolutely safe either. Are you sure that there are no passive sniffing devices on your net?
To me tho id encourage open access points to everyone. But then again im sure you dont want to get your cute little ip banned from your favorite channel.
Yes. I guess your mom stopped your pr0n surfing by installing netnanny so you really need to leech bandwidth from others.
Maybe ipv6 could help with a translated address or such. i dunno but as it is now you cant block wireless access so why even try.
IPv6 is supposed to rid us of NATs. Remember that NATs are evil.
Let's count the inacuracies (Score:3, Informative)
2. Decryption takes no longer with 128 bit wep than it does with 64bit wep. This depends on the actual RC4 implementation, but anyone who implemented RC4 in a way that it takes twice as long to crypt a 128bit string than it does to do 64 bits doesn't know what they are doing. Most implementations use a lookup table that makes encryption take the same amount of time regardless of key length. I'm no encryption expert, but I believe that all symetric algorithms share this attribute. It certainly won't "drastically shrink useable bandwidth" unless you have a very lame access point or 802.11 card. I don't believe any implementation will reduce the bandwidth at all by using 128 bit encryption.
3. Turning off beacon frames breaks some important 802.11 features, such as power management support. What most vendors do is not disable sending beacons, but they lie about the ssid (or leave it blank) in the beacons, and only respond to probe requests if the client request the correct ssid in the probe.
4. Turning off or hiding the ssid gives you no security whatsoever. All it does is keep the casual person from seeing your network. Any form of WEP will work better than that, because the casual user won't be able to exchange data packets on your network. The professional cracker will not be slowed down at all by hiding the ssid, all it takes is a sniffer to listen for a probe request/response which contains the actual ssid. Anyone who thinks they are securing their network in this way is deluding themselves.
5. I won't repeat the comments previously made about the authors incorrect understanding of how RC4 works, and why it is exploitable in this implementation.
After I finish reading the parts on 802.1x maybe I'll add to this list.