Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security

802.1X Security Overview 98

Posted by michael from the secure-your-network-or-someone-else-will dept.
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."
This discussion has been archived. No new comments can be posted.

802.1X Security Overview More

802.1X Security Overview

Comments Filter:

  • No No, there's nothing wrong with it! (Score:3, Funny)

    by Shanep ( 68243 ) on Friday July 19, 2002 @09:02AM (#3915877) Homepage
    Really! I'm enjoying my free broadband!

    Just keep using it, everything is all right.

    • For subscribers only?

      I like to make PDF's of pages of particular interest for offline reading and archiving should they ever go offline.

      I usually click the printer friendly version if they have one, print it to a file, which gives me a postscript file within Linux, then using the a tool that come with ghostscript (?) "ps2pdf" the file. It usually comes out very nice.

      But with Ars, I prefer to just grab the article with wget, since they don't seem to offer a printer friendly version outside of a subscribers only PDF file. Anyone subscribed? Free?

      Course, now I have OS X, I just print preview then save to PDF.

      • The subscription is something like $10 per month. In addition to the PDFs, you also get to post in the Lounge and Velvet Room (aka the off topic bandwidth hungry forums) in the OpenForum, and have Subscriptor in your Openforum profile, and some other random perks.

        Oh, I think the PDFs feature vector graphics, so they'll print far nicer than your ps2pdf PDF will.

        I think Ace's Hardware offers something similar, but I can't remember.
        • The subscription is something like $10 per month.

          Bugger that! Thanks for the info.

          Oh, I think the PDFs feature vector graphics, so they'll print far nicer than your ps2pdf PDF will.

          Postscript and PDF both do vector. If the fonts on the page you are printing are vector, you print to postscript, you get vector fonts in the postscript, ps2pdf that and you get vector fonts in the resulting PDF.

          Most of the PDF's I have created within Debian Linux using ps2pdf, have shown within Acrobat Reader, at 1600x zoom, to be completely smooth vector fonts.

          Sometimes you might get a font within one of these PDF's that is obviously bitmap, they don't look great on screen, but they do look much better printed than on screen. Good thing is though, the most popular fonts tend to be vector within Debian at least.

  • For those of you who need some info on.... (Score:4, Informative)

    by karnal ( 22275 ) on Friday July 19, 2002 @09:05AM (#3915889)
    how the current standard is broken, visit toms hardware:

    http://www.tomshardware.com/network/02q3/020719/ in dex.html

    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.

    • That's in the Ars article too.

    • So we should be using Application Layer encryption as well if security is that important.

      You can set up your 128-bit WEP connection, and open an SSH connection over it, or connect to your important websites with 128-bit SSL. Sure, wireless is still easier to break into than a cat5 cable, but as a business you trade the possibility of someone internally with a packet sniffer and a vengeance for someone externally with a packet sniffer, a wireless connection, time, and a vengeance/paid purpose. For major corporations, this trade-off may not be worth it, but for Joe Q. BusinessOwner, the odds that they are A) likely to be attacked, and B) transmitting sensitive data over their wireless connections without any consideration for security are low.

      As time marches on, security will become a greater concern, and these issues will be more publibly noticed. But I'm looking forward to public-access networks with a universal distributed authentication system (set up much like DNS) where our data will be encrypted at the physical, transport, and application layers, and we will authenticate with our home/work networks no matter where we are

      • Damn right. How many of the people (suits perhaps) worrying about the lack of strong encryption on wireless LANs are quite happy to use regular Ethernet? Which is ridiculously easy to sniff.

        I guess there is some point to hardware-layer encryption because many widespread protocols like DNS and NFS don't have usable secure equivalents. But even there, couldn't you use IPsec?

  • No signal going through the air is secure... (Score:1, Insightful)

    by Anonymous Coward
    ... unless it's encrypted. Even then, your signal will be able to be recored and broken 10 years later when computers are faster.

  • Zaurus doesn't pay attention to the SID? (Score:3, Interesting)

    by dolphinuser ( 211295 ) on Friday July 19, 2002 @09:09AM (#3915908)
    I have a Zaurus SL-5500, and when using it with my 802.11b network, it doesn't seem to care about the SID.

    It doesn't matter what name I use, it seems to always work. Has anyone else experienced this?

    John

  • SSID Security (Score:2, Insightful)

    by jamesbernsen ( 121493 )
    From the article:

    The SSID should be created with the same rules as any strong password (long, non-meaningful strings of characters including letters, numbers and symbols).

    By default the Access Point broadcasts the SSID every few seconds in what are known as 'Beacon Frames'. While this makes it easy for authorized users to find the correct network, it also makes it easy for unauthorized users to find the network name.

    Can someone then explain to me what is the reason for choosing a secure SSID?

    • Re:SSID Security (Score:4, Informative)

      by Conspiracy Theorist ( 250373 ) on Friday July 19, 2002 @09:23AM (#3915975)
      Actually most APs broadcast a few (or many) Beacon Frames every second rather than a Beacon every few seconds. But to your question, the client (whether authorized or un-authorized) needs the SSID to associate with an AP. Picking one that is difficult to guess and using a AP that can suppress the SSID in Beacon Frames makes it that much more difficult for an un-authorized client to associate with your AP.
      • This is just stupid. SSID provides security in no way what so ever. There is no point to picking a SSID that is hard to guess and a random string of letters and numbers will just add to support headaches. The SSID in in the clear. Anyone can see it with a sniffer. Even if you turn broadcast SSID off it can still be seen. Good advice would be something like this. Use a word that is easy to spell and remember so that your support staff can remember it and user will not have a problem mistyping it.
        • You know I thought this when I first read it, but now I know better! ;) No, I didn't get owned and noone got access to my network, but this is security you can see. When you turn the broadcast off, then the SSID isn't transmitted (well duh) and, also, even on clients that do have a matching SSID, you will not see the AP in your handheld's Wireless app, but you will see it is on the network. This makes it easy for some warchalkers and crackers to just pass it on by. Especially ones who have no idea why a WiFi AP would be installed in say a unassuming house in suburbia. Why investigate every house and business when you just have to look for all of the clueless folks who broadcast their SSID.
          • If the fact that you do not see the AP when you use an app like Netstumbler make you think you have added security by turning off broadcast SSID and using a difficult to remember SSID good for you. The bottom line is that you have not. Plenty of sniffer still see your traffic and still see the SSID.
            • That may be true, but why advertise? Broadcasting the SSID is like saying look at me! I have a wirless network! Also, there's one thing that I always do when I leave for a extended period of time (a week or so)....I turn off the radio. Problem solved. BTW, I didn't use Netstumbler. I used the app builtin to my handheld. This is a layer that one has to go thru, and not a full security solution. All the layers put together is your whole solution. Should WiFi be stronger in it's security? Hell yeah, but no matter how much network security you have someone will always be able to break it. Not broadcasting the SSID is something that should be done. If it was a big deal to implement, well, maybe not but it isn't. I agree with him. Besides, Script Kiddies aren't likely to know enough or be able to get some of the tools they need to crack these things. Those are the one's I am more afraid of. Not saying that they don't have the knowledge...some don't and some do, but it adds another thing they have to do to get thru.
          • SSID should never be used as a security mechanism for your wireless network. SSID's are truly designed to allow for roaming within your site, and for installations where there are multiple organizations attempting to utilize multiple access points (on varying channels).

            802.1x allows a site owner to utilize RADIUS authentication on the access point level in combination with WEP (OTA security). This attempts to fix the original flaw with WEP, in that the 4 configurable keys were static set, therefore allowing anyone with enough time to determine at least 1 of the 4 static keys.

            802.1x creates an authentication process at the access point, as well as dynamic key generation for WEP.

            This, of course, helps a single enterprise network, but what about hotspots that want to include public and private applications. There is no way to do it, with the exception of a product by Roving Planet [rovingplanet.com].

      • Picking one that is difficult to guess and using a AP that can suppress the SSID in Beacon Frames makes it that much more difficult for an un-authorized client to associate with your AP.

        Unless your attacker has a clever, devious and even diabolical mind...

        ... and sets his card to connect to any SSID.

        For most wireless network users there's no reason whatsoever to specify an SSID, so most clueless users will see and connect to your network with nary a problem. SSIDs are to allow you to select one of multiple physically co-located but logically distinct networks. They are not, were not and cannot be a security feature.

        • Oh, wow! I never knew that when you set your card to connect to any SSID it magically fills in the SSID field of the association request frame with the correct SSID of the AP it is requesting association with!

          In order for a client to associate with an AP it must know the SSID the ap is using. It must fill in the SSID field in the associate request frame if it hopes to be granted association. Some (most? ... all?) APs that suppress the SSID in the beacon also suppress it in the probe response as well. That means that the only time the SSID is transmitted out over the air is during the association process. The only way an attacker (no matter how clever, devious or diabolical they are) can associate with your AP is if they were sniffing at the time some valid client associated, grabbed the SSID out of the frame and used it in their own association request. No it's not perfect security, it's not even that great of a security mechanism, but it's an extra hurdle that people have to get over in attacking your network.

          Setting the card to connect to any SSID simply lets the card fill in the association request frame SSID field with an SSID it has seen out on the air, either through beacons or probe responses. If the AP suppresses the SSID in both beacons and probe responses, the card has no way of knowing the SSID.

          If you are worried about warchalkers (or wardrivers, or whatever) connecting up to your AP, suppressing the SSID in beacons and probe responses will probably be enough to keep them walking.

          If you are worried about competitors gaining access to your network through the wireless APs, suppressing the SSID will not be enough.

    • Re:SSID Security (Score:2, Informative)

      by heliocentric ( 74613 )
      By default the Access Point broadcasts the SSID every few seconds...

      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.

  • personal security (Score:5, Interesting)

    by Jacer ( 574383 ) on Friday July 19, 2002 @09:18AM (#3915952) Homepage
    i use a little "consumer elvel" access point/router with DHCP turned off, and a strong subnet mask (i'm talking 29 bits!) then i filled up every IP address in the range by assiging multiple ip addresses to the adapter on my server

  • wep is a stupid idea (Score:2, Interesting)

    by Anonymous Coward
    whats the difference between an encrypted ack packet and a non enc'd one from a sniffing point of view not a one..

    any key you could possible be using will get exposed through these very well documented and standardized packets.

    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.

    even if they manage to enc say only data in a packet. 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.

    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. 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.

    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.

    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.

    Transmitting any sensitive information over radio just doesnt make any sense and is the very reason for the extreme security measures taken by governments. For example in nuclear launch codes.... One time use of one code which has to be on the sub prior to it leaving dock. ol dubyah cant just call up some sub and say launch without the right one of these codes and for good reason.

    As for unrestricted broadband access (connection sniffing/interjection) thats tougher. How do you keep someone who can know your keys off your system well you got two choices... You setup a custom algorithm that changes the keys on both the client and access point according to a certain time internally. At best a hacker will grab 3 or 4 of these keys but if they continually rotate around something that cant be standardized it would be very difficult short of knowing the algorithm used to change keys to get reliable access tho it would undoubtedly be possible given enough time to figgure out the deal with the algorithm.

    Any way you look at it its gonna be security through obsfuscation and theres really nothing you can do about it. You want wireless you're gonnna have to accept the freeloaders on your service.

    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. 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.

    • Re:wep is a stupid idea (Score:5, Insightful)

      by Oculus Habent ( 562837 ) <oculus.habent@gma i l . c om> on Friday July 19, 2002 @09:39AM (#3916077) Journal
      You want wireless you're gonnna have to accept the freeloaders on your service.

      I haven't played with any wireless base stations other than my AirPort, but I can limit MAC Addresses, as well. Sure, this doesn't work in an environment where many friends/clients will be accessing your network unexpectedly, but in a home/school where the number of new users is extremely limited or well-controlled, this can improve security quite substantially.

      Sure, they can still sniff packets, and they can still break encryption, but it will be a sight harder for them to access your wired network/Internet connection.

      • If I can decrypt your packets - I can find your MAC address. Then I spoof your MAC address (when your not using it) and I have access to your network.

        • There will always be people willing to break the encryption no matter what the costs in time, and technology. If you wanted access to my Internet connection through my 802.11 (without physically breaking into my home), you could get it eventually. But I can make it difficult for you, and that is the point.

          Encryption was never to prevent information from being intercepted. It was never to stop data from being read. It was to delay. It comes back to the simple question - how important is the security of your network/data?

          • I agree with you completely, and I use a 802.11b network at home. I was just pointing out that restricting by MAC address is fairly easy to get around. That doesn't mean that it isn't worth doing.
        • The MAC address is required to be unencrypted, even when using WEP... no need to crack anything there.

          Most WiFi cards make it trivial to override the MAC and set it to anything you'd like, so "closed MAC access" doesn't give you any added security.
      • many friends/clients will be accessing your network unexpectedly
        If you need people to access your network "unexpectedly," but you want security, no currently available technology can be of assistance.

        Sure, they can still sniff packets, and they can still break encryption, but it will be a sight harder for them to access your wired network/Internet connection.
        Harder, but still not hard. The script-kiddie-class wireless sniffing programs probably reset your MAC address to one they see in a packet (just in case); if they don't, they will soon. Breaking WEP at least requires hanging around until X megs of traffic have passed across the AP.
      • MAC addresses can be faked. I just need to find the MAC address of a trusted user, which will be easy once the WEP is cracked.
      • but I can limit MAC Addresses, as well. ... Sure, they can still sniff packets, and they can still break encryption, but it will be a sight harder for them to access your wired network/Internet connection.

        If they've gone to the trouble to break your encryption, they will have no problem forging a fake MAC address, it's fairly trivial to do.
    • whats the difference between an encrypted ack packet and a non enc'd one from a sniffing point of view not a one..

      any key you could possible be using will get exposed through these very well documented and standardized packets.

      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.

      Nope. The best encryption techniques are proof against a 'known plaintext attack'; which is what you are talking about here. The code is not resolvable from the plaintext or the encrypted text or both together. Well, theoretically it is resolvable, but the amount of processing necessary to do it is completely beyond computational reach.

      At best you might be able to guess from the context that it was an ack packet, but that's about it.


    • "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."

      Well, the whole point of asymmetric encryption is that you do use non-reversable encryption methods. Of course, with any encryption system knowing how a frame looks both before and after encryption is a massive bonus for any would-be cracker of encryption codes...

      The real problem for most crackers is when they don't have any sort of before and after comparisons to make on packets sent over WEP. In many cases, the fact that it's encrypted will force the majority of potential bandwidth hijackers to go looking for softer, more vulnerable targets to prey on.

      • Well, the whole point of asymmetric encryption is that you do use non-reversable encryption methods.

        Sorry, that's not right. An asymmetric encryption is still reversible- it has to be- that's how you decrypt it!

        'Asymmetric encryption' just means that given one key you can't figure out the other key and vice versa. Symmetric means you can - the keys are related in some usually trivial way- like they're the same, or backwards or something.

        Of course, with any encryption system knowing how a frame looks both before and after encryption is a massive bonus for any would-be cracker of encryption codes...

        Yes. But when you design codes it's usual to assume a 'known plaintext'; and then design the code to deal with this. A more difficult test still is 'chosen plaintext', where the bad guy get's to give your encyption module a bunch of data and look at the results; and from that tries to work out the key.

        As a rule of thumb, unless the module can stand a chosen plaintext attack, I wouldn't touch it with a barge pole.

    • any key you could possible be using will get exposed through these very well documented and standardized packets
      This is wrong -- if knowing the plaintext for a given ciphertext exposes the key, then your cryptography is bad. https sessions are mostly known-plaintext (http headers & static html), but you still have to brute-force the key (as far as we know.)

    • Re:wep is a stupid idea (Score:3, Informative)

      by chekhov ( 88482 )
      Bah, FUD and snake oil. Written by a five year old too.

      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.
      • chops and chekhov are right, and the (currently +4!)comment they're replying to is wrong.

        All the block ciphers in PGP, like IDEA, CAST and so on have (so far) survived cryptanalysis based on known plaintext attacks. In fact, a cipher is considered "cracked" in the academic sense if the key can be retrieved with *chosen* plaintext in less time than by searching all possible keys.
    • The above rambling is simply not true. The problem with WEP is that the method was designed by people who were unaware of basic methods of cryptography. You can do much, much better than that.

      To get technical: if an encryption method is used that is "plaintext aware" then an attacker with access to a (bounded) set of plaintext-ciphertext pairs cannot forge a valid ciphertext that's not in that set with more than negligible probability. Add replay prevention and you end up with a much better system,

      Rotating the keys like a madman is not necessary if the system is well-designed. For a N-bit block cipher you need to rotate the keys before you encrypt 2^(N/2) blocks, otherwise ciphertexts will start to repeat. For a 128 bit cipher like AES you can encode over 100 exabytes before you have to rotate the key, which is every six million years or so at 802.11b speeds. Nobody cares after 6 million years.
    • This guy went on a complete rant and someone gave him a 4 score. Sheesh.
      You have touched upon a few good points (and a lot of bad ones).
      The good stuff:
      1. I think some of the stuff at the top you're trying to get at is summarized very neatly in the end-to-end argument paper by Reed, Saltzer and Clark (MIT). THe core of the argument (applied to security) is that you have to assure secrecy between the two end-points that matter. Encryption in between may only be used as an optimization - no guarantees can be made or expected. Read the paper if you haven't:
      http://web.mit.edu/Saltzer/www/publications/pubs.h tml

      The bad stuff:
      1. 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.
      What utter nonsense. Go back home and read your crypto book. What you're talking about is a known plaintext attack (you know the plain text and the cypher text and try to determine a key) and almost all the ciphers out there (DES, Rijndael, DES-variants) can withstand this attack.
      2. 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. 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.
      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.
      No no and no. Knowing the source does not allow you to break a crypto scheme. That's the whole difference between good crypto and security by obscurity. Read some books. The secret is usually the key, not the protocol, not the algorithm.


    • If you want security fork out the bucks for wired systems.

      As if a "wired" system is secure. There is no such thing as a secure network, the goal is to make it easier to go next door. It's like protecting your house. A crook, if they really want to, will get in no matter how much money you throw at it. A determined person will either break in or get caught trying. By layering WEP with Radius Authentication and MAC address filtering on a "Closed" AP network you make it alot more trouble than it is really worth.

      • If you want security fork out the bucks for wired systems.

        As if a "wired" system is secure.

        It's more secure if the people who have access to it can be trusted. A family in a home network can usually be trusted with their own network. Add wireless and now you have to trust your whole neighborhood.

        A determined person will either break in or get caught trying.

        If they need to break in to my house, then they'll probably just take the computers.

  • from the secure-your-network-or-someone-else-will dept.

    Are you trying to say I am the only one who has been hacking in to windows systems, applying patches, and beefing up security? I mean, the ends justify the means, right? Just don't be surprised if you leave your system on, leave the room, and come back to discover gentoo running on it....

  • My experience. . . (Score:3, Informative)

    by patrik ( 55312 ) <pbutler@killer[ ].org ['tux' in gap]> on Friday July 19, 2002 @09:46AM (#3916123) Homepage

    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

    • Actually he's arguing that IPSec is bad because:

      a) it allows people on the same AP (subnet) to communicate and use your bandwidth up, because they only need IPSec to go through the IPSec portal, not communicate with each other.

      b) You have to secure the clients as well

      I argue that a) is irrelevant because black hats can easily set up their own network (ad-hoc network if they want- they don't even need an AP for that), and the wireless bandwidth still gets used up, so this has little or nothing to do with security.

      b) is true however, each machine needs a firewall.

      • I agree with you completely.

        The whole article is a bit silly, pushing relatively unproven standards (EAP) which have been extended (LEAP) and extended (PEAP) over VPN standards with a good trackrecord (IPSEC).

        The client is always the weakest link, for both VPN and wireless access. Basically, the author's argument boils down to saying that most IPSEC clients do not block access from other clients while they are connected (split tunneling), whereas the [LP]EAP clients do.

        It's a matter of configuration. There is no way one can claim that one client is more secure that the other. Clients are always unsafe, and if not, its user is :-). I'm sure a determined recalcitrant enduser can always hack his [LP]EAP client to enable split tunneling, or other unsafe settings.

        The only way to fix this (for both VPN and wireless) is to supply the user with trusted hardware. But that would mean a lot of money and a revolt of endusers because their PCs will be taken away...

        By the way, here's an article by Microsoft [microsoft.com] on this matter. It basically says that Microsoft will solve all your problems if only you would buy into the latest Microsoft offerings.

        Would you rather use a solution based on open standards, try Wavesec [wavesec.org]. It is mostly based on IPSEC, DHCP and DDNS.

    • IPSec is great for auth/encrypt, but if you have a network with 10 or more AP's, that is 110Mbs of available bandwidth for wireless clients. The cost of a VPN concentrator that can terminate 100Mbs+ of 3DES IPSec traffic is VERY high. 802.1x will help solve this problem. Cisco's LEAP in conjunction with thier RADIUS server, while proprietary, works quite well. You can dynamicaly re-key WEP every few minutes, and authenticate your users back to AD or NDS or another RADIUS server for that matter.
      • I've been thinking of hacking together a somewhat simple system that would randomly generate WEP keys, use tcl/expect/perl-expect whatever to control lynx-ssl to connect to my AP, set up a new WEP key on the AP (it can have multiple keys), then ssh to my laptops and change the wep keys on them.
        One could easily write small scripts for whatever AP or system you wanted to reconfig, assuming you can do 'em from a command line.

        Comments?

  • default SSID (Score:2, Funny)

    by mattyohe ( 517995 )
    in my town there are so many (mostly linksys) AP's that use the default SSID that I could practically drive arround and hit the internet from anywhere. It would be interesting to compromise a machine across the internet while connected to someone else's AP... the deleting of your logs is basically driving home.
  • ok i know the last one was that "infamous" M$ paper, but could someone give me a "color chart" as to define all these different papers that i'm seeing more and more often posted on slashdot?
    • White paper usually refers to a document that is printed in black text on white paper. The idea is to contrast documents that have useful technical information (which are usually printed in boring black text on boring white paper) with the usless documents that you get from marketing (which are all kinds of pretty colors on cool glossy paper).

      The joke here is that ars has published an aritcle that has useful technical information, but their website has a black background with white text. Therefore, this is a black paper.

  • Blackpaper? That's a kewl term I haven't heard before. I suppose it's a paper in response to a white paper showing the dark side of a technology?

    M@

  • Good implementation more than just security (Score:3, Informative)

    by limako ( 45118 ) on Friday July 19, 2002 @10:40AM (#3916496) Homepage Journal

    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.

    1. For us, security that was "good enough" meant having by-user authentication, putting the access points behind a router, and being vigilant to evidence of inappropriate use. There's not much point in putting bars on the windows when you never lock the door anyway.
    2. For end-user simplicity, we wanted to support a diverse client userbase while minimizing the amount of configuration and additional software required by client machines.
    3. For set-up and management, we wanted to depend on open-source and free software packages that we were already familiar with and not have the administration become a burden.

    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.

    • There is a new product group being created called "Access Controllers" Article on 802.11 Planet [80211-planet.com] Another company making a similar product for multiple organizations to exist on a common wireless infrastructure is Roving Planet [rovingplanet.com].

      These companies use central servers with satellite net appliances behind the access point to control user access and in some cases bandwidth provisioning for user groups. Roving Planet also has bandwidth provisioning for specific applicaitons.

  • There was a mention of using a VPN scheme to secure your wireless LAN, which would be fine to protect your own data but still allows 'visitors' to piggyback their own networks on top of yours. This still allows the 'visitor' to take an IP address from your DHCP server and talk to the other machines.

    This thought might not solve the piggyback problem but it might go a step further in securing your data. Use a PPPoE server (such as a Win2K box running RASPPPoE) to hand out network addresses and require all your clients to connect using some form of PPPoE (again, such as RASPPPoE) which can be reasonably protected using MD5 CHAP for passwords and encrypted packets.

    The only thing exposed then are MAC addresses, so 'visitors' could still piggyback their own network on top of yours, but they're not taking up IP addresses or able to see *anything* on your network except other MAC addresses.

    And if you wanted to be really smart you could have a probe program (too bad one doesn't exist yet) that could compare a MAC address to a matching PPPoE connection, say every ten minutes. If a MAC address doesn't have a corresponding PPPoE connection, it's blacklisted for a while and the port is freed for a legitimate client.

  • Not bad, albeit a bit confused about RC4 (Score:3, Informative)

    by mkettler ( 6309 ) on Friday July 19, 2002 @10:57AM (#3916629)
    The only major objection I have is that Ars is presenting some WEP problems as being RC4 problems ie: that RC4 is broken and cannot be secure if implemented properly. "The main problem with WEP is that the RC4 stream cipher used to encrypt the data has been proven insecure." I'd change that to read ".. has been proven insecure if research notes regarding these problems are ignored."

    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.
  • In other news, a consortium of large companies has announced that they have developed a building material that spray paint cannot adhere to. This should help companies that can not or will not secure their networks protect themselves from the insiduous threats of wardriving and warpainting. More news at 11.
  • The article seems very intent on proving that every possibility is flawed. However I wonder about their VPN reasoning. They exude that using VPN's you can still let "crackers" talk and communicate using your WAP. But why would anyone go to the trouble of hacking into a WAP, just to essentially use ad-hoc mode on their wireless cards?

    Bueller?
    Bueller?

  • Let's count the inacuracies (Score:3, Informative)

    by kevin42 ( 161303 ) on Friday July 19, 2002 @11:48AM (#3916954)
    1. Authentication comes before association, not the other way around as the article mentioned. Authentication was not added in 802.11b it was there in the original 802.11 spec.
    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. :)
    • 2. Decryption takes no longer with 128 bit wep than it does with 64bit wep. This depends on the actual RC4 implementation...

      In fact, the way RC4 works, the key and IV are concatenated and repeated over and over to create a 256-byte(2048-bit) key. The way I usually code up RC4 (I've done it a few times before I memorized RC5... now to memorize AES.) is that I don't expand the key, just loop over it, so a longer key means fewe conditional branches and actually faster rekeying. Encryption speed should be identical. The key only sets the initial state (the permutation of 0..255), which evolves durring encryption/decryption. Unless the programmer is completely retarded, the actual encryption and decryption speeds for RC4 should be copletely independant of key size. (Yes, a keystream lookup table for short keys is cmpletely retarded.)

  • Watch the terminology (Score:2, Interesting)

    by GigsVT ( 208848 )
    When you say something like 802.1X and you mean all wireless, you are showing ignorance.

    802.1 encompasses a large number of wired standards in addition to wireless.

    Or maybe the poster meant the actual standard named 802.1x? Port Based Network Access Control? I thought that was used for tying switch ports to certain MAC addresses.

    I propose if you mean to say "all the 802.11 standards" you say 802.11*, since IEEE uses letters such as "x" to denote certain standards, not as a wildcard.
    • but wouldn't they use a lowercase x? 802.11a b g ect and not A B G. But i could be wrong
    • You are correct that 802.1X is the "Port Based Network Access Control" standard. That standard has hooks to permit it to be used in 802.11 networks as well as in switches.

      802.1X is becoming widely adopted as a security adjunct to 802.11 WLAN infrastructures. In fact, the 802.11 Task Group "i" is developing its enhanced security additions to 802.11 on the basis of 802.1X. With "i", 802.11 and 802.1X become joined at the hip.

      While your criticism is somewhat accurate, the use of 802.1X in the title is actually quite relevant to the discussion of evolving 802.11 security.
  • The "black paper" makes this conclusion about shared-secret authentication as part of association:

    "By passively listening to the conversation, an attacker can obtain two of the three variables in the authentication equation; the clear text challenge string and what the challenge string looks like after it has been encrypted. By plugging these values into the RC4 equations, the attacker can easily solve for the shared authentication key. "

    Actually, this is not what their referenced whitepaper [umd.edu] describes at all. By observing the authentication sequence, an attacker can forge an authentication by responding correctly to the challenge without knowing the WEP key. This is made possible by the amateur 802.11b authentication scheme, not because RC4 is easily 'solved'.

    So, while the shared secret authentication does not hinder a determined attack, it is incorrect to say that it weakens security at all. In the case of unenthusiastic stumblers, it may hinder casual associations with your AP.

    To recommend an "open authentication" scheme for improved security seems like bad advice.
  • Apparently "blackpaper" means "white text on a black background".

    Please - this is one fad from the '90s that deserves to die, quickly.

Slashdot Top Deals

"I've seen it. It's rubbish." -- Marvin the Paranoid Android

Close