idnits 2.17.1 draft-ietf-dnsind-sig-zero-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2535]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (December 1999) is 8871 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) == Unused Reference: 'RFC 1982' is defined on line 325, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 UPDATES RFC 2535 IBM 4 Expires: June 2000 December 1999 5 draft-ietf-dnsind-sig-zero-01.txt 7 DNS Request and Transaction Signatures ( SIG(0)s ) 8 --- ------- --- ----------- ---------- - ------- - 10 Status of This Document 12 This draft, file name draft-ietf-dnsind-sig-zero-01.txt, is intended 13 to become a Proposed Standard RFC updating Proposed Standard [RFC 14 2535]. Distribution of this document is unlimited. Comments should 15 be sent to the DNS Working Group mailing list 16 or to the author. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months. Internet-Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet- 27 Drafts as reference material or to cite them other than as a 28 ``working draft'' or ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 Extensions to the Domain Name System (DNS) are described in [RFC 39 2535] that can provide data origin and transaction integrity and 40 authentication to security aware resolvers and applications through 41 the use of cryptographic digital signatures. 43 Implementation experience has indicated the need for minor but non- 44 interoperable changes in Request and Transaction signature resource 45 records ( SIG(0)s ). These changes are documented herein. 47 Acknowledgments 49 The significant contributions and suggestions of the following 50 persons (in alphabetic order) to this draft are gratefully 51 acknowledged: 53 Olafur Gudmundsson 54 Brian Wellington 56 Table of Contents 58 Status of This Document....................................1 59 Abstract...................................................1 61 Acknowledgments............................................2 62 Table of Contents..........................................2 64 1. Introduction............................................3 65 2. SIG(0) Design Rationale.................................3 66 2.1 Transaction Authentication.............................3 67 2.2 Query Authentication...................................4 68 2.3 Keying.................................................4 69 2.4 Differences Between TSIG and SIG(0)....................4 71 3. The SIG(0) Resource Record..............................6 72 3.1 Calculating Request and Transaction SIGs...............6 73 3.2 Processing Responses and SIG(0) RRs....................7 74 3.3 SIG(0) Lifetime and Expiration.........................8 76 4. Security Considerations.................................9 77 5. IANA Considerations.....................................9 78 References.................................................9 80 Author's Address..........................................10 81 Expiration and File Name..................................10 82 Appendix: SIG(0) Changes from RFC 2535....................10 84 1. Introduction 86 This document makes minor but non-interoperable changes to part of 87 [RFC 2535], familiarity with which is assumed, and includes 88 additional explanatory text. These changes concern SIG Resource 89 Records (RRs) that are used to sign DNS requests and transactions / 90 responses. Such a resource record, because it has a type covered 91 field of zero, is frequently called a SIG(0). The changes are based 92 on implementation and attempted implementation experience with TSIG 93 [draft-ietf-dnsind-tsig-*.txt] and the [RFC 2535] specification for 94 SIG(0). 96 Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2 97 and 4.3. No changes are made herein related to the KEY or NXT RRs or 98 to the processing involved with data origin and denial authentication 99 for DNS data. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC 2119]. 105 2. SIG(0) Design Rationale 107 The authenticated data origin and data existence denial services of 108 secure DNS protect only data resource records (RRs) or 109 authenticatably deny their nonexistence. These services provide no 110 protection for DNS requests, no protection for message headers on 111 requests or responses, and no protection of the overall integrity of 112 a response. 114 If header bits are falsely set by a bad server, there is little that 115 can be done. However, it is possible to add transaction and query 116 authentication to be sure that queries and responses and not tampered 117 with in transit. 119 2.1 Transaction Authentication 121 Transaction authentication means that a requester can be sure it is 122 at least getting the messages from the server it queried and that the 123 response is from the request it sent (i.e., that these messages have 124 not been diddled in transit). This is accomplished by optionally 125 adding either a TSIG RR [draft-ietf-dnsind-tsig-*.txt] or, as 126 described herein, a SIG(0) resource record at the end of the response 127 which digitally signs the concatenation of the server's response and 128 the corresponding resolver query. 130 2.2 Query Authentication 132 Requests can also be authenticated by including a TSIG or, as 133 described herein, a special SIG(0) RR at the end of the request. 134 Authenticating requests serves no function in DNS servers the predate 135 the specification of dynamic update. Requests with a non-empty 136 additional information section produce error returns or may even be 137 ignored by a few such older DNS servers. However, this syntax for 138 signing requests is defined for authenticating dynamic update 139 requests [RFC 2136], TKEY requests [draft-ietf-dnsind-tkey-*.txt], or 140 future requests requiring authentication. 142 2.3 Keying 144 The private keys used in transaction security belong to the host 145 composing the DNS response message, not to the zone involved. 146 Request authentication may also involve the private key of the host 147 or other entity composing the request or of a zone to be affected by 148 the request or other private keys depending on the request authority 149 it is sought to establish. The corresponding public key(s) are 150 normally stored in and retrieved from the DNS for verification as KEY 151 RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY). 153 Because requests and replies are highly variable, message 154 authentication SIGs can not be pre-calculated. Thus it will be 155 necessary to keep the private key on-line, for example in software or 156 in a directly connected piece of hardware. 158 2.4 Differences Between TSIG and SIG(0) 160 There are significant differences between TSIG and SIG(0). 162 Because TSIG involves secret keys installed at both the requester and 163 server the presence of such a key implies that the other party 164 understands TSIG and likely has the same key installed. Furthermore, 165 TSIG uses keyed hash authentication codes which are relatively 166 inexpensive to compute. Thus it is common to authenticate requests 167 with TSIG and responses are authenticated with TSIG if the 168 corresponding request is authenticated. 170 SIG(0) on the other hand, uses public key authentication, where the 171 public keys are stored in DNS as KEY RRs. Thus, existence of such a 172 KEY RR does not necessarily imply implementation of SIG(0). In 173 addition, SIG(0) involves relatively expensive public key 174 cryptographic operations that should be minimized and the 175 verification of a SIG(0) involves obtaining and verifying the 176 corresponding KEY which can be an expensive and lengthy operation. 177 Indeed, a policy of using SIG(0) on all requests and verifying it 178 before responding would, for some configurations, lead to a deadly 179 embrace with the attempt to obtain and verify the KEY needed to 180 authenticate the request SIG(0) resulting in additional requests 181 accompanied by a SIG(0) leading to further requests accompanied by a 182 SIG(0), etc. Furthermore, omitting SIG(0)s when not required on 183 requests halves the number of public key operations required by the 184 transaction. 186 For these reasons, SIG(0)s SHOULD only be used on requests when 187 necessary to authenticate that the requester has some required 188 privilege or identity. SIG(0)s on replies are defined in such a way 189 as to not require a SIG(0) on the corresponding request and still 190 provide transaction protection. Some replies, such as those 191 involving TKEY [draft-ietf-dnsind-tkey-*.txt], MUST be authenticated 192 with TSIG or SIG(0). For other replies, whether they are 193 authenticated by the server or required to be authenticated by the 194 requester SHOULD be a local configuration option. 196 3. The SIG(0) Resource Record 198 The structure of and type number of SIG resource records (RRs) is 199 given in [RFC 2535] Section 4.1. However all of Section 4.1.8.1 and 200 the parts of Sections 4.2 and 4.3 related to SIG(0) should be 201 considered replaced by the material below. Any conflict between [RFC 202 2535] and this document concerning SIG(0) RRs should be resolved in 203 favor of this document. 205 For all transaction SIG(0)s, the signer field MUST be the name of the 206 originating server host and there MUST be a KEY RR at that name with 207 the public key corresponding to the private key used to calculate the 208 signature. (The inverse IP address mapping name MAY be used if the 209 relevant KEY is stored there.) 211 For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are 212 meaningless. The TTL fields SHOULD be zero and the CLASS filed 213 SHOULD be ANY. To conserve space, the owner name SHOULD be root (a 214 single zero octet). When SIG(0) authentication on a response is 215 desired, that SIG RR must be considered the highest priority of any 216 additional information for inclusion in the response. If the SIG(0) 217 RR cannot be added without causing the message to be truncated, the 218 server MUST alter the response so that a SIG(0) can be included. 219 This response consists of only the question and a SIG(0) record, and 220 has the TC bit set and RCODE 0 (NOERROR). The client SHOULD at this 221 point retry the request using TCP. 223 3.1 Calculating Request and Transaction SIGs 225 A DNS request may be optionally signed by including one or more 226 SIG(0)s at the end of the query additional information section. Such 227 SIGs are identified by having a "type covered" field of zero. They 228 sign the preceding DNS request message including DNS header but not 229 including the UDP/IP header or any request SIG(0)s at the end and 230 before the request RR counts have been adjusted for the inclusions of 231 any request SIG(0)s. 233 Note: requests and response can either have a TSIG or one or more 234 SIG(0)s but not both a TSIG and a SIG(0). 236 They are calculated by using a "data" (see [RFC 2535], Section 4.1.8) 237 of (1) the SIG's RDATA section omitting the signature subfield 238 itself, (2) the entire DNS query messages, including DNS header, but 239 not the UDP/IP header or any SIG(0) and before the reply RR counts 240 have been adjusted for the inclusion of any SIG(0). That is 242 data = RDATA | request - SIG(0)s 244 where "|" is concatenation and RDATA is the RDATA of the SIG(0) being 245 calculated less the signature itself. 247 Similarly, a SIG(0) can be used to secure a response and the request 248 that produced it. Such transaction signatures are calculated by 249 using a "data" of (1) the SIG's RDATA section omitting the signature 250 itself, (2) the entire DNS query message that produced this response, 251 including the query's DNS header and any SIG(0)s but not its UDP/IP 252 header, and (3) the entire DNS response message, including DNS header 253 but not the UDP/IP header or any SIG(0) and before the response RR 254 counts have been adjusted for the inclusion of any SIG(0). 256 That is 258 data = RDATA | full query | response - SIG(0)s 260 where "|" is concatenation and RDATA is the RDATA of the SIG(0) being 261 calculated less the signature itself. 263 Verification of a response SIG(0) (which is signed by the server host 264 key, not the zone key) by the requesting resolver shows that the 265 query and response were not tampered with in transit, that the 266 response corresponds to the intended query, and that the response 267 comes from the queried server. 269 In the case of a DNS message via TCP, a SIG(0) on the first data 270 packet is calculated with "data" as above and for each subsequent 271 packet, it is calculated as follows: 273 data = RDATA | DNS payload - SIG(0)s | previous packet 275 where "|" is concatenations, RDATA is as above, and previous packet 276 is the previous DNS payload including DNS header and any SIG(0)s but 277 not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an 278 alternative, TSIG may be used after, if necessary, setting up a key 279 with TKEY [draft-ietf-dnsind-tkey-*.txt]. 281 Except where needed to authenticate an update, TKEY, or similar 282 privileged request, servers are not required to check request SIGs. 284 3.2 Processing Responses and SIG(0) RRs 286 If a SIG RR is at the end of the additional information section of a 287 response and has a type covered of zero, it is a transaction 288 signature covering the response and the query that produced the 289 response. For TKEY responses, it MUST be checked and the message 290 rejected if the checks fail. For all other responses, it MAY be 291 checked and the message rejected if the checks fail. 293 If a response SIG(0) checks succeed, such a transaction 294 authentication SIG does NOT directly authenticate the validity any 295 data-RRs in the message. However, it authenticates that they were 296 sent by the queried server and have not been diddled. (Only a proper 297 SIG(0) RR signed by the zone or a key tracing its authority to the 298 zone or to static resolver configuration can directly authenticate 299 data-RRs, depending on resolver policy.) If a resolver or server does 300 not implement transaction and/or request SIGs, it MUST ignore them 301 without error where they are optional and treat them as failing where 302 they are required. 304 3.3 SIG(0) Lifetime and Expiration 306 The inception and expiration times in SIG(0)s are for the purpose of 307 resisting replay attacks. They should be set to form a time bracket 308 such that messages outside that bracket can be ignored. In IP 309 networks, this time bracket should not normally extend further than 5 310 minutes into the past and 5 minutes into the future. 312 4. Security Considerations 314 No additional considerations beyond those in [RFC 2535]. 316 The inclusion of the SIG(0) inception and expiration time under the 317 signature improves resistance to replay attacks. 319 5. IANA Considerations 321 No new fields are created or field values assigned by the document. 323 References 325 [RFC 1982] - Robert Elz, Randy Bush, "Serial Number Arithmetic", 326 09/03/1996. 328 [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate 329 Requirement Levels", March 1997. 331 [RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic 332 Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. 334 [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", 335 March 1999. 337 [draft-ietf-dnsind-tsig-*.txt] - P. Vixie, O. Gudmundsson, D. 338 Eastlake, B. Wellington, "Secret Key Transaction Signatures for DNS 339 (TSIG)". 341 [draft-ietf-dnsind-tkey-*.txt] - D. Eastlake, "Secret Key 342 Establishment for DNS (RR)" 344 Author's Address 346 Donald E. Eastlake 3rd 347 IBM 348 65 Shindegan Hill Road 349 Carmel, NY 10512 USA 351 Telephone: +1-914-276-2668(h) 352 +1-914-784-7913(w) 353 fax: +1-914-276-2947(h) 354 email: dee3@us.ibm.com 356 Expiration and File Name 358 This draft expires June 2000. 360 Its file name is draft-ietf-dnsind-sig-zero-01.txt. 362 Appendix: SIG(0) Changes from RFC 2535 364 Add explanatory text concerning the differences between TSIG and 365 SIG(0). 367 Change the data over which SIG(0) is calculated to include the SIG(0) 368 RDATA other than the signature itself to secure the signature 369 inception and expiration times and resist replay attacks. Specify 370 SIG(0) for TCP. 372 Add discussion of appropriate inception and expiration times for 373 SIG(0). 375 Change wording to permit mixing TSIG and SIG(0) RRs. 377 Reword some areas for clarity.