[4394] in Kerberos
Re: What new in beta 4?
daemon@ATHENA.MIT.EDU (Donald Sharp)
Wed Dec 21 12:39:57 1994
Date: Wed, 21 Dec 1994 12:16:14 -0500
From: Donald Sharp <cc32859@vantage.FMR.Com>
To: Jim-Miller%suite.com@stowe.FMR.Com
Cc: kerberos%MIT.EDU@stowe.FMR.Com
The following is a compilation of the release announcement from
Theodore T'so for the various Beta 4 releases:
Kerberos V5 Beta 4. This release contains several new features, including:
* Configure scripts built from autoconf, to eventually supplant
the imake build system.
* A kadmin server which speaks the Kerberos V4 admin protocol,
but which modifies the V5 database. (For backwards
compatibility; only lightly tested so far.)
* A ksu client.
* Updated GSSAPI code to follow changes in the evolving Internet
draft.
* The most recent version of telnet.
* Fixed inter-realm handling so that it actually works
* Updated documentation, including a significantly improved API
manual.
* Lots of miscellaneous bug fixes and improvements.
Kerberos V5 Beta 4 patchlevel 2:
This new release has numerous bug fixes, and should be much easier
to compile on a wide variety of platforms than patchlevel 1.
Platforms which were used in-house to test patchlevel 2 include
Ultrix, SunOS, Solaris, and Linux.
There are two major new features of note in this release. This
first is the addition of hand-coded ASN.1 parsers to replace the
ISODE-generated ASN.1 parsers that has been used in prior versions
of Kerberos V5. We will be removing support for the
ISODE-generated parsers once we have done further testing to
satisfy ourselves that the hand-conded parsers are a complete
replacement for the ISODE-generated parsers.
The second major feature to note is the elimination of imake and
its associated files in this release. (We *can* stamp out imake
in our lifetime). Concurrent with this, all directories (with the
exception of the tests directory) has been migrated to use GNU
autoconf.
Kerberos V5, Beta 4 patchlevel 3:
There have been numberous bugs fixed in pl3; the most significant
of which is a that a very severe security hole related to
inter-realm authentication has been fixed. The hole was noticed
by myself and Cliff Neumann, and CyberSAFE corporation donated the
code necessary to fix it. Many thanks to CyberSAFE and to Tony
Andrea at CyberSAFE, who actually performed the coding.
pl3 should be more portable; we've been gradually incorporating
portability patches submitted to us, as well as increasing the
number of platforms which we use in-house to test things out.
There are still a whole host of portability fixes which haven't
made it in yet, so please be patient. appl/bsd is perhaps the
worst offender in this regard; I intend to see that it is
significantly improved for pl4.
Please note that pl3 use a new database encoding format, version
2.0. pl3 can read Kerberos database entries created by previous
versions (both 1.0 and 0.0), but will only write database entries
in the new format. Hence, while you are testing pl3, please make
sure that you do not modify your Kerberos database, using either
kdb5_edit or the kadmin server, until you are sure that you will
not need to back out pl3.
Alternatively, you can save a copy of pl2's kdb5_edit program, and
you can then backout to the pl2 format by using the pl3 kdb5_edit
to dump the database in ASCII format, and then using the pl2
kdb5_edit to reload the database.
Once you are satisified with pl3, I suggest that you dump the
database using kdb5_edit's dump_db command, and then reload it
using kdb5_edit'sl oad_db command. This will ensure that all
database records are rewritten using the newest format. This is
an important thing to do, since future releases additional
database format changes, and the backwards compatibility support
for database entry versions 1.0 and 0.0 will eventually be phased
out.
IMPORTANT NOTE
==============
Currently, all of the MIT implementations of the Kerberos protocol are
not fully compliant with the Kerberos RFC. Specifically, we do not
implement the DES w/ MD5 checksum which is required by the RFC; this was
an oversight, where the RFC got updated but the code never did. This
problem still exists in the Beta 4 release, although I expect to have
this fixed in a patch release as soon as possible --- I didn't have time
to have it fixed for this release. I believe that we can fix this with
minimal compatibility impacts with previous versions; vendors
contemplating shipment of this code as product should wait for the patch
release or contact us for futher details.
- Ted
--------
Don Sharp cc32859@vantage.fmrco.com
Fidelity Investments (617) 570-3905
82 Devonshire St. A2A
Boston, MA 02109
