Both the user and the computer can authenticate to the wireless network without any interaction from the person at the keyboard. You’re probably familiar with cached credentials for Windows systems. Using cached credentials, users can authenticate directly to a system that they’ve authenticated to in the past without having network access to query Active Directory. This is a common scenario for wireless networks. If you have to wait for a user to log into a system before he can authenticate to the wireless network using those same credentials, then what do you do if the user hasn’t logged into this particular system before?

You can use digital certificates to have the workstation authenticate to the wireless network before the user logs in. Thus, even if the user has never logged into this particular system before, the system has access to authenticate to Active Directory. This can be extremely handy for wireless devices that get passed around a lot.

In addition, using certificates we can provide mutual authentication. Mutual authentication means that both parties are authenticating each other. In this case, the client is authenticating the wireless network and the wireless network is authenticating the client. This ensures that both parties are communicating with the intended party.

For these reasons, WPA2-Enterprise with digital certificates is considered the best solution for environments demanding the most security from their wireless networks. For the most challenging of environments, you might consider using WPA2-Enterprise with smart cards, but this is beyond the scope of this book.

A Public Key Infrastructure is not simply the complex math and algorithms behind public keys, private keys, and digital certificates; it is actually all of the technologies, servers, systems, and even human processes that support digital certificates. Many times people will incorrectly refer to PKI as the mathematics that make digital certificates possible, but this is incorrect and doesn’t paint the entire picture. Typically, people are actually referring to Public Key Cryptography, which is a component of an entire Public Key Infrastructure. You can see some of the components that make up a Public Key Infrastructure in Figure 7-1.

Every entity in the digital world that wishes to authenticate using digital certificates has two keys (which can be generated by a third party or generated by the entity itself). The public key can be given to anyone else, and the private key is kept, well, private. Data encrypted using the private key can only be decrypted using the public key. Conversely, data encrypted using the public key can only be decrypted using the private key.

The process is as follows:

Hash functions take in a variable amount of data and produce a fixed-length hash code, or simply “hash.” The reason for this is simple: If we want to verify that two sets of data are the same, we can run both sets of data through a hash algorithm and if the resulting hash (which is much smaller and much easier to compare) is the same, we know the input data was the same. Thus, a hash function will always produce the same hash value for the same input data. The input data can be anything from a binary program file, an entire e-book, or an e-mail with three words in it. The resulting hash will still be the same fixed length.

The hash function cannot be reversed, meaning you can’t take the resulting hash value, run it through a “reverse hashing algorithm” and come up with the original data. This is where the term one-way hash comes from. Arguably the two most popular hashing algorithms today are Secure Hash Algorithm (SHA) and Message Digest Five (MD5). MD5 produces a 128-bit output, whereas SHA-1 produces a 160-bit hash value. In Figure 7-5, you’ll see that although two input files are vastly different in size they both produce the same output length from the hash function.

Many password systems use a hashing algorithm to store the “encrypted” value of the password on the system. Both Unix and Windows systems store passwords as hashed values. If an attacker obtained these hashed values, he couldn’t directly reverse them. Although you can’t reverse a hashed password, you can obtain a password via brute forcing. Remember that brute forcing a password involves running a list of cleartext passwords through the hashing algorithm; if the resultant hash matches the user’s hash, you have ascertained the password.

When Neo composes an e-mail and addresses it to Morpheus, he signs the e-mail using his private key. Remember that to sign the message, the e-mail program Neo is using will run the entire e-mail through a hash algorithm and then encrypt the resultant hash value using Neo’s private key. Neo then appends this signature value to the end of the e-mail and sends it on its way to Morpheus.

When Morpheus receives the message from Neo with details of their next rendezvous point, Morpheus wants to verify that the e-mail has come from Neo and that the message has not been tampered with by anyone. To do this, he takes Neo’s public key and decrypts the signature on the e-mail to come up with the encrypted hash value. He then creates a hash value for himself and compares this with the hash value from Neo’s signature. If the values match, Morpheus knows the message is from Neo and that it has not been changed.

If Mr. Smith changes the actual data in the message and forwards the message on to Morpheus, what will happen? Morpheus receives the message and decrypts the signature using Neo’s public key. So far, so good. This message did in fact come from Neo. However, when Morpheus runs the data through a hashing algorithm and compares that to the hash from the digital signature, they will not match. Therefore, Morpheus will know something is wrong with the message—it was changed either on purpose or accidentally while in transit. Either way, the message is no longer valid, and Morpheus should disregard the message.

So the attacker can’t simply change the data and leave the digital signature, so what can he do? What if the attacker changes the data in the e-mail and also removes the digital signature from the e-mail and then sends it on to the recipient. If Morpheus receives the e-mail and it does not contain a digital signature, the source simply can’t be verified and Morpheus should completely disregard the message.

It would appear Mr. Smith’s only choice is to manipulate the data in the message as well as change the digital signature. So, one last time, Mr. Smith changes the message body and tries changing a few bits in the digital signature. Once Morpheus receives the message and tries to decrypt the digital signature using Neo’s public key, it will fail to decrypt the digital signature, so Morpheus knows he can’t trust the validity of this message.

