NoCatAuth

NoCat Authentication v0.80
===========================
(c) 2001, 2002 Schuyler Erle & Robert Flickenger.

============
Installation
============
*** Read the INSTALL to get a quick jumpstart on building a gateway.  
  Read doc/* (particularly Introduction.txt, AuthService.txt, and
  SameMachine.txt) for more details on setting up your own
  authservice. ***

*** REPEAT: The documentation is in INSTALL and in doc/*! READ IT! ***


========
Download
========

NoCatAuth-0.80.tar.gz 

===========
Description
===========

Project requirements
~~~~~~~~~~~~~~~~~~~~

The goal of NoCat is to provide a mechanism for creating multiple classes of
service for cooperative wireless networking.

The three major components of the network are:

* Roaming Clients

* Wireless Gateways

* Cooperative Authentication Services

 
Roaming Clients are defined as:

  * Any computer capable of wireless communication

  * Optionally, also capable of authenticating themselves to the
    Authentication Service


Wireless Gateways are defined as:

  * A computer capable of wireless communication that is also able to relay
    traffic to the Internet

  * Capable of verifying the authenticity of, and acting upon, messages
    received from the Authentication Service


Authentication Service is defined as:

  * An internetworked service that maintains a database of cooperative
    members and their credentials

  * Capable of accepting incoming authentication attempts, and notifying
    the origin gateway of the outcome of such attempts

  * Having a really cool logo


There are at least three potential classes of service:

Priority

Co-op member

Public at large


The Priority class is intended to allow the gateway owner (and anyone else
they see fit) priority access to the gateway's resources.  This class is
optional.

The Co-op class is a standard class of service, accessible to all
cooperative participants.  This class is mandatory.

The Public class is open to any unauthenticated Roaming Client, and has the
lowest access priority to gateway resources.  This class is also mandatory,
but note that it may be defined at any Gateway as having no access
whatsoever, except access to the Authentication Service, if so desired.


Note that Cooperative membership criterion should be reached by consensus of
the people intending to participate, and is beyond the scope of this paper.


A final requirement of the system is that all authentication transactions
are carried out in a cryptographically secure manner, and in a fashion that
preserves trust relationships between all components.


Specifications
~~~~~~~~~~~~~~

  Process Overview
  ----------------

  * For Public access, a Roaming Client, within range of a Wireless Gateway,
    requests a DHCP lease.  The Gateway responds, and communication
    commences.  Have a nice day.  (It is expected that the Gateway will be
    configured to preempt this class in favor of higher priority traffic,
    and will likely restrict services that this class has access to.)

    See below for discussion on the roaming IP problem.

    
  * For all other access:
    
    -The Roaming Client requests, and immediately receives a lease.
    
    -The Client then makes an HTTPS POST request to the Authentication
     Service (probably via an SSL enabled browser.)  The POST request
     includes the member's login, password, and optional MAC address
     information.

    -The Authentication Service validates the request, and returns an
     appropriate response to the Client.

    -The Authentication Service then sends a PGP signed cleartext message to
     the originating Gateway, containing the user's login, current MAC
     address, and authentication status (yea or nay).  

    -The Wireless Gateway receives the message and verifies it based on the
     Authentication Service's public key.  It then decides if/how to modify
     its firewall rules:

      +If nay, do nothing (and probably log it...) effectively keeping
       Public Class service
      
      +If yea and the login is a local Priority user, assign Priority Class
       access to the IP matching the MAC address
    
      +If yea and the login is NOT a Priority user, assign Co-op Class
       access

    -The Client must then re-authenticate to the Service before a (per
     Gateway) predetermined timeout period expires, or the Gateway will
     revert the MAC back to Public class service.  The Client can
     reauthenticate at any time, and is encouraged to before the timeout. 
     (This can be facilitated by an automatic HTTP REFRESH sent by the
     Authentication Service).


Component Specs
~~~~~~~~~~~~~~~

Roaming Client Specs (Public class):

  * Computers capable of TCP/IP networking, with a DHCP client

  * Must use an 802.11b (or 802.11 DSSS) wireless card for communications


Roaming Client Specs (Co-op and Priority class):

  * All of the above

  * As the clients could run any number of potential operating systems,
    distributing native applications is very inconvenient.  Given the
    ubiquity of web browsers, and to fulfill the security requirements,
    we've selected HTTPS as the client authentication transport. 
    Authentication requests will be made via the HTTPS POST method.  


Wireless Gateway Specs:

  * A Gateway shall run a dynamic IP firewall.  It is expected that the
    Gateway will run either Linux or BSD, but any firewall capable of
    changing its firewall rules on demand qualifies.

  * It must be able to receive and verify Authentication Service messages
    against the Service's public PGP key.

  * The Gateway will need to be able to update its firewall rules based on
    authenticated messages, and revert those rules after a timeout period.
  
  * It will maintain its own local list of optional Priority logins.


Authentication Service Specs:

  * An Authentication Service provider will maintain a (probably
    distributed) list of authentication credentials.
    
  * Its job is to accept incoming HTTPS authentication requests, check the
    login, pass, and MAC info against information in the database, and
    return the results to the IP address that made the request (namely, the
    Gateway that the Remote Client has associated with).
    
  * The message format is to be determined, but will consist of the member's
    login name, MAC address, and a yea/nay response, all in cleartext signed
    with the Service's own private key.  HTTP will likely be the transport
    agent used to send the message to the Gateway.

  * The Service will also provide a method for users to securely update
    their profiles (including password and acceptable MAC address
    information).  Auth Service providers may optionally provide a mechanism
    for applying for Co-op member accounts (sponsorship?).  This should all
    take place over SSL.
  
  * All SSL certs must be registered!
  

Comments
~~~~~~~~

We expect to be able to produce and distribute software that will provide
all of this functionality on most conventional PC hardware.  It is beyond
the scope of this project to attempt to manage private keys or other
sensitive data at all Gateways.

The web of trust looks something like this:

  * Clients must trust the Authentication Service with their login
    credentials, and that the Service's SSL cert hasn't been compromised. 
    Using a registered cert (and properly managing it) should be sufficient
    in providing this level of trust.  Passwords shall be stored as MD5
    hashes in the database, and incoming auth requests will be compared to
    the hashed versions, never storing a plaintext copy.  MAC address
    information will be stored in the clear, as it is never private
    information anyway (it is sent in plain text in every packet!)
  
  * Clients do not need to trust individual Gateways for authentication, as
    no sensitive information is passed in the clear to or through them. 

  * Clients do, however, need to trust the Gateway's notion of DNS and
    routing...  Although this is not an issue for Co-op authentication, as
    the Service will use registered SSL certs, the gateways *could* spoof
    unencrypted traffic.  Clients are therefore encouraged to use secure
    application layer encryption, such as SSH or VPN, to maintain data
    privacy.

  * Gateways need to trust the Authentication Service to return good
    Authentication Messages.  This is assisted by the use of signed
    cleartext messages.  Assuming that the PGP key has not been compromised,
    and that the Gateway has a good copy of the Service's current public
    key, message authenticity is practically guaranteed.
  

Bugs
~~~~

* IP Camping

* Stealing IPs before the timeout period ends

* "bad boy" Gateways spoofing DNS data (for clear text services only)


Roaming IP problem
~~~~~~~~~~~~~~~~~~

Here's a novel solution we're kicking around for the Roaming IP problem...

The problem
-----------

  You're in range of Gateway 'A'.  You get a lease and start talking.  You
then move out of range of 'A', but into range of Gateway 'B'.  What's your
IP address?  Gateway?  DNS server?

  Under normal circumstances, these could (and will) all change when you
pick up a new lease.  But worse than that, you won't be able to route
packets until you pick up that new lease, either by manually kicking over
your DHCP client, or when it times out and grabs another one.

  Of course, these could be anything but normal circumstances...  ;)
  
  Picture this:
  
  Instead of the local DHCP server assigning your IP from a pool of
addresses, it takes your MAC address, hashes it, takes the least significant
24 bits, and drops them on the end of a 10.x.x.x address.  It furthermore
always assigns the gateway and DNS server as 10.254.254.254 (or the like)
which is the IP of its wireless card, with a caching DNS server sitting on
it.

  What does this bit of mangling do?

  Good:
    
  * You always get the same IP address, DNS, and gateway info no matter
    which node you visit, all without the need for Gateways to share data

  * Packets will still route, even without picking up a new lease.  When
    your DHCP lease expires, it will return the exact same info anyway.
  
  Bad:
    
  * The first couple of packets will probably be dropped, as your system
    figures out that its local ARP entry is wrong
    
  * Stateful connections (like SSH) and authenticated access (like cookie
    enabled web pages) will break, as you'll appear to be coming from a
    different IP address (namely, the Gateway's real IP address)

  So, while it's not a perfect solution, it goes a fair bit toward some
network sanity.  If we can all agree to use a hacked dhcpd on the Gateway
nodes, this should be a piece of cake...  And Public class users would
probably never notice a difference.  Other classes should just need a quick
'Reload' to fix it...

  Of course, if you're moving between nodes, popping out your card and
reinserting it will do the same thing as the above.  Is it worth it to
pursue this line of hackery?


[  C O M M E N T S   W E L C O M E . .  .   .    . nocat@pez.oreillynet.com  ]



=======
Credits
=======
Core dev team:

* Schuyler Erle
* Rob Flickenger

NoCat website design:

* Adam Flaherty
* Terrie Miller

Other Cool Cats (for their support, testing, code, 
    bug reports, and general well-wishing):

* Jim Rosenbaum
* Nate Boblitt
* Rich Gibson
* Terry Schmidt
* Michael Codanti
* Craig Slimmer

This code also includes contributions from:

* Michael Bailey (LocalGateway patch, dynamic FORWARD filter, and some
  filesystem restructuring)
* Matt Westervelt (ipchains code + testing)
* Steve Beattie (original ipchains support)
* Pasi Lahtinen (fix for RedHat 7.1 ipchains/iptables strangeness)
* Matt Peterson (*BSD ipf detection and support)
* Michael Codanti (ARP expiration and a bunch of other stuff)
* Don Park (gateway status page)
* Richard Lotz (OpenBSD packetfilter support)
* Nathan Zorn (LDAP support)
* Jan-Patrick Perisse (RADIUS support)
* Matt William Barclay (Syslog support)

...and, of course, a slew of other people who provide ideas, rants, flames,
public demos, and even the occasional patch.

==========
Assistance
==========
For more assistance, and to contribute, join the NoCat mailing list, or
find us on IRC at irc.openprojects.net #wireless.  See http://nocat.net
for more details.

==========
Desiderata
==========
We hope NoCat Auth helps you provide unlimited bandwidth
everywhere for free.

You can always get the most current release at:

http://nocat.net/download/NoCatAuth/