idnits 2.17.1 draft-ietf-dnsind-tsig-00.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-25) 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 68 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (September 1996) is 10084 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? 'DNSSEC' on line 69 looks like a reference -- Missing reference section? 'UPDATE' on line 215 looks like a reference -- Missing reference section? 'MD5' on line 91 looks like a reference -- Missing reference section? 'HMAC' on line 246 looks like a reference -- Missing reference section? 'RFC1321' on line 239 looks like a reference -- Missing reference section? 'RFC1521' on line 242 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSIND Working Group Paul Vixie (Ed.) (ISC) 2 INTERNET-DRAFT Olafur Gudmundsson (TIS) 3 September 1996 5 Amends: RFC 1035 7 Simple Transaction Signature for DNS 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This protocol allows for transaction level authentication using 30 shared secrets and one way hashing. It can be used to authenticate 31 dynamic updates as coming from an approved client, or to authenticate 32 responses as coming from an approved caching/forwarding name server. 34 No provision has been made here for distributing the shared secrets; 35 it is expected that a network administrator will statically configure 36 name servers and clients using some out of band mechanism such as 37 sneaker-net. 39 1 - Motivation 41 1.1. [DNSSEC] creates a framework for authenticating DNS data by DNS 42 Resolvers and servers. To do this securely a chain of trusted Keys must 43 be constructed to a Key that is unconditionally trusted (preconfigured). 44 For expediency nameservers will store large caches of KEYs. If a name 45 server does not have a KEY that it needs to authenticate RRs in an 46 incoming message, it must query for that KEY before it can pass the 47 original data on as secure. 49 1.2, Common DNS implementations use ``stub'' resolvers, which do not 50 have caches. Thus it is impractical in most cases for resolvers to 51 perform [DNSSEC] authentication. To overcome this problem, [DNSSEC] 52 includes Transaction Signatures. Unfortunately, Transaction Signatures 53 with the RSA algorithm are expensive to generate, and [DNSSEC]'s RR 54 format is difficult to encode and decode. A cheaper and necessarily 55 less secure way of performing transaction authentication is required. 56 This document specifies a standard inexpensive transaction signature for 57 use in certain cases. 59 1.3. There are two main requirements for this. In [UPDATE], messages 60 may originate from hosts that do not support encryption. It is a 61 terrible idea to allow clients to update DNS servers without any 62 authentication. The second requirement is to allow resolvers to 63 authenticate the response they got from a local query came from a 64 trusted server. 66 1.4. The mechanism proposed here uses shared secret keys to establish 67 trust relationship between two entities. This key must be protected or 68 anyone can mascarade one of the parties. [DNSSEC] transaction 69 signatures are much stronger and as [DNSSEC] uses Public/Private KEY 70 algorithms the Public KEY can be advertised. There is a urgent need to 71 provide some authentication between clients and local servers. This 72 proposal is unsuitable for server to server authentication, due to the 73 fact that resolvers on user machines only talk to few local servers. 74 Servers on the other hand talk to many other servers. A server acting 75 as a caching resolver -- a ``slave forwarder'' in common usage -- might 76 use transaction signatures when communicating with its small number of 77 preconfigured ``upstream'' servers. 79 2 - TSIG RR Format 81 2.1. To provide the authentication between server and client, we use a 82 new RR type whose mnuemonic is TSIG, and whose type code is UNASSIGNED. 83 TSIG RRs can be used for authenticating a previously established context 84 between the clients and servers who are supplied with and configured to 85 use a shared secret key. 87 2.2. As the TSIG RRs are related to one DNS query/response there is no 88 value in storing or retransmitting them, thus the TSIG RR should be 89 discarded once it has been used to authenticate DNS packet. The only 90 Message Digest algorithm specified in this document is "MD5" (see 91 [MD5]). Other algorithms can be specified at later date. Names and 92 definitions of new algorithms must be registered with IANA. 94 2.3. The TSIG RR has the same syntax as the TXT RR (see [RFC1034 95 3.3.14]), with each treated as a field, with 96 boundaries between s being significant, and with at 97 least one field always present. 99 NAME The owner name of the TSIG RR is the name of the shared 100 secret, which allows a resolver to use a different secret for 101 each of its recursive name servers, and allows a server to 102 know different secrets for each of its client resolvers. This 103 owner name is not registered in the Domain Name System. 105 TYPE TSIG (Transaction SIGnature). 107 CLASS expiration (offset from "now"), in seconds; set to estimate of 108 RTT + fudge. 110 TTL "now" (time since 1 Jan 1970, 00:00 UTC, 32 bit unsigned), in 111 seconds. 113 RDATA As for TXT RR, with each treated as a 114 field. The first field is the algorythm name, e.g., "MD5". 115 The second and following fields are the Message Digest in 116 Base64 encoding (see [RFC1521 5.2]). 118 2.4. Note that the Message Digest is represented by all TXT subparts 119 after the first. It is possible that the Message Digest will be empty, 120 or will be representable with one (1) , or will be 121 represented by many s. In either case, ordering and boundaries can be significant and must be stable 123 during storage and forwarding, even across internal program APIs. 125 3 - HMAC-MD5 Details 127 3.1. There are some concerns about the strength of MD5. To make MD5 128 more secure, the HMAC mechanism has been proposed. This draft specifies 129 the use of the HMAC mechanism (see [HMAC]). The HMAC operation is: 131 MD5( K xor OPAD, MD5( K xor IPAD, DNSDATA)) 133 K The KEY used or a message digest of the key if the key is 134 longer than 64 bytes. The key is padded to 64 bytes by 135 appending the NUL bytes (0x00) as needed. 137 IPAD A 64 byte string with the value 0x36 in each byte. 139 OPAD A 64 byte string with the value 0x5C in each byte. 141 DNSDATA The data the whole outgoing DNS packet in wire format, 142 before the TSIG RR has been added to the additional data 143 section and before the DNS Message Header's ARCOUNT field 144 has been incremented to contain the TSIG RR. 146 4 - Message Digest Operation 148 4.1. Once the outgoing packet has been constructed, the message digest 149 operation can be performed. The resulting message digest will then be 150 stored in a TSIG which is appended to the additional data section. 151 Appending a Transaction signature to an DNS transaction is not allowed 152 to result in a truncated response, TCP connection must be used to 153 prevent the truncation. 155 4.2. Upon receipt of a packet with a TSIG RR, the TSIG RR is copied to a 156 safe location, removed from the DNS Message, and decremented out of the 157 DNS Message Header's ARCOUNT. At this point the message digest 158 operation is performed. If the algorythm name or key name is unknown to 159 the recipient, or if the message digests do not match, the whole DNS 160 Message must be discarded and a response with RCODE 5 (REFUSED) should 161 be sent back to the sender. A message to the system operations log 162 ought to be generated in this case, to warn the operations staff of a 163 possible security incident in progress. 165 5 - Protocol Details 167 5.1. Client performs the message digest operation and appends TSIG to 168 additional data section and transmits query to server. The client must 169 store the message digest from the query while waiting for an answer. 170 Note that some older name servers will not accept queries with a 171 nonempty additional data section, but clients will only attempt signed 172 transactions against servers who are known to support TSIG and to share 173 some secret key. 175 5.2. Upon receipt of a QUERY, server will check if there is a TSIG RR, 176 if one exists, it requires the server to return a TSIG RR in the 177 response. If the query TSIG does not validate, the server responds with 178 RCODE 5 (REFUSED) if OPCODE is 0 (QUERY) or RCODE 9 (NOTAUTH) if the 179 opcode is 5 (UPDATE). 181 5.3. When server has generated a response, it calculates the a digest. 182 The DNSSDATA in this case is: 184 message digest from query | dnsANSWER 186 TSIG is appended and the response is sent. The inclusion of the message 187 digest from the query binds the response to the initiating request. 189 5.4. When a client receives a response from a server it expects a TSIG 190 from, it first checks if the TSIG RR is present in the reply, if not the 191 reply is treated as having a format error. Client performs the TSIG 192 adjustment and calculates the message digest over: 194 message digest from query | dnsANSWER 196 5.5. This protocol allows client and server to share multiple secrets, 197 if server rejects a particular secret by sending back either REFUSED or 198 NOTAUTH the client can either try the next secret, or give up on this 199 server. 201 6 - Storage of Shared Secrets 203 6.1. Resolvers usually run unprivileged, which means all users of a host 204 will usually be able to see whatever configuration data is used by the 205 resolver. This presents a problem in that the shared secrets probably 206 ought not to be visible to anyone except the network or system manager. 207 In the absence of a Public Key Algorythm, there is no way to make the 208 resolver's share secrets secure. 210 6.2. A name server usually runs privileged, which means its 211 configuration data need not be visible to all users of the host. For 212 this reason, a host that implements transaction signatures should 213 probably be configured with a ``stub resolver'' and a local 214 ``caching/forwarding name server.'' This presents a special problem for 215 [UPDATE] which otherwise depends on clients to communicate only with a 216 zone's authoritative name servers. 218 7 - Security Considerations 220 The approach specified here is weaker than an RSA/MD5 transaction 221 signature, but this approach is computationally much less expensive, 222 easier to implement and easier to configure. MD5 implementations are 223 common and are not restricted anywhere in the world, unlike RSA. The 224 main goal here is to provide protection of DNSDATA on the last hop from 225 the local name server to the user resolver. The authentication provided 226 here is better than nothing and allows protection against some attacks, 227 as long as the shared secret key is not compromised. 229 Secret keys should be changed periodically. If client host has been 230 broken into, server should suspend the use of all secrets known to that 231 client. If possible, secrets should be stored in encrypted form. 232 Secrets should never be transmitted in the clear over any wire. This 233 draft does not address the issue on how to distribute and store secrets. 234 One vulnerability is that someone may find a way to calculate the shared 235 secret key given enough data. 237 8 - References 239 [RFC1321] Rivest, R., ``The MD5 Message-Digest Algorithm,'' RFC 1321, 240 MIT LCS & RSA Data Security, Inc., April 1992. 242 [RFC1521] N. Borenstein, N. Freed, ``MIME (Multipurpose Internet Mail 243 Extensions) Part One,'' RFC 1521, Bellcore & Innosoft, 244 September 1993. 246 [HMAC] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5 247 for Message Authentication,'' draft-ietf-ipsec-hmac- 248 md5-00.txt, March, 1996. 250 9 - Author's Addresses 252 Paul Vixie Olafur Gudmundsson 253 Internet Software Consortium Trusted Information Systems 254 Star Route Box 159A 3060 Washington Road, Route 97 255 Woodside, CA 94062 Glenwood, MD 21738 256 +1 415 747 0204 +1 301 854 6889 257