[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12                        
   DNSIND Working Group                              Paul Vixie (Ed.) (ISC)
   INTERNET-DRAFT                                  Olafur Gudmundsson (TIS)
                                            Donald Eastlake 3rd (CyberCash)
   <draft-ietf-dnsind-tsig-01.txt>                            November 1996
   Amends: RFC 1035
               Secret Key Transaction Signatures for DNS (TSIG)
   Status of this Memo
      This document is an Internet-Draft.  Internet-Drafts are working
      documents of the Internet Engineering Task Force (IETF), its areas,
      and its working groups.  Note that other groups may also distribute
      working documents as Internet-Drafts.
      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as ``work in progress.''
      To learn the current status of any Internet-Draft, please check the
      ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
      Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
      munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
      ftp.isi.edu (US West Coast).
      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
   Expires May 1997                                                [Page 1]

   INTERNET-DRAFT                  DNS TSIG                   November 1996
   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 [DNSSEC]
   to provide for data origin authentication, public key distribution, and
   query and transaction authentication, all based on public key
   cryptography and public key based digital signatures.  To be practical,
   this form of 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 [DNSSEC] 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 [DNSSEC] 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.  [DNSSEC]
   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 an efficient secret key based
   transaction signature that avoids these difficulties.
   1.3. A second area where use of straight [DNSSEC] public key based
   mechanisms may be impractical is authenticating dynamic update [UPDATE]
   requests.  [DNSSEC] provides for query/request signatures but with
   [DNSSEC] they, like transaction signatures, require computationally
   expensive public key cryptography and complex authentication logic.
   This document's secret key based signatures can be used to authenticate
   DNS update requests as well as transaction responses.
   1.4. The signature mechanism proposed in this document uses shared
   secret keys to establish trust relationship between two entities.  Such
   keys must be protected in a fashion similar to private keys, or anyone
   can masquerade one of the parties (forge signatures).  There is a urgent
   need to provide some authentication between clients and local servers
   and this proposal addresses this need.  This proposal is unsuitable for
   general server to server authentication for servers which speak with
   many other servers.  But it is suitable for many resolvers on hosts that
   only talk to few recursive servers.
   Expires May 1997                                                [Page 2]

   INTERNET-DRAFT                  DNS TSIG                   November 1996
   1.5. A server acting as a caching resolver -- a ``slave forwarder'' in
   common usage -- might use transaction signatures when communicating with
   its small number of preconfigured ``upstream'' servers.  TSIG may also
   be suitable for use on zone transfers to secondaries.  Other uses of DNS
   secret key signatures and possible systems for automatic secret key
   distribution may be proposed in separate future documents.
   2 - TSIG RR Format
   2.1. To provide secret key signatures, we use a new RR type whose
   mnemonic is TSIG. TSIG is a meta-RR and can not be stored, its type code
   is TBD.  TSIG RRs can be used for authentication between DNS entities
   that have established a shared secret key.  TSIG RRs are dynamically
   computed to cover a particular DNS query or transaction and are not DNS
   RRs in the usual sense.
   2.2. As the TSIG RRs are related to one DNS query/response there is no
   value in storing or retransmitting them, thus the TSIG RR should be
   discarded once it has been used to authenticate DNS packet.  The only
   Message Digest algorithm specified in this document is ``HMAC-MD5'' (see
   [MD5], [HMAC]).  Other algorithms can be specified at later date.  Names
   and definitions of new algorithms should be registered with IANA.
   2.3. Record Format:
      NAME   A domain name of the key used, 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 and B in same zone share a key then the key name could be A-
             B-<id>.<zone>.  If two host in different zone share the key
             the key name could be <id>.A.<Azone>.B.<Bzone> It should be
             possible for more than one key to be in simultaneous use among
             a set of interacting hosts.
      TYPE   TSIG (Transaction SIGnature).
      CLASS  IN
      TTL    0
      RdLen  (variable)
   Expires May 1997                                                [Page 3]

   INTERNET-DRAFT                  DNS TSIG                   November 1996
             Field Name       Data Type      Notes
             Algorithm Name   domain-name    points to an RP RR giving the
                                             algorithm definer's address.
             Time Signed      u_int32_t      seconds since 1-Jan-70 UTC.
             Expire           u_int32_t      set to estimate of RTT/2+fudge.
             Signature Size   u_int16_t      number of octets in Signature.
             Signature        octet stream   defined by Algorithm Name.
             Other Data       undefined      ignore any following RDATA.
   2.4. Example:
      TYPE   TSIG
      CLASS  IN
      TTL    0
      RdLen  as appropriate
             Field Name       Contents
             Algorithm Name   HMAC-MD5.IANA.ORG.
             Time Signed      853804800
             Expire           853805400
             Signature Size   as appropriate
             Signature        as appropriate
   2.5. All multioctet integers described above are sent in network byte
   Expires May 1997                                                [Page 4]

   INTERNET-DRAFT                  DNS TSIG                   November 1996
   3 - HMAC-MD5 Details
   3.1. The only algorithm defined in this document is HMAC-MD5.  (Note:
   HMAC-MD5 does not suffer from the possible weaknesses that have been
   found in MD5.)  The HMAC-MD5 operation for a query signature is:
      MD5( K xor OPAD, MD5( K xor IPAD, DATA))
      K     The KEY used or an MD5 message digest of the key if the key is
            longer than 64 bytes.  The key or digest is padded to 64 bytes
            by appending the NUL bytes (0x00) as needed.
      IPAD  A 64 byte string with the value 0x36 in each byte.
      OPAD  A 64 byte string with the value 0x5C in each byte.
      DATA  The data being signed as described in section 4 below and
            appened by the expiration time in network byte order.
   4 - Protocol Operation
   4.1. Once the outgoing packet 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.  Appending a query or transaction signature to an DNS message
   is not allowed to result in a truncated response, TCP connection must be
   used to prevent the truncation.
   4.2. Upon receipt of a message with a TSIG RR, the TSIG RR is copied to
   a safe location, removed from the DNS Message, and decremented out of
   the DNS Message Header's ARCOUNT.  At this point the keyed message
   digest operation is performed.  If the algorithm name or key name is
   unknown to the recipient, or if the message digests do not match, the
   whole DNS Message must be discarded and a response with RCODE 5
   (REFUSED) should be sent back to the originator.  A message to the
   system operations log should to be generated in this case, to warn the
   operations staff of a possible security incident in progress.
   4.3. Expire check, if the value of expire field is in the past this
   transaction should be assumed to be an replay attack, and RCODE 5
   (REFUSED) should returned.  For expire to work correctly it is
   recommended that all machines using TSIG signatures use clock
   synchronization.  If clock synchronization is not used the ``Fudge'' has
   to be larger but ``Fudge'' should always be less or equal than the
   smallest TTL of the RR in the message.
   Expires May 1997                                                [Page 5]

   INTERNET-DRAFT                  DNS TSIG                   November 1996
   5 - Protocol Details
   5.1. Client performs the message digest operation and appends TSIG to
   additional data section and transmits query to server.  The data
   digested is the whole outgoing DNS packet in wire format, before the
   TSIG RR has been added to the additional data section and before the DNS
   Message Header's ARCOUNT field has been incremented to contain the TSIG
   RR.  The client must store the message digest from the query while
   waiting for an answer.  Note that some older name servers will not
   accept queries with a nonempty additional data section, but clients will
   only attempt signed transactions against servers who are known to
   support TSIG and share some secret key with the client.
   5.2. Upon receipt of a message, server will check if there is a TSIG RR.
   If one exists, it requires the server to return a TSIG RR in the
   response.  If the request's TSIG does not validate, the server responds
   with RCODE 9 (NOTAUTH) if OPCODE is 0 (UPDATE, else with RCODE 5
   5.3. When server has generated a response, it calculates the keyed
   digest over the concatenation of the keyed message digest field from the
   TSIG on the query and the whole outgoing DNS answer packet in wire
   format before the answer TSIG RR has been added and before the ARCOUNT
   field has been incremented for it.  That is, the data to be digested is:
      message digest from query | dnsANSWER
   TSIG is appended and the response is sent. The inclusion of the message
   digest from the query binds the response to the initiating request.
   5.4. When a client receives a response from a server it expects a TSIG
   from, it first checks if the TSIG RR is present in the reply, if not the
   reply is treated as having a format error.  The client then extracts the
   TSIG, adjusts the ARCOUNT, and calculates the keyed digest in the same
   way as the server.  If the TSIG does not validate, that response must be
   5.5. This protocol allows the client and server to share multiple
   secrets, if the server rejects a particular secret by sending back
   either REFUSED or NOTAUTH, the client can either try the next secret, or
   give up on this server.
   Expires May 1997                                                [Page 6]

   INTERNET-DRAFT                  DNS TSIG                   November 1996
   5.6. A server acting as a Forwarding Server of a DNS packet, should
   check for the existence of the TSIG record.  If the name on the TSIG is
   not of a secret that the server shares with the originator the server
   will forward the packet unchanged including the TSIG.  If the name of
   the TSIG is of a key this server shares with the originator it processes
   the TSIG.  If the TSIG passes checks the forwarding server has the
   obligation of including a TSIG of his own, using a shared secret it
   shares with the destination or if that is not available then use one it
   shares with the next forwarder on the path to the destination.
   6 - Shared Secrets
   6.1. Secret keys are very sensitive information and all available steps
   should be taken to protect them on every host on which they are stored.
   Generally such hosts need to be physically protected.  If they are
   multi-user machines, great care should be taken that unprivileged users
   have no access to me keying material.  Resolvers usually run
   unprivileged, which means all users of a host will usually be able to
   see whatever configuration data is used by the resolver.
   6.2. A name server usually runs privileged, which means its
   configuration data need not be visible to all users of the host.  For
   this reason, a host that implements transaction signatures should
   probably be configured with a ``stub resolver'' and a local
   ``caching/forwarding name server.''  This presents a special problem for
   [UPDATE] which otherwise depends on clients to communicate only with a
   zone's authoritative name servers.
   6.3. Use of strong random shared secrets is essential to the security of
   TSIG.  See RFC1750 for a discussion of this issue.  The secret should be
   at least as long as the keyed message digest digest, i.e., 16 bytes for
   7 - Security Considerations
   7.1. The approach specified here is computationally much less expensive
   that the query and transaction signatures specified in [DNSSEC].  In
   addition, it is believed that MD5 is less subject to governmental
   restrictions than the RSA algorithm of [DNSSEC].  As long as the shared
   secret key is not compromised, strong authentication is provided for the
   last hop from a local name server to the user resolver.
   Expires May 1997                                                [Page 7]

   INTERNET-DRAFT                  DNS TSIG                   November 1996
   7.2. Secret keys should be changed periodically.  If the client host has
   been broken into, the server should suspend the use of all secrets known
   to that client.  If possible, secrets should be stored in encrypted
   form.  Secrets should never be transmitted in the clear over any wire.
   This document does not address the issue on how to distribute secrets.
   7.3. This mechanism does not authenticate source data, only its
   transmission between two parties who share some secret.  The original
   source data can come from a compromised zone master or can be corrupted
   during transit from an authentic zone master to some ``caching
   forwarder.''  However, if the server is faithfully performing the full
   [DNSSEC] security checks, then only security checked data will be
   available to the client.
   8 - References
   [RFC1034]  P. Mockapetris, ``Domain Names - Concepts and Facilities,''
              RFC 1034, ISI, November 1987.
   [RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
              Specification,'' RFC 1034, ISI, November 1987.
   [RFC1321]  R. Rivest, ``The MD5 Message-Digest Algorithm,'' RFC 1321,
              MIT LCS & RSA Data Security, Inc., April 1992.
   [RFC1521]  N. Borenstein, N. Freed, ``MIME (Multipurpose Internet Mail
              Extensions) Part One,'' RFC 1521, Bellcore & Innosoft,
              September 1993.
   [RFC1750]  D. Eastlake, S. Crocker, J. Schiller, ``Randomness
              Recommendations for Security,'' RFC 1750, DEC, CyberCash &
              MIT, December 1995.
   [DNSSEC]   D. Eastlake , C Kaufman, ``Domain Name System Security
              Extensions,'' draft-ietf-dnssec-secext-10.txt, CyberCash &
              Iris, August 1996.
   [UPDATE]   P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
              Updates in the Domain Name System,'' <draft-ietf-dnsind-
              dynDNS-11.txt>, ISC & Bellcore & Cisco & DEC, November 1996.
   [HMAC]     H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5
              for Message Authentication,'' draft-ietf-ipsec-hmac-
              md5-01.txt, IBM, UCSD & IBM, November, 1996.
   Expires May 1997                                                [Page 8]

   INTERNET-DRAFT                  DNS TSIG                   November 1996
   9 - Author's Addresses
      Paul Vixie                          Olafur Gudmundsson
         Internet Software Consortium        Trusted Information Systems
         Star Route Box 159A                 3060 Washington Road, Route 97
         Woodside, CA 94062                  Glenwood, MD 21738
         +1 415 747 0204                     +1 301 854 6889
         <paul@vix.com>                      <ogud@tis.com>
      Donald E. Eastlake 3rd.
         CyberCash, Inc.
         318 Acton Street
         Carlisle, MA 01741
         +1 508 287 4877
   Expires May 1997                                                [Page 9]