Linux Unwired [Electronic resources] نسخه متنی

4.3 WPA: a Subset of 802.11i

Work on 802.11i began in 2001 after the
weaknesses in WEP were made public by several teams of researchers.
However, as with any standards body, the IEEE does not always work as
fast as some people would like.

In mid-2002, the Wi-Fi Alliance, an industry consortium, proposed a
subset of 802.11i, based on draft 3 from the IEEE working group, and
called it Wireless Protected Access (WPA). The upcoming full IEEE
implementation is also being referred to as WPA v2.

WPA, as a subset of the 802.11i proposed standard, incorporates two
major features:

Use of 802.1x for authentication

Use of the Temporal Key Integrity Protocol (TKIP)

Chipsets supporting WPA began to become available in 2003. As of this
writing, many access points either support WPA out of the box or have
firmware updates available that include WPA.

WPA is not only an encryption mechanism but also includes 802.1x
authentication, so support is required on the client for the
authentication mechanism. As of this writing, your options are very
limited regarding WPA support in Linux.

A few vendors have released updated firmware for older radio cards
with WPA support; Apple AirPort cards, the Linksys WPC-11, and the
Dell TrueMobile 1150 all have updates available.

The Dell 1150 card is a rebranded Orinoco card; Agere has drivers on its web site listed "for evaluation only" that include this same update. However, Proxim, the new owner of the Orinoco brand, has nothing on its web site about WPA for older cards.

All of this is interesting but not immediately useful, however,
because you can't use any of these cards under Linux
and take advantage of the WPA code in the cards. Why? Because their
associated Linux drivers do not support WPA. As of early 2004, you
have two options if you want to use WPA under Linux, which we discuss
below. In order to take advantage of these methods, you should
understand how 802.1x works.

4.3.1 802.1x Authentication

802.1x was originally designed
for wired Ethernet networks. It is a port-based authentication
mechanism; when a client is authenticated, traffic is allowed to flow
from the Ethernet port of the client through the authenticating
device and out into the secured network.

In a wireless network, the principle is the same. Your notebook
client is required to authenticate to the access point. If
authentication does not occur, wireless frames are not allowed to be
sent through the access point to the wired network.

802.1x authenticates users via a four-part process:

The Supplicant (the client that wants to access a network resource)
connects to the Authenticator (whose resource is needed).

The Authenticator asks for credentials from the Supplicant and passes
the credentials to the Authenticating Server.

The Authenticating Server authenticates the Supplicant on behalf of
the Authenticator.

If the Supplicant is authenticated, access is then granted.

Note that before the authentication is performed, all the
communications go through an uncontrolled port. After authentication,
the controlled port is used.

For the Authenticating Server to authenticate the Supplicant, the
Extensible Authentication Protocol (EAP) is used. EAP supports
multiple authentication mechanisms and was originally developed for
PPP.

There are many variants of EAP. Here are some
that you may come across in wireless security literature:

EAP-MD5

EAP-MD5 uses the
challenge/response method to allow a server to authenticate a user by
requesting a username and password. EAP-MD5 does not provide mutual
authentication and is vulnerable to an offline dictionary attack.

EAP-Transport Layer Security (EAP-TLS)

EAP-TLS is based on X.509 (an ITU standard specifying the contents of
a digital certificate) certificates. It is currently the most
commonly used EAP type for securing wireless networks. However,
EAP-TLS requires the use of Public Key Infrastructure (PKI), which is
not feasible to be implemented on small networks.

Protected EAP (PEAP)

To counter the complexity of using EAP-TLS, PEAP was proposed as an
alternative. PEAP uses a server-side certificate to allow the
authentication of the server. It creates an EAP-TLS tunnel and then
uses other authentication methods over the tunnel. EAP methods such
as MD5, MS-CHAP, and MS-CHAP v2 are supported. PEAP was proposed as
an IETF standard by Microsoft, Cisco, and RSA.

EAP Tunneled TLS (EAP-TTLS)

EAP-TTLS is similar to PEAP. It creates a tunnel between the user and
the RADIUS server. It supports EAP methods such as MD5, MS-CHAP, and
MS-CHAP v2.

Lightweight EAP (LEAP)

LEAP is Cisco's proprietary version of EAP, which
works mostly with Cisco's wireless cards, RADIUS
servers, and access points.

Microsoft Challenge-Handshake Authentication Protocol Version 2 (MS-CHAP v2)

Originally designed by Microsoft as a PPP authentication protocol,
MSCHAP v2 is a password-based, challenge-response, mutual
authentication protocol that uses the Message Digest 4 (MD4) and Data
Encryption Standard (DES) algorithms to encrypt responses. MS-CHAP v2
is now an EAP type in Windows XP.

In the wireless world, suppose a notebook PC needs to connect to an
access point. The notebook PC is the Supplicant, and the access point
is the Authenticator. The access point, as the Authenticator,
maintains a list of users and passwords and acts as the
Authenticating Server. For small networks, this is not an issue; for
large networks, however, this is an additional overhead in
maintenance and a potential security risk, because it means that
users must have another account and password.

In this case, the access point is told to refer to an external
RADIUS server. RADIUS was developed by
Livingston (now part of Lucent) for use in large dial-up modem pools,
and is widely used by ISPs as the authentication mechanism for PPP
and PPPoE users. The protocol is now defined by RFCs 2058, 2138, and
2139.

A RADIUS server maintains the user and password list, and performs
authentication on behalf of the access point. The RADIUS server in
this scenario is the Authenticating Server. Frequently, a RADIUS
server is merely a method to transform authentication from some other
sourcefor example, NIS, LDAP, or Kerberos authentication from
a corporate network, which is then used by the RADIUS server to
authenticate clients.