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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
