Kerberos Upgrade Project
Kerberos 5 Migration
Stanford's Kerberos infrastructure is based on a combination of a Kerberos 5 cell (stanford.edu) and a Kerberos 4 cell (IR.STANFORD.EDU), and an Active Directory (AD) cell (WIN.STANFORD.EDU) that supply authentication credentials to most of Stanford's core services. All of these cells are run in parallel, and their password databases are kept in sync. Having three cells is a very unusual architecture--most sites only use Kerberos 5 and/or AD. It makes our authentication infrastructure more complicated than it should be, and causes some vendor software (especially software designed to change passwords and otherwise deal directly with the management of a user's kerberos principal) to not work without extensive modifiction.
There are three main factors motivating IT Services to complete this project:
While there is no known way to crack a Kerberos v4 ticket, it is not invulnerable. If the Kebreros 4 hashing scheme were broken, it would expose all K4 transactions that involve a forwarded ticket (i.e., all klogin transactions). As Kerberos 4 becomes a less supported technology by the open source community, we risk not being able to speedily patch our infrastructure. Kerberos 4 is also vulnerable against offline brute force attacks that can break individual accounts, although we try to mitigate against that possibilty by using aggressive password strength checking.
Kerberos 4 is no longer a widely-used technology, even amongst AFS users. There have been discussions about ending active development on Kerberos 4-the last kth release was in March of 2003. We are likely to get much faster patches for security vulnerabilities by using Kerberos 5 exclusively. We are also maintaining a set of Stanford-specific patches to both Kerberos 4 and Kerberos 5, which we must update with each new release of either version of Kerberos we intend to deploy. This increases our response time for any major security vulnerability in either version of Kerberos.
- Development Paralysis
Although the mixed-realm Kerberos environment is very functional, it is hampering future development efforts around authentication technology. In particular, it complicates the relationship with the Windows Active Directory KDC, and prevents us from using many of the features of Kerberos. Inability to use the native password aging functionality of Kerberos made the remediation of an audit finding consume significant development resources.
The Kerberos 5 Migration project aims to eliminate Kerberos 4 as an authentication technology we use at Stanford. To accomplish this, we need to do the following things:
- Migrate or Retire Services that Use Kerberos 4 to use Kerberos 5
Many core infrastructure services rely on Kerberos 4 to authenticate. These services must be either migrated, such as AFS, several ways to check e-mail (including KPOP and the PC-Leland mail proxy), and srvtab/keytab distribution, or eliminated, such as K4 S/Ident, Webauth v2, and sysctl.
- Change the Relationship between Stanford's Kerberos Realms
Currently the Kerberos 4 cell is the master cell amongst the three kerberos realms at Stanford. Password changes are made in K4, then propogated Kerberos 5 and Active Directory. Two major changes need to made in this relationship. First, Kerberos 5 needs to be the master cell, propogating changes to Kerberos 4 (temporarily) and Active Directory. Also, AD and Kerberos 5 need to be brought into a trust relationship, allowing tickets granted by one cell to be recognized by the other.
- Distribute New Kerberos Client Software
Part of this project is the cretion and distribution of new client software that uses Kerberos 5 as the primary means of authentication. This includes new OpenAFS, PC-Leland, and MacLeland software, new Kerberos kits for UNIX, and a new system to download keytabs. Getting this new software adopted by the campus community is a prerequisite to being able to turn off the Kerberos 4 cell.
- Retire the Kerberos 4 Cell
Finally, once we have migrated all services off of K4 and have upgraded clients to software that only uses Kerberos 5 to access these services, we turn off the Kerberos 4 KDC.