Avoiding "KDC has no support for encryption type while getting initial credentials" by pinning selected KDC

[Osipov, Michael]

Hi folks,

we are experiencing an issue where we don't know this is a bug or missing
feature in MIT Kerberos. I tend to a bug.

We have a headless service which relies on a client keytab to perform some
HTTP calls from within a C application with libcurl. Once in a while these
calls fail due to: "KDC has no support for encryption type while getting
initial credentials".

The keytab contains three keys for one principal: RC4, AES128, AES256.
Our home realm is backed up by 80 to 100 KDCs of various Windows Server
versions, not all support AES. KDC lookups rely on DNS only and we do
not intend to hardcode them in krb5.conf.

While analyzing this issue we noticed that for each and every KDC call
MIT Kerberos uses another KDC instead of pinning the first one which has
responded to the library. In this specific case, MIT Kerberos advertises
AES256, AES128, etc. in AS-REQ and the KDC responds with PREAUTH_REQUIRED,
PA-ENCTYPE-INFO2: AES256. The next AS-REQ goes again to another KDC which
unfortunately does *not* support AES256, hence responding with ERR_ETYPE_NOSUPP.

I would expect MIT Kerberos to pin the first working KDC because some
Information has been negotiated already but send to a completely different
KDC. This is annoying because I would expect the communication between client
and server is predictable.

I know this cannot be configured currently but is this possible to implement
without big hassle?

The issue has been verified with versions 1.13.1 and 1.14.3 on various
platforms. Wireshark dumps can be send privately.

Best regards,

Michael Osipov