NoCat: An Alternative Method of Wireless User Authentication

Apart from considering RADIUS and 802.1x for wireless user authentication, you can also select an entirely different method of user access control. The idea behind NoCat authentication is straightforward and helps you avoid using WEP or closed ESSIDs as (insecure) authentification means from the access point side. The most useful implementation of NoCat would be public infrastructure Web access services such as community wireless nodes listed at consume.net. In fact, NoCat was initially developed as a project for community and as an amateur wireless network authentication scheme that does not require time and resource-consuming RADIUS server and user database setup. NoCat sources as well as additional information and support documentation can be downloaded from http://nocat.net or from this book's supplementary Web site.

The network layout of the NoCat authentication scheme would involve the following:

• An AP with enabled bridging (required mainly for roaming purposes but not compulsory)

• A Linux router or gateway box

It is then up to the Linux router or gateway box to issue DHCP leases, control bandwidth usage, permit access to other networks, and provide other control methods.

The typical authentication process, as described in the NoCat documentation, is shown here:

1 Redirect

A client associates with the AP and is immediately given a DHCP lease. All access beyond contacting the authentication service is denied by default. When the user tries to browse the Web, he or she is immediately redirected to the router or gateway service that redirects to the SSL login page. The user is then presented with three choices: Log in with the prearranged login information, click on a link to find out more information, or skip the login option.

2 Connect Back

The authentication system connects back to the wireless gateway and notifies it of the outcome. The gateway then decides whether or not to allow further access. Once the user has either logged in correctly or skipped the process, the authentication system then creates an outcome message, signs it with PGP, and forwards it back to the wireless gateway.

The gateway has a copy of the authentication service's public PGP key and can verify the authenticity of the message. A part of the data included in the response is the random token that the gateway has originally issued to the client; it makes it very difficult to deceive the gateway with a replay attack. The digital signature prevents the possibility of other machines posing as the authentication service and sending bogus messages to the wireless gateway. Then 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.

3 Pass Through

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 or her browser, the connection is reset and requires another manual login.

Installation and Configuration of NoCat Gateway

The installation of the gateway service is quite simple and straightforward. After installing the NoCat gateway you will have a transparent proxy-like service that simply forwards all client requests to a desired destination. Prior to the installation, make sure you satisfy these dependencies:

• Linux 2.4.x with iptables

• The gpgv tool that comes with GnuPG package to verify PGP signatures

• Optionally (and recommended), DHCP server to issue DHCP leases

• Optionally (and recommended), a local caching DNS server

To install the NoCat gateway, perform the following commands:

arhontus:~# tar -xzf NoCatAuth-x.xx.tar.gz

arhontus:~# cd NoCatAuth-x.xx

arhontus:# make gateway

Before running the service, you should edit the configuration file to meet your gateway requirements:

arhontus:~# cd /usr/local/nocat

arhontus:# vi nocat.conf

To run the NoCat gateway, issue the command like this:

arhontus:~# /usr/local/nocat/bin/gateway &

If the server is successfully activated, the following lines should appear in your system log:

[2003-06-02 12:18:12] Resetting firewall.

[2001-06-02 12:18:12] Binding listener socket to 0.0.0.0

If all goes well, your new NoCat gateway is ready; enjoy! If you would like more information, you are advised to consult the documentation pages that come with the tool.

Installation and Configuration of Authentication Server

The installation of NoCat Authentication Server requires a bit more hassle than the gateway service, but it is worth the trouble. After installing NoCat AuthService you will have a fully functional wireless authentication mechanism that can address centralized database or locally stored passwd-like files. Prior to the installation, make sure you satisfy these dependencies:

• An SSL-enabled Web server, such as Apache

• Perl 5.6 or better

• Digest::MD5, DBI, and DBD::MySQL Perl modules

• GnuPG 1.0.6 or better

• Optionally, use MySQL 3.23.4x or better (for centralized database authentication)

To install AuthService, do the following:

arhontus:~# tar -xzf NoCatAuth-x.xx.tar.gz

arhontus:# cd NoCatAuth-x.xx

arhontus:# make authserv

Then you need to generate a set of keys that will be used to encrypt all the messages sent between the AuthService and the gateways. This can be done by entering:

arhontus:~# make pgpkey

Do not enter a password at this stage, or you will have various errors during message encryption.

Now, edit the /usr/local/nocat/nocat.conf file to suit your particular requirements. Don't forget to include this:

DataSource:  (Currently, must be DBI or Passwd.  Use DBI for MySQL, or Passwd for local

 file-based authentication).

For simplicity's sake, we include Passwd configuration in this book. For the SQL database authentication you should consult the NoCat software documentation. To create your authentication sources and add users, simply run the admintool that can be found in /usr/local/nocat/bin.

Make sure your /usr/local/nocat/pgp and pgp/* are owned by the user that your Web server runs as (usually www or sometimes www-data or nobody). If they are not, you will get permission errors.

Now add /usr/local/nocat/etc/authserv.conf to your Apache's httpd.conf, either by including the contents of the file in the httpd.conf itself, or by using the Include /usr/local/nocat/etc/authserv.conf line. Don't forget to force NoCat authentication via HTTPS/SSL, otherwise all the user credentials will "fly in the air" unencrypted and ready to be sniffed.

Additionally, make sure that /usr/local/nocat/cgi-bin is served from your Web server and copy your /usr/local/nocat/trustedkeys.gpg to all of your wireless gateways. Now, cross your fingers and restart the Web server. If all goes well, you are sorted out with your NoCat Authentication Service. Your clients' login screen should have a similar look, as shown in Figures 13-25 and 13-26.

Figure 13.25. NoCat login screen.

[View full size image]

Figure 13.26. NoCat authenticated user screen.

[View full size image]

Congratulations, you have just installed a simple and efficient user authentication system without setting up a RADIUS server and user database (LDAP or other). Nevertheless, please take into account that NoCat only provides user authentication and does not supply WEP or TKIP key rotation as the 802.1x implementation in 802.11i does.