Wireless DevCenter    
 Published on Wireless DevCenter (http://www.oreillynet.com/wireless/)
 See this if you're having trouble printing code examples


Building Wireless Community Networks

NoCatAuth: Authentication for Wireless Networks

by Rob Flickenger, author of Building Wireless Community Networks
11/09/2001

Wireless technologies, and 802.11b in particular, are making it easier and cheaper to connect large numbers of people through over-the-air networks. For the cost of hardware and a bit of planning, large amounts of information can now be sent for miles at very little cost, without ever involving a telephone or cable company.

But the freedom and flexibility of these wireless networks requires some careful planning. If you want to build a Community Wireless Network and offer network services to a group of people (or even the public at large), you'll have to address the issue of who is responsible for traffic entering the Internet. Personal responsibility: ultimately, there's no avoiding it.

While some public-node operators are perfectly happy opening their networks to whomever happens to be in range, many of us hesitate at the thought of paying for our neighbors to use our bandwidth. After all, apart from using up resources that we're paying for, anonymous users could potentially abuse other networks and have their shenanigans traced back to our network!

To provide responsible wireless access, we need to securely identify users when they connect, and then only allocate resources that the node owner is willing to contribute. The built-in security features of 802.11b are designed to create a private network full of trusted clients; they aren't well suited to managing public-access networks. Fortunately, with the proper application of open source software, a secure and easy-to-use security framework can be created.

Login, recognition, verification

The NoCatAuth project implements a third-party authentication system, designed to give node owners an alternative to the potentially risky "open gateway." Written in Perl and designed to run under Linux, it

On the gateway side, the software

The software is released under the GPL.

Related Reading

Building Wireless Community NetworksBuilding Wireless Community Networks
By Rob Flickenger
Table of Contents
Index
Sample Chapter
Full Description

The system was designed to preserve trust. The gateways and end users need only trust the Auth system, which is secured with a registered SSL certificate. Passwords are never given to the wireless gateway (thus protecting the users from any "bad guy" node owners), and gateway rules are modified only by a cryptographically-signed message from the Auth system, protecting the gateway from users or upstream sites trying to spoof the Auth system.

Three classes of users

A wireless user falls under one of three possible classes:

A Public class user would be someone who knows nothing about the local wireless group, and just wants access to the Internet. NoCat grants these users very little bandwidth and restricts their access to services through firewall rules.

Public class users can learn more about who is providing the wireless service, and how they can get in touch with the local group (and ultimately get more access). They do not have personal logins, but must still authenticate by manually skipping the login process (hence the term catch and release). This also gives the node owner a chance to post an Acceptable Use Policy that the user must agree to before gaining access.

The Co-op class consists of users with pre-arranged login information. Local community groups determine the rules for membership, and add new members to the central Auth system database. This class is typically granted much greater bandwidth and access to ports, as users can now be held accountable for their own actions.

The Owner class is much the same as the Co-op Class, but is reserved for the owner of a given node, and anyone else to whom they want to grant access. The Owner class pre-empts traffic from all other classes and has free use of all network resources.

The connection process

Related Articles

Bridging 802.11 Networks with Linksys

802.11b Tips, Tricks, and Facts

A Wireless Long Shot

Recipe for a Linux 802.11b Home Network

An 802.11 ISP on Maine's Rocky Coast

The typical connection process looks like this:

  1. Redirect. A roaming user associates with the AP, and is immediately issued a DHCP lease. All access beyond contacting the Auth service is denied by default. When the user tries to browse the Web, they are immediately redirected to the gateway service, which then redirects them to the Auth system's SSL login page (after appending a random token and some other information to the URL line). The user is then presented with three choices: either login with their pre-arranged login information, click on a link to find out more about membership, or click the "Skip Login" button.
  2. Connect Back. Once the user has either logged in correctly or skipped the process, the Auth system then creates an outcome message, signs it with PGP, and sends it back to the wireless gateway. The gateway has a copy of the Auth service's public PGP key, and can verify the authenticity of the message. Since part of the data included in the response is the random token that the gateway originally issued to the client, it's very difficult to fake out the gateway with a replay attack. The digital signature prevents the possibility of other machines posing as the Auth service and sending bogus messages to the wireless gateway.
  3. Pass Through. Now, if all has gone well for the user, the wireless gateway modifies its firewall rules to grant further access, and redirects the user back to the site they were originally trying to browse to. The user can now continue along their merry way.

To keep the connection open, a small window is opened on the client side (via JavaScript) that refreshes the login page every few minutes. Once the user moves out of range or quits their browser, the connection is reset and requires another manual login.

The requirements on the gateway side are minimal: the system was designed to run under Linux 2.4.x, on a 486 with 16 Mbytes of RAM. The wireless client requirements again are minimal (only an SSL-enabled browser is required). Key management issues are non-existent, provided that the Auth Service's private SSL and PGP keys are kept secure. The public PGP key is included in the NoCatAuth distribution, and the the Auth service's SSL cert is signed by a well-known Certificate Authority.

The entire implementation assumes that everyone is running IPv4, but beyond that, isn't tied to a particular wireless technology. This means that the same system will work with HomeRF, 802.11a, or any other physical layer. You could even use the system to limit wired clients' access to network resources!

Currently MySQL is officially supported, although the back end has a pluggable architecture. Other contributors have extended NoCatAuth to use Radius as an authentication source, for example. This makes it an interesting alternative to proprietary wireless security solutions for corporate wireless LANs.

Additionally, BSD, Linux 2.2/ipchains, and inter-group global roaming are all being developed. (We've received patches from many users, from places as far away as Australia and the UK!) This demonstrates the beauty of an open source collaborative effort: if you need the software to do something, join the mailing list and make your contribution. Chances are, someone else would like to see it happen as well.

The NoCatAuth system is under active development. You can get the latest version from http://nocat.net.

Rob Flickenger is a long time supporter of FreeNetworks and DIY networking. Rob is the author of three O'Reilly books: Building Wireless Community Networks, Linux Server Hacks, and Wireless Hacks.

O'Reilly & Associates will soon release (November 2001) Building Wireless Community Networks.


Return to the Wireless DevCenter.

Copyright © 2009 O'Reilly Media, Inc.