Authenticating Aperiodic Connections to the Campus Network

The demand for dial-in access to our campus networks is likely to be exceeded by demand for direct connections from personal portable computers. Well over 50% of UC Berkeley students own their own computers and an increasing number of these are portables. In anticipation of this trend, the newest campus lecture halls and library study areas are wired for network connections at every seat. However, network service is not yet offered at these locations. Unlike dial-in access, there is no widely available, convenient mechanism for authenticating the individual who might attach their computer aperiodically to a part of the campus network. This paper suggests a way to use existing technologies, with minor extensions, to solve this looming problem. If successful, it might change significantly the way entire campus networks are managed.

Context

There was no need for authentication at the central modem hub when campus modem services were first established. Data flow was character oriented and the only destinations available were local timesharing systems which performed their own authentication. With the advent of serial line Internet protocols (SLIP and PPP), it became possible to establish the dial-in user's computer as a node on the campus network. This new type of service allowed access to all nodes on the campus network and, unless specific measures were taken, allowed access to the entire Internet. In response to concern over anonymous use of campus resources as well as the potential for abuse of systems on the Internet, campuses implemented authentication as the first step in establishing a network connection via a dial-in modem. Commercial Internet Access Providers rely on this step to account for use of their fee-based services.

LAN technologies, on the other hand, developed in a highly controlled environment where connections were established permanently to computers owned by known individuals or departments. Authentication was not an issue. The network was simply a resource available to all campus computers. It is still the case that LAN technologies do not offer a mechanism that would support an authentication step as link level connectivity is being established.

The idea of a "live network outlet on the wall" to which anyone's computer can be attached is not new. It has long been an appealing idea in areas where the population is mobile, such as a classroom or reconfigurable office. One of the requirements for widespread use of this type of service - automatic configuration of the computer's network protocol parameters - is embodied in the Dynamic Host Configuration Protocol (DHCP) as defined in Internet RFC 1541. What must be added to the DHCP implementation is an authentication step supported by enhanced intelligence in network hubs serving the "live network outlets."

Goals of the Authentication Model

In order to be truly useful, the authentication mechanism must fit easily into practical environments and should complement other network support requirements. A mechanism has been designed to achieve the following goals:

• to identify a straight forward mechanism to support authentication at the time a link level connection is established;

• to incorporate this as part of an automatic configuration process to ensure a high probability that the connection will function properly;

• to deny service unless authentication is completed and then to provide service only to the authenticated user's computer;

• to minimize the potential for damage to the network by unauthorized connections;

• to use existing technologies, including authentication services, as much as possible, and to be adaptable to new ones;

• to minimize any manual intervention required to support the service.

Constraints on the Model

There are two basic limitations inherent in the requirement to control access. First, there must be a one-to-one mapping between a LAN hub port and an associated user which therefore constrains the use of secondary work group (non-intelligent) hubs. Second, protocols such as DECNET that change MAC addresses will not be usable without a rather significant extension of the protocol since the authentication must be bound to a particular MAC [1] address as the only way to recognize a particular computer at the link level.

Figure 1: Components of the Authenticated DHCP Model

Design Considerations

Many considerations went into the design of the proposed authentication mechanism. It seems clear that the LAN hub must provide several important functions that can not be done easily elsewhere. For example, the hub must be able to detect the presence of a computer that is attempting to gain access and the hub must recognize the link level identity of that computer.

The simplest way to recognize a newly connected computer would be to receive a packet from the computer intended to initiate a configuration and authentication process. However, the hub while in the idle state must not transmit any usable packets to the computer since that would allow "eavesdropping." Therefore the LAN hub port must be able to be put into an asymmetric state when no authenticated connection is present.

Unfortunately the ability of the attached computer to send packets opens the possibility of abuse, e.g. flooding or jamming the network. Therefore some means must be available to shut down the LAN hub port entirely when necessary.

With current products, there is no reliable and practical way for a remote process to associate a MAC address with the particular LAN hub port. Even if the LAN hub's MIB[2] includes the MAC address associated with each port, it would be necessary to scan the entire network segment in order to find it. It would be much more straight forward for the LAN hub controller to offer that information directly under specific conditions.

