AuthBridge

Authenticated Network Access

Network Development
Carnegie Mellon University

Overview

AuthBridge is a new system designed at Carnegie Mellon for authenticated network access. It uses a machine running a modified Linux kernel to control access at layer 2 (Ethernet). Registered users enjoy full, unrestricted access, while unregistered machines are switched to a private network for registration.

Historical Review

Over five years ago (Fall 1996), Carnegie Mellon deployed the NetBar system for authenticated access to public Ethernet ports. Since then, much has changed. The NetBar network has grown to include multiple buildings, including a number of lecture halls with one port-per-seat. Since this expansion is generally piecemail, however, the access layer is an eclectic collection of Cisco 1900, 2800, and 2900 series switches, with many more differences in firmware and software. Maintaining common configurations and dealing with the idiosyncracies of the various SNMP implementations has been time consuming.

With the recent widespread deployment of IEEE 802.11 wireless access points across campus, the need for NetBar as a network has changed, while the need for NetBar as a technology has expanded. The wireless network is well positioned to provide basic network access from literally any location on campus. However, when used by entire roomfuls of students, the performance to a single wavepoint can suffer dramatically. This is especially problematic if the entire class is asked to simultaneously load a content-rich web page. Thus there is still a desire for public ethernet ports.

However, there is also a desire for stronger authentication mechanisms on our wireless network. Currently we operate essentially an open network. That is, the network name (ESSID) is not announced on the wireless network, but is easily guessed or learned from our online documentation. We do not use WEP. We can not use the NetBar system on wireless, since NetBar toggles network access based on connection port (and clearly, wireless is much different.)

Thus arose the idea for an access control system that centralizes management while being capable of controlling access from the wireless network. AuthBridge is the result of this idea.

Requirements

The basic idea of AuthBridge is to use a machine running Linux with ethernet bridging enabled. Every packet is filtered real-time on the source Ethernet (MAC) address. Packets not matching the filter for general Internet access are then passed to our secured authentication network.

Our requirements in this system are:

• The system is able to switch packets at Fast Ethernet speeds (switching 90-100Mbps full duplex and 25,000 packets per second.)
• The system centralizes management of the authentication mechanisms; access layer switches are deployed in basic configurations. All elements of the system that are dynamically changing must be centralized.
• The system provides a lightweight and familiar interface for user registration.
• The authentication mechanism is completely modular.

Design

A network map of the AuthBridge test network is below. This map shows only the single-bridge implementation of the network. Below we discuss a dual (redundant) bridge implementation. There are several paths in this network, but they are fairly easy to digest when taken individually. The overarching design is that normal, authenticated traffic from user machines flows on the green path in the map, while unauthenticated traffic takes the red path (determined by the AuthBridge machine).

Network Components

• External GW: In our case, the external gateway is a Cisco Catalyst 6509 switch with MSFC (router) card. This router announces the 128.2.236.0/24 IP space externally. All traffic to this netblock is forwarded to the AuthBridge machine. Additionally, this router announces and forwards the 128.2.33.128/28 to AB-Auth (for simplicity, since we do NOT want AB-Auth announcing a route to 128.2.236.0, even though the network is directly connected.)
  
  
• AB-Auth: This second router is required due to our configuration of both the External GW and AB-Auth with the same IP address. Directly connected to this router is the "AuthBridge Auth Net", a small netblock for any machines that need direct connectivity to user machines during the authentication phase. To avoid incorrect routes being propogated, AB-Auth uses static routing only. AB-Auth has static routes for the real DNS servers towards the Auth Net. It has a static default route towards the External GW.
  
  
• AuthBridge: The actual AuthBridge machine is a Linux box running a 2.4.10 kernel with Ethernet briding features. These features were locally modified to allow a single physical interface to exist in more than one bridge group. The packet forwarding behavior is to first try bridging the packet on the green packet path (ie general access). If the packet is not authorized to use this path, it will fall back to using the red path. Not shown on the map is an optional fourth management interface that is not in any bridge group. It is a good idea to have this interface, as the kernel interface and routing tables are modified when bridging is started and stopped.
  
  
• AB DNS/Web: The AuthBridge DNS server masquerades as our traditional nameservers. That way, once a user is authenticated they continue using the "same" DNS server, when in fact they use the standard nameservers after authenticated. This machine also runs the web server which handles user registration and authorization for network access. It informs the AuthBridge machine once a machine is authorized to begin normal communication. The DNS server on this machine is configured to respond to any A record request with a single IP address. Namely, it responds with its IP (128.2.33.131). In this way, a user trying to connect to, for example, www.cnn.com, will instead be directed at our web server.

