Supplicant to AS Authentication Protocols

If we view EAP as the encapsulating format (or even as a general “transport” mechanism) for authentication information exchanged between a supplicant and AS, the next question would be which authentication protocol is to be executed between the supplicant and AS (to prove, among others, to the AS that the supplicant is indeed the entity is claims to be).

The answer is that EAP is extensible enough that the security engineer needs to “instantiate” EAP with the authentication protocol that she or he wishes to use. To that extent, the EAP specifications talk about “methods” or “types” that need to be defined for a particular usage scenario. Note that the EAP methods need not only be related to security,3but can be any other method defined for other functions in a WLAN. EAP will be further discussed in Chapter 3.

Figure 2.3(b) shows an overview of an authentication process and key gener- ation. This can be better understood by looking at the 802.1X process as consisting of four phases:

1. Identity establishment: In the first phase, the supplicant and the AS begin exchanging identity information. This occurs after the 802.11 association. This leads to the need of each end point to prove their identities (namely, through authentication). Part of this phase is for the AS to indicate to the client which authentication method the AS is expecting to use.

2. End point (mutual) authentication: In the second phase, the supplicant and the AS execute the authentication protocol, expressed as an EAP method. Note that not all EAP methods for authentication provide mutually strong

3 At the time of this writing, there were over two dozen EAP methods that had been proposed, five or six of which were related to security functions.

authentication. For example, a password-based method such as EAP-CHAP does not provide a strong authentication as one side (the supplicant) supplies only a password, which is a weak credential.

3. Encryption key derivation: The successful outcome of the authentication pro- cess results in both the supplicant and AS deriving some common crypto- graphic parameter (i.e., keys) that will be used for the basis for deriving (tem- poral) encryption keys used to encrypt the data in frames for the over-the-air segment of the communications.

Since the over-the-air segment is the segment between the supplicant and the AP, and since the AP has so far not been involved in key negotiations, the AS must forward a copy of the derived common cryptographic parameter to the AP so that the AP can begin to derive the (temporal) frame encryption keys and itself begin encrypting/decrypting data frames to/from the Suppli- cant. See Chapter 8 for further information on the key derivation algorithms. 4. Frame encryption/decryption: Once both the supplicant and the AP have begun to derive (temporal) keys for the encryption of data in frames, they can begin using the keys to encrypt frames. Note that when frames from the supplicant have been decrypted by the AP, the wired segment of the communications from the AP to the AS is by default in plaintext. Thus, additional security mechanisms must be applied for that wired segment (e.g., encryption in RADIUS or establish IPsec VPNs).

The reader is directed to Chapter 3 for further discussion on how 802.1X func- tions with the EAP protocol (as transport) and EAP methods (as the authentication protocols).

2.6 THE RADIUS PROTOCOL

The remote authentication dial-in user service (RADIUS) [11] is an authentication protocol that has wide deployment in the dial-up Internet services world. Due mostly to its simple password-based authentication method and simple transaction structure, RADIUS has become the de facto “authentication protocol” in the dial- up world for IP connectivity using the point-to-point protocol (PPP) [12]. More recently, interest in RADIUS has also been extended to the new area of WLAN authentication. In this section we briefly review RADIUS in order to provide a context for ensuing discussions in the following chapters.

RADIUS follows the client-server model, where a RADIUS client interacts with a RADIUS server, through possibly one or more RADIUS proxies. In the context of dial-up services the client is typically the network access server (NAS) that is usually connected to (collocated with) the remote access server (RAS), which

is essentially the end point of the dial-up connection over the telephone line (PSTN). From the client’s perspective a RADIUS-server is responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user. As such, RADIUS offers functionality beyond just authenticating a user, and provides support for authorization and accounting/auditing (AAA).

RADIUS runs over UDP (instead of TCP) for a number of reasons, though primarily because RADIUS is essentially a stateless transactions-based protocol. More specifically, in its expected usage environment, multiple RADIUS servers may be deployed to provide service reliability. Here, when one server becomes unavailable, a backup server must take on the transactions of the first server. Hence, a copy of the request must be kept above the transport layer to allow for alternate transmission. This points to UDP in the case of RADIUS being a better underlying transport than TCP. However, the use of UDP implies that the end point RADIUS entities must deploy their own reliability mechanisms to handle lost packets. Many RADIUS implementations and deployment cases today just use simple retransmission as a reliability mechanism. Finally, RADIUS was designed with a nonaggressive response in mind. The user is expected not to mind waiting several seconds for an authentication to complete. As such, TCP was deemed to be too aggressive for the needs of RADIUS.

Within the context of the 802.1X authentication framework, RADIUS is the most oft-cited protocol for supporting WLAN authentication. Here, the 802.1X supplicant (e.g., 802.11 AP) is in fact the RADIUS client communicating with the 802.1X AS, which is the RADIUS server. In the context of WiFi roaming, RADIUS is also the most oft-cited authentication protocol since many ISPs and aggregators who are providing new WiFi roaming services typically already have a dial-up infrastructure built using RADIUS, which represents a technology investment these organizations would naturally like to preserve.

From the perspective of protocol extensibility, RADIUS provides an attractive solution as all transactions between the client and server are based on the 3- tuple attribute-value-length (AVL) format. As such, a given implementation of RADIUS can introduce its own domain-relevant extensions without affecting other implementations.

In this section, we briefly cover the RADIUS server emphasizing points and issues relevant to the WLAN deployment. For a more comprehensive treatment of RADIUS itself, the reader is directed to the RADIUS-related RFCs (RFC2058 [11], RFC2865 [3], RFC2866 [7], RFC3579 [8], and others) and to the book [13].