[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: heimdal 1.0.1 w2k interop
>> - 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
" 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
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.