Title

A unique TSIG key used by a BIND 9.x server must be generated for each pair of communicating hosts. (Cat II impact)

Discussion

To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64 encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message. The process of authenticating the source of a message and its integrity through hash-based message authentication codes (HMAC) is specified through a set of DNS specifications known collectively as TSIG. The sender of the message uses the HMAC function to generate a MAC and sends this MAC along with the message to the receiver. The receiver, who shares the same secret key, uses the key and HMAC function used by the sender to compute the MAC on the received message. The receiver then compares the computed MAC with the received MAC; if the two values match, it provides assurance that the message has been received correctly and that the sender belongs to the community of users sharing the same secret key. Thus, message source authentication and integrity verification are performed in a single process. To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64 encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.

Check Content

Verify that the BIND 9.x server is configured to use separate TSIG key-pairs when securing server-to-server transactions. Inspect the "named.conf" file for the presence of TSIG key statements: On the primary name server, this is an example of a configured key statement: key tsig_example. { algorithm hmac-SHA1; include "tsig-example.key"; }; zone "disa.mil" { type Primary; file "db.disa.mil"; allow-transfer { key tsig_example.; }; }; On the secondary name server, this is an example of a configured key statement: key tsig_example. { algorithm hmac-SHA1; include "tsig-example.key"; }; server <ip_address> { keys { tsig_example }; }; zone "disa.mil" { type Secondary; Primarys { <ip_address>; }; file "db.disa.mil"; }; Verify that each TSIG key-pair listed is only used by a single key statement: # cat <tsig_key_file> If any TSIG key-pair is being used by more than one key statement, this is a finding.

Fix Text

Create a separate TSIG key-pair for each key statement listed in the named.conf file. Configure the name server to use separate TSIG key-pairs for each key statement listed in the named.conf file. Restart the BIND 9.x process.

Additional Identifiers

Rule ID: SV-272376r1067967_rule

Vulnerability ID: V-272376

Group Title: SRG-APP-000176-DNS-000076

Expert Comments

CCIs tied to check.

Controls tied to check. These are derived from the CCIs shown above.