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).
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).
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).
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.
Sections
