gregh@aplcomm.JHUAPL.EDU (Robert G. Hollingsworth) (02/19/91)
Several months ago, I sent out a query to this group about vendor support for Kerberos. I'd like to run Kerberos on some of our hosts, but this requires that Kerberized client software on a variety of hosts. The only way I'm going to be able to run Kerberos here is if I can I can get 'out of the box' Kerberos clients that require minor configuration changes. I received some feedback from my original posting that hinted that I might someday be able to obtain Kerberized client software for Macs and PC's, and that Ultrix 4.0 was being shipped with Kerberos. Sounded like there might be a chance of running it here someday. Recently I have heard that DEC is taking Kerberos, incorporating RSA into it, and redistributing it widely. I read through their literature (I'm no cryptography expert), it sounded like a reasonable addition to me. Now I fear that I'm going to have a set of DEC hosts that run RSA Kerberos, and a set of client systems that run standard Kerberos. Can anyone comment on what I can expect to see in the future in the Kerberos arena. Will we ever be able to use Kerberos in our large heterogeneous network? Greg
jis@MIT.EDU (Jeffrey I. Schiller) (02/19/91)
DEC will be offering an authentication system which I believe
will be called "SPX" (formerly known as Sphinx). SPX is not Kerberos
with RSA added. It is a separate system which is based on RSA Public
Key Encryption.
SPX offers a lot of the same features of Kerberos, but is not
a Kerberos spinoff.
The good news is that the SPX developers and the Kerberos
developers have been in touch with each other. Our hope is to offer a
generic application programmer's interface (Generic API) that will
work with either SPX or Kerberos. This would also support the linking
of applications so as to allow them to operate in either an SPX or
Kerberos environment.
We have also begun preliminary internal discussions on how to
integrate public key technology directly into Kerberos. For now this
is a back burner project at MIT (V5 needs to get out the door!).
... Can
anyone comment on what I can expect to see in the future in the
Kerberos arena. Will we ever be able to use Kerberos in our large
heterogeneous network?
Expect to see Kerberos enhanced to support Public Key at some point.
Ideally I would hope to see the Kerberos and SPX technologies merged
into one comprehensive (and compatible) system. How we do this, I
don't rightly know... but I think it is in everyone's interest. [Note:
I *do* expect to see the Generic API mentioned above, getting the
protocols themselves to interact is a tougher goal, and is what I am
referring to in this paragraph.]
-Jeffcjr@UUNET.UU.NET (Chris Riddick) (02/19/91)
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
kannan@SEJOUR.NAC.DEC.COM (02/20/91)
Chris Riddick writes : > 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 Sphinx will be publicly available. Digital has already licensed RSA public key technology and Sphinx embodies the RSA patent. Therefore users don't need to license RSA for Sphinx. However, Sphinx users are not authorized to use the RSA algorithm beyond the intended use in the Sphinx (SPX) software. -kannan
pato@APOLLO.COM (Joe Pato) (02/20/91)
Chris Riddick writes :
> 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
Sphinx will be publicly available.
kannan,
Is Sphinx a DEC product for VMS and Ultrix or is Digital going to support
Sphinx on HP/UX, Sun OS, AIX, MVS, MS DOS, Domain/OS etc.? The public
availability of Kerberos exists because MIT will freely distribute the Kerberos
source code and because a number of vendors have independently chosen to
support commercial version. In addition the OSF DCE will provide a common
industrial version of Kerberos V5 with generic interfaces for implementing
authenticated RPC applications.
-- Joe Pato
Cooperative Computing Division
Hewlett-Packard Company
pato@apollo.hp.com
-------kannan@SEJOUR.LKG.DEC.COM (02/27/91)
Joe Pato writes : >Is Sphinx a DEC product for VMS and Ultrix or is Digital going to support >Sphinx on HP/UX, Sun OS, AIX, MVS, MS DOS, Domain/OS etc.? The public >availability of Kerberos exists because MIT will freely distribute the Kerberos >source code and because a number of vendors have independently chosen to >support commercial version. In addition the OSF DCE will provide a common Sphinx has been ported to a small number of platforms and we encourage anyone to port our freely distributed source code to other platforms, and use Sphinx inhouse. If those who port Sphinx send us diffs, we are willing to distribute these changes with the Sphinx kit. Distribution of this software is authorized only if no profit or remuneration of any kind is received in exchange for such distribution. Commercial distribution is still an open question which needs to be discussed with us. -kannan
bede@LINUS.MITRE.ORG (02/27/91)
From: kannan@sejour.lkg.dec.com
Date: Tue, 26 Feb 91 14:02:16 EST
[ . . . ]
Sphinx has been ported to a small number of platforms and we encourage anyone
to port our freely distributed source code to other platforms, and use Sphinx
inhouse.
If those who port Sphinx send us diffs, we are willing to distribute these
changes with the Sphinx kit. Distribution of this software is authorized
only if no profit or remuneration of any kind is received in exchange for
such distribution. Commercial distribution is still an open question which
needs to be discussed with us.
Could you please supply some functional details about how people at
nonprofit/educational organizations might acquire your freely
distributed Sphinx source code?
-Bede McCall
The MITRE Corporation
Mail Stop A114
Burlington Road
Bedford, Massachusetts 01730 (617) 271-2839
Internet: bede@mitre.org
uucp: {decvax,philabs}!linus!bedekannan@SEJOUR.LKG.DEC.COM (03/05/91)
>Could you please supply some functional details about how people at >nonprofit/educational organizations might acquire your freely >distributed Sphinx source code? Send mail to "sphinx-request@crl.dec.com" for more information. A SPX (formally known as Sphinx) mailing list has been created for discussions related to the deployment of SPX public key based authentication service. Please send contributions to the list at "sphinx@crl.dec.com". Administrative requests, e.g., additions to or deletions from the list, should be sent to "sphinx-request@crl.dec.com". -kannan