Unsigned GSS-TSIG TKEY Query Response

As reported to us in Support Ticket #14010

BIND 9.10.2

This is a report of an issue in bind's GSS-TSIG support. First some background

GSS-TSIG is described in RFC-3645. The second paragraph of section 3.1.3.1 of the RFC states:

3.1.3.1. Value of major_status == GSS_S_COMPLETE ... Confirmation is in the form of a query response with RCODE=NOERROR and with the last client supplied TKEY record in the answer section of the query. The response MUST be signed with a TSIG record. Note that the server is allowed to sign a response to unsigned client's query due to modification to the RFC 2845 specified in Section 2.2 above. The signature in the TSIG record MUST be verified using the procedure detailed in section 5, Sending and Verifying Signed Messages. If the response is not signed, OR if the response is signed but the signature is invalid, then an attacker has tampered with the message in transit or has attempted to send the client a false response.
...

Also, section 4.1.3 states:

4.1.3. Send TKEY Query-Response to Client ... If major_status is GSS_S_COMPLETE the server component of the negotiation is finished. If output_token is non-NULL, then it MUST be returned to the client in a Key Data field of the RDATA in TKEY. The error field in the TKEY record is set to NOERROR. The message MUST be signed with a TSIG record as described in section 5, Sending and Verifying Signed Messages. Note that server is allowed to sign a response to unsigned client's query due to modification to the RFC 2845 specified in Section 2.2 above. The context state is advanced to Context Established. Section 4.2 discusses the usage of the security context. ...

And section 6, step X:

X. Server responds to the TKEY query

Since the major_status = GSS_S_COMPLETE in the last server's call to GSS_Accept_sec_context and the output_token is NULL, the server responds to the TKEY query placing in the answer section a TKEY record that was sent by the client in the Additional records section of the client's latest TKEY query. In addition, this server places a TSIG record in additional records section of its response. Server calls GSS_GetMIC to generate a signature to include it in the TSIG record. The server specifies the following GSS_GetMIC INPUT parameters: ...

So based on the above statements from RFC-3645 a TKEY query response MUST be signed by a TSIG record when sent to the client. The TSIG record is placed in the additional records section of the response.

The issue we believe we found is that named is not signing the TKEY responses as required in RFC-3645. While this doesn't seem to bother Microsoft Windows clients since after they receive the TKEY response they then just go ahead and send GSS-TSIG signed DDNS updates it does seem to bother the Mac clients. They seem to believe that the response is either false or was tampered with and don't send DDNS updates.

A pcap demonstrating the unsigned TKEY query response in third packet can be obtained from the Support ticket