ETYPE-INFO & AS-REP questions

[Tom Maher <tmaher@watson.org>]

So, according to the most recent version of the kerberos 5 clarification
draft I can find

http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-clarifications-07.txt

section 3.1.3 claims:

   When the AS server is to include pre-authentication data in a KRB-
   ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-INFO,
   if the etype field of the client's AS-REQ lists at least one "newer"
   encryption type.  Otherwise (when the etype field of the client's AS-
   REQ does not list any "newer" encryption types) it MUST send both,
   PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for each
   enctype).  A "newer" enctype is any enctype first officially
   specified concurrently with or subsequent to the issue of this RFC.
   The enctypes DES, 3DES or RC4 and any defined in [RFC1510] are not
   "newer" enctypes.

In recent heimdal snapshots, in kdc/kerberos5.c, towards the end of
as_rep(), the KDC does just that.  If the client's AS-REQ contains a newer
enctype (e.g., aes256), ETYPE-INFO2 is sent.  If AS-REQ has an older enctype
(e.g., des-* or des3), KDC sends both ETYPE-INFO and ETYPE-INFO2.

My problem is that when the Solaris 10 kinit receives an AS-REP that
containts ETYPE-INFO2, it dumps core.  I've already filed a ticket with Sun
about this (kinit shouldn't core dump, ever).  But oddly enough, the MIT
krb5 1.4.1 KDC seems to obey the draft as well (relevent code is
src/kdc/kdc_preauth.c), but doesn't cause a core dump in Solaris 10 kinit.

Is this a heimdal bug, or am I misreading the MIT code?  Also, is there a
more recent version of the draft that I just haven't read?

-- 
Tom Maher <tmaher@watson.org>