[ISC-support #20638] dhcp-ddns fatal error on non-existant gss_tsig kerberos principal

This is a customer feature request from: https://support.isc.org/Ticket/Display.html?id=20638

---

We're using the gss_tsig Kea hook (as of the eng-drop-2021-11-10 tag) on Kea 2.0.1. We've noticed an annoying behavior in our test where an incorrect server principal makes kea-dhcp-ddns exit.

I can reproduce it with the attached config with the following krb5.conf:

[realms]
    EXAMPLE.COM = {
            kdc = 172.17.0.3
    }

The important part of kea-dhcp-ddns.conf is this line: "server-principal": "DNS/nsx.example@EXAMPLE.COM", where there's a typo in the principal name, and the KDC running on 172.17.0.3 doesn't recognize it (KDC must be running and reachable on that address to reproduce the issue).

In code inspection, the reason for this behavior is that the call to gss_init_sec_context() fails in GssApiSecCtx::init(), which causes a C++ exception:

        isc_throw(GssApiError, "gss_init_sec_context failed with "
                  << gssApiErrMsg(major, minor));

and it's propagated to the very top level of the code, which considers the error to be fatal and exits.

I'm not sure if this behavior is intentional or not, but if it's intentional, I'd like to ask to revisit it for the following reason:

• It seems to be too harsh to kill the server just due to a specific part of config error. It also doesn't seem to be a good practice to die because of a response from a remote server (KDC in this case).
• The behavior doesn't seem to be consistent with other similar config error, like specifying the wrong KDC address. In that case acquireCredentials() called from TKeyExchangeImpl::doExchange() would throw but it's caught within doExchange() and the server keeps running. This seems to be the more sensible behavior in errors like this.

I hope the behavior for the wrong principal will be changed in a future version of the hook.