Secret Key Transaction Authentication for DNS (TSIG)
RFC 2845

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

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
   parties (forge MACs).  There is an urgent need to provide simple and
   efficient authentication between clients and local servers and this