Microsoft "embraces and extends" Kerberos V5

by Theodore Ts'o
<tytso@MIT.EDU>

Theodore Ts'o leads the Kerberos V5 development team at MIT. He is a member of the Internet Engineering Task Force, where he currently serves on the Security Area Directorate and as co-chair of the IP Security Working Group.

A lot of excitement was generated by Microsoft's announcement that NT 5.0 would use Kerberos, followed by a lot of controversy when Microsoft announced that it would be adding proprietary extensions to the Kerberos V5 protocol. Exactly what and how Microsoft did and tried to do has been a subject of some confusion. Here's the scoop about what really happened.

NT 5.0 will indeed use Kerberos. However, Microsoft has "embraced and extended" this protocol by adding a digitally signed Privilege Attribute Certificate (PAC) to the Kerberos ticket. The PAC will contain information about the user's 128-bit NT unique id, as well as a list of groups to which the user belongs.

The NT PAC unfortunately is not compatible with the PACs used by the Open Software Foundation's Distributed Computing Environment (DCE). It is also somewhat debatable whether the NT PAC is legal with respect to RFC-1510, the IETF Kerberos V5 protocol specification. The original intent of RFC-1510 prohibited what Microsoft was trying to do, but Microsoft found what it claimed to be a loophole in RFC-1510 specification.

Many folks, including Paul Hill and myself at MIT, as well as Cliff Neumann at ISI, have tried to work with Microsoft to find a more compatible way of doing what they wanted to do. To that end, we made changes in the upcoming revision of RFC-1510 to add a clean and compatible way of adding extensions such as Microsoft's PAC to the Kerberos ticket.

To Microsoft's credit, it agreed to change NT 5.0 to use a cleaner and more compatible way of adding extensions to the Kerberos V5 ticket. It also pledged that it would make available to us detailed technical information about the NT PAC after the beta release of NT 5.0. This pledge was very important to MIT and other commercial, educational, and government sites which have an extensive deployed base of Kerberos V4 applications (for example Transarc's AFS). At MIT, for example, we had planned to add the ability to generate an NT PAC to the MIT Kerberos V5 implementation, which has backwards compatibility for Kerberos V4 applications.

Unfortunately, at the Microsoft Professional Developers Conference (PDC) in September, Microsoft appeared to be backing away from this commitment. For the first time, Microsoft revealed that it had chosen to implement the NT Domain Controller in such a way that the Active Directory Server and the Microsoft KDC run in the same process space, and that NT clients cannot be configured to split a Domain Controller across two machines. Thus, it would not be useful for Microsoft to reveal its proprietary extensions to the Kerberos protocol.

However, at the PDC, Microsoft did indicate that it had licensed its Domain Controller to a few UNIX vendors. So it may eventually be possible to run a Domain Controller on a non-NT machine, but there is no indication what the license may cost each site. It is doubtful, however, whether Kerberos V4 support will be included in those products.

Microsoft should be commended for using a mature industry standard such as Kerberos for its authentication protocol. Kerberos has had a long review period, and its use has been proven in many operational environments. It seems ironic, however, that Microsoft would choose to design and deploy its implementation with features that are guaranteed to alienate the early adopters of Kerberos, the very people that have helped to create and improve the technology that Microsoft has chosen to "embrace and extend."