Network Links

• Ext GW btw. AuthBridge: Strictly speaking, traffic from the GW to AuthBridge also passes through the bridge filter. However, the MAC address of Ext-GW must be in the bridge table, so all packets will pass. The Ext-GW will have standard IP ingress filters to prevent IP spoofing off the network. It will also have helper addresses for our DHCP servers.
• AB-Auth btw. AuthBridge: The bridge link between AB-Auth and the user network has no filters. The AB-Auth machine will have standard IP ingress filters, as well as helper addresses for our DHCP servers.
• Ext GW btw. AB-Auth: Of all the links in the system, the most care needs to be taken when configuring this one. We could have extended the OSPF cloud from Ext-GW to AB-Auth. However, given the possibilities for misrouting due to duplicating the 128.2.236.1 address, static routes are used. There is an egress filter on AB-Auth to allow only traffic from AuthNet and DHCP requests to leave.
• AB-Auth btw. AB-DNS: This is a fairly standard connection for a small group of machines assisting in the user authentication. The machines are set to a default gateway of 128.2.33.129. The interface has IP ingress filters and helper addresses of our DHCP servers.

Notes

• The only traffic from the user network that can reach an external network by way of AB-Auth (ie pre-auth) is DHCP traffic. In this case, outgoing traffic will flow through AB-Auth, while responses from the DHCP server will actually flow back across the Ext-GW. This is fine (just asymmetric routing) since Ext-GW is always allowed to send traffic TO user machines.

Network Map

A map of the AuthBridge test network.

			Updated 12/7/2001

Technical Details

AuthBridge Machine and Configuration

This machine is running Linux kernel 2.4.x kernel with bridging module enable Stock kernel only provides bridging. Using patch, we were able to filter packets based on source/destination MAC addresses and made it work as switch.

Standalone Setup

• Kernel Configuration:
  In networking options, enable '802.1d Ethernet Bridging'
  #CONFIG_BRIDGE=y
  
  
• User Configuration:
  To control bridging in kernel, there is a user level utility called,'brctl'. Get the source code of bridge-utils-0.9.5.tar.gz. Apply following patch here
  To enable bridging one has to create virtual bridge interface and add physical interface into virtual interface.
  # brctl addbr authUser
  # brctl addif authUser eth0
  # brctl addif authUser eth1
  
  # brctl addbr authBridge
  # brctl addif authBridge eth0
  # brctl addif authBridge eth2
  
  After adding physical interfaces to virtual interfaces, put those physical interface in promiscuous mode.
  # /sbin/ifconfig eth0 0.0.0.0
  # /sbin/ifconfig eth1 0.0.0.0
  # /sbin/ifconfig eth2 0.0.0.0
  
  For failure recovery we have redundant Linux box, which have same configuration. configuration. For correct operation in this environment, we must have 'spanning tree protocol' enabled.
  # brctl stp authUser on
  # brctl stp authBridge on
  
  When physical interfaces are added to virtual interface they will lost their inet addresses. After configured them, machine is able to do bridging but one can't reach that machine because, machine doesn't have inet address. To access machine we give inet address to one (or both) virtual interfaces.
  # ifconfig authUser 10.4.2.1 netmask 255.255.255.0 up
  # ifconfig authBridge 10.4.2.2 netmask 255.255.255.0 up
  
  Above is the basic configuration. (Only difference you saw, from standard version is it allows same physical interface to be part of different virtual bridge interfaces).Our goal is to allow access only to those users who are registered in our system, rest of them will be diverted to our private network and force to register with our centralize registration system NetReg
  For that we modifed bridging code and add filters as well as switching functionality. Now, we have filtering database of MAC address in kernel.
  First we will add MAC addresses into database. For correct operation, we have to add MAC addresses of all the physical interfaces of /this/ machine and default gateway of /this/ machine.
  # brctl ftdbaddmac authUser 001122334455
  
  And then add/delete/modify filter policies
  # brctl setfilter authUser src on
  # brctl setfilter authUser dest off
  # brctl setpolicy authUser src deny
  
  After applying source filtering and policy on bridge, only those packets will be forwarded whose source MAC address in the kernel database of filtering MAC.