Finally, a given port must be switched reliably to an unusable state when no longer in use by an authenticated user. Merely the capability for remote on/off control by an SNMP[3] agent is not enough. Consider a connection that has been established properly and is in the "usable" state: there is no reliable way to know if the attached computer is removed and another one inserted in its place unless the LAN hub recognizes either the loss of "carrier" or a different MAC address received from the attached computer. Loss of "carrier" alone is not enough if the connection was made via a secondary LAN hub.

Fortunately LAN hub products exist today that can support most of the required functionality described above. Both so-called "data secure" LAN hubs and switching LAN hubs have the ability to recognize and act upon the MAC address of an attached computer. It is reasonable to assume that future hub products could provide equivalent functionality, including the minor extensions required for reliable access control.

An important design decision was whether authentication would take place over basic link level communication or would use full network level transport. It is undesirable in a large distributed environment to build an authentication process into the hub itself since this creates yet another system requiring operational support. It might be possible to build enough intelligence into the hub to perform a link level handshake with the attached computer and then verify the user with a separate authentication service. However, that would require a new set of protocols and software and a much more complex hub. Therefore I have chosen to assume full network level transport will be used.

An implication of the above is that the newly connected computer must be able to communicate at least to the local subnet in order to reach an authentication service. In larger installations it will be most desirable to be able to reach a campus-wide authentication service. This implies that there be a relay server on each subnet, similar to the BOOTP[4] relay but in support of the authentication service, or the protocol used by the computer be routable - i.e. it must be IP. Rather than require another type of server on every subnet, the proposed design requires that the user's computer be properly configured and that the hub allow two-way communications before authentication can be initiated.

Finally, since there is assumed to be no pre-registration of the computer with the authentication service, we can not assume that secure communications at the link level is possible. In most environments we do not want to send the new user's password "in the clear" over a network with arbitrary users on it. Therefore we must consider use of an authentication system such as Kerberos[5] that addresses that concern. Again, this will require that the new user's computer be properly configured and be able to exchange IP packets with the secure authentication server.

A Conceptual Model

The proposed model for authenticating network connections assumes the use of standard DHCP for configuration of the computer (end-station) and some form of standard authentication service such as Kerberos. In operation, the following scenario would take place:

1) The LAN hub serving the "public network outlet" is initialized to a state where it can receive packets but will not send usable packets to the outlet.

2) The computer user plugs into the outlet and executes a configuration program that broadcasts a standard DHCP service request.

3) The LAN hub sees the packet, notes the MAC address, and notifies a special SNMP agent which then enables the hub port.

4) The DHCP server sends IP network parameters to the user's computer and sets a timer[6] to wait for authentication to complete. The information provided by the DHCP server might include the authentication server's address.

5) Using standard Kerberos protocols, the configuration program initializes a Kerberos session on behalf of the user and requests a "ticket" for the DHCP service. It then gives that ticket to the DHCP server that provided the configuration parameters.

6) If the DHCP server does not receive confirmation of the authentication before the timer expires, it resets the LAN hub port to the idle state.

7) If the LAN hub ever loses connection to the user's computer or receives a packet from a different MAC address, it notifies the SNMP agent which resets the port to the idle state. Thus if the sequence fails to complete for any reason, the user can return to step 1 above merely by unplugging and replugging their network connection (or by rebooting their computer).

More specific technical details of this scenario are given in Appendix A.

The use of Kerberos in the scenario above has an important secondary advantage: we want a universal, strong authentication mechanism in widespread use on our networks and we want it to be "user friendly." By incorporating Kerberos initialization into the required setup stage, we not only achieve the goals of an authenticated link level connection but we also prepare the user for access to Kerberized campus resources.

If this scenario is implemented well, with reliable and well managed servers, then it could be used to initialize almost all workstation connections on the campus network. The configuration and authentication steps would be part of booting any machine, permanent or mobile. This would ease the problems of relocating or changing machines, adding nodes to the network, etc. Of course, this would require a well thought out scheme for address allocation and reclamation. For reliability, redundant servers would be needed with appropriate synchronization. Scenarios such as recovering from a wide spread power failure should be considered. However, a significant advantage of this strategy is that, by logging authenticated DHCP requests, the campus Network Operations group would have a far more accurate picture of the real connections on the network than they do today with manual procedures.

