Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!olivea!uunet!shelby!UUNET.UU.NET!nss1!cjr From: nss1!cjr@UUNET.UU.NET (Chris Riddick) Newsgroups: comp.protocols.kerberos Subject: Future of Kerberos and Vendor support Message-ID: <9102191520.aa20663@nss1.UUCP> Date: 19 Feb 91 15:20:15 GMT Sender: news@shelby.stanford.edu (USENET News System) Organization: Internet-USENET Gateway at Stanford University Lines: 69 Greg, Jeff Schiller gave a good response to your query about Kerberos and public key technology. Regarding your interest in vendor support for a variety of environments and platforms, we at Simpact Associates have been using Kerberos as an authentication system for a distributed system security product. As a spinoff of the effort, we offer a vendor-supported MS-DOS Kerberos toolkit which supplies the Kerberos client library functions to the MS-DOS programmer. These include the DES library as well as our own login program for MS-DOS that provides optional support for both our PrivateKey memory device and smart cards for password storage. Currently supported version of Kerberos is V4. We are running the latest release of V5, and we will provide an upgrade for the toolkit when V5 is finally released by MIT. We are defining an API that will provide application-level support for security services on a distributed system. Our API is backwards compatible with Kerberos so standard Kerberos applications will run with our environment without modification. We provide a level of transparency above the Kerberos interface. This provides an abstraction that enables application developers to establish authenticated and secure sessions without any formal knowledge of the underlying authentication mechanism or encryption algorithm. The important point to note here is that distributed system security should be transparent to the application developer unless the programmer wishes to expand on the security services or use them in a non-standard fashion. The reasons for choosing Kerberos over SPX (Sphinx) or any other authentication system is dependent upon many factors. Kerberos is a third-party authentication scheme that provides a strong authentication mechanism between two mutually suspicious parties. SPX is a two-party system that allows the parties to authenticate each other on the basis of public key technology with key published in a directory such as X.500. Both techniques are valid authentication mechanisms. One may choose Kerberos over Sphinx because of its public availability and use of DES and passwords. Shinx requires licensing RSA public key technology in order to use the system. However, Sphinx provides an advantage over Kerberos in that the communicating parties need not have exchanged a secret key. Only the public key of the destination and the sender's own private key are required to perform authentication. Kerberos requires that all communicating parties place their secret key in a secure storage location managed by the trusted third party. Both systems provide advantages and disadvantages, but it is clear that both systems will be around for some time to come. OSF has selected a hybrid of Kerberos for their Distributed Computing Environment (DEC). OSF has defined an API for remote procedure calls that would permit substitution of some other authentication for Kerberos in the future. They have also recognized the need to support more than one scheme. The bottom line is that there is extensive vendor support for Kerberos as well as other authentication mechanisms. Perhaps Jeff at MIT could establish a list for those of us interested in the merging of Kerberos and other systems like Sphinx so that we can exchange ideas on a generic API. I would be pleased to share what we are doing at Simpact in defining a generic API for security services. How about it, Jeff??? Chris Riddick UUNET: uunet!nss1!cjr Internet: nss1!cjr@UUNET.UU.NET USSnail: Simpact Associates, Inc. 12007 Sunrise Valley Drive Reston, Virginia 22091 Phone: 703-758-0190 x2156 FAX: 703-758-0941