Secret Key Transaction Authentication for DNS (TSIG)
RFC 2845
| Document | Type |
RFC - Proposed Standard
(May 2000; No errata)
Updates RFC 1035
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 2845 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group P. Vixie
Request for Comments: 2845 ISC
Category: Standards Track O. Gudmundsson
Updates: 1035 NAI Labs
D. Eastlake 3rd
Motorola
B. Wellington
Nominum
May 2000
Secret Key Transaction Authentication for DNS (TSIG)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This protocol allows for transaction level authentication using
shared secrets and one way hashing. It can be used to authenticate
dynamic updates as coming from an approved client, or to authenticate
responses as coming from an approved recursive name server.
No provision has been made here for distributing the shared secrets;
it is expected that a network administrator will statically configure
name servers and clients using some out of band mechanism such as
sneaker-net until a secure automated mechanism for key distribution
is available.
1 - Introduction
1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated
hierarchical distributed database system that provides information
fundamental to Internet operations, such as name <=> address
translation and mail handling information. DNS has recently been
extended [RFC2535] to provide for data origin authentication, and
public key distribution, all based on public key cryptography and
public key based digital signatures. To be practical, this form of
Vixie, et al. Standards Track [Page 1]
RFC 2845 DNS TSIG May 2000
security generally requires extensive local caching of keys and
tracing of authentication through multiple keys and signatures to a
pre-trusted locally configured key.
1.2. One difficulty with the [RFC2535] scheme is that common DNS
implementations include simple "stub" resolvers which do not have
caches. Such resolvers typically rely on a caching DNS server on
another host. It is impractical for these stub resolvers to perform
general [RFC2535] authentication and they would naturally depend on
their caching DNS server to perform such services for them. To do so
securely requires secure communication of queries and responses.
[RFC2535] provides public key transaction signatures to support this,
but such signatures are very expensive computationally to generate.
In general, these require the same complex public key logic that is
impractical for stubs. This document specifies use of a message
authentication code (MAC), specifically HMAC-MD5 (a keyed hash
function), to provide an efficient means of point-to-point
authentication and integrity checking for transactions.
1.3. A second area where use of straight [RFC2535] public key based
mechanisms may be impractical is authenticating dynamic update
[RFC2136] requests. [RFC2535] provides for request signatures but
with [RFC2535] they, like transaction signatures, require
computationally expensive public key cryptography and complex
authentication logic. Secure Domain Name System Dynamic Update
([RFC2137]) describes how different keys are used in dynamically
updated zones. This document's secret key based MACs can be used to
authenticate DNS update requests as well as transaction responses,
providing a lightweight alternative to the protocol described by
[RFC2137].
1.4. A further use of this mechanism is to protect zone transfers.
In this case the data covered would be the whole zone transfer
including any glue records sent. The protocol described by [RFC2535]
does not protect glue records and unsigned records unless SIG(0)
(transaction signature) is used.
1.5. The authentication mechanism proposed in this document uses
shared secret keys to establish a trust relationship between two
entities. Such keys must be protected in a fashion similar to
private keys, lest a third party masquerade as one of the intended
Show full document text