MIT vs. Heimdal/Sun: "Decrypt integrity check failed"
Karsten Petersen
we have a KDC (Heimdal 0.6.2) running for a test. kinit works, it
successfully provides users with krb4 and krb5 TGTs.
But now I am trying to write a simple GSS based program and get an
error which I can not clearly classify:
0. A service principal was created on the KDC. A krb5 keytab on the
GSS test machine was created by calling Heimdal's kadmin with
"ext_keytab *hostname*". The keytab contains 10 different
encryptions of the service key. The user calling the GSS client-app
always has a clean ticket cache with only the krb5 TGT in it.
1. GSS client- and server-app on the GSS test machine both use MIT
Kerberos5 1.3.1. This works like a charm. I will use this GSS
server-app for all further tests.
2. The GSS client-app on another machine, also using MIT Kerberos5
1.3.1, works too.
3. The GSS client-app using Heimdal 0.6.2 on just another Linux machine
does not work.
4. The GSS client-app on SunOS 5.8 (using Sun's GSS-implementation) does
not work either.
The GSS server-app shows the same error message for 3. and 4.:
gss_accept_sec_context: Miscellaneous failure
gss_accept_sec_context: Decrypt integrity check failed
(The GSS client-app then gets an error message from the server and quits
also.)
I traced the GSS server-app (during 3.) and found it calculating a MD5
sum (it was using des-cbc-md5) which came out different than the one
from the client.
So where is the problem?
Thanks in advance,
Karsten Petersen
--
Dipl. Inf. Karsten Petersen, Universitaetsrechenzentrum, TU Chemnitz
E-Mail: ka...@hrz.tu-chemnitz.de
Telefon: (0371) - 531 - 1725
Arbeitsplatz: Strasse der Nationen 62 // Raum 1/B301.A
Karsten Petersen
after some more testing and playing around with krb5.conf directives I
believe that I have found the problem:
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.
Because we want to migrate our AFS to Heimdal Kerberos5, we have the
AFS-salt (and the v4-salt) activated on the kdc.
> 0. A service principal was created on the KDC.
And this principal got by default not only v5-salted keys, but also v4-
and AFS-salted.
> A krb5 keytab on the GSS test machine was created by calling Heimdal's
> kadmin with "ext_keytab *hostname*".
This exported all keys to the keytab, which therefore ended up with
several keys per encryption type.
> The keytab contains 10 different encryptions of the service key.
3 x des-cbc-crc
3 x des-cbc-md4
3 x des-cbc-md5
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.
Yeah, because it took the des3-cbc-hmac key. If forced to some other
encryption type, it did not work too.
After deleting the principal on the server, recreating it only with
v5-salted keys and exporting it again - everything worked.
> So where is the problem?
It seems to me that MIT Kerberos5 1.3.1 is not able to handle keytab
files with several keys of the same encryption type (but different
salts).
Or is there some magical krb5.conf option I did not find yet?
Best wishes,
Tom Yu
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
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Alberto Patino
> Hi,
>
> after some more testing and playing around with krb5.conf directives I
> believe that I have found the problem:
>
> 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.
> Because we want to migrate our AFS to Heimdal Kerberos5, we have the
> AFS-salt (and the v4-salt) activated on the kdc.
>
> > 0. A service principal was created on the KDC.
> And this principal got by default not only v5-salted keys, but also v4-
> and AFS-salted.
>
> > A krb5 keytab on the GSS test machine was created by calling Heimdal's
> > kadmin with "ext_keytab *hostname*".
> This exported all keys to the keytab, which therefore ended up with
> several keys per encryption type.
>
> > The keytab contains 10 different encryptions of the service key.
> 3 x des-cbc-crc
> 3 x des-cbc-md4
> 3 x des-cbc-md5
> 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.
> Yeah, because it took the des3-cbc-hmac key. If forced to some other
> encryption type, it did not work too.
>
> After deleting the principal on the server, recreating it only with
> v5-salted keys and exporting it again - everything worked.
>
> > So where is the problem?
> It seems to me that MIT Kerberos5 1.3.1 is not able to handle keytab
> files with several keys of the same encryption type (but different
> salts).
Heimdal KDC instead of the Mit based krb5kdc.
In my case I didn't remove the encrytio types from the KDC server, but
I DO delete the extra entries from the /etc/krb5/krb5.keytab SUN-MIT
dependent file ( Because the SUN NFS use native kr5 library from MIT)
> Or is there some magical krb5.conf option I did not find yet?
>
> Best wishes,
> Karsten Petersen
________________________________________________