[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [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)
   <draft-ietf-dnsind-tsig-00.txt>                           September 1996
   Amends: RFC 1035
                     Simple Transaction Signature for DNS
   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 caching/forwarding 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 March 1997                                             [Page 1]

   INTERNET-DRAFT                  DNS TSIG                  September 1996
   1 - Motivation
   1.1. [DNSSEC] creates a framework for authenticating DNS data by DNS
   Resolvers and servers.  To do this securely a chain of trusted Keys must
   be constructed to a Key that is unconditionally trusted (preconfigured).
   For expediency nameservers will store large caches of KEYs. If a name
   server does not have a KEY that it needs to authenticate RRs in an
   incoming message, it must query for that KEY before it can pass the
   original data on as secure.
   1.2, Common DNS implementations use ``stub'' resolvers, which do not
   have caches.  Thus it is impractical in most cases for resolvers to
   perform [DNSSEC] authentication.  To overcome this problem, [DNSSEC]
   includes Transaction Signatures.  Unfortunately, Transaction Signatures
   with the RSA algorithm are expensive to generate, and [DNSSEC]'s RR
   format is difficult to encode and decode.  A cheaper and necessarily
   less secure way of performing transaction authentication is required.
   This document specifies a standard inexpensive transaction signature for
   use in certain cases.
   1.3. There are two main requirements for this.  In [UPDATE], messages
   may originate from hosts that do not support encryption.  It is a
   terrible idea to allow clients to update DNS servers without any
   authentication. The second requirement is to allow resolvers to
   authenticate the response they got from a local query came from a
   trusted server.
   1.4. The mechanism proposed here uses shared secret keys to establish
   trust relationship between two entities.  This key must be protected or
   anyone can mascarade one of the parties.  [DNSSEC] transaction
   signatures are much stronger and as [DNSSEC] uses Public/Private KEY
   algorithms the Public KEY can be advertised.  There is a urgent need to
   provide some authentication between clients and local servers.  This
   proposal is unsuitable for server to server authentication, due to the
   fact that resolvers on user machines only talk to few local servers.
   Servers on the other hand talk to many other servers.  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.
   Expires March 1997                                             [Page 2]

   INTERNET-DRAFT                  DNS TSIG                  September 1996
   2 - TSIG RR Format
   2.1. To provide the authentication between server and client, we use a
   new RR type whose mnuemonic is TSIG, and whose type code is UNASSIGNED.
   TSIG RRs can be used for authenticating a previously established context
   between the clients and servers who are supplied with and configured to
   use a shared secret key.
   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 "MD5" (see
   [MD5]).  Other algorithms can be specified at later date.  Names and
   definitions of new algorithms must be registered with IANA.
   2.3. The TSIG RR has the same syntax as the TXT RR (see [RFC1034
   3.3.14]), with each <character-string> treated as a field, with
   boundaries between <character-string>s being significant, and with at
   least one field always present.
      NAME   The owner name of the TSIG RR is the name of the shared
             secret, which allows a resolver to use a different secret for
             each of its recursive name servers, and allows a server to
             know different secrets for each of its client resolvers.  This
             owner name is not registered in the Domain Name System.
      TYPE   TSIG (Transaction SIGnature).
      CLASS  expiration (offset from "now"), in seconds; set to estimate of
             RTT + fudge.
      TTL    "now" (time since 1 Jan 1970, 00:00 UTC, 32 bit unsigned), in
      RDATA  As for TXT RR, with each <character-string> treated as a
             field.  The first field is the algorythm name, e.g., "MD5".
             The second and following fields are the Message Digest in
             Base64 encoding (see [RFC1521 5.2]).
   2.4. Note that the Message Digest is represented by all TXT subparts
   after the first.  It is possible that the Message Digest will be empty,
   or will be representable with one (1) <character-string>, or will be
   represented by many <character-string>s.  In either case, <character-
   string> ordering and boundaries can be significant and must be stable
   during storage and forwarding, even across internal program APIs.
   Expires March 1997                                             [Page 3]

   INTERNET-DRAFT                  DNS TSIG                  September 1996
   3 - HMAC-MD5 Details
   3.1. There are some concerns about the strength of MD5.  To make MD5
   more secure, the HMAC mechanism has been proposed.  This draft specifies
   the use of the HMAC mechanism (see [HMAC]).  The HMAC operation is:
      MD5( K  xor OPAD, MD5( K xor IPAD, DNSDATA))
      K        The KEY used or a message digest of the key if the key is
               longer than 64 bytes.  The key 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.
      DNSDATA  The data 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.
   4 - Message Digest Operation
   4.1. Once the outgoing packet has been constructed, the 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 Transaction signature to an DNS transaction is not allowed
   to result in a truncated response, TCP connection must be used to
   prevent the truncation.
   4.2. Upon receipt of a packet 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 message digest
   operation is performed.  If the algorythm 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 sender.  A message to the system operations log
   ought to be generated in this case, to warn the operations staff of a
   possible security incident in progress.
   Expires March 1997                                             [Page 4]

   INTERNET-DRAFT                  DNS TSIG                  September 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 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 to share
   some secret key.
   5.2. Upon receipt of a QUERY, 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 query TSIG does not validate, the server responds with
   RCODE 5 (REFUSED) if OPCODE is 0 (QUERY) or RCODE 9 (NOTAUTH) if the
   opcode is 5 (UPDATE).
   5.3. When server has generated a response, it calculates the a digest.
   The DNSSDATA in this case 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.  Client performs the TSIG
   adjustment and calculates the message digest over:
      message digest from query | dnsANSWER
   5.5. This protocol allows client and server to share multiple secrets,
   if 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
   Expires March 1997                                             [Page 5]

   INTERNET-DRAFT                  DNS TSIG                  September 1996
   6 - Storage of Shared Secrets
   6.1. 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.  This presents a problem in that the shared secrets probably
   ought not to be visible to anyone except the network or system manager.
   In the absence of a Public Key Algorythm, there is no way to make the
   resolver's share secrets secure.
   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.
   7 - Security Considerations
   The approach specified here is weaker than an RSA/MD5 transaction
   signature, but this approach is computationally much less expensive,
   easier to implement and easier to configure.  MD5 implementations are
   common and are not restricted anywhere in the world, unlike RSA.  The
   main goal here is to provide protection of DNSDATA on the last hop from
   the local name server to the user resolver.  The authentication provided
   here is better than nothing and allows protection against some attacks,
   as long as the shared secret key is not compromised.
   Secret keys should be changed periodically.  If client host has been
   broken into, 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
   draft does not address the issue on how to distribute and store secrets.
   One vulnerability is that someone may find a way to calculate the shared
   secret key given enough data.
   Expires March 1997                                             [Page 6]

   INTERNET-DRAFT                  DNS TSIG                  September 1996
   8 - References
   [RFC1321]  Rivest, R., ``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.
   [HMAC]     H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5
              for Message Authentication,'' draft-ietf-ipsec-hmac-
              md5-00.txt, March, 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>
   Expires March 1997                                             [Page 7]