idnits 2.17.1 draft-ietf-dnsext-sig-zero-02.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 (June 2000) is 8716 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 319, 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 Motorola 4 Expires: December 2000 June 2000 6 DNS Request and Transaction Signatures ( SIG(0)s ) 7 --- ------- --- ----------- ---------- - ------- - 8 10 Status of This Document 12 This draft is intended to become a Proposed Standard RFC updating 13 Proposed Standard [RFC 2535]. Distribution of this document is 14 unlimited. Comments should be sent to the DNS Working Group mailing 15 list or to the author. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 Extensions to the Domain Name System (DNS) are described in [RFC 37 2535] that can provide data origin and transaction integrity and 38 authentication to security aware resolvers and applications through 39 the use of cryptographic digital signatures. 41 Implementation experience has indicated the need for minor but non- 42 interoperable changes in Request and Transaction signature resource 43 records ( SIG(0)s ). These changes are documented herein. 45 Acknowledgments 47 The contributions and suggestions of the following persons (in 48 alphabetic order) to this draft are gratefully acknowledged: 50 Olafur Gudmundsson 51 Ed Lewis 52 Erik Nordmark 53 Brian Wellington 55 Table of Contents 57 Status of This Document....................................1 58 Abstract...................................................1 60 Acknowledgments............................................2 61 Table of Contents..........................................2 63 1. Introduction............................................3 64 2. SIG(0) Design Rationale.................................3 65 2.1 Transaction Authentication.............................3 66 2.2 Request Authentication.................................4 67 2.3 Keying.................................................4 68 2.4 Differences Between TSIG and SIG(0)....................4 69 3. The SIG(0) Resource Record..............................5 70 3.1 Calculating Request and Transaction SIGs...............6 71 3.2 Processing Responses and SIG(0) RRs....................7 72 3.3 SIG(0) Lifetime and Expiration.........................7 73 4. Security Considerations.................................7 74 5. IANA Considerations.....................................8 75 References.................................................8 77 Author's Address...........................................9 78 Expiration and File Name...................................9 79 Appendix: SIG(0) Changes from RFC 2535.....................9 81 1. Introduction 83 This document makes minor but non-interoperable changes to part of 84 [RFC 2535], familiarity with which is assumed, and includes 85 additional explanatory text. These changes concern SIG Resource 86 Records (RRs) that are used to digitally sign DNS requests and 87 transactions / responses. Such a resource record, because it has a 88 type covered field of zero, is frequently called a SIG(0). The 89 changes are based on implementation and attempted implementation 90 experience with TSIG [draft-ietf-dnsext-tsig-*.txt] and the [RFC 91 2535] specification for SIG(0). 93 Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2 94 and 4.3. No changes are made herein related to the KEY or NXT RRs or 95 to the processing involved with data origin and denial authentication 96 for DNS data. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC 2119]. 102 2. SIG(0) Design Rationale 104 SIG(0) provides protection for DNS transactions and requests that is 105 not provided by the regular SIG, KEY, and NXT RRs specified in [RFC 106 2535]. The authenticated data origin services of secure DNS either 107 provide protected data resource records (RRs) or authenticatably deny 108 their nonexistence. These services provide no protection for glue 109 records, DNS requests, no protection for message headers on requests 110 or responses, and no protection of the overall integrity of a 111 response. 113 2.1 Transaction Authentication 115 Transaction authentication means that a requester can be sure it is 116 at least getting the messages from the server it queried and that the 117 received messages are in response to the query it sent. This is 118 accomplished by optionally adding either a TSIG RR [draft-ietf- 119 dnsext-tsig-*.txt] or, as described herein, a SIG(0) resource record 120 at the end of the response which digitally signs the concatenation of 121 the server's response and the corresponding resolver query. 123 2.2 Request Authentication 125 Requests can also be authenticated by including a TSIG or, as 126 described herein, a special SIG(0) RR at the end of the request. 127 Authenticating requests serves no function in DNS servers the predate 128 the specification of dynamic update. Requests with a non-empty 129 additional information section produce error returns or may even be 130 ignored by a few such older DNS servers. However, this syntax for 131 signing requests is defined for authenticating dynamic update 132 requests [RFC 2136], TKEY requests [draft-ietf-dnsext-tkey-*.txt], or 133 future requests requiring authentication. 135 2.3 Keying 137 The private keys used in transaction security belong to the host 138 composing the DNS response message, not to the zone involved. 139 Request authentication may also involve the private key of the host 140 or other entity composing the request or of a zone to be affected by 141 the request or other private keys depending on the request authority 142 it is sought to establish. The corresponding public key(s) are 143 normally stored in and retrieved from the DNS for verification as KEY 144 RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY). 146 Because requests and replies are highly variable, message 147 authentication SIGs can not be pre-calculated. Thus it will be 148 necessary to keep the private key on-line, for example in software or 149 in a directly connected piece of hardware. 151 2.4 Differences Between TSIG and SIG(0) 153 There are significant differences between TSIG and SIG(0). 155 Because TSIG involves secret keys installed at both the requester and 156 server the presence of such a key implies that the other party 157 understands TSIG and very likely has the same key installed. 158 Furthermore, TSIG uses keyed hash authentication codes which are 159 relatively inexpensive to compute. Thus it is common to authenticate 160 requests with TSIG and responses are authenticated with TSIG if the 161 corresponding request is authenticated. 163 SIG(0) on the other hand, uses public key authentication, where the 164 public keys are stored in DNS as KEY RRs and a private key is stored 165 at the signer. Existence of such a KEY RR does not necessarily imply 166 implementation of SIG(0). In addition, SIG(0) involves relatively 167 expensive public key cryptographic operations that should be 168 minimized and the verification of a SIG(0) involves obtaining and 169 verifying the corresponding KEY which can be an expensive and lengthy 170 operation. Indeed, a policy of using SIG(0) on all requests and 171 verifying it before responding would, for some configurations, lead 172 to a deadly embrace with the attempt to obtain and verify the KEY 173 needed to authenticate the request SIG(0) resulting in additional 174 requests accompanied by a SIG(0) leading to further requests 175 accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when not 176 required on requests halves the number of public key operations 177 required by the transaction. 179 For these reasons, SIG(0)s SHOULD only be used on requests when 180 necessary to authenticate that the requester has some required 181 privilege or identity. SIG(0)s on replies are defined in such a way 182 as to not require a SIG(0) on the corresponding request and still 183 provide transaction protection. For other replies, whether they are 184 authenticated by the server or required to be authenticated by the 185 requester SHOULD be a local configuration option. 187 3. The SIG(0) Resource Record 189 The structure of and type number of SIG resource records (RRs) is 190 given in [RFC 2535] Section 4.1. However all of Section 4.1.8.1 and 191 the parts of Sections 4.2 and 4.3 related to SIG(0) should be 192 considered replaced by the material below. Any conflict between [RFC 193 2535] and this document concerning SIG(0) RRs should be resolved in 194 favor of this document. 196 For all transaction SIG(0)s, the signer field MUST be a name of the 197 originating host and there MUST be a KEY RR at that name with the 198 public key corresponding to the private key used to calculate the 199 signature. (The host domain name used may be the inverse IP address 200 mapping name for an IP address of the host if the relevant KEY is 201 stored there.) 203 For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are 204 meaningless. The TTL fields SHOULD be zero and the CLASS field 205 SHOULD be ANY. To conserve space, the owner name SHOULD be root (a 206 single zero octet). When SIG(0) authentication on a response is 207 desired, that SIG RR MUST be considered the highest priority of any 208 additional information for inclusion in the response. If the SIG(0) 209 RR cannot be added without causing the message to be truncated, the 210 server MUST alter the response so that a SIG(0) can be included. 211 This response consists of only the question and a SIG(0) record, and 212 has the TC bit set and RCODE 0 (NOERROR). The client should at this 213 point retry the request using TCP. 215 3.1 Calculating Request and Transaction SIGs 217 A DNS request may be optionally signed by including one SIG(0)s at 218 the end of the query additional information section. Such a SIG is 219 identified by having a "type covered" field of zero. It signs the 220 preceding DNS request message including DNS header but not including 221 the UDP/IP header and before the request RR counts have been adjusted 222 for the inclusions of the request SIG(0). 224 It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of 225 (1) the SIG's RDATA section entirely omitting (not just zeroing) the 226 signature subfield itself, (2) the DNS query messages, including DNS 227 header, but not the UDP/IP header and before the reply RR counts have 228 been adjusted for the inclusion of the SIG(0). That is 230 data = RDATA | request - SIG(0) 232 where "|" is concatenation and RDATA is the RDATA of the SIG(0) being 233 calculated less the signature itself. 235 Similarly, a SIG(0) can be used to secure a response and the request 236 that produced it. Such transaction signatures are calculated by 237 using a "data" of (1) the SIG's RDATA section omitting the signature 238 itself, (2) the entire DNS query message that produced this response, 239 including the query's DNS header but not its UDP/IP header, and (3) 240 the entire DNS response message, including DNS header but not the 241 UDP/IP header and before the response RR counts have been adjusted 242 for the inclusion of the SIG(0). 244 That is 246 data = RDATA | full query | response - SIG(0) 248 where "|" is concatenation and RDATA is the RDATA of the SIG(0) being 249 calculated less the signature itself. 251 Verification of a response SIG(0) (which is signed by the server host 252 key, not the zone key) by the requesting resolver shows that the 253 query and response were not tampered with in transit, that the 254 response corresponds to the intended query, and that the response 255 comes from the queried server. 257 In the case of a DNS message via TCP, a SIG(0) on the first data 258 packet is calculated with "data" as above and for each subsequent 259 packet, it is calculated as follows: 261 data = RDATA | DNS payload - SIG(0) | previous packet 263 where "|" is concatenations, RDATA is as above, and previous packet 264 is the previous DNS payload including DNS header and the SIG(0) but 265 not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an 266 alternative, TSIG may be used after, if necessary, setting up a key 267 with TKEY [draft-ietf-dnsext-tkey-*.txt]. 269 Except where needed to authenticate an update, TKEY, or similar 270 privileged request, servers are not required to check a request 271 SIG(0). 273 Note: requests and responses can either have a single TSIG or one 274 SIG(0) but not both a TSIG and a SIG(0). 276 3.2 Processing Responses and SIG(0) RRs 278 If a SIG RR is at the end of the additional information section of a 279 response and has a type covered of zero, it is a transaction 280 signature covering the response and the query that produced the 281 response. For TKEY responses, it MUST be checked and the message 282 rejected if the checks fail unless otherwise specified for the TKEY 283 mode in use. For all other responses, it MAY be checked and the 284 message rejected if the checks fail. 286 If a response's SIG(0) check succeed, such a transaction 287 authentication SIG does NOT directly authenticate the validity any 288 data-RRs in the message. However, it authenticates that they were 289 sent by the queried server and have not been diddled. (Only a proper 290 SIG(0) RR signed by the zone or a key tracing its authority to the 291 zone or to static resolver configuration can directly authenticate 292 data-RRs, depending on resolver policy.) If a resolver or server does 293 not implement transaction and/or request SIGs, it MUST ignore them 294 without error where they are optional and treat them as failing where 295 they are required. 297 3.3 SIG(0) Lifetime and Expiration 299 The inception and expiration times in SIG(0)s are for the purpose of 300 resisting replay attacks. They should be set to form a time bracket 301 such that messages outside that bracket can be ignored. In IP 302 networks, this time bracket should not normally extend further than 5 303 minutes into the past and 5 minutes into the future. 305 4. Security Considerations 307 No additional considerations beyond those in [RFC 2535]. 309 The inclusion of the SIG(0) inception and expiration time under the 310 signature improves resistance to replay attacks. 312 5. IANA Considerations 314 No new parameters are created or parameter values assigned by this 315 document. 317 References 319 [RFC 1982] - Robert Elz, Randy Bush, "Serial Number Arithmetic", 320 09/03/1996. 322 [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate 323 Requirement Levels", March 1997. 325 [RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic 326 Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. 328 [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", 329 March 1999. 331 [draft-ietf-dnsext-tsig-*.txt] - P. Vixie, O. Gudmundsson, D. 332 Eastlake, B. Wellington, "Secret Key Transaction Signatures for DNS 333 (TSIG)". 335 [draft-ietf-dnsext-tkey-*.txt] - D. Eastlake, "Secret Key 336 Establishment for DNS (RR)". 338 Author's Address 340 Donald E. Eastlake 3rd 341 Motorola 342 140 Forest Avenue 343 Hudson, MA 01749 USA 345 Telephone: +1-978-562-2827(h) 346 +1-508-261-5434(w) 347 fax: +1 978-567-7941(h) 348 +1-508-261-4447(w) 349 email: Donald.Eastlake@motorola.com 351 Expiration and File Name 353 This draft expires December 2000. 355 Its file name is draft-ietf-dnsext-sig-zero-02.txt. 357 Appendix: SIG(0) Changes from RFC 2535 359 Add explanatory text concerning the differences between TSIG and 360 SIG(0). 362 Change the data over which SIG(0) is calculated to include the SIG(0) 363 RDATA other than the signature itself so as to secure the signature 364 inception and expiration times and resist replay attacks. Specify 365 SIG(0) for TCP. 367 Add discussion of appropriate inception and expiration times for 368 SIG(0). 370 Add wording to indicate that either a TSIG or one or more SIG(0)s may 371 be present but not both. 373 Reword some areas for clarity.