9.3 The Extensible Authentication Protocol

EAP is supported in the new RADIUS extensions and allows for new authentication types to be used over links running on the PPP protocol. Authentication schemes such as public key, smart cards, one-time passwords, Kerberos, and others are supported over PPP when EAP is used. To support EAP, RADIUS includes two new attributes—EAP-Message and Message-Authenticator—that are described in this section.

Typically, the RADIUS server acts as an intermediary between the client and a backroom proprietary security and authentication server. It normally encapsulates the EAP packets within a standard RADIUS packet, using the EAP-Message attribute, and then transmits them back and forth between the two machines. This lets the RADIUS server talk to the other proprietary authentication server using a standard protocol that requires no special modifications on the RADIUS server. It can still fully support standard RADIUS requests with reduced overhead.

A typical EAP over RADIUS transaction occurs in a standard format, which is outlined here:

The authentication continues as many times as needed until either an Access-Reject message or an Access-Accept message is received. If the EAP transaction follows these typical steps, then the RADIUS client gear will never have to manipulate an EAP packet. Of course, the world is not always as simple as that; as such, there are a couple of caveats to this scenario.

First, you must permit proxy capability between RADIUS machines that may not be compliant with the EAP protocol. If the RADIUS client machine sends the EAP-Request/Identity, as described previously in step two, the RADIUS client has to copy the relevant information into the appropriate fields in a standard RADIUS packet. For example, the contents of the EAP-Response/Identity packet need to be copied into the User-Name attribute. As well, the NAS-Port or NAS-Port-ID attributes should be included in the Access-Request packet, and the NAS-Identifier and NAS-IP-Address attributes must be included. (All of this must, of course, be present in the subsequent packets exchanged between the proxy machines and the original, EAP-compliant RADIUS server.) All of this is to facilitate accounting.

Second, the RADIUS client may not always issue the EAP-Request/Identity packet. Primarily, this occurs when the identity of a user has been verified through some other means, such as a callback and caller-ID value. You can tell this has happened when the Called-Station-ID or Calling-Station-ID attributes are present in a RADIUS packet (these are required to be present when identity is verified through their use). In this case, the RADIUS client sends a standard Access-Request packet to the RADIUS server with an EAP-Message; inside that message is the EAP-Start instruction, which is indicated by sending an EAP-Message attribute with a length of two octets. This method, although convenient, is not within the RADIUS specification as per RFC 2865, and there are problems with this approach when proxies are in use.

9.3.1 Examples of an EAP Conversation

Figure 9-1 is an example of a transaction between a dial-up client, a RADIUS client box, and an EAP-compliant RADIUS server using the OTP authentication scheme. (This is the same example used in the RADIUS Extensions RFC, number 2869. It has been remodeled for clarity and potentially better visual comprehension.)

Figure 9-1. A typical RADIUS over EAP transaction

9.3.2 Potential Uses

EAP has a lot of potential, although its current uses are limited since most of the protocols it uses to talk with a backend security authenticator are proprietary, largely due to a lack of standardization. However, RADIUS over EAP compensates for some of the security deficiencies of the core RADIUS protocol's design, as discussed at length in Chapter 8, and is recommended for use where appropriate.