Wireless network security: 802.11i and WPA basicsDate: Nov 12, 2008
A proper enterprise wireless network security setup must always begin with a good base, one that uses 802.11i and WPA.
In this video, Joel Snyder of Opus One reviews the protocols, along with the other minimum requirements necessary for building a secure network.
Read the full transcript from this video below:
Wireless network security: 802.11i and WPA basics
Good day, and thanks for tuning in. My name is Joel Snyder. I work for Opus One; we're an IT consulting company. And I'm going to talk today about building secure wireless networks. I have some slides that they'll be showing you.
Now this presentation I wrote because frankly ,I was a little tired of the basic 802.11 presentations that I've been given for the past eight or 10 years. I think that we've come a long way with wireless security and we're at the level now where we can think about more things than just building a basic secure infrastructure.
So a lot of us have spent a lot of time down at the bottom of the layers of thinking about 802.11, and that is very important because if you don't have a secure base that you can build on, if you don't have a secure infrastructure, then you can't have a good wireless network on top, but you also have to look at other parts of building a secure wireless network, and I'm defining secure in a very broad way. I'm saying that security is not just encryption and authentication, but also includes things like availability and usability because in order to build a business-class, secure wireless network, you have to have more than just an encrypted channel, you have to have a network which is where people need it when they need it.
But, of course, you have to start from a secure base. So I'm going to summarize a decade's work of wireless security presentations by saying that you absolutely start by using 802.11i, which you might hear called WPA2 and WPA, which is sort of a pre-subset of 802.11i, to protect the channel and to authenticate your users. This is an absolute minimum. If you're going to talk about building wireless security you've got to start with a secure base provided by 802.11i or WPA, then you can always build on top of that. And I've listed on this slide right here the minimum requirements for secure enterprise wireless networks.
So, if at all possible, you always start with 802.11i, which is WPA2 security. That gives you encryption, it gives you per-user authentication, and it also gives you per-session encryption keys so that every single user has their own set of encryption keys that change periodically in order to make sure that no one can sniff anyone else's traffic.
Now, if you can't do WPA2, you can fall back to WPA. That's slightly less secure for most enterprise networks. It's really not going to have a very significant difference. You want to aim for WPA2 if you can, but if your hardware supports WPA and not WPA2, that's okay. What you don't want to be in is a situation where you have anything less than WPA. So as you're looking at your enterprise wireless network, look for 802.11 gear that will not support WPA, put it into a cardboard box, and send it off to a charity. Or give it to your employees to take home so that their kids can make it into building blocks.
If you've invested in an enormous pile of wireless gear that won't do WPA, then you have a very serious potential security problem and you need to think about whether or not that opens you up to bigger issues than it provides in terms of functionality. Because this is fairly inexpensive gear it's really not unreasonable, especially with 802.11n technology coming out and certainly 802.11a, if you have old gear that won't do WPA it's probably b/g only, or b only, even worse.
With these new technologies coming out you might have other reasons to do an upgrade. But certainly you don't want to be in a situation where you're in a courtroom and expert witness comes up on the stand and says, "Yes, the minimum enterprise requirement nowadays is WPA," and you have to explain why you weren't doing that. Because that would possibly negligence, really.
All right, I'm going to review 802.11i's important parts just very quickly here to make sure we all have a good understanding. So, first of all, 802.11i has a user trying to connect up to an access point. That's what you see in the bottom lower-left of the slide, I just show a laptop here in this case, but it could be any device. The access point then has a discussion with the AAA server, probably a radius server because that's the way we normally do it. That conversation, unless you've gone to fairly extreme measures, which would be nice if you could, but for most enterprises, is going to be using standard RADIUS protocol.
The discussion between the access point and the AAA server has to be protected in some way, and the RADIUS protocol was designed to be used with servers in the same room as the RADIUS server. It was not really designed with the idea that someone's going to attack that protocol. Well when you don't have the access point in the same room as the AAA server, when you're sending it across campuses or even across WAN links, you have a much bigger security issue. The main protection, unless again you go to extreme measures like an IPSec tunnel, but the main protection between the access point and the AAA server is actually the RADIUS secret. That's what protects the most important parts of the RADIUS dialogue, so you have to make sure you pick a good RADIUS secret.
For many years most of us didn't bother because it really didn't matter, so we'd pick ABCDEF or something like that. Don't let that happen to you. When you're doing secure wireless, especially if there's any distance between your wireless APs and your AAA server pick a nice long secret, 20, 30 hexadecimal digits, some nice big random number, get an OpenSSL generate-a-key, something like that. You need to have a good secret to protect that dialogue.
Now, the IP tunnel is going to be created between the end-users laptop or desktop, or whatever it is, and the AAA server. The access point actually can't see into that tunnel. So that's going to be protected by TLS. Now TLS, as you know, uses a digital certificate. That digital certificate is very important because that solves the problem of rogue access points, evin twins, whatever you want to call them. And it also solves the problem of, "Who am I giving my password to?" A lot of people are perfectly willing to give their username and password to any screen that pops up. That's why phishing has been so successful, and that's why it's continuing on.
But we don't want our users to be passing out their username and password to everyone. We want to make sure that their dialogue between the laptop and the AAA server, over which a user is going to send probably a reusable username and password unless you use a one-time token, is protected. It's got to be protected with a TLS tunnel. That's protected with a certificate. The certificate has to be a good, valid certificate. It's very important when you do any sort of wireless deployment to train your users to never, ever accept an invalid certificate.
If they ever see a dialogue box that pops up that says anything at all about a certificate, it's either the time range is wrong, or the domain name is wrong, or anything, your training must tell them, "Say no. Step away from the keyboard. Take your hands off the laptop. Call the help desk. Figure out what's going on." Because all of the attacks that you're going to see described against 802.11 generally include stupid user behavior. Now you can't solve all stupid user behavior, but you have to have, as part of your wireless deployment, some training so that the users understand never, under any circumstances, in any scenario, ever accept an invalid certificate because that opens them up to a whole series of problems.
When next summer comes around, it's hot in Las Vegas, no one wants to go there, that's where they're going to have DEFCON and Black Hat, you're going to see more attacks against wireless, more attack against NAC, more attack against everything. Many of those will be predicated on the hand-waving assumption that users will click okay on anything. And that might be true, unless you train them not to.
The user credentials are going to be sent down that encrypted tunnel to the AAA server. The AAA server will authorize the user. If the session is proper and if the user is allowed to get on, the AAA server is going to make up some initial keying material that'll be used. It's going to send it over the tunnel to the laptop and it's going to send it over to the AAA server. It's got to send it to the AAA server separately because the tunnel is encrypted. I'm sorry, to the access point; the AAA server sends it to the access point and has to send it separately because the access point can't look inside of the tunnel.
Therefore, again, we have to make sure that our RADIUS secret protects those keys as well as it can and that the transaction between the AAA server and the access point is as protected as we can make it within the limits of the technology we've selected. Once those keys are there, then we get a protected and authenticated connection between the user and access point. No one else can sniff it. No one else can inject packets, or I guess they can delete packets, of course. But we've got a nice, secure connection.
That's 802.11. Those are the things that you need to be careful of: picking a good AAA secret, making absolutely sure that you train your users not to say okay for a bad certificate, and making sure that you do what you can to protect the transaction between the AAA server and the access point. That gives you enterprise class security.