Secret Key Transaction Authentication for DNS (TSIG) (RFC2845)
Original Publication Date: 2000-May-01
Included in the Prior Art Database: 2019-Feb-13
Internet Society Requests For Comment (RFCs)
P. Vixie: AUTHOR [+3]
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. [STANDARDS-TRACK]
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 (C) The Internet Society (2000). All Rights Reserved.
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]...