From: ggm@brolga.cc.uq.oz.au (George Michaelson)
Subject: is kadmind exportable as a binary? if so, begging letter.
Organization: Prentice Centre, University of Queensland
Date: Thu, 13 Aug 1992 02:31:24 GMT


(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
Xref: sparky comp.protocols.kerberos:586 comp.unix.ultrix:6208