[2090] in Kerberos
is kadmind exportable as a binary? if so, begging letter.
daemon@ATHENA.MIT.EDU (George Michaelson)
Wed Aug 12 23:15:54 1992
Date: Thu, 13 Aug 1992 02:31:24 GMT
From: ggm@brolga.cc.uq.oz.au (George Michaelson)
To: kerberos@shelby.Stanford.EDU
(1) kadmind doesn't send encypted data on the network, it listens
for such packets instead. since it doesn't GENERATE encrypted
data, I hope a binary doesn't contravene the DES export
requirements. I already have exported product to generate the
input it requires, binary only, built into a terminal server.
Oh dear.. kadmind has to communicate the passwd update status
back.. perhaps that uses a DES encoded exchange. If so, would
that prevent export of a kadmind daemon?
(2) I have a product which refuses to parse V4 "bones" (with non-US
sourced DES re-inserted) changepw.kerberos packets. It accepts
DEC/MIPS changepw.kerberos packets, but the same V4 "bones" src
kadmind refuses to decode these once 'used' by the product to
generate an update password request to the masters kadmind.
Regrettably DEC do not supply their own kadmind.
I suspect that DEC's product actually does something less than
full encyption of the packet, but there don't seem to be
halfway house #ifdefs in the V4 bones code to cope with this.
In the code, you either do DES or your don't. In the latter
case, the DEC changepw.kerberos packet is still unparsable by
MITs kadmind.
Kpasswd works fine with the whole MIT V4 suite built and
installed on different (byte order, compiler, opsys)
architectures. Its thus self-consistent but not interoperable
with DECs kerberos or the 3rd party vendors client side code.
(3) Thus, I am seeking a BINARY of kadmind for DEC/MIPS Ultrix 4.2 which
is known to interop with DECs kerberos daemon, and changepw.kerberos
packets which it generates.
Simply installing exportable MIT V4 will not work. Nor will using
DECs supplied code, since this lacks kadmind. Nor will mixing and
matching from each.
(4) Points of information.
I have reason to suspect V5 operating in V4 backwards compat
mode also fails to satisfy the client beast.
Stateside s/w developers of the terminal server swear blind
that straight V4 works fine. They even state that MIT code is
whats incorperated into their product. However the ONLY
kerberos daemon which will take this thing beyond the
changepw.kerberos ticket exchange into asserting kadmind input
on the kerberos master... is DECs kerberos which is believed by
me to have been DEC export-lobotomized in some way.
Comments on this by DEC & MIT are welcomed!
I don't want to just pillage the various ftp sites stateside if I can avoid
this. I think sticking to the export requirements is "nicer" for everybody.
However if the interop of DEC's kerberized stuff, 3rd party code in binary
only form, and MIT export-licencable src is not there, what else can I do?
Somebody please help! The package is being installed to secure terminal
servers against sustained hacking from dial-in modem banks. US located
research agencies have already suffered as a result of this hacking, so
getting me kerberized can be seen as directly beneficial to US federal
interests!
-George
--
George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre | There's no market for
University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079 QLD Australia 4072 | -Bertold Brecht
