CNIT 107, Homework #6 -- March 26, 2004

Dan Keller

Wireless Network Security

https://www.dan-keller.com/wifi/CNIT107HW6.html

Overview

Wireless network technology today suffers from poor security. Fortunately, remedial work is underway. In the next year or two, new standards will be released enabling a new generation of wireless technology to function with security that will be adequate for most purposes.

In this homework assignment we briefly survey both existing and future mechanisms for wireless network security. We describe one of these in detail. I have chosen the authentication mechanism called the RADIUS server.

Flaws in Current WLAN Security Schemes

Effective network security protects user data from a variety of threats. These include man-in-the-middle, authentication forging, weak IV attack (AirSnort), packet forgery (replay attack), and dictionary attacks. Description of these threats is beyond the scope of this paper. However, it should be clear that each presents a distinct challenge and demands explicit planning and design for its mitigation. Two of the most commonly-used (and flawed) defense mechanisms are:

Improved Schemes

Here are the main areas of activity to improve wifi security.

RADIUS Protocol

The RADIUS protocol standard is described in RFC 2058.

A RADIUS conversation goes like this:

Laptop: Hello, access point? Let me in!

Access point: Hello, Radius? This guy wants to get in.

Radius: Ask him his name.

Access point: Laptop, what's your name?

Laptop: Mary.

Access point: Radius, it's a girl. She says she's Mary.

Radius: Ask her for her password.

Access point: Mary, what's your password?

Laptop: abc123.

Access point: Radius, Mary says abc123.

Radius: Hmm, let me check... Ok, let her in.

Access point: Ok Mary, you're cool.

Laptop: Thanks, access point. Now let's see, gimme my e-mail, a buncha websites, a telnet session, some instant messaging...

Of course, the technical terminology is more formal. The access point is termed a Network Access Server (NAS) and it operates as a client of RADIUS. It passes user information to the RADIUS server and acts on the response that is returned.

The RADIUS server receives user connection requests, authenticates users, and returns any configuration information necessary for the client to deliver service to the user. For example, users may be restricted by bandwidth throttles or content filters. RADIUS tells NAS what these rules are for each user it authenticates and then NAS must enforce them.

Communications between NAS and RADIUS must be secure. These are authenticated through the use of a shared secret, which is never sent over the network. In addition, user passwords are sent encrypted between NAS and RADIUS, to protect from network snooping.

Each phase of the conversation has a name. The initial contact from NAS to RADIUS is termed an Access-Request. RADIUS's demand for a password is an Access-Challenge. NAS's response is a Reply-Message. RADIUS' final bestowing of its blessing on Mary is an Access-Accept. Had it not recognized Mary, it would have issued an Access-Reject.

Colloquially, the format of the conversation between NAS and RADIUS is called A-V (attribute-value) Pairs. For example, a simplified version of the first Reply-Message from NAS to RADIUS might have been User-Name:Mary where User-Name is the attribute and Mary is the value of that attribute.

It's convenient to think of the protocol as comprised of A-V Pairs and much of the vendor documentation uses this terminology. In fact, the complete specification calls for variable length Attribute-Length-Value 3-tuples. The first of the three parts is a Protocol:Attribute name; the second is its length in bytes, and the third is the value. The beauty of this scheme is that it is easily extended. New attribute values can be added without disturbing existing implementations of the protocol.

RADIUS Software

The RADIUS protocol definition (like any network protocol definition) simply defines an interface, it does not decree how to implement it. Thus, programmers are free to build software however they wish, as long as it communicates according to the protocol. There are several RADIUS server implementations.

Nor does the protocol specify an authentication method. Server implementations support a variety of methods such as PPP PAP or CHAP, UNIX login, and others.

RADIUS servers are often extended to provide ancillary services such as resource accounting. They capture and store such data as which users were authenticated and the time of day. This data is useful for billing, for statistical analysis of usage patterns, and for other services that customers may require. Failures, too, can be logged. This helps in detecting intrusion attempts.

Data collected by RADIUS servers can be stored in local files. A more common and flexible approach is for the server to format this data into SQL which is then passed to a relational database. Thus, instead of in files the data is stored in indexed tables. Fine-tuned report generation can then be done with SQL SELECT statements fed directly to the database. This modular approach means that the RADIUS server itself need have no reporting capability built-in.

Another common strategy is to drive the administrative user interface from a web server. On the web server's backend is a collection of PHP scripts (or JSP applets, or Perl/CGI, etc.) that query and control the RADIUS server and its database. Thus, for example, to add a user to the authenticated community, an administrator would fill in an HTML form which would drive the web server to run a PHP script that would generate SQL to add a row to the user table in the database which, when consulted by RADIUS, would enable it to recognize and authenticate the new user. And that's the RADIUS house that Jack built!

References