[1249] in Kerberos
Future of Kerberos and Vendor support
daemon@ATHENA.MIT.EDU (Chris Riddick)
Tue Feb 19 11:27:52 1991
From: nss1!cjr@uunet.UU.NET (Chris Riddick)
To: uunet!aplcomm.jhuapl.edu!greg@uunet.UU.NET
Cc: athena.mit.edu!kerberos@cjr.uunet!athena.mit.edu
Date: Tue, 19 Feb 91 10:20:15 EST
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
