Home > Archives > April 2006 >

Machine Shop

Who's Who in Cambridge

Harvard and MIT have similar identity management challenges but very different solutions. Comparing the two is a good exercise for any CSO looking at ID management.

By Simson Garfinkel

E-mail this article  |  Printer friendly

Advertisers

Cambridge, Mass., is home to two of the world's great universities, MIT and Harvard. Both have massive enterprise networks with every imaginable kind of off-the-shelf and custom device. Both schools have diverse user populations with tens of thousands of highly mobile members. And both schools have a need for strong network security—these universities are under constant attack, from both the outside and from within.

MIT and Harvard have been on the Internet since the early 1970s, and they had fully deployed campus networks before most people in the United States even had a dial-up connection. Thus, it's not surprising that both schools have built their own custom identity management systems. What is surprising, though, is that the under­lying design and implementation of the two identity management systems are radically different, yet in many ways they offer similar functionality and have similar problems.

Identity management systems provide for a centralized directory of the organization's members. They give members a way to authenticate themselves, and they may even track each person's level of authority and authorization. The best identity management systems can be easily integrated with a wide variety of legacy systems. For example, they could interoperate with a Microsoft Active Directory server and provide the possibility of "federation," that is, allowing organizations to certify the identity of a member to other organizations. Such a system could be used by a company like Ford to enable the employees of its suppliers to directly interoperate with the Ford website using their existing user names and passwords, rather than forcing them to get new user names and passwords that would only be used at the Ford website.

Comparing the strengths and weaknesses of MIT's system and Harvard's is illuminating for any CSO whose organization is considering deploying or expanding an identity management system of its own.

Good Watchdog, Surly Pet

Researchers at MIT developed one of the world's first identity management systems back in the 1980s. Called Kerberos, the system was designed to allow users of distributed Unix workstations to identify and authenticate themselves to services running on other computers.

Kerberos had only a few design goals. MIT's network designers realized that there would be no way to prevent students from running their own packet sniffers, so the primary goal was to give everyone on the MIT campus the ability to use any network-based service without sending their passwords over the local area network. This goal was realized with a complex system running on users' computers that obtains encrypted "tickets" from a central Kerberos server.

When an MIT student or staff member logs in to his computer, the computer asks the Kerberos server for a special "ticket granting ticket." The Kerberos server sends the ticket encrypted with the user's password. If the user's computer can decrypt the ticket, then the user must know the right password, so the user has been implicitly authenticated. With that decrypted ticket, the user can go on to request other tickets for specific online services. At MIT's Project Athena the Kerberos system is used for e-mail, for file access and even for sending jobs to the printer. (Each student has a monthly printing limit.)

MIT deployed Kerberos widely by the late 1980s. In the 1990s Kerberos was adopted by most Unix vendors; Microsoft added support to Windows 2000.

Kerberos has a reputation for being very secure. It also has a reputation for being very difficult to configure and use. Both reputations are justly deserved. The big problem with Kerberos is that every application program needs to be specially "Kerberized" so that it can work with Kerberos—a difficult process. Web browsers, in particular, were very hard to Kerberize because they were numerous and evolving so fast. So in the late 1990s, MIT adopted a second enterprise authentication system, based on SSL and client-side X.509 digital certificates, which it runs in parallel with Kerberos. Students and staff members create their Kerberos user name and password when they show up at the Institute. Once they have a Kerberos account, they can go to a special website and get an "MIT Certificate" by entering their Kerberos user name, password and MIT ID number.

The combination of Kerberos and client-side certificates produces a system that is awkward and confusing; some services are certified by Kerberos, some are certified by the MIT Certificate, and it really isn't clear which service uses which certification or why. For example, a student who wants to read her bursar's statement needs to use her MIT Certificate to access the special MIT student website. That's because the SSL certificates are considered secure. But a student who wants to read his MIT Web mail goes to a different website and enters his Kerberos user name and password. The reason for this difference is that MIT assumes that students will be reading their Web mail at Internet cafés and friends' computers—places where students shouldn't be leaving copies of their MIT Certificate. Unfortunately, this means that students' Kerberos passwords could be stolen by keyboard sniffers. Fortunately, anybody with a Kerberos password that's truly valuable doesn't use computers at Internet cafés: They carry their own laptops.

Another problem with MIT's enterprise authentication is that it doesn't work outside the Institute. MIT's libraries subscribe to hundreds of online information services. These organizations refuse to accept either Kerberos tickets or MIT Certificates. Instead, they want to authenticate members of the MIT community by their IP address. That's no problem for MIT users who are on campus. Professors and students who are off campus can either run the MIT Virtual Private Network client (which authenticates users with their Kerberos password) or else go through one of the special proxy servers that the MIT libraries have set up (which authenticate users with their MIT Certificate). Both of these systems create a tunnel between the user's computer and MIT so that the third-party information providers think the user is actually on campus and using an MIT IP address.

<< Previous ||  1  2  || Next >>