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

[Tom Yu]

>>>>> "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