Microsoft and the Kerberos Standard
Microsoft’s decision to make Kerberos the core security protocol in Windows 2000 is unquestionably a good thing. Kerberos is faster than the protocol used in Windows NT 4.0, offers more features, and is a multi-vendor standard, as well. What’s not to like?
Well, for one thing, there’s doubt in some quarters about whether Microsoft really follows the standard. Is it possible to make Windows 2000 Kerberos interoperate with other implementations, especially the free implementation offered by MIT? Or is Microsoft blowing smoke, trying to appear standard while remaining proprietary enough to lock in customers?
Microsoft claims that its implementation follows RFC 1510, the defining standard for Kerberos. To the best of my knowledge, this statement is true. Ideally, this would be enough to guarantee interoperability with MIT Kerberos. In fact, things aren’t so simple. First, like many standards, RFC 1510 defines various options, and Microsoft has made some idiosyncratic choices among them. For example, clients send preauthentication data during login -- a legal but not commonly implemented option; Windows 2000 Kerberos defaults to RC4 for its encryption algorithm rather than the more traditional DES; and the scheme Microsoft uses to derive encryption keys from passwords doesn’t exactly match how MIT Kerberos does it.
Another important issue stems from the fact that the RFC leaves some critical issues unspecified. For instance, Kerberos creates and distributes byte strings called tickets, then allows clients to present these tickets to applications to prove their identity. Every ticket contains a field called Authorization Data, intended to carry information identifying the client. RFC 1510 leaves undefined what the contents of this field should be. Microsoft’s implementation, not too surprisingly, sends Windows 2000-specific information, mainly a group of Security IDs (SIDs) identifying the user and the groups the user belongs to. Applications that receive tickets can extract this information, then use it to make an authorization decision. Tickets generated by non-Microsoft implementations of Kerberos won’t typically contain this Windows-oriented information. If, say, a Unix client gets a ticket from an MIT Kerberos server, then presents this ticket to a Windows 2000 domain, that ticket won’t contain the information that a Windows 2000 server application needs -- the SIDs -- to make an authorization decision. This could potentially make it tough to build a workable environment that includes Microsoft and MIT versions of Kerberos.
Clearly, there are important differences between Windows 2000 Kerberos and the standard MIT implementation. But the interoperability picture isn’t really so bleak. Microsoft’s Kerberos can be configured to accept logins from clients without preauthentication data, to negotiate DES for encryption, and to use the standard MIT function for deriving keys from passwords. It’s also possible to configure Windows 2000 Kerberos to accept a ticket created by an MIT Kerberos server, then map that ticket’s client into a Windows 2000 account. The result is that, with some administrative effort, a user coming from a domain that doesn’t use Windows 2000 Kerberos can still present the authorization information expected by an application running on Windows 2000.
It’s difficult to believe that Microsoft is allowing interoperability with other implementations -- it doesn’t fit the company’s reputation. Yet looking at what is actually in the product leaves me convinced that this is, in fact, the goal. Making Kerberos work as well as possible in a pure Windows 2000 domain and minimizing the pain of migration from NT 4 are clearly higher priorities, which is probably the right approach. After all, the current installed base of MIT Kerberos is much smaller than the installed base of NT 4. Valuing interoperability above satisfying current customers wouldn’t make much sense. Still, the company has gone to a good deal of trouble to add features to the product that make interoperability possible. Much as I might like to find things to criticize here, I have a hard time doing it. -- David Chappell is principal of Chappell & Associates (Minneapolis), an education and consulting firm. Contact him at david@chappellassoc.com.