e-type / kvno processing in 1.8

[Tim Metz]

Greetings,

We have in our MIT KDC some legacy principals that were imported from 
another commercial Kerberos product. For kvno=0, they have an unknown 
e-type.  For kvno=1, they have an e-type "DES cbc mode with CRC-32, 
Version 4".

Under MIT versions 1.6.3 and 1.7.1, running kinit against these 
principals is functional.

Starting with MIT version 1.8 however, using the same import process for 
the principals, kinit fails as follows:

kinit -k -t /etc/krb5.keytab host/hostname.example.com
kinit(v5): KDC has no support for encryption type while getting initial 
credentials

At first pass, the problem at least has the appearance that it could be 
related to kvno processing code.  More specifically, in versions prior 
to 1.8 if a kvno=0 contained an unsupported encryption type, processing 
would continue to kvno=1 and succeed.  Starting with version 1.8, it 
looks like if kvno=0 has an unsupported e-type, processing fails, and 
does not continue on to consult kvno=1.

The full MIT information on one of these principals is included below.  
The kinit transcript above, and principal data below have had the host 
and realm data minimally sanitized.

-----------------------------------------------------------------
Principal: host/hostname.example.com at EXAMPLE.COM
Expiration date: [never]
Last password change: Tue Feb 05 14:44:00 PST 2008
Password expiration date: [none]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 32 days 00:00:00
Last modified: Tue Feb 05 14:44:00 PST 2008 (K/M at EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, DES cbc mode with CRC-32, Version 4
Key: vno 0, <Encryption type 0x0>, Version 4
Attributes:
Policy: [none]
-----------------------------------------------------------------

Probably a unique issue I'm sure, looking for input though from anyone 
with similar experience, or familiarity with the kvno processing code?

Thanks.