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). 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 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 sneaker-net. 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 seconds. 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 server. 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]
