idnits 2.17.1 draft-ietf-dnsind-tsig-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 95 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 130 has weird spacing: '...hm Name doma...' == Line 134 has weird spacing: '...re Size u_in...' == Line 135 has weird spacing: '... stream defi...' == Line 148 has weird spacing: '... RdLen as ap...' == Line 157 has weird spacing: '...re Size as a...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1996) is 10016 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1034' on line 309 looks like a reference -- Missing reference section? 'RFC1035' on line 312 looks like a reference -- Missing reference section? 'DNSSEC' on line 326 looks like a reference -- Missing reference section? 'UPDATE' on line 330 looks like a reference -- Missing reference section? 'MD5' on line 105 looks like a reference -- Missing reference section? 'HMAC' on line 334 looks like a reference -- Missing reference section? 'RFC1321' on line 315 looks like a reference -- Missing reference section? 'RFC1521' on line 318 looks like a reference -- Missing reference section? 'RFC1750' on line 322 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSIND Working Group Paul Vixie (Ed.) (ISC) 3 INTERNET-DRAFT Olafur Gudmundsson (TIS) 4 Donald Eastlake 3rd (CyberCash) 5 November 1996 7 Amends: RFC 1035 9 Secret Key Transaction Signatures for DNS (TSIG) 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This protocol allows for transaction level authentication using 32 shared secrets and one way hashing. It can be used to authenticate 33 dynamic updates as coming from an approved client, or to authenticate 34 responses as coming from an approved recursive name server. 36 No provision has been made here for distributing the shared secrets; 37 it is expected that a network administrator will statically configure 38 name servers and clients using some out of band mechanism such as 39 sneaker-net. 41 1 - Introduction 43 1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated 44 hierarchical distributed database system that provides information 45 fundamental to Internet operations, such as name <=> address translation 46 and mail handling information. DNS has recently been extended [DNSSEC] 47 to provide for data origin authentication, public key distribution, and 48 query and transaction authentication, all based on public key 49 cryptography and public key based digital signatures. To be practical, 50 this form of security generally requires extensive local caching of keys 51 and tracing of authentication through multiple keys and signatures to a 52 pre-trusted locally configured key. 54 1.2. One difficulty with the [DNSSEC] scheme is that common DNS 55 implementations include simple ``stub'' resolvers which do not have 56 caches. Such resolvers typically rely on a caching DNS server on 57 another host. It is impractical for these stub resolvers to perform 58 general [DNSSEC] authentication and they would naturally depend on their 59 caching DNS server to perform such services for them. To do so securely 60 requires secure communication of queries and responses. [DNSSEC] 61 provides public key transaction signatures to support this but such 62 signatures are very expensive computationally to generate. In general, 63 these require the same complex public key logic that is impractical for 64 stubs. This document specifies an efficient secret key based 65 transaction signature that avoids these difficulties. 67 1.3. A second area where use of straight [DNSSEC] public key based 68 mechanisms may be impractical is authenticating dynamic update [UPDATE] 69 requests. [DNSSEC] provides for query/request signatures but with 70 [DNSSEC] they, like transaction signatures, require computationally 71 expensive public key cryptography and complex authentication logic. 72 This document's secret key based signatures can be used to authenticate 73 DNS update requests as well as transaction responses. 75 1.4. The signature mechanism proposed in this document uses shared 76 secret keys to establish trust relationship between two entities. Such 77 keys must be protected in a fashion similar to private keys, or anyone 78 can masquerade one of the parties (forge signatures). There is a urgent 79 need to provide some authentication between clients and local servers 80 and this proposal addresses this need. This proposal is unsuitable for 81 general server to server authentication for servers which speak with 82 many other servers. But it is suitable for many resolvers on hosts that 83 only talk to few recursive servers. 85 1.5. A server acting as a caching resolver -- a ``slave forwarder'' in 86 common usage -- might use transaction signatures when communicating with 87 its small number of preconfigured ``upstream'' servers. TSIG may also 88 be suitable for use on zone transfers to secondaries. Other uses of DNS 89 secret key signatures and possible systems for automatic secret key 90 distribution may be proposed in separate future documents. 92 2 - TSIG RR Format 94 2.1. To provide secret key signatures, we use a new RR type whose 95 mnemonic is TSIG. TSIG is a meta-RR and can not be stored, its type code 96 is TBD. TSIG RRs can be used for authentication between DNS entities 97 that have established a shared secret key. TSIG RRs are dynamically 98 computed to cover a particular DNS query or transaction and are not DNS 99 RRs in the usual sense. 101 2.2. As the TSIG RRs are related to one DNS query/response there is no 102 value in storing or retransmitting them, thus the TSIG RR should be 103 discarded once it has been used to authenticate DNS packet. The only 104 Message Digest algorithm specified in this document is ``HMAC-MD5'' (see 105 [MD5], [HMAC]). Other algorithms can be specified at later date. Names 106 and definitions of new algorithms should be registered with IANA. 108 2.3. Record Format: 110 NAME A domain name of the key used, the name should reflect the 111 names of the hosts and uniquely identify the key among a set 112 of keys these two hosts may share at any given time. If hosts 113 A and B in same zone share a key then the key name could be A- 114 B-.. If two host in different zone share the key 115 the key name could be .A..B. It should be 116 possible for more than one key to be in simultaneous use among 117 a set of interacting hosts. 119 TYPE TSIG (Transaction SIGnature). 121 CLASS IN 123 TTL 0 125 RdLen (variable) 126 RDATA 128 Field Name Data Type Notes 129 ---------------------------------------------------------------- 130 Algorithm Name domain-name points to an RP RR giving the 131 algorithm definer's address. 132 Time Signed u_int32_t seconds since 1-Jan-70 UTC. 133 Expire u_int32_t set to estimate of RTT/2+fudge. 134 Signature Size u_int16_t number of octets in Signature. 135 Signature octet stream defined by Algorithm Name. 136 Other Data undefined ignore any following RDATA. 138 2.4. Example: 140 NAME GW-DENVAX-0042.HOME.VIX.COM. 142 TYPE TSIG 144 CLASS IN 146 TTL 0 148 RdLen as appropriate 150 RDATA 152 Field Name Contents 153 ------------------------------------ 154 Algorithm Name HMAC-MD5.IANA.ORG. 155 Time Signed 853804800 156 Expire 853805400 157 Signature Size as appropriate 158 Signature as appropriate 160 2.5. All multioctet integers described above are sent in network byte 161 order. 163 3 - HMAC-MD5 Details 165 3.1. The only algorithm defined in this document is HMAC-MD5. (Note: 166 HMAC-MD5 does not suffer from the possible weaknesses that have been 167 found in MD5.) The HMAC-MD5 operation for a query signature is: 169 MD5( K xor OPAD, MD5( K xor IPAD, DATA)) 171 K The KEY used or an MD5 message digest of the key if the key is 172 longer than 64 bytes. The key or digest is padded to 64 bytes 173 by appending the NUL bytes (0x00) as needed. 175 IPAD A 64 byte string with the value 0x36 in each byte. 177 OPAD A 64 byte string with the value 0x5C in each byte. 179 DATA The data being signed as described in section 4 below and 180 appened by the expiration time in network byte order. 182 4 - Protocol Operation 184 4.1. Once the outgoing packet has been constructed, the keyed message 185 digest operation can be performed. The resulting message digest will 186 then be stored in a TSIG which is appended to the additional data 187 section. Appending a query or transaction signature to an DNS message 188 is not allowed to result in a truncated response, TCP connection must be 189 used to prevent the truncation. 191 4.2. Upon receipt of a message with a TSIG RR, the TSIG RR is copied to 192 a safe location, removed from the DNS Message, and decremented out of 193 the DNS Message Header's ARCOUNT. At this point the keyed message 194 digest operation is performed. If the algorithm name or key name is 195 unknown to the recipient, or if the message digests do not match, the 196 whole DNS Message must be discarded and a response with RCODE 5 197 (REFUSED) should be sent back to the originator. A message to the 198 system operations log should to be generated in this case, to warn the 199 operations staff of a possible security incident in progress. 201 4.3. Expire check, if the value of expire field is in the past this 202 transaction should be assumed to be an replay attack, and RCODE 5 203 (REFUSED) should returned. For expire to work correctly it is 204 recommended that all machines using TSIG signatures use clock 205 synchronization. If clock synchronization is not used the ``Fudge'' has 206 to be larger but ``Fudge'' should always be less or equal than the 207 smallest TTL of the RR in the message. 209 5 - Protocol Details 211 5.1. Client performs the message digest operation and appends TSIG to 212 additional data section and transmits query to server. The data 213 digested is the whole outgoing DNS packet in wire format, before the 214 TSIG RR has been added to the additional data section and before the DNS 215 Message Header's ARCOUNT field has been incremented to contain the TSIG 216 RR. The client must store the message digest from the query while 217 waiting for an answer. Note that some older name servers will not 218 accept queries with a nonempty additional data section, but clients will 219 only attempt signed transactions against servers who are known to 220 support TSIG and share some secret key with the client. 222 5.2. Upon receipt of a message, server will check if there is a TSIG RR. 223 If one exists, it requires the server to return a TSIG RR in the 224 response. If the request's TSIG does not validate, the server responds 225 with RCODE 9 (NOTAUTH) if OPCODE is 0 (UPDATE, else with RCODE 5 226 (REFUSED). 228 5.3. When server has generated a response, it calculates the keyed 229 digest over the concatenation of the keyed message digest field from the 230 TSIG on the query and the whole outgoing DNS answer packet in wire 231 format before the answer TSIG RR has been added and before the ARCOUNT 232 field has been incremented for it. That is, the data to be digested is: 234 message digest from query | dnsANSWER 236 TSIG is appended and the response is sent. The inclusion of the message 237 digest from the query binds the response to the initiating request. 239 5.4. When a client receives a response from a server it expects a TSIG 240 from, it first checks if the TSIG RR is present in the reply, if not the 241 reply is treated as having a format error. The client then extracts the 242 TSIG, adjusts the ARCOUNT, and calculates the keyed digest in the same 243 way as the server. If the TSIG does not validate, that response must be 244 discarded. 246 5.5. This protocol allows the client and server to share multiple 247 secrets, if the server rejects a particular secret by sending back 248 either REFUSED or NOTAUTH, the client can either try the next secret, or 249 give up on this server. 251 5.6. A server acting as a Forwarding Server of a DNS packet, should 252 check for the existence of the TSIG record. If the name on the TSIG is 253 not of a secret that the server shares with the originator the server 254 will forward the packet unchanged including the TSIG. If the name of 255 the TSIG is of a key this server shares with the originator it processes 256 the TSIG. If the TSIG passes checks the forwarding server has the 257 obligation of including a TSIG of his own, using a shared secret it 258 shares with the destination or if that is not available then use one it 259 shares with the next forwarder on the path to the destination. 261 6 - Shared Secrets 263 6.1. Secret keys are very sensitive information and all available steps 264 should be taken to protect them on every host on which they are stored. 265 Generally such hosts need to be physically protected. If they are 266 multi-user machines, great care should be taken that unprivileged users 267 have no access to me keying material. Resolvers usually run 268 unprivileged, which means all users of a host will usually be able to 269 see whatever configuration data is used by the resolver. 271 6.2. A name server usually runs privileged, which means its 272 configuration data need not be visible to all users of the host. For 273 this reason, a host that implements transaction signatures should 274 probably be configured with a ``stub resolver'' and a local 275 ``caching/forwarding name server.'' This presents a special problem for 276 [UPDATE] which otherwise depends on clients to communicate only with a 277 zone's authoritative name servers. 279 6.3. Use of strong random shared secrets is essential to the security of 280 TSIG. See RFC1750 for a discussion of this issue. The secret should be 281 at least as long as the keyed message digest digest, i.e., 16 bytes for 282 HMAC-MD5. 284 7 - Security Considerations 286 7.1. The approach specified here is computationally much less expensive 287 that the query and transaction signatures specified in [DNSSEC]. In 288 addition, it is believed that MD5 is less subject to governmental 289 restrictions than the RSA algorithm of [DNSSEC]. As long as the shared 290 secret key is not compromised, strong authentication is provided for the 291 last hop from a local name server to the user resolver. 293 7.2. Secret keys should be changed periodically. If the client host has 294 been broken into, the server should suspend the use of all secrets known 295 to that client. If possible, secrets should be stored in encrypted 296 form. Secrets should never be transmitted in the clear over any wire. 297 This document does not address the issue on how to distribute secrets. 299 7.3. This mechanism does not authenticate source data, only its 300 transmission between two parties who share some secret. The original 301 source data can come from a compromised zone master or can be corrupted 302 during transit from an authentic zone master to some ``caching 303 forwarder.'' However, if the server is faithfully performing the full 304 [DNSSEC] security checks, then only security checked data will be 305 available to the client. 307 8 - References 309 [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' 310 RFC 1034, ISI, November 1987. 312 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 313 Specification,'' RFC 1034, ISI, November 1987. 315 [RFC1321] R. Rivest, ``The MD5 Message-Digest Algorithm,'' RFC 1321, 316 MIT LCS & RSA Data Security, Inc., April 1992. 318 [RFC1521] N. Borenstein, N. Freed, ``MIME (Multipurpose Internet Mail 319 Extensions) Part One,'' RFC 1521, Bellcore & Innosoft, 320 September 1993. 322 [RFC1750] D. Eastlake, S. Crocker, J. Schiller, ``Randomness 323 Recommendations for Security,'' RFC 1750, DEC, CyberCash & 324 MIT, December 1995. 326 [DNSSEC] D. Eastlake , C Kaufman, ``Domain Name System Security 327 Extensions,'' draft-ietf-dnssec-secext-10.txt, CyberCash & 328 Iris, August 1996. 330 [UPDATE] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic 331 Updates in the Domain Name System,'' , ISC & Bellcore & Cisco & DEC, November 1996. 334 [HMAC] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5 335 for Message Authentication,'' draft-ietf-ipsec-hmac- 336 md5-01.txt, IBM, UCSD & IBM, November, 1996. 338 9 - Author's Addresses 340 Paul Vixie Olafur Gudmundsson 341 Internet Software Consortium Trusted Information Systems 342 Star Route Box 159A 3060 Washington Road, Route 97 343 Woodside, CA 94062 Glenwood, MD 21738 344 +1 415 747 0204 +1 301 854 6889 345 347 Donald E. Eastlake 3rd. 348 CyberCash, Inc. 349 318 Acton Street 350 Carlisle, MA 01741 351 +1 508 287 4877 352