But, perhaps the worst component of authentication on wireless networks is the complete lack of understanding that most people have of how it works. Now, you can argue that you don't need to know how your engine works in order to drive a car, so you don't really need to know how wireless authentication works in order to use your computer. And, in general, I would agree with you. However, most people would agree with me that knowing more about how their engine works results in an engine that generally works better because those people know what to look for and what types of behaviors can cause them trouble down the line. With wireless authentication, it is also the same thing. However, if you destroy the engine on your car, you will be out a lot of money to fix it or replace the car. If you screw up with your authentication the damage can be far worse, and far more expensive. So, do yourself a favor and learn a bit more about how the authentication on your wireless networks work.
My goal in this blog entry is to try to boil down the authentication process in to plain English, while mapping some of the technical jargon in to something that an average person can understand. As a result, this blog entry will be very long. But, hang in there with me. I think it will be worth it.
We are going to look specifically at user name and password based authentication on networks. This type of authentication is commonly used on enterprise wireless networks. However, it can also be used on wired networks. In fact, the method of authentication used in these networks was designed originally to be used on wired networks. It was adapted to work with wireless networks, and that is where it seems to have found the most success. This standard is called IEEE 802.1X. Some people may now be yelling at their screen, "Nuh uh! WPA-Enterprise or WPA2-Enterprise is used on wireless networks, not this 802.1X stuff!" Those people are both right and wrong at the same time. The WPA specifications outline how to use the encryption keys that are generated during an authentication with 802.1X. So, we will be focusing on 802.1X, and leaving the encryption key stuff for another time.
There are two ways that an authentication starts. One is that the network recognizes that you have connected to it and sends a request to start the authentication. The other is the client machine (i.e. your laptop or phone) sends a message to the network requesting that it start the authentication process. Both methods result in the network sending an identity request to the client station. The station responds to this request with a message that contains some form of identification. Because of the way that 802.1X has evolved, this identification is often referred to as the "outer identity" or "anonymous identity". This terminology is technically questionable, but seems to be what the industry has settled on. Probably because the "proper" terminology would just be confusing to anyone that doesn't understand how the various authentication methods works. So, we will use the "outer identity" or "anonymous identity" to reference this through the rest of this blog post.
Following this identity request, the network will send a challenge message to start the authentication. If you have ever configured authentication for a wireless network, and seen the choices such as (EAP-)PEAP, (EAP-)TTLS, (EAP-)TLS, this is where those settings come in to play. The challenge message that the network sends includes an identifier that tells the client what type of authentication the network wants to use. If the client is configured to allow that type of authentication, the process proceeds. If not, then the client will respond to the network asking for a different type of authentication. If the network allows the type of authentication the client requests then it sends another challenge, this time identifying the authentication method requested by the client.
At this point, the details of the methods used for authentication diverge wildly depending on which authentication system you use. But, the basic ideas are all the same. So, rather than dive in to the details of the various authentication protocols, we will discuss what the goals of the authentication are, and then work backwards.
The network, the client, and the user each have specific goals when they enter the authentication. Those goals are :
- The networks wants to make sure the client is someone that is allowed to use the network.
- The client wants to make sure that it doesn't provide its credentials to anyone other than the networks that it believes it can trust.
- The user just wants to get on the network, everything else be damned.
So basically, the client and the network want to make sure that both the network and the user are protected. But, as usual, the user is the weak link as they will probably do just about anything to gain access to the network. (Facebook statuses won't update themselves!) This is one of the biggest failures in the design of the various authentication protocols. For methods such as PEAP or TTLS, the user has the ability to gut the security of the connection as an easy way of gaining access to the network.
So, if we ignore the desires of the user and focus on the security aspects of the authentication, how do the goals of the network and the client get met?
The first step is for the network to identify itself to the client. Currently, this is done using a word that strikes terror in to most network administrators. "Certificates". Certificates really aren't as scary as most admins think they are, but that is a topic for another blog entry. For the purposes of this discussion, the network provides a certificate to the client that the client can run some checks on to verify that the network is who it claims to be. (Side note : There are a lot of potential security issues with certificates and this type of authentication. But, that is beyond the scope of this post.) If the client decides it doesn't trust the certificate it will either send a message to the network indicating it doesn't like it, or simply disconnect from the network. Assuming it does trust the certificate, various pieces of information are used to generate cartographic keys that allow all of the future messages to be encrypted when they cross the network. This layer of encryption is usually referred to as the "inner tunnel" or sometimes just "the tunnel".
At this point, if the client believes it can trust the network, it will fulfill the desires of the network by proving it should be allowed access to the network. This is usually done by using a second authentication method "inside the tunnel". This portion of the authentication is known in most documentation as "phase 2" or "the inner phase". At this point of the authentication, the client sends the user name and password back to the server using the encryption keys that were generated by the certificate exchange. It is believed that the encryption set up by the certificate exchange is pretty secure, since it is basically the same type of encryption that is used when you purchase something from a secure web site.
Taking a quick side trip back to the beginning of the authentication, it should now be more clear why the initial identity the network requests is called the "outer identity". However, it isn't any more clear why it might be called the "anonymous identity". The reason it can be called that is because the specifications for PEAP and TTLS explicitly state that the first identity request can be answered with an identity of "anonymous" because the users actual user name will be passed to the network using encryption later in the process. The idea is that by returning "anonymous" for the first identity it makes it a little harder for a bad guy to use that identity to target a specific user, since the first identity is sent over the network with no encryption. (Side note : The first identity isn't always sent unencrypted. There are situations where it is encrypted, but the working assumption in the standards is that it is unencrypted.)
Once the user name and password are sent to the network, the network can decide if it wants to allow the client to access the network. If the client is allowed, then the network sends a success message and opens the network up to be used. If the client is not allowed, then the network sends a failure message and blocks the client from using the network.
While I don't want to get in to many of the security aspects of this type of authentication, I do want to point out the weakest link. There is an assumption that the client will validate the certificate the server provides to it. There are a lot of places that can go wrong, but by far the biggest one is the user disabling the checking of that certificate at all. Sadly, some devices like the Nook tablets and Windows RT both default to not checking the certificate, or in the case of the Nook doesn't even allow the user to configure checking the certificate! (Note : I have not looked at the latest Nooks, so it is possible this issue has been resolved.) If the client doesn't verify the certificate, then the client will send the user name and password to any device that pretends to be the wireless network the user wants to connect to. Depending on the authentication method used, this could mean that the password is sent to the bad guy with no encryption, or only lightly hashed.
Hopefully someone finds this post useful. 802.1X authentication can quickly go from something that seems simple enough to a wildly complex set of decisions with potentially huge negative consequences. In the coming months, I plan to go in to more of a "deep dive" on the different authentication methods and what the known risks are with each of those methods.
No comments:
Post a Comment