DNSIND Working Group Paul Vixie (Ed.) (ISC) INTERNET-DRAFT Olafur Gudmundsson (TIS) Donald Eastlake 3rd (CyberCash) 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). 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. 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-.. If two host in different zone share the key the key name could be .A..B. 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 RDATA 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: NAME GW-DENVAX-0042.HOME.VIX.COM. TYPE TSIG CLASS IN TTL 0 RdLen as appropriate RDATA 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 order. 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 (REFUSED). 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 discarded. 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 HMAC-MD5. 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,'' , 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 Donald E. Eastlake 3rd. CyberCash, Inc. 318 Acton Street Carlisle, MA 01741 +1 508 287 4877 Expires May 1997 [Page 9]