MIT is committed to assuring that its Kerberos V5 referenceimplementation is Y2K compliant. To that end, we have audited ourcodebase looking for Y2K problems, and have fixed those problems whichwe have found. These fixes have been reflected in the latest 1.0release, which is version 1.0.6.
The Y2K bugs discovered in the 1.0.5 release were not especiallysignificant. None of the bugs caused security breaches, or wouldcause the Kerberos authentication process to fail. In addition noproblems were found in the Kerberos and GSSAPI library functions whichwould be used by client/server applications programs. Most of the Y2Kissues were in how the year field timestamp of Kerberos server logfiles 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 parsingdates in 21st century (although specifying just a time and no date wouldwork correctly), and it would prevent the KDC configuration file codefrom 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 havecaused the non-standard MDTM ftp protocol element to fail, thuspreventing the non-standard ftp restart functionality from workingproperly. 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.6release.
Please note the following caveats:
1) Kerberos V5 depends on the Y2K compliance of the underlyinghardware and operating system on which is running. In particular, theANSI standard C library functions must be Y2K compliant.
2) MIT makes the Kerberos V5 reference implementation available for useat no cost as a public service. Since we make no money (and yet investmuch 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 usingKerberos V5, either due to Y2K bugs or any other problems. Please notein particular the following excerpt from our Copyright PermissionNotice:
M.I.T. makes no representations about the suitability ofthis software for any purpose. It is provided "as is" withoutexpress or implied warranty.
That being said, we use Kerberos V5 in-house, and we have everyintention to continue business operations past the year 2000. SinceKerberos V5 is used to authenticate our SAP R/3 accounting system,you may be sure that we treat Kerberos V5's continued operation overthe 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 brancheswere caused by different platform ports. There are at least 2 or 3separate Kerberos V4 ports to the Macintosh, for example. We haveused Cornell's kclient as the standard Macintosh Kerberos library,but (a) there are a few others, and (b) we can make no guaranteesregarding the level of support which Cornell will provide for theMacintosh Kerberos library.
Some of these versions have been only lightly tested; some we havenot tested at all. In some cases, a special set of libraries mightbe used by a single business office, and we might not even know thatthey are using a non-standard Kerberos implementation.
We do not expect Kerberos V4 users to encounter any significantY2K related bugs. Kerberos V4 software is unlikely to cause anysecurity breaches or any failures of the authentication process as aresult of Y2K related bugs. The bugs which users are likely toencounter are display related. For example, one bug affects the waythat the year field timestamp of Kerberos server log files would beprinted (i.e., 99, 100, 101 instead of 1999, 2000, 2001), inparticular in the Kerberos V4 compatibility server.
However, some implementations of Kerberos V4 set the principalexpiration date of principals to some time in December 1999,which may cause problems. Users of Kerberos V4 KDCs aresuggested to move to using a Kerberos V5 KDC in compatibiltymode, and to clear the expiration dates on the principals intheir databases.
Although MIT's Kerberos V4 distribution does not contain an ftpdistribution, there are others that do. Those users will probablyencounter problems in the ftp code. This Y2K bug would cause thenon-standard MDTM ftp protocol element to fail, thus preventing thenon-standard ftp restart functionality from working properly. Standard ftp uploads and downloads would continue to work. This Y2Kbug was inherited from the BSD ftp/ftpd programs and has beenobserved in unremediated Kerberos V5 systems. We have not tested ourKerberos V4 systems for this problem.
MIT is no longer doing any development on Kerberos V4. Ourapplications which require continued Kerberos services are beingmigrated to Kerberos V5, for which a Y2K compliant release (version1.0.6) is now available. If you are unable to migrate to KerberosV5, we suggest that you test any applications which depend onKerberos V4 in an appropriate test environment. MIT maintains aKerberos-2000 environment for use by developers within the MITcommunity. Kerberos users who do not have an MIT affiliation maywish to use this service as a model for setting up their own testingenvironment.
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 everyintention to continue business operations past the year 2000. Sinceour development efforts have shifted to Kerberos V5 however, we areunable to commit resources to V4 remediation. Any Y2K related bugsin Kerberos V4 which impair any of MIT's critical systems will bedealt with. Although we might choose to make any resulting V4updates available to the public, they will likely only apply to thehardware platforms in use at MIT which have encountered Y2K problems.We are unlikely to provide updates to fix any Y2K related problemswhich do not cause failures in MIT's critical systems.