In the previous examples, we started with the caveat that Neo physically handed Morpheus his public key. In the real world, it would be completely feasible to physically hand someone your public key. In this case, this person doesn’t need a certificate because he knows you personally and has verified the source of the public key for himself. But what about on the Internet or even just a large network where there are potentially thousands of users? Do you really want to figure out a way to obtain, organize, and keep secure thousands of public keys? Unless you’re a complete masochist, the answer should be no. So how do we manage a situation where we can’t possibly personally verify the validity of public keys? The answer is digital certificates, of course, and that is our next topic.

Let’s first take a minute to ponder what real-world problem we are trying to solve with digital certificates. We’re trying to authenticate that a person (or system) is who they say they are. Certificates can provide a strong solution to this problem, and PKI is the infrastructure that supports the secure distribution and authorization of digital certificates.

Let’s first start with a very basic example of how a computer system would use a digital certificate to authenticate itself and then move on to a deeper understanding of exactly how the technologies behind the scenes work. The example everyone is familiar with involves visiting an e-commerce website on the Internet. How do you know the website you’re visiting is the actual intended website and not a website hosted by a malicious attacker that looks completely identical to the legitimate website, waiting to grab your credit card details? Also, how does the owner of the e-commerce website convince you (the potential shopper) that their site belongs to a legitimate business that is reputable to some degree and that your communications are with the intended party.

The e-commerce website will have a digital certificate that states their identity as well as who has verified their information. The certificate presented to you by the e-commerce website will be digitally signed by a “trusted” third-party known as an Internet Certificate Authority. There are many Certificate Authorities available to the owner of the e-commerce website to sign their digital certificate and thus prove the identity of the website.

The locations on your computer where certificates are saved are known as certificate stores. The Trusted Root Certification Authorities Store is the location of all the Certificate Authorities your computer is configured to trust.

So here’s where the real-world problem presents itself. Yes, your computer is preconfigured to trust VeriSign and thus trust certificates signed by VeriSign, but does that mean that you (a flesh and blood person) should actually trust VeriSign, and what exactly does that even mean (to trust a company)? Ultimately, if you as a flesh and blood person trust VeriSign, that would tend to imply that you trust Verisign’s processes for thoroughly verifying the identity of the people and businesses they provide digital IDs for. This, of course, is a difficult thing for many reasons. First of all, people who don’t work for a Certificate Authority will probably not know the inner workings of how the Certificate Authority actually verifies identities. Second, these verification processes have proven to have flaws, where individuals and businesses that should not have passed the verification process have received digital certificates.

Remember that we’re talking about the process that employees of Certificate Authorities follow to verify identities. Whenever there is human involvement in a security process, your ears should perk up, because humans are far more prone to error than computers.

The vast majority of digital certificates today are in the format of an X.509 certificate, which is currently in version 3 (X.509 v3). The X.509 standard utilizes the X.500 naming convention. The X.500 standard has its own hierarchical naming convention, which we’ll look at later. You might already be familiar with the X.500 standard, which deals with electronic directory services. The Lightweight Directory Access Protocol (LDAP), which is a component of Microsoft Active Directory, has a similar hierarchical naming convention.

Digital Certificates contain important information, including the owner of the certificate, the issuer of the certificate, and the public key of the owner. Remember that all of this information is signed using the issuing Certificate Authority’s private key. Thus, if anyone, including the owner of the certificate, tries to change any of the information, the signature will indicate that something is wrong with the certificate.

In Figure 7-11, you can see a few of the entries in the giant list of trusted Certificate Authorities that the Chrome browser trusts by default. You can manually add trusted Certificate Authorities to this list.

You can think of each of the subordinate CAs as a child to the higher-level CA. The parent CA would sign that child’s certificate, at which point the child could sign certificates using its own certificate (or private key). It is typically advised to take the root CA offline once you have deployed your intermediate CAs to ensure the security of your entire CA hierarchy. A compromise of any of the Certificate Authorities would compromise all of the CAs beneath it in the hierarchy. Many times segmentation makes sense to separate CAs with different functions. For example, you might have one CA that issues only authentication certificates while another CA issues certificates used solely for secure e-mail.

An enterprise certificate server, on the other hand, has to be a member of an Active Directory domain. This integration with Active Directory allows for additional features and greater flexibility. The following are the defining characteristics of an enterprise certificate server, straight from Microsoft:

Wait a minute, doesn’t that run completely counter to everything we just discussed about issuing certificates? If we have a server automatically sending people certificates, how do we know that it’s giving the certificates to the appropriate people? An excellent question. In this case, because we’re configuring an enterprise Certificate Authority, which integrates with Active Directory, we just rely on the fact that the users have already authenticated themselves with their Active Directory credentials and are on clients that are members of our domain.

In addition, because an enterprise CA has access to write to Active Directory, it can publish the root certificate to Active Directory as well as the Certificate Revocation List. The root certificate for the domain will then propagate down to each member of the AD domain to the Trusted Root Certification Authority Store on that system.

