802.11i Groundwork

When the IEEE created the 802.11i amendment, they successfully grafted much of the infrastructure used to secure wired networks onto the wireless world. This immediately improved the security of 802.11 networks tremendously. It also required network administrators become familiar with many protocols they might not have run into before. This section aims to clear up the mystery behind all of the protocols that the 802.11i amendment sits on top of.

Few people realize that at 802.11i's core is a protocol with roots going as far back as 1992. This protocol is the Extensible Authentication Protocol (EAP), and in order to understand what 802.11i does (and the myriad of intertwined protocols it uses under the covers), it helps to study EAP and where it came from.

Technically, EAP didn't become its own protocol until 1998, when RFC 2284 was first published. However, the beginnings of EAP are evident in the Point-to-Point Protocol (PPP) RFCs (see section 7.2 of RFC 1331), where EAP evolved and first came into use.

PPP is a popular protocol used by dialup ISPs. PPP acts a sort of link layer on your phone line between you and your ISP. It allows you to encapsulate more than one network layer protocol, though it is currently used for IP almost exclusively. PPP includes features that you probably never thought you needed, but it addresses issues that had been quite a problem. The most obvious is how do you handle IP address configuration across a dialup link? Your phone line is not an Ethernet cable; you cannot simply send a DHCP request to the broadcast address. PPP addresses this and various other network layer configuration problems through a library of what it calls Network Control Protocols (NCPs). The particular protocol used to configure IP over PPP is IPCP, and it is specified in RFC 1332.

As PPP matured, it became clear that a method for authenticating users was required. Initially, the standard specified two ways for users to authenticate: PAP and CHAP. PAP stands for Password Authentication Protocol, but it should really be named Plaintext Authentication Protocol. PAP is a euphemism for sending a username and password across the wire in the clear; they had to call it something.

CHAP stands for Challenge Handshake Authentication Protocol. CHAP is probably the forerunner to any other challenge-response protocol you might have seen. Basically, the ISP sends you a random challenge, and you compute a hash of a function that takes your password and the challenge as input and sends the hash back. If you know the password, you can compute the hash; if not, you can't. The ISP does the same, and if your hashes match, you must know the secret.

Now CHAP was a big improvement over PAP (since the password is never sent in the clear), and most dialup users still use either CHAP or PAP. However, the people writing the standard could see that they might be adding more and more authentication schemes as time progressed. Instead of modifying the PPP protocol every time a new authentication scheme was cooked up, they modified it so PPP could handle arbitrary authentication schemes. They did this by creating EAP.

Extensible Authentication Protocol (EAP)

EAP is a very small protocol. When most people think of protocols, their head immediately fills up with layer-two protocols such as Ethernet, layer-three protocols such as IP, and so on. EAP is very different than the protocols most people are familiar with. It is designed to run directly on top of layer-two protocols (such as Ethernet or PPP), but it is not really supposed to carry arbitrary network/transport protocols on top of it. Also, unlike most protocols that run directly on top of the link layer, there is no real addressing scheme. As far as EAP is concerned, there are only two entities: the entity requesting to be authenticated (for example, a dialup user or a wireless client) and the entity on the other end of the link doing the authenticating. EAP has been modified to use the same terms for these entities that 802.1X uses (EAP came first, but the 802.1X terminology became more ubiquitous). Consequentially, this means that EAP calls the entity that wants to be authenticated the supplicant, and the guy on the other end of the link doing the authentication is called the authenticator. The dialup user scenario is shown in Figure 3-8.

To return to wireless security for a moment, consider the diagram in Figure 3-9. The layer labeled EAPOL stands for EAP over LAN, which is covered in the 802.1X section. Although EAP is certainly used in wireless authentication, we are going to continue with the dialup example because that is where the protocols covered in this section actually originated.

Now that you know who EAP exchanges messages with, I'll describe those messages. EAP is deceptively simple; there are only four categories of messages defined in the standard (RFC 3748):

