FreeBSD-14.3 nsupdate krb5 failure (beyond issue 4436)

[Michał Kępień]

Hi Peter,

> This is the error:
> ---------------------------------------------
> recvmsg reply from GSS-TSIG query
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:   4885
> ;; flags: qr ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> ;; QUESTION SECTION:
> ;3478577972.sig-conr-e.intra.daemon.contact. ANY        TKEY
> 
> ;; ANSWER SECTION:
> 3478577972.sig-conr-e.intra.daemon.contact. 0 ANY TKEY gss-tsig. 0 0 3 BADKEY 0  0
> 
> dns_tkey_gssnegotiate: TKEY is unacceptable
> ---------------------------------------------
> With debugging the server reports this:
> 
> client @0x1fd41731b090 fd00::4202#19192
>        (3656045201.sig-conr-e.intra.daemon.contact): view intra: query:
>        3656045201.sig-conr-e.intra.daemon.contact ANY TKEY -T (fd00::4202) 
> failed gss_inquire_cred: GSSAPI error: Major = No credentials were
>        supplied, or the credentials were unavailable or inaccessible,
>        Minor = No Kerberos credentials available (default cache:
>        FILE:/tmp/krb5cc_53).
> failed gss_accept_sec_context: GSSAPI error: Major = Unspecified GSS
>        failure.  Minor code may provide more information, Minor =
>        Cryptosystem internal error.
> process_gsstkey(): dns_tsigerror_badkey

So it looks like krb5 is unable to process the initial GSS-API token
sent by nsupdate - something inside krb5 returns the
KRB5_CRYPTO_INTERNAL error code.

Could you perhaps start named with the KRB5_TRACE environment variable
set to a file path of your choosing and then paste the contents of
that file after a failed nsupdate run?  It might shed some light on what
krb5 is trying to do and/or what specifically fails.

> I have removed the "tkey-gssapi-credential" option due to another
> recommendation, so the only relevant configuration is now
>         tkey-gssapi-keytab      "/etc/krb5-named.keytab";
> 
> And that one contain the correct cred, both in root and chroot:
> ktutil:  rkt /var/named/etc/krb5-named.keytab
> ktutil:  l
> slot KVNO Principal
> ---- ---- ---------------------------------------------------------------------
>    1    1 DNS/conr-e.intra.daemon.contact at OUTRA.PHASE23
> 
> When nsupdate is invoked, it obtains that same cred.

How?  Could you please paste (or link to) a full debug log of a failed
nsupdate invocation?

> Inside the server I did follow the proceedings via
>     process_gsstkey() -> dst_gssapi_acceptctx() ->
>     gss_accept_sec_context()
>     which returns GSS_S_FAILURE
> 
> For strange reasons the krb5 tries to create an rcache (but it does
> not try to connect the kerberos server):
>    root at conr:/var/named/etc # ls -l /var/named/var/tmp/
>    total 1
>    -rw-------  1 bind wheel 0 Aug 25 20:51 krb5_53.rcache2
> 
> Somehow this looks like the krb5 believes to be a (forwarding?)
> client, not a server.

rcache is a replay cache, not a credential cache.  This does not strike
me as weird.

> When I reinsert the deprecated "tkey-gssapi-credential" option, the
> behaviour is significantly different: the empty krb5_53.rcache2 file
> is not created, the "No Kerberos credentials available" error does not
> appear. Instead I see this during startup:
> 
> acquiring credentials for DNS/conr-e.intra.daemon.contact at OUTRA.PHASE23
> acquired accept credentials for DNS/conr-e.intra.daemon.contact at OUTRA.PHASE23
> gss cred: "DNS/conr-e.intra.daemon.contact at OUTRA.PHASE23",
>     GSS_C_ACCEPT, 4294967295
> 
> However, the "Cryptosystem internal error." does appear all the same.

Right, I would not expect "tkey-gssapi-credential" to affect the
outcome, but good call checking it anyway.

So far, I have not spotted anything wrong with BIND 9 per se based on
the output above.  We continuously test GSS-TSIG on FreeBSD 14.3 using
krb5 [1] (the relevant system tests are "nsupdate" and "tsiggss"), so it
cannot be completely broken.

[1] see e.g. https://gitlab.isc.org/isc-projects/bind9/-/jobs/6073942

-- 
Best regards,
Michał Kępień