Date: Thu, 23 Oct 1997 15:40:40 -0400 From: "Theodore Y. Ts'o" <tytso@MIT.EDU> To: kerberos@MIT.EDU I've been keeping relatively quiet on this subject while we tried working with Microsoft to come up with a more positive solution. Unforunately, I regret to say that the results have been less than optimal. The following article will be appearing in an upcoming issue of Usenix's ;login newsletter, and it pretty much sums up the entire story. Obviously, because NT clients can only use the Kerberos server embedded inside an NT Domain Controller running on a Windows NT box, this is going to cause major problems for anyone who has already deployed a Kerberos infrastructure in their site --- this includes folks using OSF DCE, Transarc AFS, not just those folks using either the MIT Kerberos implementation, or one of the commercial Kerberos products from Cybersafe, OpenVision, Cygnus, etc. We're still investigating what we might be able to do to salvage this situation, but most of the solutions that we've looked at aren't pretty one way or another. - Ted Microsoft Embraces and Extends Kerberos V5 ========================================== There has been a lot of excitement generated by Microsoft's announcement that NT 5.0 would use Kerberos. This excitement was followed by a lot of controversy when it was announced by Microsoft 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, this protocol has been "embraced and extended" by Microsoft, 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 is unfortunately not compatible with the PAC's 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 they 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, they agreed to change NT 5.0 to use a cleaner and more compatible way of adding extensions to the Kerberos V5 ticket. They also pledged that they 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), as 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 appears to be backing away from this commitment. For the first time, Microsoft revealed that they had chosen to implement the NT Domain Controller such that the Active Directory Server and the Microsoft KDC ran in the same process space, and that NT clients could not be configured to split a Domain Controller across two machines. Thus, it would not be useful for Microsoft to reveal their proprietary extensions to the Kerberos protocol. However, at the PDC, Microsoft did indicate that they had licensed their 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 their 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 their 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."