Microsoft also defines certificate templates, which are a necessary component for using auto-enrollment. Creating a template defines the type of certificate, the key size, the hash algorithm used, what the certificate will be used for, and so on. You then select the users who are allowed to automatically obtain certificates using that template. We will cover the steps to configure automatic enrollment and certificate templates in the next chapter.

RADIUS provides authentication, authorization, and accountability (or AAA). Therefore, the RADIUS server is sometimes referred to as a “Triple-A server.” It’s easy to understand how RADIUS provides authentication, as this may be considered its primary purpose. Authorization can be performed and is closely related to authentication. Authorization can stipulate specific actions that the user can perform or certain resources the user can access. In addition, the server can keep an audit log of a user’s activity, which would provide accountability of the user’s actions.

Your RADIUS server can be a stand-alone system that authenticates users against a local database, or it can authenticate users against an external database such as Active Directory. In Figure 7-13, you’ll see an example of a RADIUS server using a database on the same system which holds the user credentials. In Figure 7-14, you’ll see an example of a RADIUS server authenticating to a separate server which holds the database of user credentials, such as Active Directory.

RADIUS is assigned UDP ports 1812 and 1813 by the Internet Assigned Numbers Authority (IANA). Port 1812 is used for authentication, whereas port 1813 is used for accounting. However, before the official UDP ports had been assigned by IANA, many vendors had settled on using UDP port 1645 for authentication and UDP port 1646 for authentication. Therefore, some RADIUS servers listen to both sets of UDP ports by default. Microsoft RADIUS servers default to using UDP ports 1812 and 1813. You should check the documentation for your specific RADIUS server to determine which UDP ports it listens on by default. However, the protocol operates completely identical no matter which UDP port the server is configured for. The administrator of the RADIUS server configures a shared secret, which must be entered on the authenticator to ensure it’s also an authorized agent.

The communication between the clients, the authenticator, and the authentication server happen using the Extensible Authentication Protocol (EAP), which we discussed in Chapter 6. Essentially, the authenticator (in our case, the access point) is relaying the messages between the supplicant and the authentication server and doesn’t necessarily understand the messages being exchanged. It just waits to see an authentication success message from the authentication server, at which point it grants access to the wireless client.

To better understand how 802.1x functions on a wireless network, you should understand its roots in wired networks. 802.1x, or Port-Based Access Control, requires users to authenticate to the switch they’re physically connected to before they’re granted access to the network. Typically, this authentication will happen against a unique database that resides on a server separate from the network device the user is directly connected to. 802.1x has its own unique nomenclature to identify each component in the authentication process. 802.1x refers to these components as a supplicant, authenticator, and authentication server. In a wireless network, a user’s laptop would be the supplicant, the wireless access point would be the authenticator, and the RADIUS server would be the authentication server. This basic architecture is shown in Figure 7-15.

Any client device (supplicant) that wishes to connect to the protected network must support the 802.1x protocol in the form of client software, typically referred to as supplicant software. Most modern operating systems come preinstalled with supplicant software; however, you may need to install supplicant software, depending on your client devices and authenticators.

Both RADIUS and 802. 1x are highly versatile systems. Remember that as well as being able to operate separately, these two systems handle much more than just authentication for wireless clients. You could employ an identical design using switches to authenticate users before they’re allowed access to the wired LAN. In some documentation, you may see WPA-Enterprise referred to as WPA-802.1x

Also remember that certificates are optional in a WPA-Enterprise network. The core architecture is the same except for the addition of the Certificate Authority. This is shown in Figure 7-17 and 7-18, respectively. We’ll cover the configuration of WPA-Enterprise without certificates in Chapter 9.

You should understand that for a client computer to download the certificate for the CA, it must have network access to Active Directory, meaning that this can’t happen over the same wireless network the user wants to authenticate to without having previously obtained the certificate. Therefore, you must ensure that the computer is connected to the network via hardwire or a different wireless network before attempting to authenticate to the wireless network to allow the computer to download the CA certificate. The same is true for the user’s certificate obtained through auto-enrollment.

Before we go any further, we’ll do exactly that. We’ll connect our laptop to our LAN and verify that it was able to download both the Certificate Authority certificate and the user certificate to be used for authentication to the wireless network. We’ll then configure our RADIUS server. In Windows 2008, the RADIUS functionality is under the role of the Network Policy Server (NPS).

A connection request policy is a policy on the NPS that designates which RADIUS clients we’ll accept requests for and what we’ll do with them. In our case, the RADIUS client is our access point, and we will accept authentication requests from this client. We then create a Network Policy that combines the connection request policy and assigns the users and the conditions that allow them to authenticate successfully.

Finally, we’ll configure our wireless access points, which is probably the easiest part. We’ll configure the access point to use WPA2-Enterprise and configure it to authenticate to the IP address of the RADIUS server we configured. Then we’ll test authentication from our client device to the access point. After successful authentication, you can pour yourself a huge glass of your favorite drink and take a much-deserved vacation!

In this chapter, we looked at the following topics: