AuthNet - Carnegie Mellon's Solution to Authenticated Access for Large Area Networks

Background

This information is used when a user abuses our acceptable use policies, and does something malicious, such as sending a death threat to the president, or launching denial-of-service attacks. Typicaly these abuses can be tracked down to the originating IP address, at which point we must be able to determine who was responsible for that IP address at that time.

The AuthNet project will allow us to extend a new type of network connection to the campus community. This connection will not only allow us to make sure we know who is responsible for a machine, but it will also limit access from non-registered machines, no matter where they go on our network.

Network Connections

Departments

These users typicaly add a machine to the network, and that's the last we hear from them. The only other time we hear about the machine is when the machine is physicaly moved.

Dorms

Every year, students register their machine for use in a new location. While this is the last we would like to hear from them, sometimes this isn't the case. Some user abuse activities force us to remove the computer from the network entirely, and we need to make sure that moving the machine to another active outlet will not give that machine access once again.

Wireless

Users with wireless cards register with us for an IP address. However, at this time, a user with a wireless card could theoreticly make up an IP address in the proper subnet, and achieve full network access without us knowing who is using that IP address.

NetBar

Our current netbar infrastructure does not require users to register their machines with us before use. However, in order for a user to gain full network access, they must prove their identity, via a Kerberos login, to our central site. Since this identity is provided to us, we know exactly who is using the IP address, and can contact the user if necessary.

Registered AuthNet

Once a machine is registered with our central facilities (TINA), the machine will be usable on all AuthNet outlets. Just plug the machine in, and it will work. The user that registered the machine is responsible for all traffic originating from that machine. If an abuse occurs, the machine will be removed from the Campus network, and it will not be able to gain full network connectivity via an AuthNet connection.

UnRegistered AuthNet

Machines that are not registered on the AuthNet network will receive an active network connection, in which they may only communicate with other unregistered machines. There will also be a mechanism in place that allows a user to prove their identity, at which time their machine will be granted full network access.

AuthNet Implementation

By writing our own VMPS which communicates with our central facilities (TINA), we should be able to configure all Cisco hardware to only allow machines on the main network VLAN ("Campus") that have been registered. Unregistered machines will be placed on a different VLAN ("Unknown").

With this in place, once a user registers a machine with TINA, it will be granted full network access on all AuthNet ports.

Another area of research within the AuthNet project is the ability to notify switches on the fly that a MACAddress is now given access to a new VLAN. If a user connects an unregistered machine to a port, contacts to the AuthNet server, and proves his/her identity, the machine should be given full network access. At this time, how this will be accomplished is uncertain. This can probably be accomplished by sending the switch the user is plugged into an SNMP request.

A third area of research within the AuthNet project is the configuration of multiple VLANs across multiple routed subnets. The "UnRegistered Authnet" connection requires all users on the "Unknown" VLAN to have IP access to only one machine on campus. One way to accomplish this is to have the "Unknown" VLAN shared across all AuthNet switches. The configuration of our core routers to route the appropriate subnets, and bridge the "Unknown" VLAN is an area to be researched. Other methods of accomplishing the IP connectivity to the authentication server will also be explored.

Other AuthNet Advantages

Dealing with abuse cases will also be more fair, and require less time. If a user's machine must be removed from the network, it's entry is updated in TINA. From then on, the machine will be unusable, no matter where it goes.

Right now, if a machine is to be removed from the network, the network outlet that the machine is plugged into is removed. If there are multiple machines sharing the network outlet, they all suffer. With AuthNet, only the machine in question will be punished.

Finally, AuthNet will help with large shared networks, such as our Wireless network. With the entire wireless infrastructure using AuthNet switches, unknown users will not be able to get full network access.

AuthNet Architecture

Network Outlet <-> Hub <-> Cisco Switch <-> Router <-> Internet

With this structure, all connections within a dorm filter through a building aggregator switch, which will make sure that all traffic passing beyond that dorm is on the appropriate VLAN.

In reality, unregistered users on the hub will be able to see traffic to/from other machines, including the traffic sent to/from the main campus network. AuthNet is not a replacement for secure network connections. However, it will limit and reduce the number of security incidents with off-campus sites.