MIT vs. Heimdal/Sun: "Decrypt integrity check failed"

[Henry B. Hotz]

In Heimdal the way to do this is:

1) Create the principal with kadmin add -r <princ>
(IIRC this creates a principal without the multiple key salt's because  
there is no corresponding password, and therefore no applicable key  
salt.  You get a principal with a better key and less confusion.)

2) kadmin del_enctype <...>
(Delete the enctypes that aren't supported by your target platform.  If  
you're not sure try deleting all of them except des-cbc-md5.)

3) kadmin ext -k <keytab> <princ>
And securely copy the keytab where it belongs.  Note you have to do  
this step last because step 2 changes the kvno of the key.

I think you can do this in one step with the Heimdal ktutil on the  
remote machine.  I've done the above to get keytabs for Solaris that  
work fine, and I never installed Heimdal on the Solaris client (until  
much later).

On Jun 3, 2004, at 10:53 PM, kerberos-request at MIT.EDU wrote:

> Date: Fri, 04 Jun 2004 00:01:32 -0400
> From: Tom Yu <tlyu at MIT.EDU>
> To: kerberos at MIT.EDU
> Subject: Re: MIT vs. Heimdal/Sun: "Decrypt integrity check failed"
> Message-ID: <ldvwu2oj7j7.fsf at cathode-dark-space.mit.edu>
> In-Reply-To: <slrncbuaeg.sbn.kapet at frodo.hrz.tu-chemnitz.de> (Karsten
>  Petersen's message of "Thu, 3 Jun 2004 13:38:25 +0000 (UTC)")
> References: <slrncbtqk2.sbn.kapet at frodo.hrz.tu-chemnitz.de>
> 	<slrncbuaeg.sbn.kapet at frodo.hrz.tu-chemnitz.de>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 8
>
>>>>>> "kapet" == Karsten Petersen <kapet at hrz.tu-chemnitz.de> writes:
>
> kapet> Karsten Petersen wrote:
>>> we have a KDC (Heimdal 0.6.2) running for a test.  kinit works, it
>>> successfully provides users with krb4 and krb5 TGTs.
> kapet> Because we want to migrate our AFS to Heimdal Kerberos5, we  
> have the
> kapet> AFS-salt (and the v4-salt) activated on the kdc.
>
>>> 0. A service principal was created on the KDC.
> kapet> And this principal got by default not only v5-salted keys, but  
> also v4-
> kapet> and AFS-salted.
>
> I suspect this is at least part of your problem.
>
>>> The keytab contains 10 different encryptions of the service key.
> kapet> 3 x des-cbc-crc
> kapet> 3 x des-cbc-md4
> kapet> 3 x des-cbc-md5
> kapet> 1 x des3-cbc-hmac
>
>>> 1. GSS client- and server-app on the GSS test machine both use MIT
>>> Kerberos5 1.3.1.  This works like a charm.
> kapet> Yeah, because it took the des3-cbc-hmac key.  If forced to some  
> other
> kapet> encryption type, it did not work too.
>
> When you set up the des3-cbc-hmac key, did you only specify one salt
> type?  It looks like that is the case.
>
> kapet> After deleting the principal on the server, recreating it only  
> with
> kapet> v5-salted keys and exporting it again - everything worked.
>
>>> So where is the problem?
> kapet> It seems to me that MIT Kerberos5 1.3.1 is not able to handle  
> keytab
> kapet> files with several keys of the same encryption type (but  
> different
> kapet> salts).
> kapet> Or is there some magical krb5.conf option I did not find yet?
>
> The Kerberos protocol has no inherent way to tell the application
> server which of several keys for the same encryption type to use to
> decrypt the ticket.  The ticket only indicates thet encryption
> algorithm, and not which of several keys suitable for the encryption
> algorithm.
>
> The code that reads the request from the client will search the keytab
> for the first key which matches the encryption type and kvno specified
> in the ticket.  If this is not the same key which the KDC used to
> encrypt the ticket, you will get an error.  The MIT KDC will pick the
> first listed key of the highest kvno in the principal entry for
> encrypting the ticket.  I'm not sure what Heimdal does in this case.
>
> If you intend a principal to be used as a service principal, it is
> probably safest to ensure that it only has one key per encryption
> type.
>
> It could be argued that the rd_req operation should attempt to use all
> keys in the keytab which match the encryption type and kvno of the
> ticket, but this is not currently done in the MIT code.
>
> ---Tom
>
------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu