Jump to content

TSIG

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Mzajac (talk | contribs) at 23:25, 18 November 2010 (→Alternatives to TSIG: combine 1-item lists). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

TSIG (Transaction SIGnature) is a computer networking protocol defined in RFC 2845. It is used primarily by the Domain Name System (DNS) to provide a means of authenticating updates to a Dynamic DNS database, although it can also be used between servers and for regular queries. TSIG uses shared secret keys and one-way hashing to provide a cryptographically secure means of identifying each endpoint of a connection as being allowed to make or respond to a DNS update.

Although queries to DNS may be made anonymously (but see DNSSEC), updates to DNS must be authenticated since they make lasting changes to the structure of the Internet naming system. The use of a key shared by the client making the update and the DNS server guarantees the authenticity of the update request. However, the update request may be passing over an insecure channel (the Internet). A one-way hashing function is used to prevent malicious observers from learning the secret key and using it to make their own modifications.

A timestamp is included in the TSIG protocol to prevent recorded responses from being reused, which would allow an attacker to breach the security of TSIG. This places a requirement on dynamic DNS servers and TSIG clients to contain an accurate clock. Since DNS servers are connected to a network, Network Time Protocol may be used to provide an accurate time source.

DNS updates, like queries, normally are transported via UDP since it requires lower overhead than TCP. However, DNS servers support both UDP and TCP requests.

Implementation

An update, as specified in RFC 2136, is a set of instructions to a DNS server. These include a header, the zone to be updated, the prerequisites that must be satisfied, and the record(s) to be updated. TSIG adds a final record, which includes a timestamp and the hash of the request. It also includes the name of the secret key that was used to sign the request. RFC 2535 has recommendations on the form of the name.

The response to a successful TSIG update will also be signed with a TSIG record. Failures are not signed to prevent an attacker from learning anything about the TSIG key using specially crafted update "probes".

The nsupdate program can use TSIG to do DNS updates.

The TSIG record is in the same format as the other records in the update request. The meaning of the fields is described in RFC 1035.

TSIG record fields
Field Bytes Description
NAME max 256 Key name, which must be unique on client and server
TYPE 2 TSIG (250)
CLASS 2 ANY (255)
TTL 4 0 (since TSIG records must not be cached)
RDLENGTH 2 Length of RDATA field
RDATA variable Structure containing the timestamp, algorithm and hash data

Alternatives to TSIG

Although TSIG is widely deployed, there are several problems with the protocol:

  • It requires distributing secret keys to each host which must make updates.
  • The HMAC-MD5 digest is only 128 bits.
  • There are no levels of authority. Any host with the secret key may update any record.

As a result, a number of alternatives and extensions have been proposed.

  • RFC 2137 specifies an update method using a public key "SIG" DNS record. A client holding the corresponding private key can sign the update request. This method matches the DNSSEC method for secure queries. However, this method is deprecated by RFC 3007.
  • In 2003, RFC 3645 proposed extending TSIG to allow the Generic Security Service (GSS) method of secure key exchange, eliminating the need for manually distributing keys to all TSIG clients. The method for distributing public keys as a DNS resource record (RR) is specified in RFC 2930, with GSS as one mode of this method. A modified GSS-TSIG - using the Windows Kerberos Server - was implemented by Microsoft Windows Active Directory servers and clients called Secure Dynamic Update. In combination with poorly configured DNS (with no Reverse Lookup Zone) using RFC 1918 addressing, reverse DNS updates using this authentication scheme are forwarded en masse to the root DNS servers and increase the traffic to root DNS servers in the course of doing so[1]. There is an anycast group which deals with this traffic to take it away from the root DNS servers[2].
  • RFC 2845, which defines TSIG, specifies only one allowed hashing function HMAC-MD5, which is no longer considered to be highly secure. As of 2006, proposals are being circulated to allow RFC 3174 Secure Hash Algorithm (SHA1) hashing to replace MD5. The 160-bit digest generated by SHA1 should be more secure than the 128-bit digest generated by MD5.
  • RFC 2930, which defines TKEY, a DNS Record used to automatically distribute keys from a DNS server to DNS clients
  • RFC 3645, Which defines GSS-TSIG which uses gss-api and TKEY to automatically distribute keys in gss-api mode
  • The DNSCurve proposal has many similarities to TSIG.

See also

References

  • Broido, Nemeth, claffy. "Spectroscopy of DNS Update Traffic", CAIDA, 2002.
  • RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE)
  • RFC 2845 Secret Key Transaction Authentication for DNS (TSIG)
  • RFC 2930 Secret Key Establishment for DNS (TKEY RR)
  • RFC 3645 Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)
  • RFC 3174 US Secure Hash Algorithm 1
  • RFC 4635 HMAC SHA TSIG Algorithm Identifiers
Retrieved from "https://en.wikipedia.org/w/index.php?title=TSIG&oldid=397577344"