Federated Network Authentication by Matthew Gast 04/08/2005 http://www.oreillynet.com/lpt/a/5778
Educational institutions in general, and those of higher education specifically, have been early and aggressive users of 802.11. Wireless LANs excel at providing network access throughout a large and distributed campus on networks with a high number of mobile users, and giving easy access to guests. Universities have been some of the earliest builders of 802.11 networks, because they often face exactly these problems. I recently attended the Internet2 Joint Techs workshop at the University of Utah in Salt Lake City. I attended a number of sessions, but the two most interesting were Kevin Miller's workshop on federated authentication and Terry Simons' discussion about 802.1x. Both dealt with the problem of balancing the needs to retain the traditional openness of academic networks with the practical requirement for network security. Roam If You Want to Early wireless LAN technology had only crude security mechanisms. As a result, most organizations maintained network security by closing down the wireless network, either by shutting it off completely or by isolating it from the rest of the network to such a degree that it had only limited functionality. Both of the Joint Techs sessions on authentication were about how to use authentication to open the network back up. The current state of the art in authentication protocols works well in a standard corporate environment with unified network administration, but there are shortcomings for the classic academic environment. Higher education institutions are often internally balkanized to a much greater degree than corporations are. The larger the academic organization, the harder it is to build a unified infrastructure. Departments build their own networks for a variety of reasons. Within a single institution, users naturally cross administrative or political boundaries, often without even being aware they are doing so. When crossing these invisible boundaries, users have the reasonable expectation that security will not be an obstacle. Universities also have much more porous borders than corporations. Researchers and scholars may hold appointments at multiple institutions or be involved in research teams that draw members from across the country or the world. Frequent visitors require network access. Without a full-time appointment, they may not be eligible for full access at the visited institution, but the hassle of repeatedly provisioning guest accounts is no solution. Within the academic IT community, this is called the "roaming scholar" problem. How can a user visit an institution and access the network there without needing to learn several guest-provisioning processes? Can authentication be extended to visiting scholars to automate the workflow? Some network administrators even go so far as to refer to the solutions as enabling single sign-on, because the goal is to allow the roaming scholar to use a single set of credentials from the home institution at any visited institution. Although this discussion is based on scholars moving between universities, it can be applied to many network environments. Geographically distributed organizations might have traveling administrators or even roving teachers. Joint ventures between two companies, for example, might depend on expertise at both of the parents, and it improves productivity to allow visitors from parent organizations to use the network at the joint venture. Companies with tight partnerships may also depend on close cooperation and may find it useful to share network resources with visitors, though some restrictions on visitors would undoubtedly be necessary. Federations and Meshes Networks, whether wireless or wired, may be loosely associated and coalesced into small groups called federations. Federated networks are composed of several member networks that share some level of trust, but member networks retain their own administrative control. Each member network is constructed and run separately. Related Reading 802.11 Wireless Networks: The Definitive Guide, 2nd Edition 802.11 Wireless Networks: The Definitive Guide, 2nd Edition By Matthew Gast Users expect to be able to use every network in a federation, although they are not usually integrated seamlessly. A user account may be granted privileges in multiple member networks of a federation. Generally, the user account is created in a home network, and other members of the federation grant privileges to users from other networks. When moving between members of a federation, all bets are off for services and configuration. Two member networks may have separate naming conventions and provide separate access. Federations work to extend network access across administrative boundaries. By establishing trust between networks, it becomes possible for a user to attach to a foreign network and receive access without any local configuration. (Mobile telephony also uses authentication protocols to let subscribers roam onto foreign networks; GSM was the first system to handle roaming well.) In many cases, authorization is used to limit the access rights of visiting users. Loose federations can provide restricted network access to visitors, while crossing network boundaries in tighter federations can be almost imperceptible. Authorization can assign different levels of trust to different users. Within a single university, users from other departments on the campus may be more trusted and given greater network access than guest users from other universities. Trust levels influence the roaming agreements. Within a campus, the roaming agreement is often informal, along the lines of "if you want your department's users to have access to other networks on campus, you need to accept other users onto your network." Agreements are based on personal relationships and the policy within a single institution. To establish roaming between universities, expect paperwork. (EduRoam, a Europe-wide federation, requires a formal, signed contract for connection.) The technology ties that bind The core technologies that are used to build a mesh are authentication standards. 802.1x offers control of network ports, and it integrates tightly with RADIUS authentication servers. It also limits network access before user identity is established through RADIUS. Both 802.1x and RADIUS are natural building blocks for federations. Within a member network, there is an authentication system that can authenticate users locally. In a campus environment, a member network is typically a department. Local users can be authenticated locally. Unknown users are passed to a higher-level authentication server. As an example, a hypothetical school named Authentication University (AuthU) has built a campuswide federation. Several departments maintain their own authentication servers. Engineering department users are given user IDs in the form [EMAIL PROTECTED], music department users are [EMAIL PROTECTED], and so on. Within the engineering department, the RADIUS server has user definitions for any user from eng.authu.edu. Visitors from other departments are passed up to a "core" server that can refer queries to other departments. The core server has RADIUS relationships with all the member networks on campus. It does not need to have user accounts--it is just glue that stitches together the authentication system in a unified way. The authentication backbone supporting a federation is called a mesh, because every authentication server in the federation has the ability to authenticate users from every other authentication server in the federation. The actual configuration may be a hub-and-spoke, with a core server that holds the entire system together; it may also be a full mesh, with all RADIUS servers directly peered with each other. The hub-and-spoke topology is significantly easier to configure because new member networks (spokes) need only to be configured on the core (hub). One of the earliest RADIUS meshes was built at the University of Utah. The design of the mesh was part of an early white paper written at the university. Terry Simons, one of the chief architects and administrators of the university mesh, also wrote a more detailed paper for the Interop Labs. The Internet2 conference network used the University of Utah's RADIUS mesh. Each conference attendee was assigned a temporary account, and several departments across campus assisted in preparations and production. Once the conference network was configured to use the campus RADIUS mesh, any user account on campus was accepted on the network. Technical challenges Federations can be built on both wired and wireless networks, but wireless networks are more attractive. Granting access to wireless LANs frees guests from having to search for network ports, and many travelers have computers with 802.11 interfaces. Guests often are more mobile than internal users, especially since they rarely have office space at the visited institution. Wireless networks pose a special set of problems for federations, though. 802.1x supplicants need to authenticate to new access points, and transferring authentication requests across the internet is subject to additional latency. On a campuswide basis, the extra latency to authenticate across a RADIUS mesh is negligible. Latency across the internet may be significant, especially when moving between access points. RADIUS meshes are typically built on a series of point-to-point trust relationships. Each relationship is used to proxy a certain type of user identifier, and the proxy configuration winds up defining a routing table for authentication. Each hop in the RADIUS proxy configuration requires a shared secret. Much like static IP routing, correctly distributing a large number of RADIUS shared secrets poses a major administrative headache. RADIUS servers must be protected from intentional denial-of-service attacks as well as bugs. In a hub-and-spoke RADIUS mesh, it is vital that the core remain operational. One of the network administrators mentioned that an access point software bug resulted in a flood of 50 unique RADIUS access requests per second. Many RADIUS servers are unable to cope with such a load. In building a large federation, it is vital to ensure bugs (or attacks) are unable to disrupt operation of the authentication backbone. Beyond the purely operational issues, the intersection of the technology's capabilities with policy enforcement is an unsettled question. Extending authorization beyond static information to encompass machine state is an emerging development. If an authorization fails, what is the appropriate way to notify a user? 802.1x provides a facility to send messages to the end user called EAP notification, but it is not widely implemented by most supplicant software. Which organization is responsible for assisting the user--the home network or the visited network? Beyond machine state, some federation members may wish to require additional information. If I were to visit another network, it may not be enough to know that my employer vouches for me. Secure authentication methods can protect user identifiers and allow users to be anonymous to the networks they visit. The visited organization may have a policy that all users must be identified, or that they must obtain contact information from visiting users. If a network kicks off users who become infected with viruses or worms, it makes sense for the local network to take the lead in remediation. Local lockouts can be removed locally; when users travel across multiple time zones, situations may easily arise when the user's home support organization is not available due to the time change. By requiring the release of the mobile telephone number to the visited network, local administrators can take action immediately. Today, local lockouts are handled in a different way on each RADIUS server. Radiator can perform multiple authentications and require that all of them succeed. The University of Utah performs authentication against the user's home account, as well as a lockout list used for DMCA complaints. Even if the user credentials are correct, the account can be locked by a separate list. EAP notifications are used to send messages to users whose accounts are locked out so that they can learn about the lockout and generic reason without face-to-face interaction. What Next? At the conference, the Federated Wireless NetAuth working group proposed a two-phase implementation schedule. In the first phase, the group is building a traditional RADIUS mesh based on a hub-and-spoke topology. After exchanging RADIUS shared secrets with each member network in the federation, it will be operational. In the second phase, which has a moving target goal to be running later in the year, the hub-and-spoke topology will be replaced with direct links between members in the federation. To enable the selective release of information to visited sites, the working group is experimenting with Shibboleth, a middleware tool that plugs into campus identity management systems. To build momentum for the federation, it may be brought to a conference near you. Connecting a conference network into the mesh allows any user from the mesh to use home credentials to get network access, rather than requiring the conference network to provision and maintain user accounts for only a brief event. Protocol development As I sat in both of these sessions, I was struck by the age of RADIUS and how poorly adapted it is to the modern world. RADIUS was designed for the dial-up era of the internet, which is long past. (I can't remember the last time I used a modem to obtain internet connectivity.) As federations evolve, potentially into a new "authentication backbone," the limitations of RADIUS show through more clearly. The initial design for the Internet2 federation uses an Internet2 core RADIUS server as the hub. Each university joining the federation defines only a single RADIUS proxy relationship to the core. Internet2 maintains the core, and any member must connect to the core. As I listened to the description of the technical architecture, I was reminded of the Exterior Gateway Protocol (EGP, RFC 904), an early routing protocol that assumed the existence of a single internet core. When the federation grows and becomes much more useful, the existence of a single core will stress the routing system for authentication requests. By definition, the hub in a hub-and-spoke topology must be involved in any inter-domain authentication request. It does not have to do heavy cryptographic work because the tunnel for authentication is established from the user to the authentication server at his or her home organization. However, RADIUS packets must still be validated with the shared secret on reception, and "signed" when forwarded on to the next hop. Routing authentication requests is still in its infancy. Just as EGP gave way to the more sophisticated Border Gateway Protocol (BGP, RFC 1771), so might RADIUS proxy relationships give way to a more sophisticated routing system. Multihop hub-and-spoke topologies are necessary because RADIUS relationships are defined in a pairwise fashion. Practically speaking, an initial version needs to be built on a hub-and-spoke topology due to the limitations of RADIUS. Rather than defining pairwise relationships between each member of the federation (an order N-squared configuration), a hub-and-spoke requires only one pairwise relationship with each member (an order N configuration). Future authentication protocols might separate the discovery of the home authentication server from the authentication traffic itself. Extra hops through the core of a hub-and-spoke topology add latency, especially across wide-area networks. Without proper configuration, the extra latency may cause authentication trouble. In a "cut-through" protocol, discovery of the user's home authentication server might be done with traffic through a slower hub-and-spoke system, but the authentication packets themselves could be sent directly between endpoints. There was a short discussion of using DNS service location records (SRV records, specified in RFC 2782). Although SRV records could be used to assist with locating appropriate authentication servers for the user's home network, it cannot be used to establish a RADIUS client-server relationship between two servers. To reflect the messy realities of building a federated network, a more generic trust mechanism needs to be developed. Matthew Gast is the author of 802.11 Wireless Networks: The Definitive Guide, Network Printing, and T1: A Survival Guide. You are a subscribed member of the infowarrior list. Visit www.infowarrior.org for list information or to unsubscribe. This message may be redistributed freely in its entirety. Any and all copyrights appearing in list messages are maintained by their respective owners.
