Today’s 802.11 networks authenticate users according to the IEEE 802.1x standard. 802.1x specifies how to run the Extensible Authentication Protocol (EAP) directly over a link layer protocol. EAP is essentially a transport protocol that can be used by a variety of different authentication types known as EAP methods. EAP was standardized by the IETF in March 1998 for use over point-to-point network connections.

Among the EAP methods developed specifically for wireless networks are a family of methods based on public key certificates and the Transport Layer Security (TLS) protocol. These are EAP-TLS, EAP-TTLS, and PEAP. We will consider each of these in this section, and then consider another family of EAP methods, the strong password methods (sometimes known as Zero Knowledge Password Proof – ZKPP).

3.1. EAP-TLS
EAP-TLS uses the TLS public key certificate authentication mechanism within EAP to provide mutual authentication of client to server and server to client. With EAP-TLS, both the client and the server must be assigned a digital certificate signed by a Certificate Authority (CA) that they both trust.

Features of EAP-TLS include:

• Mutual authentication (server to client as well as client to server)
• Key exchange (to establish dynamic WEP or TKIP keys)
• Fragmentation and reassembly (of very long EAP messages necessitated by the size of the certificates, if needed)
• Fast reconnect (via TLS session resumption)

3.2. EAP-TTLS
The Tunneled TLS EAP method (EAP-TTLS) provides a sequence of attributes that are included in the message. By including a RADIUS EAP-Message attribute in the payload, EAP-TTLS can be made to provide the same functionality as PEAP (discussed below). If, however, a RADIUS Password or CHAP-Password attribute is encapsulated, TTLS can protect the legacy authentication mechanisms of RADIUS. When the TTLS server forwards RADIUS messages to the home server, it decapsulates the attributes protected by EAP-TTLS and inserts them directly into the forwarded message. Because this method is so similar to PEAP, it is being used less frequently.

Figure 1

3.3. PEAP
Like the competing standard TTLS, PEAP makes it possible to authenticate wireless LAN clients without requiring them to have certificates, simplifying the architecture of secure wireless LANs. Protected EAP (PEAP) adds a TLS layer on top of EAP in the same way as EAP-TTLS, but it then uses the resulting TLS session as a carrier to protect other legacy EAP methods. PEAP uses TLS to authenticate the server to the client but not the client to the server. This way, only the server is required to have a public key certificate; the client need not have one. The client and server exchange a sequence of EAP messages encapsulated within TLS messages, and the TLS messages are authenticated and encrypted using TLS session keys negotiated by the client and the server.

PEAP provides the following services to the EAP methods it protects:

• Message authentication (Imposters may neither falsify nor insert EAP messages.)
• Message encryption (Imposters may neither read nor decipher the protected EAP messages.)
• Authentication of server to client (so that the protected method only needs to authenticate client to server)
• Key exchange (to establish dynamic WEP or TKIP keys)
• Fragmentation and reassembly (of very long EAP messages, if needed)
• Fast reconnect (via TLS session resumption)

PEAP is especially useful as a mechanism to augment the security of legacy EAP methods that lack one or more of the above features.

Microsoft PEAP
Microsoft PEAP supports client authentication by onlyMS-CHAP Version 2, which limits user databases to those that support MS-CHAP Version 2, such as Windows NT Domains and Active Directory.

To use Microsoft’s PEAP, users must purchase individual certificates from a third-party certification authority (CA) to install on their IAS, and a certificate must be installed in the user’s local computer certificate store. For wireless clients to validate the IAS certificate chain properly, the root CA certificate must be installed on each wireless client.

Windows XP, however, includes the root certificates of many third-party CAs. If the IAS server certificates correspond to an included root CA certificate, no additional wireless client configuration is required. If users purchase IAS server certificates for which Windows XP does not include a corresponding root CA certificate, they must install the root CA certificate on each wireless client.

Cisco PEAP
Cisco PEAP supports client authentication by One-Time Password support (OTP) and logon passwords. This allows support for OTP databases from vendors such as RSA Security and Secure Computing Corporation, and also supports logon password databases like LDAP, Novell NDS, and Microsoft databases. In addition, the Cisco PEAP client can protect user name identities until the TLS encrypted tunnel is established. This provides additional assurance that user names are not being broadcast during the authentication phase.

3.4. PROBLEMS WITH CERTIFICATE BASED METHODS
Despite the many advantages of certificate-based EAP types, there are some disadvantages as well.

3.4.1. Cost of Administration
The biggest down side to certificates is the cost of administration. All of the methods in this family require the authenticator to have a public key certificate signed by an authority that is recognized by the clients (the users’ devices). This requires network administrators either to purchase server certificates from a commercial certificate authority (CA) or to acquire the software and expertise to create their own. Next, each device that will access the network must be configured to recognize the certificates of the authenticator and the CA. The EAP-TLS method requires all the user devices to have certificates as well. This significantly increases the cost of administration. Not only do certificates have to be created or purchased for each user device, but distribution can be a problem as well – there must be a method of securely installing the certificates on the user devices. Also, it can be difficult to maintain a Certificate Revocation List (CRL) so that the authenticator will know which certificates are good and which are not.

3.4.2. Lengthy Protocol Exchange
A second disadvantage of using a certificate-based EAP method is the number of sequential protocol exchanges (round trips) that are required between the user client and the authenticator in order to complete the authentication. For example, to authenticate a single user via EAP-MD5 protected by PEAP requires six round trips between the user station and the authenticator. Requiring a large number of protocol exchanges both lengthens the authentication delay for the user and uses more computing resources on the authenticator. Because the authentication delay is a particular problem for mobile users who must be reauthenticated when moving from one access point to another and who require a seamless handoff so as not to disrupt ongoing sessions, these methods all permit use of the TLS session resumption feature. This mitigates the handoff problem, but does not help the initial authentication.

3.4.3. Authenticates the Device Instead of the User or Requires a Smart Card
A third disadvantage is that the certificate must either be stored on the user device or on a smart card that the user carries. When certificates are stored on the user’s device, it is the device that is authenticated rather than the individual user. In environments where the device cannot be sufficiently secured or where many individuals use the device, it is important to authenticate each individual user. A smart card is a way users can carry their certificates with them, but they are a source of inconvenience and require all the devices to have a card interface.