AuthBridge with NetReg

Above configuration stands as itis. If user is unauthenticated, he/she will be redirected to /authBridge/ side. As shown in above figure, this will lead user to Proxy DNS Server and give a chance to register with our centralize registration system called NetReg.
Once user will select its department (and time to be on system), he/she will be asked password as part of authentication. After authenticating user, System tells NetReg to add user and also tells kernel to add MAC address in its filter database.
We have Perl script, running on AuthBridge machine and listen commands (e.g. add, query, del MAC address ) from Web Server. Then this script calls 'brctl' to manipulate kernel database.

AuthBridge DNS and Web

DNS

The DNS component of AuthBridge translates any DNS request made by properly configured clients (ie those that use DHCP) into a response of the Web server's IP address (in our case, the same machine). If user machines do NOT use DHCP or decide to use nameservers other than those assigned by DHCP, they will not have connectivity, and would have to connect to the IP address of the Web server.

Because we still need to have (correct) DNS service to the fake DNS/Web machine, /etc/resolv.conf is edited to point to nameservers that the machine is not masquerading as.

The current network is built using a Solaris 8 machine in this capacity. Configuring the aliases on this machine is done as:
#! /bin/sh

BASE=le0
IF=/sbin/ifconfig

$IF $BASE addif 128.2.4.21 netmask 255.255.255.255 up
$IF $BASE addif 128.2.64.2 netmask 255.255.255.255 up

The nameserver on this machine is ISC BIND 9. We define a root zone in named.conf:

acl authbridge { 128.2.121.236; 128.2.236.0/24; };

zone "." in {
type master;
file "BASE.zone";
allow-query { authbridge; };
allow-transfer { authbridge; };
};


The authbridge acl is defined to prevent any accidental leakage of our fake zone to any clients not on the AuthBridge network (or the special IP used for testing). The BASE.zone file is:

$TTL 2
$ORIGIN .
@ IN SOA ab-ns.net.cmu.edu advisor.andrew.cmu.edu (1 1 1 1 1 )
  IN NS ab-ns.net.cmu.edu.
* IN A 128.2.33.131


This is the extent of the nameserver configuration. One of the simplest configurations around!

Web

We use the Apache web server to serve just a few Perl scripts. The scripts use the AuthBridge.pm Perl module. When users connect to the homepage of this machine, they are presented with a boilerplate introduction to the AuthBridge network. They are then asked to select their academic department (for purposes of long-term machine registration), and are optionally able to select a timeout value for the registration. The browser then posts to the actual registration script. We use the standard Apache user authentication system (in our case, authentication is done via Kerberos) over SSL.

If the user successfully authenticates, the script then locates the user's MAC address from the IP they connected with. We use an SNMP query to the AB-Auth router to find the MAC address. Once located, the registration script contacts the AuthBridge machine via a proprietary TCP-based protocol. The registration script sends:
ADD 00aabbccddee 10000 U0ZUTcLxL3oPa0S/j3oLdg
It receives either an "OK" response from AuthBridge, indicating the MAC address was added, or an "ERROR" response with a free-form error text message. The outgoing "ADD" message is straightforward: the keyword 'ADD' followed by the hexidecimal representation of the MAC address. A timeout value can then be specified, or the value '0' must be present, indicating no timeout. The last field is an authentication string. AuthBridge and the AB-Web server share an authentication key and calculate this value independently. Updates are only done when the values match.

The web server responds to any 403 or 404 errors with the main homepage. This means that users try to connect to (nearly any) subdirectories of the server will also see the AuthBridge homepage. Additionally, the scripts return Pragma: No-Cache definitions and set a very short expire time on all served pages, in an attempt to prevent confusion after users have been authenticated.

ToDo List

• We are trying to make this architecture as generic as possible. Long term plan is to build different modules which support, attributes based queuing (use builtin queuing discipline) in conjunction with '802.1q vlan' and 'bridging'. So, that we can do traffic shapping, policing and metering.

Summary

Developers Involved

Bug Reporting/Contact

• authbridge-dev: Bugs can be reported to this address. This is also general user mailing list.