[3840] in Kerberos
Re: key value
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Sep 15 12:18:41 1994
Date: Thu, 15 Sep 1994 12:08:37 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: brian@nothing.ucsd.edu
Cc: kerberos@MIT.EDU
In-Reply-To: Brian Kantor's message of Wed, 14 Sep 1994 15:58:35 -0700,
<199409142258.PAA13240@nothing.ucsd.edu>
Date: Wed, 14 Sep 1994 15:58:35 -0700
From: brian@nothing.ucsd.edu (Brian Kantor)
I have two krb5 databases on two different machines, with the same
master password and the same principal with the same password in the
two databases. One is krb5b3 and the other is krb5b4p2.
Since the realms, principals, and passwords are the same in both cases,
would it be reasonable to expect a database dump to display the same
hex value for the key on both systems?
They aren't the same. Why might this be?
Starting in beta4 patchlevel 1, the master key version number (and all
key version numbers) are created starting at 1, instead of 0. The
reason for this is that it's the simplest way of fixing an ASN.1
encoding problem deep in the guts of the Kerberos library.
Essentially, the problem is that ASN.1 distinguishes between sending an
integer 0, and not sending an optional field. But in a C structure,
there is no such distinction (unless you manually set one up, and we
didn't). The key version number is an optional field, but according to
the Kerberos V5 RFC, it must always be sent if the key is derived from a
key in the Kerberos database. So, our implementation was incorrectly
leaving out an optional field. Now, this is no big deal, since most
implementations will fill in a zero when an optional field is omitted;
so, this problem won't cause any problems in beta 3 implementations.
However, it's still not right, which is why we made the change in beta
4.
- Ted
