7.8 NoCatAuth Captive Portal

While some node owners are perfectly happy opening their networks to whomever happens to be in range, most 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! If we want to provide responsible wireless access, we need a way to securely identify users when they connect and then allocate only the resources that the node owner is willing to contribute. After the Portland Summit, it was obvious that one key component was missing from the community network idea: a freely available captive portal implementation.

The idea behind a captive portal is fairly straightforward. Rather than relying on the built-in security features of 802.11b to control who can associate with an AP, we configure the access point with no WEP and as an open network. The AP is also in bridged mode and connected via a crossover cable to an Ethernet card on a Linux router. It is then up to the router to issue DHCP leases, throttle bandwidth, and permit access to other networks. When a user attempts to browse any web page, they are redirected to a page that presents the user with a login prompt and information about the node they are connected to. If the wireless gateway has a method of contacting a central authority to determine the identity of the connected wireless user, then it can relax its firewall rules appropriately and allow the privileges due to that user (for example, more bandwidth or access to other machines and ports).

The NoCatAuth project implements such a third-party authentication system (or Auth system, for short). Written in Perl and C, it takes care of presenting the user with a login prompt, contacts a MySQL database to look up user credentials, securely notifies the wireless gateway of the user's status, and authorizes further access. On the gateway side, the software manages local connections, sets bandwidth throttling and firewall rules, and times out old logins after a user-specified time limit. The software is released under the GPL (http://www.gnu.org/copyleft/gpl.html).

We are designing the system so that trust is ultimately preserved; 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 "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).

We provide for three possible classes of wireless user:

• Public Class

• Co-op Class

• Owner Class

A typical Public Class user knows nothing about the local wireless group, and simply is looking for access to the Internet. This class is granted very little bandwidth, and users are restricted in what services they can access by the use of firewall rules. The Public Class of user is given the opportunity to 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).

The Co-op Class consists of users with prearranged login information. The rules for membership are usually determined by local community groups and configured in 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 preempts traffic from all other classes and has free use of all network resources.

The typical connection process starts when a roaming user associates with the AP, and is immediately issued a DHCP lease, as shown in Figure 7-9. All access beyond contacting the Auth service is denied by default. When the user tries to browse the web, he is immediately redirected to the gateway service, which then redirects him to the Auth system's SSL login page (after appending a random token and some other information to the URL line).

Figure 7-9. The user is immediately issued a lease, and his first web connection is redirected to the wireless gateway's service

The user is then presented with three choices: log in with his prearranged login information, click on a link to find out more about membership, or click the Skip Login button.

Once the user has either logged in correctly or skipped the process, the Auth system creates an outcome message, signs it with Pretty Good Privacy (PGP) encryption, and sends it back to the wireless gateway (see Figure 7-10).

Figure 7-10. After login, the Auth system connects back to the wireless gateway and notifies it of the outcome; the gateway can then decide whether to grant further access

The gateway has a copy of the Auth service's public PGP key and can verify the authenticity of the message. Part of the data included in the response is the random token that the gateway originally issued to the client, making it 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.

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 he wanted to browse (see Figure 7-11).

Figure 7-11. The user can now continue along his merry way

In order 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 his 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 on a 486 with 16MB RAM). The Auth service is designed to be administered by a community group that maintains its user database in whatever way it sees fit. For example, running a node is one obvious way to become a co-op member. But that isn't always the best way to spend resources; people who contribute hardware, programming skill, bandwidth, or even meeting space and sandwiches should certainly be considered for membership. The technical aspects of catch and release are being solved, and it's up to everyone to work on the social details.

The NoCatAuth system is under active development, and now has a variety of new features. "Passive" mode allows operation without the connect-back phase (i.e., to work behind a NAT). There are also many additional backend authentication methods, including PAM, RADIUS, TACACS+, and even IMAP. You can always get the latest version from http://nocat.net.