MIT is committed to assuring that its Kerberos V5 reference implementation is Y2K compliant. To that end, we have audited our codebase looking for Y2K problems, and have fixed those problems which we have found. These fixes have been reflected in the latest 1.0 release, which is version 1.0.6.
The Y2K bugs discovered in the 1.0.5 release were not especially significant. None of the bugs caused security breaches, or would cause the Kerberos authentication process to fail. In addition no problems were found in the Kerberos and GSSAPI library functions which would be used by client/server applications programs. Most of the Y2K issues were in how the year field timestamp of Kerberos server log files would be printed (i.e., 99, 100, 101 instead of 1999, 2000, 2001), in particular in the Kerberos V4 compatibility server.
The most serious bug found was in date string parsing used for options; this would prevent kinit's -s (start-time) option from correctly parsing dates in 21st century (although specifying just a time and no date would work correctly), and it would prevent the KDC configuration file code from parsing the default principal expiration date in the 21st centry. Neither of these features are commonly used.
There was also a problem in the gss-ftp code. This Y2K bug would have caused the non-standard MDTM ftp protocol element to fail, thus preventing the non-standard ftp restart functionality from working properly. Standard ftp uploads and downloads would continue to work. This Y2K bug was inherited from the BSD ftp/ftpd programs.
All of the above problems have been addressed in the 1.0.6 release.
Please note the following caveats:
1) Kerberos V5 depends on the Y2K compliance of the underlying hardware and operating system on which is running. In particular, the ANSI standard C library functions must be Y2K compliant.
2) MIT makes the Kerberos V5 reference implementation available for use at no cost as a public service. Since we make no money (and yet invest much developer time) in making public releases of Kerberos V5 available, we can not be held liable if you sustain any losses as a result of using Kerberos V5, either due to Y2K bugs or any other problems. Please note in particular the following excerpt from our Copyright Permission Notice:
M.I.T. makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.
That being said, we use Kerberos V5 in-house, and we have every intention to continue business operations past the year 2000. Since Kerberos V5 is used to authenticate our SAP R/3 accounting system, you may be sure that we treat Kerberos V5's continued operation over the millenial transition with great seriousness.
The Y2K Compliance of Kerberos V4 depends on several factors. There are many different code branches. Some of the code branches were caused by different platform ports. There are at least 2 or 3 separate Kerberos V4 ports to the Macintosh, for example. We have used Cornell's kclient as the standard Macintosh Kerberos library, but (a) there are a few others, and (b) we can make no guarantees regarding the level of support which Cornell will provide for the Macintosh Kerberos library.
Some of these versions have been only lightly tested; some we have not tested at all. In some cases, a special set of libraries might be used by a single business office, and we might not even know that they are using a non-standard Kerberos implementation.
We do not expect Kerberos V4 users to encounter any significant Y2K related bugs. Kerberos V4 software is unlikely to cause any security breaches or any failures of the authentication process as a result of Y2K related bugs. The bugs which users are likely to encounter are display related. For example, one bug affects the way that the year field timestamp of Kerberos server log files would be printed (i.e., 99, 100, 101 instead of 1999, 2000, 2001), in particular in the Kerberos V4 compatibility server.
However, some implementations of Kerberos V4 set the principal expiration date of principals to some time in December 1999, which may cause problems. Users of Kerberos V4 KDCs are suggested to move to using a Kerberos V5 KDC in compatibilty mode, and to clear the expiration dates on the principals in their databases.
Although MIT's Kerberos V4 distribution does not contain an ftp distribution, there are others that do. Those users will probably encounter problems in the ftp code. This Y2K bug would cause the non-standard MDTM ftp protocol element to fail, thus preventing the non-standard ftp restart functionality from working properly. Standard ftp uploads and downloads would continue to work. This Y2K bug was inherited from the BSD ftp/ftpd programs and has been observed in unremediated Kerberos V5 systems. We have not tested our Kerberos V4 systems for this problem.
MIT is no longer doing any development on Kerberos V4. Our applications which require continued Kerberos services are being migrated to Kerberos V5, for which a Y2K compliant release (version 1.0.6) is now available. If you are unable to migrate to Kerberos V5, we suggest that you test any applications which depend on Kerberos V4 in an appropriate test environment. MIT maintains a Kerberos-2000 environment for use by developers within the MIT community. Kerberos users who do not have an MIT affiliation may wish to use this service as a model for setting up their own testing environment.
Please note the following caveats:
M.I.T. makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.
That being said, we use Kerberos V4 in-house, and we have every intention to continue business operations past the year 2000. Since our development efforts have shifted to Kerberos V5 however, we are unable to commit resources to V4 remediation. Any Y2K related bugs in Kerberos V4 which impair any of MIT's critical systems will be dealt with. Although we might choose to make any resulting V4 updates available to the public, they will likely only apply to the hardware platforms in use at MIT which have encountered Y2K problems. We are unlikely to provide updates to fix any Y2K related problems which do not cause failures in MIT's critical systems.