The following behavior was noticed at Connectathon against MIT 1.2.2:

1. The Java client sends an AS-REQ listing the enc types
{DES-CBC-MD5, DES-CBC-CRC} as supported.

2. The MIT KDC picks DES-CBC-MD5 as the enc type to use and returns
a TGT with a session key using this enc type.

3. The Java client sends a TGS-REQ using the above session key,
but with DES-CBC-CRC type encryption.

4. The KDC returns an error saying "KDC has no support for encryption
type"

The same problem might also have been noticed with a Heimdal KDC,
although with the return error "Integrity check on decrypted field
failed".

(When using the SEAM or Windows 2000 KDC, the TGS seemed to be
more forgiving since the same key could be used for both
algorithms. It probably uses EncryptedData.etype to determine
what algorithm should be used as opposed to using the session key
type.)