Ticket History #2155: krb5-1.3.x testing with default_tgs_enctypes in krb5.conf

With krb5-1.3.2-beta2 and krb5-1.3.1 on Solaris 5.7 if the krb5.conf has
default_tgs_enctypes = des-cbc-crc kadmin fails. It works with krb5-1.2.8.

I think this is a similiar problem to what I was seeing with KfW. My
circumvention it to drop the use of the default_*_enctypes.

It appears that in 1.3.1 or 1.3.2-beta when the AS_AS_REQ is issued the
default_tgs_enctypes is ignored.

With or without the default_tgs_enctypes It looks like the KDC issues a ticket:

Jan 23 13:43:05 chimera.ctd.anl.gov krb5kdc[324]: AS_REQ (4 etypes {16 23 3 1})
146.137.180.252(88): ISSUE: authtime 1074886985,etypes {rep=16 tkt=16 ses=16},
b17783/admin@KRB5.ANL.GOV for kadmin/admin@KRB5.ANL.GOV

But once the ticket is received, it fails as the ticket has rep=16 and ses=16
which is not in the default_tgs_enctypes.

/krb5/sbin/kadmin -r KRB5.ANL.GOV -p b17783/admin@KRB5.ANL.GOV
Authenticating as principal b17783/admin@KRB5.ANL.GOV with password.
Password for b17783/admin@KRB5.ANL.GOV:
kadmin: GSS-API (or Kerberos) error while initializing kadmin interface


With krb5-1.2.8 it works as expected:

With the default_tgs_enctypes = des-cbc-crc:

Jan 23 13:53:23 chimera.ctd.anl.gov krb5kdc[324]: AS_REQ (1 etypes {1})
146.137.180.252(88): ISSUE: authtime 1074887603, etypes {rep=1 tkt=16 ses=1},
b17783/admin@KRB5.ANL.GOV for kadmin/admin@KRB5.ANL.GOV


Without the default_tgs_enctypes:

Jan 23 13:54:23 chimera.ctd.anl.gov krb5kdc[324]: AS_REQ (3 etypes {16 3 1})
146.137.180.252(88): ISSUE: authtime 1074887663, etypes {rep=16 tkt=16 ses=16},
b17783/admin@KRB5.ANL.GOV for kadmin/admin@KRB5.ANL.GOV


The user, krbtgt and kadmin/admin all have both des-cbc-crc and des3-cbc-sha1
keys.



--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

The following is a comment from Doug from a thread on why he is unable
to delegate tickets vis GSSAPI from Kerberos for Windows. We originally
thought the problem was caused by the Ticket importation via the new
MSLSA krb5_ccache type. However, this makes it clear that the problem
is elsewhere:



By removing "default_tkt_enctypes" and "default_tgs_enctypes" in the
krb5.ini,
gssapi can get forwardable TGTs. I think the problem may be in the
fwd_tgt.c
where it is trying to guess what etype the host can handle.

In the following 2 examples the TGT to be forwarded is obtained from the
MS AD. The hosts are in the MIT realm.

This is strange because on one host the host principal in the MIT realm
has only a des-cbc-crc key, and this is what was in the "default_*_enctypes"
and that is is what is finally returned in the forwarded TGT. But it
only works if I remove the "default_*_enctypes"

In the other host the host principal has both a 3des and a des-cbc-crc key,
yet the forward TGT has RC4-HMAC. The system is running krb5-1.2.8 and
does not understand rc4-hmac! (This system needs to be updated to 1.3.x)

I believe that the fwd_tgt.c code is confused. But there is no
debugging output, and the gssapi silently continues if delegation
fails. It may have been confused, because the imported TGT had RC4-HMAC,
which was not in its list of "default_*_enctypes". If I let Leash
get the tickets, it ownered the "default_*_enctypes" and gets an initial
TGT with des-cbc-crc.

So I am running without the "default_*_enctypes" for now.

Doug

After an evaluation of the code by Sam and myself, we have concluded
that this is not a bug but an expected behavior. The default_*_enctypes
values act as filters to restrict the enctypes used.

In the case of TGTs being imported from the Windows LSA, the enctypes of
the TGTs may not adhere to the default_tgt_enctype value since MS is
unaware of it. The MSLSA ccache will return a TGT that does not match
the default_tgt_enctype specification. However, when forwarding tgts,
that code will insist on a conforming enctype for the TGT. Hence it is
rejected.

Removing the default_*_enctype specifications will allow things to work
in most situations.