v1.3.0: GSS-TSIG broken with Windows AD DNS servers

[onno204]

Hi,

We are using the Terraform module hashicorp/dns, which has a dependency on this project.
Hashicorp/dns recently bumped bodgit/tsig from v1.2.2 to v1.3.0, and now our dynamic DNS updates (RFC 2136) throws an error when updating DNS records on our Windows Server DNS.
We are using Kerberos with usename/password authentication.

We see the error:

Error: Error deleting DNS record: unexpected acceptor flag is not set: expecting a token from the acceptor, not in the initiator

hashicorp/dns confirmed the issue is related to the v1.3.0 version of tsig.
See hashicorp/dns issue here: hashicorp/terraform-provider-dns#642.

To quote:
Windows Server DNS appears to not set the SentByAcceptor flag in its MIC token responses, which is required by RFC 4121. It seems like the upstream library is now enforcing that behavior.

They suggested a tolerance option for non-compliant servers. Is this something that would be possible to implement into this project?
I have very little knowledge of the inner workings of Kerberos; If more information is needed, please let me know.

(I expect this will also become an issue for our kubernetes-sigs/external-dns updates, as they have also recently bumped to v1.3.0, but I didn't test that since they haven't published a new release yet.)

[bodgit]

The SentByAcceptor flag is fundamental to Kerberos. I don't believe Windows doesn't set that. I've always required that the acceptor flag is set, even before I refactored things. Here's the code in v1.2.2:

tsig/gss/gokrb5.go

Lines 230 to 243 in e486e05

	var token gssapi.MICToken
	if err = token.Unmarshal(mac, true); err != nil {
	return err
	}
	token.Payload = stripped
	if err = ctx.ss.check(token.SndSeqNum); err != nil {
	return err
	}
	// This is the actual verification bit
	if _, err = token.Verify(ctx.key, keyusage.GSSAPI_ACCEPTOR_SIGN); err != nil {
	return err
	}

The token.Unmarshal(mac, true) call is what is triggering the error. It's always been like that.

I think what happens is when Windows rejects your DNS update for some reason, it sends your signature back to you. This means the verification will always fail because your outgoing signature won't have the acceptor flag set, (nor should it). Unfortunately, because of the way idiomatic Go code is written, you check the error before looking at any DNS response code.

I have automated tests that verify things work against a BIND DNS server with Kerberos enabled, but it's near-impossible to do the same for Windows unless you know a way with GitHub actions to spin up and destroy a Windows DNS server and configure it automatically. Windows is also terrible in telling you why it might have rejected your DNS update.

I'll have to try and see if I can manually test this against a Windows server.