Let's first define exactly what authentication is, and what the technology expects out of the authentication process. We've mentioned credentials immediately preceding this section. An authentication credential is something that one party to communication has that the other parties can use to verify whether the user is really who he claims he is and is authorized to join the network.
In the preshared key case, the authentication credential is just the preshared key, a global password that every user shares. This is not very good, because every user appears identical, and there is no way for users to know that their networks are also authentic. Authentication should be a two-way street, and it is important for the clients to know that the network they are connecting to is not a fraud. With preshared keys, anyone with the key can set up a fraudulent rogue access point, install the key, and appear to be real to the users, just as they can arbitrarily decrypt over-the-air traffic.
Normal computer account security, such as what is provided by email servers, enterprise personal computers, and Active Directory (AD) networks, generally uses the notion that a user has a unique, secret password. When the user wants to access the network, or the machine, or the email account, she enters her password. If this password matches, then the user is allowed in. Otherwise, he or she is not.
(In fact, to prevent the system administrators from having access to the user's password, which the user might use in other systems and might not want to share, these systems will record a cryptographically hashed version of the password. This version, such as the MD5-hashed one mentioned in the next section, prevents anyone looking at it from knowing what the original password is, yet at the same time allows the user to type their password at any time, which leads to a new MD5-hashed string that will be identical to the one recorded by the system if and only if the passwords are identical.)
This identifies the user, but what about the network, which can't type a password to prove itself to the user? More advanced authentication methods use public key cryptography to provide more than a password. The background is quite simple, however. Public key cryptography is based on the notion of a certificate. A certificate is a very small electronic document, of an exact and precise format, containing some basic information about the user, network, or system that the certificate represents. I might have a certificate that states that it is written for jepstein@somecompany.com, pretending for a moment that that is the name of my user account at some company. The network might have a certificate that states it is written for network.somecompany.com, using the DNS name of the server running the network. To ensure that the contents of the certificate are not downright lies made up in the moment, each certificate is signed using another certificate, that of a certificate authority who both parties need to trust in advance. Finally, each certificate includes some cryptographic material: a public key, that is shouted out in the certificate, and a private key, which the owner of the certificate keeps hidden and tells no one. This private key is like a very big, randomly generated password. The difference is that the private key can be used to encrypt data that the public key can decrypt, and the public key can be used to encrypt data that the private key can decrypt. This allows the holder of the certificate to prove his or her identity by encrypting something using his or her private key. It also allows anyone else in the world to send the holder of the certificate a private message that only the holder can decrypt.
Certificates are necessary for network authentication. When the user tries to authenticate to the network, the network will prove its identity by using its private key and certificate, and the client will accept it only if the network gives the right information based on that certificate. Certificates are also useful for user authentication, because the same properties work in reverse. The EAP method known as EAP-TLS requires client certificates. Most of the other Wi-Fi-appropriate EAP methods use only server certificates, and require client passwords instead.
To recap, authentication over Wi-Fi means that the user enters a password or sends his certificate to the AAA server, which proves his identity, while the network sends its certificate to the client, whose supplicant automatically verifies the network's identity—just like how web browsers using HTTPS verify the server's identity.
It is the EAP method's job to specify whether passwords or certificates are required, how they are sent, and what other information may be required. The EAP method also is required to allow the AAA server and the client to securely agree to a master key—the PMK—which is used long after authentication to encrypt the user's data. The EAP method also must ensure that the authentication process is secure even though it is sent over an open, unencrypted network, as you will see in the following section on 802.1X.
The administrator is allowed to control quite a bit about what types of authentication methods are supported. The AAA administrator (not, you may note, the networkadministrator, unless this is the same person) determines the EAP methods, and thus the certificate and authentication requirements. The AAA administrator also chooses how long a user can keep network access until he or she has to reauthenticate using EAP. The network administrator controls the encryption algorithm—whether to use WPA or WPA2. Together, the two administrators can use extensions to RADIUS to also introduce network access policies based on the results of the AAA authentication.
No comments:
Post a Comment