Components of the Model

The proposed model has three main components: an enhanced DHCP user agent, an intelligent hub that supports disabling and enabling of individual ports, and a DHCP server that requires the authentication step to be completed. Most of the detail of each component exists today. This paper will suggest what needs to be added in order to make a complete system that will serve a broad range of needs on our campuses.

An important element of any authentication requirement is the particular authentication mechanism. Ideally anyone who is authorized to use services on our campus network should be able to connect to a LAN outlet a priori. Many campuses are running or are in the process of implementing some version of the Kerberos technology under which every member of the campus community will have an identity. Therefore Kerberos was chosen to illustrate the use of an authentication server in the proposed model. However, other technologies could be used if appropriate.

Enhanced DHCP User Agent

The DHCP software in the user's computer would combine standard DHCP with standard Kerberos initialization and service authorization. The only "enhancement" would be to combine both functions in a way that would appear seamless to the user.

A related issue beyond the scope of this paper is the integration of Kerberos support into the Mac and PC desktop environment[7]. For some desktop environments it might not be possible yet to use Kerberos for more than the connection authentication.

Intelligent Hub with Port Control

Certain LAN hubs today include hardware to recognize the MAC address of an attached machine and suppress data not destined for that machine. One class of these are sometimes referred to as "secure hubs" since they prevent "eavesdropping" on the network by obscuring the data field in all packets except those destined for the attached computer. A rapidly growing class of such hubs are the so-called "LAN switching hubs" that act as multi-way filtered repeaters, often with multiple internal paths. Switching hubs only direct packets to a port if they are destined for the attached computer.

This type of capability also could be used to completely deny service to an attached computer. Rather than automatically "learning" the MAC address of the attached computer, the hub would allow a MAC address to be "set" for each port by means of an SNMP command. To disable a port, a MAC address that is randomly selected or impossible in real hardware would be "set" by the DHCP server (or its SNMP agent). To enable a port, the actual MAC address of the attached computer would be "set." An important benefit of this approach to LAN hub port control, as opposed to simple "on/off" control, is that it prevents "eavesdropping" even after a connection is authenticated.

In addition to this capability, the LAN hub should generate an SNMP Alert message if the MAC address of a received packet differs from that "set" for any port. This particular alert would be forwarded to a specific SNMP server address preconfigured into the hub.

Finally, the LAN hub should send an SNMP Alert, and optionally disable the port, when link level connectivity is lost, e.g. the attached computer is unplugged or powered off.

None of these capabilities require new hardware in the LAN hub. All are simple programmed extensions of existing capabilities. However, such extensions must be made by the hub vendor.

DHCP Server with Authentication Support

The most complex component is the enhanced DHCP server. In addition to the standard DHCP protocol, it must understand the authentication method to be used and interact properly with the user agent and/or the authentication server. If Kerberos is used, it must be prepared to accept a ticket for DHCP Services and correlate it with a previously received standard DHCP request. It also must maintain a timer for each port that is in the initialized, pre-authorization state.

The DHCP server also must interact with an SNMP agent to control the state of the LAN hub ports. This interaction could be simplified by including the SNMP code in the DHCP server itself. In any case, a certain amount of additional state must be maintained for each port but the critical state must be known for only a short period.

The DHCP server or SNMP agent could also provide protection against accidental or intentional "denial of service" attacks such as flooding or jamming of the local subnet. Since an SNMP Alert is generated for each packet received from a non-authenticated computer, a flood of such packets over a short period could be detected and the associated LAN hub port disabled completely for a suitable period.

Required development would include adding the timer function, the SNMP agent, and the authentication interface to existing DHCP server code.

The Next Step: a Prototype Implementation

Certainly there are other models for achieving the goals defined for this service. What this paper has tried to illustrate is that it can be done in a straight forward way with technology that, for the most part, already exists. Assuming that there is interest in this type of service and concurrence that this approach might prove fruitful, the next step would be to flesh out the details and then develop a prototype implementation.

