[265] in Kerberos-V5-bugs
Re: Porting problems in V5
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Wed Dec 9 23:12:32 1992
Date: Wed, 9 Dec 92 23:11:50 EST
From: tytso@Athena.MIT.EDU (Theodore Ts'o)
To: kerberos@Athena.MIT.EDU, krb5-bugs@Athena.MIT.EDU
Cc: harvard!scubed!riipsdev.waterloo.ncr.com!ajlill@eddie.mit.edu
In-Reply-To: Tony Lill's message of Tue, 08 Dec 92 16:46:40 -0500,
Date: Tue, 08 Dec 92 16:46:40 -0500
From: Tony Lill <harvard!scubed!riipsdev.waterloo.ncr.com!ajlill@eddie.mit.edu>
My current solution(hack) is to adjust the value on the DOS machine so
it's based on the UNIX epoch. A better solution would be to encode the
timestamp in "Universal" time, as the rest of the timestamps are, or
at least, put a tm-like structure instead of the long. Comments?
Your solution of adjusting the value so that it's based on the UNIX epoch is
the right one. The KRB5_PADATA_ENC_TIMESTAMP was a quick hack I threw
together just before the beta two release came out, since people wanted
the functionality and I didn't want the delay (and pain) of messing with
ISODE.
Future releases will have a more carefully constructed
preauthentication, where the primary difference will be that it will use
politically correct ASN.1 encoding rules.
The second problem is more serious. In the ticket requests and
responses is the nonce field. From what I could gather, this is used
for two purposes, as a unique identifier, and as as a base to check if
the starttime in the reply is within the allowed clock skew. The
problem is that in the ASN.1 protocol, it is described as INTEGER.
Pepsy (from isode 8.0) turns that into an int when it creates it's
tables. Internally to kerberos, it is a krb5_int32. When the reply
comes in, the nonce has been converted from a long to an int and back,
so it doesn't match with what went out. What I'm planning to do for
now is to only compare the low word on the nonce when I check the
reply, but either pepsy must be fixed, or the kdc requests must be for
a "proper" solution. Comments?
Is the problem that an int on your machine is 16 bits, and not 32 bits?
That's a toughie; off-hand, I don't know if you can convince ISODE to
use 32-bit longs for INTEGERS, or whether it would involve diving into
the ISODE source code.
I've long wanted to replace the ISODE code with something that would be
more easily maintained --- even hand-coded ASN.1 routines would probably
be easier --- but that's a task which I haven't had time to tackle
because I've always had higher priority items on my queue. Perhaps
someone (maybe you) would be willing to try it. While this is a pretty
big task, it may or may not be simpler than trying to "fix" pepsy.
- Ted
