SSL Records over EAP

In Chapter 3, we saw that the TLS protocol (namely SSL version 3.1) deployed the SSL Record layer to fragment upper-layer data into suitable units for encryption and integrity protection before delivering the fragments to the underlying TCP protocol. In addition, other SSL protocol messages are transported also using the Record layer. The fact that TLS (SSL) uses a Record layer provides TLS with some independence over the underlying transport protocol used to deliver the SSL Records. Indeed, in EAP-TLS the SSL Records are transported using EAP.

EAP TLS (EAP-TLS) 802.11 802.3 (Ethernet) TLS (EAP-TLS) EAP IP RADIUS Client (EAP Peer) AS/RADIUS (EAP Server) Access Point (Pass-Through Authenticator) EAP 802.11 802.3 (Ethernet) IP RADIUS EAP

Figure 4.1 Example of layers involved in an EAP-TLS session.

The fact that TLS uses the SSL Record as its unit of transport fits well into EAP’s simple packet format. And the fact that EAP can run over layer-2 directly (as in EAPOL) or over the IP layer, provides the ability for TLS (or, more precisely, EAP-TLS) to be run between client and server independent of the underlying

transport medium. In the case of the typical 802.11 WLAN setup, this means EAP- TLS over layer-2 between the client and access point (AP), and continuing over layer-3 between the AP and the authentication server (AS).

Figure 4.1 shows an example of the possible layers involved within a typical 802.11 WLAN configuration. Notice that on the client-to-AP side, EAP runs directly over layer-2, without IP. In contrast, on the AP-to-AS side not only is the IP layer involved, but EAP runs over (encapsulated within) a RADIUS protocol layer. Figure 4.1 illustrates the flexibility of EAP as a “transport” for other protocols (EAP methods or types), which in this case is TLS.

4.2.2 The EAP-TLS Exchange

The basic EAP-TLS exchange is shown in Figure 4.2.1 Here, the EAP-TLS ex-

change begins after the authentication server (or “server” for short) receives the client’s identity in answer to the server’s request.

Note that the EAP peers use the EAP request and EAP response packets to carry their EAP-TLS handshake — or, more precisely, the TLS Records. Note also that the authenticator (e.g., AP) acts as a pass-through device during the EAP-TLS exchange.

The EAP-TLS exchange steps are as follows:

• In step 1 the server signifies the commencement of the EAP-TLS exchange by sending the EAP-TLS/Start message within an EAP request packet. Here the EAP type is defined to be “EAP-TLS” with the start-bit being set to indicate commencement. This message from the server does not carry any data. • In step 2 the client responds to the server by sending the usual TLS Clien-

tHello message embodied within an EAP response packet, with the EAP type

to be “EAP-TLS.” Here, the data field of EAP response packet encapsulates TLS records in TLS record layer format, containing a TLS ClientHello hand- shake message. As in the basic TLS exchange, the ClientHello message con- tains the client’s TLS version number (version 1.0 or later), a session ID, a random number, and a set of ciphersuites supported by the client.

• In step 3 the server responds with the usual TLS ServerHello message, ac- companied by several parameters needed by the client, within an EAP request packet (with EAP type being “EAP-TLS”). Similar to step 2, the ServerHello message is expressed in TLS records, and may contain other parameters, such as the server’s certificate, the server key exchange parameters, a request for the client’s certificate, and the closing ServerHelloDone message. As usual,

1 In Figure 4.2, and other figures in this chapter depicting an exchange, the lines and arrows connect the supplicant to the AS directly for clarity. However, the intent is clear that the authenticator is involved in the exchange, if only as a pass-through entity.

Authenticator Authentication Server Supplicant

EAP Request/Identity

EAP Response/Identity(UserID)

Radius Access Request (UserID) EAPOL/Start

Start EAP Authentication

Request Client Identity

EAP Response/EAP-TLS

EAP Success/RADIUS Access Success EAP Success

EAP-Type=EAP-TLS, TLS ClientHello

EAP Request/EAP-TLS Start EAP-Type=EAP-TLS, Start bit set, no data

EAP Request/EAP-TLS EAP-Type=EAP-TLS, TLS ServerHello, TLS Server Certificate, TLS Server key exchange, TLS Certificate Request, TLS ServerHelloDone EAP Response/EAP-TLS

EAP-Type=EAP-TLS, TLS Client Certificate, TLS Client key exchange, TLS Certificate Verify, TLS ChangeCipherSpec, TLS Finished EAP Request/EAP-TLS EAP-Type=EAP-TLS, TLS ChangeCipherSpec, TLS Finished EAP Response/EAP-TLS

(Deliver copy of Session Key to Authenticator) Key compute Key compute EAP-TLS exchange 1 2 3 4 5 5 6

the ServerHello message must have a TLS version number (version 1.0 or later), a session ID and the selected ciphersuite.

• In step 4 the client responds to the server by sending an EAP response packet containing the parameters requested by the server. These include the client’s certificate, the key exchange parameters, and the closing “finished” message. The session ID in this message must match that in the previous step (in the ServerHello message), lest the server think this is a new session.

• In step 5 both the client and server now have the parameters needed for each to compute the session key that will later be used for deriving the temporal keys employed to encrypt packets in the wireless segment of the communication (see Chapter 8).

• In step 6, since the server is responding to a current session, the server must include a ChangeCipherSpec message with the TLS Finished handshake message. The TLS finished message closes the session that was commenced earlier in step 3 with the ServerHello message.

The reader is directed to [4] for more details on the TLS messages and to RFC 2716 [3] for further details on the implementation requirements of EAP-TLS. Further discussion on digital certificates and PKI can be found in Chapter 3.

4.2.3 Summary of EAP-TLS

This section has attempted to provide only an overview EAP-TLS and its exchange. The important points from this section are the following:

• EAP-TLS as specified in RFC 2716 [3] implements the TLS exchange wrapped within EAP packets. The EAP-TLS method provides mutual au- thentication between the supplicant/client and the AS.

• In EAP-TLS both client-side and server-side certificates are mandatory. One reason for this design decision is the need for strong credentials, something which is true in enterprise networks today. The use of certificates as a strong credential at both end points of the exchange complements TLS (or EAP- TLS) as a strong authentication protocol.

• EAP-TLS is the model for other EAP methods that are also based on TLS. Thus, EAP methods such as PEAP and EAP-TTLS have the same basic exchange behavior and can be seen as building over EAP-TLS.