If we are to realize a prototype along the lines of the model suggested, it will require both the partnership of one or more LAN hub manufacturers as well as modest software development. The latter might be undertaken by one of the CSG member institutions with expertise in Kerberos, DHCP, and/or SNMP. The industrial partnership may be more attractive to a manufacturer if there is a clear expression of interest from many of the CSG members.

If the prototype proves successful, I would propose that we document the specifications and make them widely known, perhaps as part of the IETF process. I believe we would all benefit from a readily available common solution to this problem.

Appendix A: Detailed Connection Setup and Authorization Steps

1) The initial state of the network outlet, as determined by the LAN hub port settings, is to be able to receive packets from an attached computer (end station) but to transmit nothing, or at most unusable packets, to the end station. This might be achieved by use of a "secure hub" or switching hub that suppresses outgoing data not destined for a predefined MAC address.

2) Once plugged in and powered up, the first operation a user performs is to execute an enhanced DHCP User Agent (DUA) on their computer. This DUA begins by broadcasting a standard DHCP configuration request.

3) Two things happen then, more or less in parallel:

3A) The LAN hub sees activity on the idle port and sends an SNMP Alert to the designated SNMP Monitor Agent (SMA) - which should be on the same platform as the DHCP server. The LAN hub does not enable the port. The alert message contains the port number and the MAC address. (This is probably new functionality for commercial LAN hub products.)

3B) A DHCP server receives the configuration request, perhaps forwarded by a DHCP proxy on the local subnet. This configuration request must contain the MAC address of the requesting end station.

4) The SMA forwards the MAC address and port ID of the end station to the DHCP server in a request for permission to enable the port. This step is necessary in case the authentication fails (see step 7 below).

5) The DHCP server:

5A) Caches the parameters and acknowledges to the SMA the request to enable the port. The SMA then directs the LAN hub (using authenticated SNMP "sets") to allow bi-directional communication for that MAC address on that port.

5B) Returns configuration parameters to the end station in the standard way, including its own IP address in case there are multiple DHCP servers that might have responded.

5C) Sets a timer[8], associated with the assigned IP address, that defines how long it will wait for confirmation of an authentication step.

6) Once the DUA on the end-station configures the IP protocol stack, it initiates the authentication step:

If Kerberos is used, the DUA initiates the Kerberos authentication and saves the TGS[9] ticket for further use by the user. It then uses the TGS ticket to request a ticket for "DHCP Service" from the actual server that responded to the configuration request. When it receives this ticket, it sends it to the DHCP server.

Other authentication mechanisms might be used, such as TACACS, with appropriate hooks in the DHCP server and DUA.

7) Once the DHCP server is satisfied with the authentication step, e. g. by receiving a valid Kerberos "DHCP Service" ticket, it clears the timer for that end station IP address. If the timer expires, the DHCP server notifies the SMA to reset the LAN hub port associated with that configuration request.

8) The LAN hub port is reset to the initial (unusable) state if:

8A) the timer for an end station expires before authentication is completed, or

8B) the LAN hub detects "loss of carrier" e.g. loss of link level integrity on a 10baseT connection, or

8C) the SMA receives an alert from the LAN hub that a packet with a different MAC address has been received on an operational port. The LAN hub may have no way to distinguish between an operational port (configured with a valid MAC address) and an idle port (with an invalid MAC address). Therefore, state for each port may have to be kept in the SMA. The SMA could choose to require re-authentication if it receives such an alert as an alternative to shutting down the port.

The scenario above is probably adequate for use in a campus environment but it is not foolproof. Various attacks might be made to disable the SMA or inject illicit traffic during the authentication window. The LAN hub will protect against jamming of the network by automatically shutting down that port. The SMA could be programmed to notice less severe flooding of the network from an unauthorized station and could completely shut down that port. In any case, I believe that any remaining vulnerabilities are no worse than we face today with existing connections on our networks.

© " This work is copyrighted by the Regents of the University of California. Permission to transmit, copy or distribute is freely given, provided such transmission, copying or distribution is not for direct commercial advantage. To copy or distribute otherwise, or to re-publish, requires prior written permission. "