rfc2845.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 844 行 · 第 1/3 页

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
   proposal addresses that need.  This proposal is unsuitable for
   general server to server authentication for servers which speak with
   many other servers, since key management would become unwieldy with





Vixie, et al.               Standards Track                     [Page 2]

RFC 2845                        DNS TSIG                        May 2000


   the number of shared keys going up quadratically.  But it is suitable
   for many resolvers on hosts that only talk to a few recursive
   servers.

   1.6. A server acting as an indirect caching resolver -- a "forwarder"
   in common usage -- might use transaction-based authentication when
   communicating with its small number of preconfigured "upstream"
   servers.  Other uses of DNS secret key authentication and possible
   systems for automatic secret key distribution may be proposed in
   separate future documents.

   1.7. New Assigned Numbers

      RRTYPE = TSIG (250)
      ERROR = 0..15 (a DNS RCODE)
      ERROR = 16 (BADSIG)
      ERROR = 17 (BADKEY)
      ERROR = 18 (BADTIME)

   1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED",  and
   "MAY" in this document are to be interpreted as described in [RFC
   2119].

2 - TSIG RR Format

   2.1 TSIG RR Type

   To provide secret key authentication, we use a new RR type whose
   mnemonic is TSIG and whose type code is 250.  TSIG is a meta-RR and
   MUST not be cached.  TSIG RRs are used for authentication between DNS
   entities that have established a shared secret key.  TSIG RRs are
   dynamically computed to cover a particular DNS transaction and are
   not DNS RRs in the usual sense.

   2.2 TSIG Calculation

   As the TSIG RRs are related to one DNS request/response, there is no
   value in storing or retransmitting them, thus the TSIG RR is
   discarded once it has been used to authenticate a DNS message.  The
   only message digest algorithm specified in this document is "HMAC-
   MD5" (see [RFC1321], [RFC2104]).  The "HMAC-MD5" algorithm is
   mandatory to implement for interoperability.  Other algorithms can be
   specified at a later date.  Names and definitions of new algorithms
   MUST be registered with IANA.  All multi-octet integers in the TSIG
   record are sent in network byte order (see [RFC1035 2.3.2]).






Vixie, et al.               Standards Track                     [Page 3]

RFC 2845                        DNS TSIG                        May 2000


   2.3. Record Format

    NAME The name of the key used in domain name syntax.  The name
         should reflect the names of the hosts and uniquely identify
         the key among a set of keys these two hosts may share at any
         given time.  If hosts A.site.example and B.example.net share a
         key, possibilities for the key name include
         <id>.A.site.example, <id>.B.example.net, and
         <id>.A.site.example.B.example.net.  It should be possible for
         more than one key to be in simultaneous use among a set of
         interacting hosts.  The name only needs to be meaningful to
         the communicating hosts but a meaningful mnemonic name as
         above is strongly recommended.

         The name may be used as a local index to the key involved and
         it is recommended that it be globally unique.  Where a key is
         just shared between two hosts, its name actually only need
         only be meaningful to them but it is recommended that the key
         name be mnemonic and incorporate the resolver and server host
         names in that order.

    TYPE TSIG (250: Transaction SIGnature)

    CLASS ANY

    TTL  0

    RdLen (variable)

    RDATA

      Field Name       Data Type      Notes
      --------------------------------------------------------------
      Algorithm Name   domain-name    Name of the algorithm
                                      in domain name syntax.
      Time Signed      u_int48_t      seconds since 1-Jan-70 UTC.
      Fudge            u_int16_t      seconds of error permitted
                                      in Time Signed.
      MAC Size         u_int16_t      number of octets in MAC.
      MAC              octet stream   defined by Algorithm Name.
      Original ID      u_int16_t      original message ID
      Error            u_int16_t      expanded RCODE covering
                                      TSIG processing.
      Other Len        u_int16_t      length, in octets, of
                                      Other Data.
      Other Data       octet stream   empty unless Error == BADTIME





Vixie, et al.               Standards Track                     [Page 4]

RFC 2845                        DNS TSIG                        May 2000


   2.4. Example

      NAME   HOST.EXAMPLE.

      TYPE   TSIG

      CLASS  ANY

      TTL    0

      RdLen  as appropriate

      RDATA

         Field Name       Contents
         -------------------------------------
         Algorithm Name   SAMPLE-ALG.EXAMPLE.
         Time Signed      853804800
         Fudge            300
         MAC Size         as appropriate
         MAC              as appropriate
         Original ID      as appropriate
         Error            0 (NOERROR)
         Other Len        0
         Other Data       empty

3 - Protocol Operation

   3.1. Effects of adding TSIG to outgoing message

   Once the outgoing message has been constructed, the keyed message
   digest operation can be performed.  The resulting message digest will
   then be stored in a TSIG which is appended to the additional data
   section (the ARCOUNT is incremented to reflect this).  If the TSIG
   record cannot be added without causing the message to be truncated,
   the server MUST alter the response so that a TSIG can be included.
   This response consists of only the question and a TSIG record, and
   has the TC bit set and RCODE 0 (NOERROR).  The client SHOULD at this
   point retry the request using TCP (per [RFC1035 4.2.2]).

   3.2. TSIG processing on incoming messages

   If an incoming message contains a TSIG record, it MUST be the last
   record in the additional section.  Multiple TSIG records are not
   allowed.  If a TSIG record is present in any other position, the
   packet is dropped and a response with RCODE 1 (FORMERR) MUST be
   returned.  Upon receipt of a message with a correctly placed TSIG RR,
   the TSIG RR is copied to a safe location, removed from the DNS



Vixie, et al.               Standards Track                     [Page 5]