Re: heimdal 1.0.1 w2k interop

[Andy Polyakov <appro@fy.chalmers.se>]

>> - w2k can parse only PA_ENCTYPE_INFO structure, while heimdal fails to 
>> provide this structure, because it fails to identify w2k as "old" client;
>>
>> First issue is still present in 1.0.1, because it fails to identify 
>> legacy Microsoft cryptotypes as "old" ones. Attached patch does the 
>> trick for us [by adding just mentioned cryptotypes to older_enctype()] 
>> and [so far] was tested with w2k, wxp, vista, mit krb5 and admitmac.
> 
> Maybe all enctypes with lower numbers the aes should be considered 
> "old".

Quoting RFC4120:

"  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."

AES for Kerberos was ratified several *months* before 4120, so that one 
can argue that even AES is "old" enctype:-) But to be serious it is open 
for definition of "concurrently." Final documents have no revision 
history and it's not trivial for general public to figure if two RFCs 
were worked on concurrently. Should one expect small difference in RFC 
number? How small? Should they be ratified on the same year? But in 
either case it indeed might be appropriate to re-implement 
kerberos5.c:older_enctype() as !newer_enctype and enlist "newer" 
encryption types. I mean as opposite to maintaining list of "older" 
ones. Cheers. A.