Re: MIT & Heimdal playing together?

[ms419@freezone.co.uk]

On Oct 18, 2004, at 1:28 PM, Benjamin P Myers wrote:
> On Sunday 17 October 2004 04:42 pm, ms419@freezone.co.uk wrote:
>> 	fis:~# kstash
>> 	Master key:
>> 	Verifying - Master key:
>> 	kstash: writing key to `/var/lib/heimdal-kdc/m-key'
>> 	fis:~# ssh tor kdb5_util dump -b7 > datatrans
>> 	root@tor's password:
>> 	fis:~# scp tor:/etc/krb5kdc/stash .
>> 	root@tor's password:
>> 	fis:~# hprop -m stash -d datatrans --source=mit-dump -n | hpropd -n
>
> Hmm.  Could you try
>  'hprop -m stash -d datatrans --source=mit-dump --decrypt -n'?
>
> You might then be able to worry about re-encrypting with a different 
> master
> key in a later step.  In my recollection, I copied my mit kdc's master 
> key to
> /var/heimdal/m-key directly, used hprop to do the decryption, deleted 
> the
> master key once I was done, and didn't use kstash at all.  
> Unfortunately, I
> don't remember the exact arguments to hprop that made it work.
>
> Good Luck,
> Ben

Thanks very much, Ben, for the tip & the luck: Each was very important!

Unfortunately, I encounter these errors:

	fis:~# hprop -m stash -d datatrans --source=mit-dump -D -n | hpropd -n
	hprop: hdb_unseal_keys_mkey: Decrypt integrity check failed
	hprop: hdb_unseal_keys_mkey: Decrypt integrity check failed
	hprop: hdb_unseal_keys_mkey: Decrypt integrity check failed
	[...]
	fis:~#

& no keys are propagated:

	fis:~# kadmin -l
	kadmin> list *
	kadmin>

I gather there is a problem with the keys' checksums:

	fis:~# gdb hprop
	[...]
	(gdb) dir heimdal-0.6.3/lib/krb5/
	Source directories searched: heimdal-0.6.3/lib/krb5:$cdir:$cwd
	(gdb) run -m stash -d datatrans --source=mit-dump -D -n
	Starting program: /usr/sbin/hprop -m stash -d datatrans 
--source=mit-dump -D -n
	[...]
	Breakpoint 2, verify_checksum (context=0x10017050, crypto=0x0, 
usage=1212432981, 	data=0x10018da8, len=32, cksum=0xbffff740) at 
crypto.c:1915
	1915        if(c.checksum.length != cksum->checksum.length ||
	(gdb) l
	1910        if (ret)
	1911            return ret;
	1912
	1913        (*ct->checksum)(context, dkey, data, len, usage, &c);
	1914
	1915        if(c.checksum.length != cksum->checksum.length ||
	1916           memcmp(c.checksum.data, cksum->checksum.data, 
c.checksum.length)) {
	1917            krb5_clear_error_string (context);
	1918            ret = KRB5KRB_AP_ERR_BAD_INTEGRITY;
	1919        } else {
	(gdb) bt
	#0  verify_checksum (context=0x10017050, crypto=0x0, usage=1212432981, 
	data=0x10018da8, len=32, cksum=0xbffff740) at crypto.c:1915
	#1  0x0ff892f8 in verify_checksum (context=0x10017050, crypto=0x0, 
	usage=1212432981, data=0x10018da8, len=32, cksum=0xbffff740) at 
crypto.c:1913
	#2  0x0ff8b34c in krb5_decrypt (context=0x10018d00, crypto=0xbffff6a4, 
usage=0, 	data=0x1ee88, len=268538232, result=0x1eea8) at crypto.c:3206
	#3  0x0ffd8c0c in hdb_unseal_keys_mkey (context=0x20, ent=0x48444255, 
	mkey=0x10018da8) at mkey.c:395
	#4  0x10002a50 in ?? ()
	(gdb) p c.checksum.length
	$1 = 20
	(gdb) p cksum->checksum.length
	$2 = 20
	(gdb) p memcmp(c.checksum.data, cksum->checksum.data, 
c.checksum.length)
	$3 = -1
	(gdb) n
	1917            krb5_clear_error_string (context);
	(gdb) n
	1918            ret = KRB5KRB_AP_ERR_BAD_INTEGRITY;
	(gdb)

By bypassing verify_checksum, I managed to propagate all the keys to 
the Heimdal database, but sure enough, they are broken:

	fis% kinit
	jablko@LAT's Password:
	kinit: Password incorrect
	fis%

 From this I gather the keys aren't being correctly decrypted, but I 
can't figure out where the problem lies.

Any help or suggestions much appreciated!

Also, I overcame a different problem:

	fis:~# hprop -m stash -d datatrans --source=mit-dump -D -n | hpropd -n
	hprop: hdb_read_master_key: End of file
	fis:~#

This turned out to be an endianness problem. The stash was written on 
an i386 machine; I'm running hprop on a powerpc. The MIT stash isn't 
endian clean: 
http://article.gmane.org/gmane.comp.encryption.kerberos.devel/4

Hope that helps someone in the future.

Thanks!

Jack