Identity Management at Harvard and MIT

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.

Kerberos: 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.

One Person, One PIN

A few miles up the Charles River, Harvard has taken a dramatically different approach. Harvard has created a unified identification and authentication system called the Harvard PIN. Like the MIT Kerberos system, the Harvard PIN is also based on a simple user name and password. But that’s where the similarity ends.

Whereas the user name employed by the MIT Kerberos system is the MIT student’s or employee’s e-mail address, the user name for the Harvard PIN system is the person’s eight-digit Harvard ID number. Because this number is not widely available, it’s much harder for an attacker to figure out. Harvard passwords are also more secure: Whereas MIT lets people use pretty much whatever they wish as a password, Harvard has a “strong” password policy: PINs must be at least eight characters long, have at least one number or symbol, contain both uppercase and lowercase letters, and have at least five different characters. It actually took me 15 minutes to come up with a Harvard PIN that I could remember but that was strong enough to meet Harvard’s requirements.

When a student or staff member at Harvard needs to do something official online (such as accessing grades) the online service redirects the user’s Web browser to the Harvard PIN Server, a centralized system that requests the user’s ID and PIN and then returns the user to the online service that was requesting authentication.

It actually took me 15 minutes to come up with a Harvard PIN that I could remember but that was “strong” enough to meet Harvard’s requirements.

One nice aspect of the Harvard system is that users enter their PIN on only this single page. It always has the same look, feel and URL. The webpage is SSL-encrypted. Each of these measures reduces the chances that a Harvard PIN will be stolen through a phishing attack.

Because the Harvard PIN is used to authenticate both high-value and low-value transactions, the system allows different applications to have different “re-identification” policies. For example, the Harvard library website uses the Harvard PIN to approve access to electronic journals, but it requires that users authenticate only once. After that, it stores a cookie on the user’s computer that’s good for a day or so. In contrast, Harvard’s enterprise financial applications that can issue checks for hundreds of thousands of dollars can require that the PIN be provided for each check—and even then, they can be further restricted to accept the PIN only from particular workstations in particular locations on campus.

These days, with Microsoft, Oracle, Sun and many other enterprise software vendors offering their own identity management systems, it’s instructive to see how some of academia’s best networking wizards have solved the problem for themselves. Both systems work without a hiccup day after day and make it possible for users to authenticate to a large number of enterprise systems, they never compromise security by sending a password over a network without encryption, and they will be relatively straightforward to upgrade to high-security systems like PKI-based security tokens. Corporate America should be so fortunate.##

Simson Garfinkel, CISSP, is the author of numerous computer security books, including Security and Usability: Designing Secure Systems that People Can Use.