• Request Request packets are sent by the authenticator (think access point or an ISP's modem bank) to the supplicant (user).

• Response Responses are sent from the supplicant (user) to the authenticator (access point/modem bank).

• Success Sent by the authenticator to the supplicant to indicate that authentication was successful.

• Failure Sent by the authenticator to the supplicant to indicate that authentication was unsuccessful.

The layout of an EAP request/response is shown in Figure 3-10. In the packet, the Code field is used to determine if the EAP packet is a request, response, success, or failure message. The Identifier is used as a serial number to pair up responses with requests. Length specifies the size of the packet (in bytes, including the header). The interesting fields are the Type and Type-Data fields.

Type indicates the specific authentication type being used. Only a few of these are defined in the standard. The people who created the EAP standard are not responsible for creating specific authentication schemes. Examples of authentication schemes include EAP-TLS, which authenticates the supplicant with the use of certificates, or EAP-MD5, which is a simple challenge-response authentication scheme using MD5. The important thing to remember is that the authentication-specific details of all these messages are buried inside the Type-Data field.

Once EAP authentication begins, any number of request and response packets may be exchanged. The only requirement is that the exchange ends with either a success or failure. Regardless of the authentication scheme being used, an EAP packet with the Code field set to 3 (success) will be sent if authentication is successful.

In the simple exchange shown in Figure 3-11, the authenticator asks the supplicant his name. When the supplicant responds, the authenticator decides to let the supplicant in. This might seem like a trivial authentication scheme, but it can be useful. For example, some sort of token device might generate the user's identity. The real motivation for this example, however, is to introduce the EAP request identity message.

One of the few authentication types that the EAP standard specifies is the EAP request identity type. If it is hard to conceptualize asking someone to identify themselves as being a reasonable authentication scheme, so be it. Just think of it as the standard overloading the Type field for a special case. Regardless of whether or not asking someone his or her identity is a real authentication scheme, the standard explicitly covers it, and it is used in the opening phases of almost any authentication scheme. Even if you are going to deny someone access, you at least want to know who they claim to be.

Generally, the identity sent back is a username of some sort. The standard doesn't lay out any hard and fast rules, however. An identity could be a computer name, for example.

The most important thing to remember about EAP is that any authentication scheme can be put on top of it. This allows new authentication schemes to be deployed without disrupting the basic protocols carrying EAP messages around.

Introduction to RADIUS

So far in the dialup authentication example, the user can authenticate to the ISP using any authentication scheme that takes place over EAP. The problem with this model is that the EAP messages are only being passed from the user to the ISP's modem bank (or point of presence, as it is called). If the user were authenticating with a username and password, every modem bank would need its own copy of the username/password database. This is clearly inefficient. A more desirable model is shown in Figure 3-12. In this model, the authentication server is a central repository of usernames and passwords.

The protocol that forwards EAP messages from the authenticator to the authentication server is called Remote Access Dial-In User Service (RADIUS). RADIUS was originally defined to solve the username/password database problem when using the built-in CHAP/PAP authentication over PPP. Once EAP was created, and advanced authentication techniques implemented on top of it, RADIUS was modified to transport EAP. This is specified in RFC 2869.

As far as wireless security is concerned, RADIUS is really just a crunchy old protocol being used to transport EAP packets from an access point to an authentication server, and that is how we are going to treat it. This crunchy old protocol happens to run on top of UDP, so you can finally get the authentication packets from the end-users (who have no network layer connectivity) routed somewhere. RADIUS actually contains other complicated features related to accounting and so on, but these features aren't strictly related to wireless security and so will be overlooked for now.

RADIUS terminology, unfortunately, does not match up with that used in EAP or 802.1X. This biggest difference is that RADIUS calls the point of presence (or access point in the wireless world) a Network Access Server (NAS). This is confusing because as far as RADIUS is concerned, the access points and POPs are really clients. EAP and 802.1X both refer to these entities as authenticators.

RADIUS resembles EAP in some sense (or more accurately, EAP resembles RADIUS since RADIUS came first). Like EAP, it has four important messages related to authentication:

• Access-request Packets sent from the NAS (access point, POP) to the authentication server

• Access-challenge Responses sent from the authentication server to the NAS (access point, POP)

• Access-accept Sent by the authentication server to the NAS to indicate successful authentication

• Access-reject Sent by the authentication server to the NAS to indicate unsuccessful authentication

You can see from the terminology used for the RADIUS messages that RADIUS was designed with CHAP in mind. This is why access-challenge is called access-challenge, not access-response. Nonetheless, there is an orderly relationship between these four RADIUS packet types and EAP. When using EAP over RADIUS, EAP request messages are sent to the authentication server inside access-request messages. EAP responses are sent back to the authenticator (or NAS, in RADIUS speak) in access-challenges.

The original motivation presented for this three-tier authentication architecture was to avoid duplicating copies of a username/password database to all the POPs an ISP operates. A more general consequence of this is that the authenticator no longer has to process (or even comprehend) the authentication scheme employed between the end-user and the authentication server. As shown in Figure 3-13, consider what the authenticator is doing in general now.

The authenticator simply takes the end-user (supplicant's) EAP packets, wraps them up in a RADIUS packet, and sends them to the authentication server. Similarly, when it receives a response for the authentication server, it strips off the RADIUS packet, pulls out the EAP frame, and forwards it on to the client. The authenticator continues proxying these messages back and forth (without having to understand them) until it receives a RADIUS access-accept/access-reject message from the authentication server. The net result of this is that you can drastically change the authentication scheme on your wireless network (or dialup network) without having to modify any settings on your access points/POPs.

Once the ISPs modem bank receives the RADIUS access-accept packet, it knows that the authentication server has authenticated the client, and it is okay to let her connect. Keep in mind that at no point during this exchange did the modem bank have to know what sort of authentication method the dialup user and authentication server employed.

802.1X: Bringing EAP to the LAN

I have been discussing authentication protocols in terms of dialup users for two reasons. One is that all of the protocols mentioned so far were developed in the context of dialup users. The other is that it let me avoid introducing even more cumbersome terminology.

802.1X is another standard controlled by the IEEE (the 802. is a dead giveaway). In some sense, 802.1X is unique because it is tightly related to EAP. EAP, however, is administered by the IETF and documented in RFCs. The simplest way to describe 802.1X is to say that it wants to bring the EAP-based authentication outlined previously to everyday LAN users. The most straightforward case to consider is Ethernet.